NemoPS » tabs

Product page tabs like 1.5 on Prestashop 1.6

Nemo — Wed, 15 Jul 2015 09:15:34 +0000

Have you been missing the traditional product page tabs in the new Prestashop 1.6 Template? If so, see how to easily take them back.

Let’s get some Prestashop 1.5 template code

To start off, get some 1.5 template code and drop it into our 1.6. I chose 1.5.6.2 as it’s the latest 1.5 so far. This is how it looks like, you can simply copy/paste it:

{if (isset($product) && $product->description) || (isset($features) && $features) || (isset($accessories) && $accessories) || (isset($HOOK_PRODUCT_TAB) && $HOOK_PRODUCT_TAB) || (isset($attachments) && $attachments) || isset($product) && $product->customizable}

	
		{if $product->description}{l s='More info'}{/if}
		{if $features}{l s='Data sheet'}{/if}
		{if $attachments}{l s='Download'}{/if}
		{if isset($accessories) AND $accessories}{l s='Accessories'}{/if}
		{if isset($product) && $product->customizable}{l s='Product customization'}{/if}
		{$HOOK_PRODUCT_TAB}
	
	
	{if isset($product) && $product->description}
		
		{$product->description}
	{/if}
	{if isset($features) && $features}
		
		
		{foreach from=$features item=feature}
            {if isset($feature.value)}
			    {$feature.name|escape:'htmlall':'UTF-8'} {$feature.value|escape:'htmlall':'UTF-8'}
            {/if}
		{/foreach}
		
	{/if}
	{if isset($attachments) && $attachments}
		
		{foreach from=$attachments item=attachment}
			{$attachment.name|escape:'htmlall':'UTF-8'}
{$attachment.description|escape:'htmlall':'UTF-8'}
		{/foreach}
		
	{/if}
	{if isset($accessories) AND $accessories}
		
		
			
				
					
					{foreach from=$accessories item=accessory name=accessories_list}
						{if ($accessory.allow_oosp || $accessory.quantity_all_versions > 0 || $accessory.quantity > 0) AND $accessory.available_for_order AND !isset($restricted_country_mode)}
							{assign var='accessoryLink' value=$link->getProductLink($accessory.id_product, $accessory.link_rewrite, $accessory.category)}
							
								
									{$accessory.name|escape:'htmlall':'UTF-8'}
									{if $accessory.show_price AND !isset($restricted_country_mode) AND !$PS_CATALOG_MODE} - {if $priceDisplay != 1}{displayWtPrice p=$accessory.price}{else}{displayWtPrice p=$accessory.price_tax_exc}{/if}{/if}
								
								
									getImageLink($accessory.link_rewrite, $accessory.id_image, 'medium_default')|escape:'html'}" alt="{$accessory.legend|escape:'htmlall':'UTF-8'}" width="{$mediumSize.width}" height="{$mediumSize.height}" />
									
										{$accessory.description_short|strip_tags|truncate:400:'...'}
									
									 
								
								
								
									{l s='View'}
									{if !$PS_CATALOG_MODE && ($accessory.allow_oosp || $accessory.quantity > 0)}
									{l s='Add to cart'}
									{/if}
								
								
							
						{/if}
					{/foreach}
					
				
			
		
	{/if}

	
	{if isset($product) && $product->customizable}
		
			
				
					{l s='After saving your customized product, remember to add it to your cart.'}
					{if $product->uploadable_files}
{l s='Allowed file formats are: GIF, JPG, PNG'}{/if}
				
				{if $product->uploadable_files|intval}
				
					{l s='Pictures'}
					
						{counter start=0 assign='customizationField'}
						{foreach from=$customizationFields item='field' name='customizationFields'}
							{if $field.type == 0}
								{assign var='key' value='pictures_'|cat:$product->id|cat:'_'|cat:$field.id_customization_field}
									{if isset($pictures.$key)}
									
										
										
											
										
									
									{/if}
									
										{if !empty($field.name)}{$field.name}{else}{l s='Please select an image file from your computer'}{/if}{if $field.required}^*{/if}
										
									
								
								{counter}
							{/if}
						{/foreach}
					
				
				{/if}
				{if $product->text_fields|intval}
				
					{l s='Text'}
					
					{counter start=0 assign='customizationField'}
					{foreach from=$customizationFields item='field' name='customizationFields'}
						{if $field.type == 1}
						
							{assign var='key' value='textFields_'|cat:$product->id|cat:'_'|cat:$field.id_customization_field} {if !empty($field.name)}{$field.name}{/if}{if $field.required}^*{/if}
							{if isset($textFields.$key)}{$textFields.$key|stripslashes}{/if}
						
						{counter}
						{/if}
					{/foreach}
					
				
				{/if}
				
					
					
					
					
				
			
			^* {l s='required fields'}
		
	{/if}

	{if isset($HOOK_PRODUCT_TAB_CONTENT) && $HOOK_PRODUCT_TAB_CONTENT}{$HOOK_PRODUCT_TAB_CONTENT}{/if}
	

