• Prestashop version: 1.6.0.11 and above

How to (finally) override Prestashop Modules’ core files

Yes, we (at last!) can now override modules’ php files without messing with the core itself. It seems this mod has been around for a few days now, and the prestashop team, of course, didn’t let anyone now. I’d like to thank the Prestashop forum user Razaro who spotted this first.

Enough chitchatting. Let’s see how to override a Prestashop Module’s core. Reach the new override/modules/ folder. For this demonstration we will override the cms block, just to illustrate the purpose. Create a new folder called blockcms, and inside it a file named blockcms.php. Here is how modules overrides work:

<?php

if (!defined('_CAN_LOAD_FILES_'))
	exit;

class BlockCmsOverride extends BlockCms
{


}

The pattern is ModuleNameOverride. So in this case BlockCmsOverride. If we wanted to extend the top menu, it would have been BlockTopMenuOverride, and so on. Pretty easy to remember. Now let’s go ahead and simply add a var dump to make sure it works:

<?php


if (!defined('_CAN_LOAD_FILES_'))
	exit;

class BlockCmsOverride extends BlockCms
{
	public function displayBlockCMS($column)
	{
		var_dump('testing');
		if (!$this->isCached('blockcms.tpl', $this->getCacheId($column)))
		{
			$cms_titles = BlockCMSModel::getCMSTitles($column);

			$this->smarty->assign(array(
				'block' => 1,
				'cms_titles' => $cms_titles,
				'contact_url' => (_PS_VERSION_ >= 1.5) ? 'contact' : 'contact-form'
			));
		}
		return $this->display(__FILE__, 'blockcms.tpl', $this->getCacheId($column));
	}

}

Nothing fancy, it doesn’t do anything but it’s great to understand how the thing works: as with all overrides, you just have to replicate a method’s name to extend or replace it. We can also call the parent if we want, and make things more concise:

<?php


if (!defined('_CAN_LOAD_FILES_'))
	exit;

class BlockCmsOverride extends BlockCms
{
	public function displayBlockCMS($column)
	{
		var_dump('testing');
		parent::displayBlockCMS($column);
	}

}

As simple as that! Think about the possibilities, and the flexibility this gives to theme developers. Of course make sure you clear the class_index./php file located in the cache/ folder before testing it out!

And of course, like normal overrides, we can just create the very same “blockcms” folder in our third party module, so it will be automatically added when installed, again, like classes and controllers overrides.

Last mention

Since this silence towards the community is getting pretty annoying, I hope the Prestashop team will soon try to have more consideration for the user and developers base, informing us when such a new feature is released. Just a small code snippet for them:

if($prestashop - $community)
	die();

The post How to (finally) override Prestashop Modules’ core files appeared first on NemoPS.

Last week, I came across a really useful hook, almost by chance: displayOverrideTemplate. It’s not (of course) mentioned anywhere in the official Prestashop documentation, but it’s fundamental to anyone willing to extend/modify the current template without fearing to lose all these tweaks with the next upgrade.

It’s been around since Prestashop 1.5, given what the calling method states, inside the FrontController.php file:

	/**
	 * Returns the template corresponding to the current page.
	 * By default this method return false but could easily be overridden in a specific controller
	 *
	* @since 1.5
	* @return bool
	*/
	public function getOverrideTemplate()
	{
		return Hook::exec('DisplayOverrideTemplate', array('controller' => $this));
	}

At any rate, enough chit-chatting, it’s time to see the true power of this hook!

Example – Overriding the category page

In this example, we will use a simple module to override the category page. Download the project files above, and then place the ‘psoverridetemplatedemo’ folder in your Prestashop modules/ folder. It’s nothing fancy, it’s just a blank module that does absolutely nothing. We will add something to it right away: locate the install method, and register our fancy hook

	public function install()
	{
		if (!parent::install() ||
			!$this->registerHook('displayOverrideTemplate')
			)
			return false;
		return true;
	}
	

Install it. Then, to test that it really works, let’s add something SO invasive:

	public function hookDisplayOverrideTemplate($params)
	{
		die('here');
		// return dirname(__FILE__).'/views/templates/hook/skeleton.tpl';
	}

This should kill every single page of your store, displaying “here” instead. If not, check the registerHook method.

What should we now return from the hook? Not a template, as you might think, nor we will call smarty’s fetch method. We need to return a path to the template file we want to use. We have one in out module’s root (psoverridetemplatedemo.tpl), so let’s reference it here:

	public function hookDisplayOverrideTemplate($params)
	{
		return dirname(__FILE__).'/psoverridetemplatedemo.tpl';
	}

Save and refresh. Every page of your store should now have the center column blank. Why? Because there is nothing in the template file. Add some garbage test to try it out, and you will see it appearing in every page. Yes, but this is not so useful, how can we replace a specific template? In a previous tutorial on Target specific pages from a Prestashop Module’s Hook, I showed you how to get each page’s specific identifier using the following method:

$this->context->controller->php_self

If you recall the beginning of this article, we saw the Front Controller is passing the current controller object into the hook, which is then available to us for use within our method. The snippet I just mentioned therefore becomes:

$params['controller']->php_self;

Easy as that. Let’s override the category page only, for example:

	public function hookDisplayOverrideTemplate($params)
	{
		if ($params['controller']->php_self == 'category')
			return dirname(__FILE__).'/psoverridetemplatedemo.tpl';
	}

Save and refresh. The only overridden template will now be the category one! Sounds like a good deal. What about other pages? It’s easy enough to inspect each page’s name as follows:

	public function hookDisplayOverrideTemplate($params)
	{
		var_dump($params['controller']->php_self);
		//if ($params['controller']->php_self == 'category')
		//	return dirname(__FILE__).'/psoverridetemplatedemo.tpl';
	}

The page name will be shown at the top. There are some exceptions though.

Some pages simply don’t have any php_self assigned, and that statement would therefore cause trouble. To overcome, it’s enough to make sure it is assigned before comparing it to anything:

	public function hookDisplayOverrideTemplate($params)
	{
		if (isset($params['controller']->php_self) && $params['controller']->php_self == 'category')
			return dirname(__FILE__).'/psoverridetemplatedemo.tpl';
	}

And that’s it, you can target virtually every template for every controller with a page name now!

The post Prestashop: Upgrade-safe template modifications appeared first on NemoPS.