Smarty and box. template files

[zombiesbyte]

Hi

I've not had too much experience with smarty templating engine before so this is probably a noob question.

I want to use main.php to pull in the content.homepage.php template (which it does) but then...

within content.homepage.php use smarty includes to pull in box.banner.php and within box.banner.php again use smarty to include box.featured.php.

From what I've read on the web nested includes work fine but the variables don't seem to be set i.e. $featured

Any tips on what I could be missing?

 

This works: main.php -> {include file='templates/box.banner.php'} -> {include file='templates/box.featured.php'}

This doesn't work: main.php -> {$PAGE_CONTENT} (which uses content.homepage.php) -> {include file='templates/box.banner.php'} -> {include file='templates/box.featured.php'}

I'm presuming it has to do with the $PAGE_CONTENT (constant? What's with the uppercase anyway?) being polluted in a non-smarty way

 

If {$PAGE_CONTENT} variable is relevant to the page you're on then I presume this is switched out for a standard smarty {include file='the.page.name.php'} but I'm unsure as it happens at run time.

[bsmither]

I will re-read your post shortly to get more out of it, but this factoid may be relevant:

The content.homepage.php (assigned to $PAGE_CONTENT, as well as any other "main content area" template such as product, category, and document pages) is developed/rendered first. Then the sidepanels, header, and footer areas are developed/rendered. Meaning, data intended for the secondary areas are not yet known to the primary area.

Finally, main.php is developed/rendered.

I am pushing for CC to code the CC6.1 family to develop and populate all template variables prior to rendering any template.

 

[zombiesbyte]

Thanks bsmither,
 

That explanation makes sense, the logic of what happens doesn't

I may need to start digging for ways to change this in the controller as you're right, everything should go through the controller and flood out down the chain of templating rather than it being picky. I don't know what implication it has on performance but by the nature of the templates they should be able to address their variables at any point they are rendered since the view is last.

Hmm, 6.1 makes me nervous as I'm just starting to get things shaped the way I want. It might be better asking this on a new thread but I've changed a few bits in the core files and not really sure how to manage these changes when upgrading/updating CC in the future. You sound like you probably pimped your ride too and wondered how you kept tabs on all of your customisations/improvements that couldn't be wrapped up in some kind of plugin/hook thingy (sorry, still working on understanding hooks).

Cheers

James

 

[zombiesbyte]

Ok, managed to hack a bit to get it to work

 

line 1081 gui.class.php
	/**
	 * Display random products box
	 */

	public function displayRandomProduct($p=0)
	{
		return $this->_displayRandomProduct($p);
	}

	private function _displayRandomProduct($p=0) {
	
	...
	
	}
	

Added a public method that calls the original private method (I didn't want to change anything so this is a passive solution).

Then I added this to the smarty document scope by assigning it to the global

Line 79: cubecart.class.php
	/**
	 * Show the home page
	 */
	public function displayHomePage() {
		
	...

		$GLOBALS['smarty']->assign('LATEST_PRODUCTS', $products);
		$GLOBALS['smarty']->assign('RANDOM_FEATURED', $GLOBALS['gui']->displayRandomProduct() );
	
	...

	}

I don't actually use the template variable $RANDOM_FEATURED as it is enough just to append the rendered data to the smarty global for it to work.

I'm still not exactly sure how these smarty templating engine works but I think I understand kind of what is going on here. It works anyway so it's a win.

 

Just to clarify what I've done here's the 4 files in question

main.php

{include file='templates/box.errors.php'}
{include file='templates/box.progress.php'}
{$PAGE_CONTENT} //<- this pulls in content.homepage.php
{include file='templates/box.home_ad_grp.php'}
{include file='templates/box.popular.php'}

content.homepage.php

{include file='templates/box.banner.php'} //<- this pulls in box.banner.php
{include file='templates/box.latest.php'}

box.banner.php

{include file='templates/box.featured.php'} //<- this pulls in box.featured.php

box.featured.php

{if $featured}

//... <- this now has information (previously it did not)

{/if}

 

Edited August 29, 2016 by zombiesbyte
little code formatting

[bsandall]

At the risk of sounding like a broken record... if you are making edits to the core code, you really ought to be using some form of version control such as Git. It has a fairly steep learning curve, but once you get the hang of it, maintaining and updating your custom version of CubeCart becomes so much more manageable. If you ever get stuck, you can usually find the answer to your question on StackOverflow (easiest via Google).

If you are not comfortable with the command line interface right away, no problem - there are graphical interfaces such as SourceTree, GitHub for Windows, and others. You can even host your Git repository online for free with GitHub or BitBucket, or keep it all local if you don't want your code online.

This all goes hand in hand with using a local server (e.g. WAMP/LAMP) during development so that you're not playing with and breaking your live site.

[zombiesbyte]

Thanks bsandall,

I use bitbucket (and a bit of git) to keep track of other projects so I have a little experience with some parts of the version control although I try to stay clear of complicated development trees (start to look like the London Underground map lol).

I suppose in my mind I had the next round of changes being so far removed from this current version that a version control system would just show too much difference to be of any use. I guess I'm just fearing the lack of control I have and the unknown

Good suggestion, I'll just go for that then

PS: I'm using XAMPP for local development but this will be uploaded and sit on a hosted Linux environment (LAMP).

[bsandall]

Sounds like you're well on your way to success, then. Luckily for us, CubeCart's development tree is pretty linear, but I have well over 20 branches in my fork of it tackling various issues and new features so yes, it can definitely get messy.

You are correct, too, that if the next major version of CC diverges too much from the current codebase, it will be quite a mess to untangle. The best we can hope for in that case is that the changes will be committed incrementally and we can merge them in one or a few at a time. If not, well, at least with Git you can try to reapply your changes onto a fresh copy of the code, and barring that, you have a history of all the changes you made in comparison to the original CC code.

While there are certainly dragons, I find they are of a much less fierce variety than those found in the version-control-less lands.