{/if}

Copy the previous code. Then, open up product.tpl, which you can find in the theme’s folder, and locate this line:

{if isset($features) && $features}

Right before that, paste in the 1.5 template code. We will need to make minor adjustments to it, but before diving deep into coding, let’s comment out the 1.6 code.
Comment out everything from here:

{if isset($features) && $features}

To right before

{if isset($HOOK_PRODUCT_FOOTER) && $HOOK_PRODUCT_FOOTER}{$HOOK_PRODUCT_FOOTER}{/if}

The result should be as follows:

		{*if isset($features) && $features}
			
			
				{l s='Data sheet'}
				
					{foreach from=$features item=feature}
					
						{if isset($feature.value)}
						
						{/if}
					
					{/foreach}
				{$feature.name|escape:'html':'UTF-8'}
						{$feature.value|escape:'html':'UTF-8'}
			
			


// WHOLE CODE BLOCK HERE...



					
				
			
			
		{/if*}
		{if isset($HOOK_PRODUCT_FOOTER) && $HOOK_PRODUCT_FOOTER}{$HOOK_PRODUCT_FOOTER}{/if}

{$feature.name\|escape:'html':'UTF-8'}	{$feature.value\|escape:'html':'UTF-8'}

With the whole block commented out. Then, comment out what comes after the product footer hook as well


		{*if (isset($product) && $product->description) || (isset($features) && $features) || (isset($accessories) && $accessories) || (isset($HOOK_PRODUCT_TAB) && $HOOK_PRODUCT_TAB) || (isset($attachments) && $attachments) || isset($product) && $product->customizable}
			{if isset($attachments) && $attachments}
	

		// WHOLE CODE BLOCK HERE...

				^* {l s='required fields'}
			
			
			{/if}
		{/if*}

Pay extra attention to this step, there are a bunch of IF statements at the end of the block, which might cause a bad error if not commented out in the right place.

Adapting the code

At this point, we need to adapt a couple of sections, to make sure they are compatible with 1.6. We will simply examine each section and replace the content with its newer counterpart when needed.

The first block is the product description, and there is really nothing to change here, as it’s the same across the two templates.

Features (data sheet) is another one that can be left as it is.

THe following one would be attachments, looking like this in the 1.5 snippet:

{foreach from=$attachments item=attachment}
	{$attachment.name|escape:'htmlall':'UTF-8'}
{$attachment.description|escape:'htmlall':'UTF-8'}
{/foreach}

Let’s compare it to the 1.6 version:

{foreach from=$attachments item=attachment name=attachements}
	{if $smarty.foreach.attachements.iteration %3 == 1}{/if}
		
			{$attachment.name|escape:'html':'UTF-8'}
			{$attachment.description|escape:'html':'UTF-8'}
			
				
				{l s="Download"} ({Tools::formatBytes($attachment.file_size, 2)})
			
			
		
	{if $smarty.foreach.attachements.iteration %3 == 0 || $smarty.foreach.attachements.last}{/if}
{/foreach}

