the most important stuff I will only love in prestashop 1.4 is nothing but the very important FrontController.php.

Analysis

At first let’s just take a look at the mode of loading files in prestashop 1.4. If you “new” a class, at first the codes would search for the class file of the same name in controller, and such a way looks pretty much the same as that in the previous version. If the file could not be found there, the codes will then carry on the search in override, this folder that allows classes to be user-defined. If the file still could not be found, the codes will use exec to create a new class of the request-typed name in turn to load the names of those classes under classes plus the core classes. So, for the real FrontController.php, you have to find and get it under classes, also the corresponding name of the class will be FrontControllerCore.

If it is said that the most important stuff is init.php before, then FrontController.php in prestashop 1.4 has taken over all the work previously done by init.php. Moreover it has replaced all the other three files header.php, index.php and footer.php to carry out all of their original work, even including pagination and merchandise ordering. In a few words, just somewhat like the dispatch of zend framework, FrontController.php is a signal to have all the work start off.

	public function run()
	{
		$this->init();
		$this->preProcess();
		$this->setMedia();
		$this->displayHeader();
		$this->process();
		$this->displayContent();
		$this->displayFooter();
	}

Regarding such a style that is so similar to zend, I would doubt that if prestashop’s CTO has already been changed.

		if ($this->ssl AND !(isset($_SERVER['HTTPS']) AND strtolower($_SERVER['HTTPS']) == 'on') AND Configuration::get('PS_SSL_ENABLED'))
		{
			header('HTTP/1.1 301 Moved Permanently');
			header('Location: '.Tools::getShopDomainSsl(true).$_SERVER['REQUEST_URI']);
			exit();
		}

Automatic 301 in function init, the very new function added in prestashop 1.4. Now it looks like that the maindomin module I’ve written before has got totally f**ked up.

$page_name = (preg_match('/^[0-9]/', $page_name)) ? 'page_'.$page_name : $page_name;

The $page_name variable in function init has achieved a judgment in different pages and different modules in a very convenient way. You know in previous versions I still have to make judgments in header.tpl.

		Tools::addCSS(_THEME_CSS_DIR_.'global.css', 'all');
		Tools::addJS(array(_PS_JS_DIR_.'tools.js', _PS_JS_DIR_.'jquery/jquery-1.4.4.min.js', _PS_JS_DIR_.'jquery/jquery.easing.1.3.js'));

All above is from function serMedia. The advantage for doing so is achieving the unified management of both css and js, thereby it is available to do CCC (Combine, Compress and Cache) in prestashop, function productSort and pagination just take over the work previously done by sort and pagination while there is no significant change with respect to other aspects, as the main function is still copied from the past init.php, even the naming of each variable is still global rather than global class in the oriented object.

Customization

In folder override/classes everyone can see a file named _FrontController.php, which is actually an example of user-defined FrontController.php. Now if you delete that underscore in the file name and visit the page again, then you will see the debug information. What has to be noted here is that there are two additional files named mysql and module in the same folder. If some change were applied to FrontController.php only, it would lead to the termination problem due to some error message. Thus it is necessary to change Line 148 in _FrontController.php below:

error_reporting(E_ALL | E_STRICT);

Into:

error_reporting(7);

In regard to“7” above, if someone might not understand what it means, please refer to the relevant parts in the handbook for further study.

In order to customize FrontController.php, just create a new file named FrontController.php under folder override/class, and then write a class named extends FrontControllerCore and then it will be fine. The method can be taken to overlay the one in core directly.

class FrontController extends FrontControllerCore
{
	function setMedia()
	{
		parent::setMedia();
		Tools::addCSS(_THEME_CSS_DIR_.'addition.css');
	}
 
	public function displayFooter()
	{
		global $cookie, $smarty;
		if (!self::$initialized)
			$this->init();
 
		self::$smarty->assign(array(
			'HOOK_RIGHT_COLUMN' => (($smarty->get_template_vars('page_name') == 'category') ? '' : Module::hookExec('rightColumn', array('cart' => self::$cart))),
			'HOOK_FOOTER' => Module::hookExec('footer'),
			'content_only' => (int)(Tools::getValue('content_only'))));
		self::$smarty->display(_PS_THEME_DIR_.'footer.tpl');
		//live edit
		if ($cookie->live_edit AND $ad = Tools::getValue('ad'))
		{
			self::$smarty->assign(array('ad' => $ad, 'live_edit' => true));
			self::$smarty->display(_PS_ALL_THEMES_DIR_.'live_edit.tpl');
		}
		else
			Tools::displayError();
	}
}

In the example above, both methods namely setMedia and displayFooter have been overwritten.

When setMedia is being rewritten, such a method of original FrontController is executed and a new css is also loaded in the original css.

When displayFooter is being rewritten, such a process is actually copying the original codes to here to achieve the rewriting, and the only change can be nothing but just adding a judgment. If pagename were category, then column on the right-hand side would never be outputted so as to make a bigger space for category list.