Replacing it sounds like a good idea, so go ahead and do it. Simply paste over everything inside the foreach (make sure you also add the name=attachments part!).

Accessories is another one we need to replace, so delete everything within the condition:

	{if isset($accessories) AND $accessories}
		
		

			// Delete everything inside
		
	{/if}

Still making sure to retain the #idTab4 div

The last block of the 1.5 template concerns customizable data, and it’s better to replace the whole content here as well. Therefore, once more:

{if isset($product) && $product->customizable}
	
		// Delete everything inside

	
{/if}

Remove everything inside that div with idTab10 as ID.

We should be done…almost! There is a leftover of the 1.6 section, Pack Items, which used to be elsewhere in 1.5. If you don’t want it to be part of tabbed data, you can simply uncomment the section as it is. Otherwise, read on.

Dealing with the Pack Items block

We cannot simply copy and paste the pack items block, as that would result in a div having no parent link to call it among tabs. The first thing we therefore have to do is add a link pointing to it, in the tabs navigation bar:

	
		{if $product->description}{l s='More info'}{/if}
		{if $features}{l s='Data sheet'}{/if}
		{if $attachments}{l s='Download'}{/if}
		{if isset($accessories) AND $accessories}{l s='Accessories'}{/if}
		{if isset($product) && $product->customizable}{l s='Product customization'}{/if}
		{if isset($packItems) && $packItems|@count > 0}{l s='Pack Items'}{/if}
		{$HOOK_PRODUCT_TAB}

As you can see, I added a whole new line to handle the pack tab, which is referencing to a (still non existing) div with the id #blockpack. You can really choose any ID you want here, just making sure it matches in the following step.

Let’s not scroll back after the customization block:

	{/if}

	{if isset($HOOK_PRODUCT_TAB_CONTENT) && $HOOK_PRODUCT_TAB_CONTENT}{$HOOK_PRODUCT_TAB_CONTENT}{/if}

Right before {if isset($HOOK_… } but after that closing {/if} (which was the customization condition), so in that only one empty line, add the following:

	{if isset($packItems) && $packItems|@count > 0}
		
			{include file="$tpl_dir./product-list.tpl" products=$packItems}
		
	{/if}

Here is how it should look

{/if}
{if isset($packItems) && $packItems|@count > 0}
	
		{include file="$tpl_dir./product-list.tpl" products=$packItems}
	
{/if}
{if isset($HOOK_PRODUCT_TAB_CONTENT) && $HOOK_PRODUCT_TAB_CONTENT}{$HOOK_PRODUCT_TAB_CONTENT}{/if}

You can now breathe. The worst part is done. Save and refresh, you should have a working tabs system, even if navigation links are stack one on top of the other. Let’s give it some style!

Styling Tabs in the Product page

There is not much to do at this point. Open up product.css, located in the theme folder, css/, and paste in the following


#more_info_tabs li {
  float:left;

}

#more_info_tabs li a {
  padding: 0 20px;
  color:white;
  line-height: 40px;
  height: 40px;
  display:block;
  background: #555;
}

#more_info_tabs li a:active {text-decoration:none;}
#more_info_tabs li a.selected {
  background:black;
  text-decoration:none;
}

I gave it some generic styling to have them look like tabs, so feel free to expand over the tutorial and make it prettier! We’re done!

The post Product page tabs like 1.5 on Prestashop 1.6 appeared first on NemoPS.

How to create new homepage tabs in Prestashop 1.6

Nemo — Tue, 23 Sep 2014 12:32:51 +0000

In this quick tip we will see how easy it is to create new tabs for the homepage in Prestashop 1.6, by simply enabling two hooks in a module.

The basics

First, we need a skeleton. That is, a basic module to work with. You can choose an existing one, or follow along in creating a simple new module for this sole purpose. In the first case, you can jump directly to the next section.

We will not extensively see how to create a Prestashop Module from scratch; therefore, if you need more information about the topic you can have a look at the official Prestashop documentation on creating a Prestashop Module.

That said, let’s create the module’s folder. Inside modules/, create one named pshometabs (or whatever name you prefer, as long as you remind it later on). Then, inside it, create a file named phometabs.php. We will not add any icon to the module, as it’s only meant to demonstrate the procedure. Open up the file and paste the following after an opening php tag:



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

class psHomeTabs extends Module
{
	
	public function __construct()
	{
		$this->name = 'pshometabs';
		$this->tab = 'front_office_features';
		$this->version = '1.0';
		$this->author = 'Nemo';
		$this->need_instance = 0;

	 	parent::__construct();

		$this->displayName = $this->l('PS new homepage tabs');
		$this->description = $this->l('Adds a new block to the homepage tabs.');
		$this->confirmUninstall = $this->l('Are you sure you want to delete this module?');
	}
	
	public function install()
	{
		if (!parent::install())
			return false;
		return true;
	}
	
}

And these are only the barebones of a Prestashop Module. It’s not doing anything of course, so let’s register some hooks for the home tabs.

Registering hooks for the home tabs

First off, we need to support both of the hooks needed for home tabs. They are two, because one displays the label (e.g. Top sellers) and the other the content. Therefore, add the following content to the module’s class:

	public function hookDisplayHomeTab($params)
	{
		return $this->display(__FILE__, 'tab.tpl');
	}

	public function hookDisplayHomeTabContent($params)
	{
		return $this->display(__FILE__, 'tab_content.tpl');
	}

We could as well be done with php and focus on templating now, but to make our life easier (instead of having to manually register hooks from Modules -> Positions in the back office), let’s do it in the install() method:

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

Save, login to the back office and test if the module is correctly installing. If it is, move on to creating template files.

Creating the hooks template files

At this point, we need to display something. But what? Indeed, we need to know what displays where, and if you didn’t guess it already by the name, hookDisplayHomeTab is for the label, while hookDisplayHomeTabContent is, needless to say, for the content. Therefore, we need to write the proper label code within the tab.tpl file, and content inside tab_content.tpl. Of course, these files can have other names as well, as long as everything is consistent.

Create the following folder structure inside the module’s folder: views/templates/hook/. Inside this last one, start by adding the file named tab.tpl, and open it, pasting the following inside

{l s='New Tab' mod='pshometabs'}

Please notice the content needs to have this exact structure if you use the default Prestashop 1.6 template. So you need it to contain a list item, and an anchor tag with the data-toggle attribute, as well as href pointing to the id of the content (which we don’t have yet). Again, names are extremely important at this stage, make sure there are no duplicates or things won’t work properly.

Lastly, create tab_content and paste the following:


	
		{l s='This is a test message.' mod='pshometabs'}

Once more, to be consistent with the default theme, use an ul element with the related id used in the tab part. Make sure it has tab-pane as class, at least. And of course, an li as child, which can contain virtually anything you want.

Save and refresh, if you did everything correctly, after installing it the new tab will appear in the homepage:

Side notes on the template files

The previous code is meant to work with the default Prestashop 1.6 template. If you use a custom one, I strongly advise you to check how modules hooked to the homepage tabs are buil in the theme folder, modules (e.g. homefeatured). Then, mimic the same structure for the tab and tab content templates.

The post How to create new homepage tabs in Prestashop 1.6 appeared first on NemoPS.

Adding new tabs and fields to Prestashop products’ back office

Nemo — Wed, 11 Sep 2013 14:02:38 +0000

It is easy enough to modify Prestashop’s products’ back office and add new fields by editing the AdminProductsController. However, by using a module and a new tab, it becomes much more maintainable!

Download Project Files

Prestashop back office hooks

Although we will go through the basics of setting up a module, this tutorial assumes you already know how to create one from scratch. If you are totally new to Prestashop, I strongly recommend that you read the Official documentation on how to create a Prestashop Module before approaching this tutorial.

Now, in order to add new fields to Prestashop’s products’ back office, it is essential to be aware of the hooks that can be used to perform various operations in the admin panel. Specifically, we will be using the following ones:

DisplayAdminProductsExtra: this hook adds new tabs to the product’s back office interface, thus, we will use this hook to plug in our new content’s input field with translations

ActionAdminControllerSetMedia: if we ever need to style our new tab, or add custom javascript functions, this is the ideal hook to use to plug css and js files. This is called for every Prestashop Admin page, thus we will need to prevent it from running in pages that are not the product’s configuration.

ActionProductUpdate: the new field needs to be saved in the database. Specifically, we will add a new column (custom_field) to the product_lang table and add a new translatable field, without using overrides at all. By plugging code snippets into this hook, we can easily update the column when the product itself is updated.

At this point, we can line out our plan of action: after giving the module a basic setup, we will first create the template file that will display the new field’s input box on its own table. Then, we will see how to overcome a little issue with translatable fields, using the ActionAdminControllerSetMedia hook, and lastly, on data submission, we will update the new custom field once the product is updated. We will create a new field for demonstrational purposes only, but feel free to dare beyond the limits of this tutorial if you want!

Setting up the module

First of all, let’s start with a simple module template. You can download the blank module folder from the link at the beginning of the article. Drop the newfieldstut folder (the one from the “Start here” archive!) in the modules/ folder of your Prestashop Root. Then open up newfieldstut.php and start by adding some regular module’s code.

name = 'newfieldstut';
		$this->tab = 'front_office_features';
		$this->version = '1.0';
		$this->author = 'Nemo';
		$this->need_instance = 0;

	 	parent::__construct();

		$this->displayName = $this->l('New Fields Tutorial');
		$this->description = $this->l('Test module from Nemo\'s Post Scriptum Tutorial (nemops.com).');
	}
		
}
?>

Now that the basic structure is laid out, we want to specify the install and uninstall functions. Let’s add a new column to product_lang with an ALTER TABLE, and provide a way to remove it if this module is uninstalled:


	public function install()
	{
		if (!parent::install() OR
			!$this->alterTable('add') OR			
			!$this->registerHook('actionAdminControllerSetMedia') OR
			!$this->registerHook('actionProductUpdate') OR
			!$this->registerHook('displayAdminProductsExtra'))
			return false;
		return true;
	}
	
	public function uninstall()
	{
		if (!parent::uninstall() OR !$this->alterTable('remove'))
			return false;
		return true;
	}


	public function alterTable($method)
	{
		switch ($method) {
			case 'add':
				$sql = 'ALTER TABLE ' . _DB_PREFIX_ . 'product_lang ADD `custom_field` TEXT NOT NULL';
				break;
			
			case 'remove':
				$sql = 'ALTER TABLE ' . _DB_PREFIX_ . 'product_lang DROP COLUMN `custom_field`';
				break;
		}
		
		if(!Db::getInstance()->Execute($sql))
			return false;
		return true;
	}

Explanation: A couple of things here! First, in the install method, we

1- As with every module, call the parent’s install method
2- Alter the product_lang table, to add the new field
3- Register all the hooks we will use

Notice how I decided to structure the alterTable method. To avoid creating two functions, I stacked together the drop and add statements, passing a $method variable to determine what the function should do. Therefore, we call alterTable with ‘add’ when installing, and ‘remove’ when uninstalling.

Now, just to be sure we did everything correctly without errors, let’s try installing the module! Reach the Modules page in the back office and look for New Fields Tutorial in the modules list, as shown below.

Click install, and see if it works. If it does, move on to the next step!

Creating a new tab in the Product Back Office (DisplayAdminProductsExtra)

Okay, our module is installed, and the hooks have been registered as well. Time to test it out! Add the following function to your module:

	public function hookDisplayAdminProductsExtra($params)
	{
		if (Validate::isLoadedObject($product = new Product((int)Tools::getValue('id_product'))))
		{

			return $this->display(__FILE__, 'newfieldstut.tpl');
		}
	}

Explanation: first, we make sure the current product object is correctly loaded; if so we display the content of the module’s tpl file. Reach a product’s back office page; you should see something like this, by clicking on the new tab:

At this point, we can start filling in the tpl file. Open up newfieldstut.tpl, get rid of the placeholder text and add the following instead:


{l s='New Fields Tutorial' mod='newfieldstut'}


	
		
			{l s='Our New Field:'}
		
		
			{include file="controllers/products/input_text_lang.tpl"
				languages=$languages
				input_name='custom_field'
				input_value=$custom_field}
			{l s='Simply a new custom field'}. {l s='ie: something here as a hint'}

Do not test this out yet! It will not work. Why? Let’s have a look at what we just did: first, we setup a simple table structure imitating the one Prestashop uses by default in the Product configuration page. Then, inside the rightmost table cell (td), we include a template file Prestashop kindly provides. This file is input_text_lang.tpl, and it is located in the admin theme folder, inside the controller section for products. What it does, is it provides a standardized way to add new translatable fields without having to mess with foreach loops in our own code. We can assign the currently available languages, name of the new input field and its value.

However, if we were to refresh the page now, and turn on error reporting, this is what we would see:

This happens because we have not assigned any of those 2 variables we mention in the code: $languages and $custom_field. Let’s take care of this.

Back to newfieldstut.php, create a new method as follows:


	public function prepareNewTab()
	{

		$this->context->smarty->assign(array(
			'custom_field' => '',
			'languages' => $this->context->controller->_languages,
			'default_language' => (int)Configuration::get('PS_LANG_DEFAULT')
		));

	}

For the time being, we will not bother adding a real value to the new field. As for the other 2 variables, we get the currently available languages by the controller itself, and the default language for our store.

At this point, amend hookDisplayAdminProductsExtra as follows:

	public function hookDisplayAdminProductsExtra($params)
	{
		if (Validate::isLoadedObject($product = new Product((int)Tools::getValue('id_product'))))
		{
			$this->prepareNewTab();
			return $this->display(__FILE__, 'newfieldstut.tpl');
		}
	}

The new tab is ready! ….BUT! Hey, watch closely at what happens if you wait a couple of seconds before accessing it, or click its label right after the page reloads!

The language flags pops out after a while, or does not appear at all!

This is (I believe) yet another Prestashop bug. If we want our new translatable field to work correctly every time, we absolutely need to take this bug off. How to?

Properly enabling multilanguage fields in the product Back Office

What on earth is going on here? Basically, Prestashop loads the language translations flags using javascript. Not only this, but it also loads each tab asynchronously with Ajax, and ‘forgets’ to call the function which assigns those flags for custom tabs. This is where the ActionAdminControllerSetMedia hook becomes useful! We will plug in a new javascript file to take it into account, so that flags are assigned to our new tab as well.

First off, open up newfieldstut.js, which you can find in the project’s module folder you already know. Here is how it will look:

$(document).ready(function() {

});

Nothing but a simple jQuery ready statement. Inside, add the following


	$("#product-tab-content-ModuleNewfieldstut").on('loaded', function(){
			displayFlags(languages, id_language, allowEmployeeFormLang);
	})

And that’s it, really. A few notes though: Notice the ID we are checking the load status for. This will vary depending on the name you give your module, and you can check it by inspecting the tab element with the browser’s developer tools:

Just bear in mind you have to point the right ID, nothing else.

Now, back to newfieldstut.php once more. Add the following method:

	public function hookActionAdminControllerSetMedia($params)
	{

		// add necessary javascript to products back office
		if($this->context->controller->controller_name == 'AdminProducts' && Tools::getValue('id_product'))
		{
			$this->context->controller->addJS($this->_path.'/js/newfieldstut.js');
		}

	}

Explanation: As we saw at the beginning of the article, this hook runs for every page of the back office. Thus, we need to be sure we are embedding our javascript for the single product configuration page only. Therefore, we first check the the current controller is AdminProducts, then, to be sure we are not viewing the products list, we also make sure a product id is set in the current url. After performing these checks, we simply use a regular addJS to embed the code.

Save & refresh, at this point the language flags are always added to the new tab!

Saving and retrieving the new value

Everything is in place, but we are not doing anything now. We are not displaying the new field value, nor are we able to save its content!

First off, let’s save the value for each language inside the database. Append the following method to our beloved newfieldstut.php:


	public function hookActionProductUpdate($params)
	{
		// get all languages
		// for each of them, store the new field

		$id_product = (int)Tools::getValue('id_product');

		$languages = Language::getLanguages(true);
		foreach ($languages as $lang) {
			if(!Db::getInstance()->update('product_lang', array('custom_field'=> pSQL(Tools::getValue('custom_field_'.$lang['id_lang']))) ,'id_lang = ' . $lang['id_lang'] .' AND id_product = ' .$id_product ))
				$this->context->controller->_errors[] = Tools::displayError('Error: ').mysql_error();
		}

	}

Explanation: the hook we are targeting here(ActionProductUpdate) runs at the very same time a product’s data is stored inside the database. The perfect time to add our new content! First, we retrieve the current product ID, and then get all the currently active languages. For each of the languages, we update the database field for the matching language and product id. If the update operation cannot be completed, we spawn an error using the default Prestashop error handler for Admin tabs.

A small note on Tools::getValue(‘custom_field_’.$lang[‘id_lang’]): if you remember, we called our new field ‘custom_field’ when embedding the translatable input box. This means Prestashop generates one field, appending each language id, for each language. Thus, we end up having custom_field_1, custom_field_2 etc… Where the number after the second underscore represents the language ID. That’s why we are targeting it like this ‘custom_field_’.$lang[‘id_lang’], to be sure each language is correctly added.

Now, let’s try inputting different values for each languages, and hit ‘Save and stay’. Then, since we are not yet retrieving the field, let’s check it out in the database.

Okay, it’s done! At this point, we only need to retrieve those values! Let’s add a new method to our friend newfieldstut.php:


	public function getCustomField($id_product)
	{
		$result = Db::getInstance()->ExecuteS('SELECT custom_field, id_lang FROM '._DB_PREFIX_.'product_lang WHERE id_product = ' . (int)$id_product);
		if(!$result)
			return array();

		foreach ($result as $field) {
			$fields[$field['id_lang']] = $field['custom_field'];
		}

		return $fields;
	}

Explanation: Quite simply, using the product id as source data, we retrieve all entries for the custom_field column. Then, we format it for an array whose keys are language ids, and values the custom field value for that specific language. This is how Prestashop will be able to use them in the template: array(‘5′ => ‘value for id_lang 5), …’).

Of course, as a last step we call this function when assigning variables in prepareNewTab:


	public function prepareNewTab()
	{

		$this->context->smarty->assign(array(
			'custom_field' => $this->getCustomField((int)Tools::getValue('id_product')),
			'languages' => $this->context->controller->_languages,
			'default_language' => (int)Configuration::get('PS_LANG_DEFAULT')
		));

	}

And we are finished!

Conclusion

As you could see, adding new fields to products using modules, without any remote sign of overrides, is not as complex as it might seem. Moreover, it’s a much more maintainable practice than messing with the original back office templates and controllers! Of course, at this point, you can take this tutorial further and add front office hooks to display your new, translatable field!

Additional Resources

Official documentation on how to create a Prestashop Module

The post Adding new tabs and fields to Prestashop products’ back office appeared first on NemoPS.