Watch the screencast

Text Version

This tutorial can be applied to ThirtyBees as well!

Part of the functionality we need is in PrestaShop already, all we have to do is add some place where we can submit the change of department type.
Open up AdminCustomerThreadsController.php located in controllers/admin or use an override instead (recommended). We are interested in the renderView method, specifically where it assigns $this->tpl_vars, around line 700 in PrestaShop 1.6.1.7.

        $this->tpl_view_vars = array(
            'id_customer_thread' => $id_customer_thread,
            'thread' => $thread,
            'actions' => $actions,
            'employees' => $employees,
            'current_employee' => $this->context->employee,
            'messages' => $messages,
            'first_message' => $first_message,
            'contact' => $contact,
            'contacts' => $contacts, // <-- This is what we added!
            'next_thread' => $next_thread,
            'orders' => isset($orders) ? $orders : false,
            'customer' => isset($customer) ? $customer : false,
            'products' => isset($products) ? $products : false,
            'total_ok' => isset($total_ok) ?  Tools::displayPrice($total_ok, $this->context->currency) : false,
            'orders_ok' => isset($orders_ok) ? $orders_ok : false,
            'count_ok' => isset($orders_ok) ? count($orders_ok) : false,
            'PS_CUSTOMER_SERVICE_SIGNATURE' => str_replace('\r\n', "\n", Configuration::get('PS_CUSTOMER_SERVICE_SIGNATURE', (int)$thread->id_lang)),
            'timeline_items' => $timeline_items,
        );

Please note: if you use an override, copy the whole method, add the variable as described above, and make sure you change return parent::renderView() to return AdminController::renderView() at the very end! Failing to do so will make it impossible for our new variable to be used in the template, as the parent class would simply override the tpl_vars.

Now that we have the variable containing all contacts, let’s add a form to submit it, in the view.tpl template of that controller. The file we want is located in the theme folder themes\default\template\controllers\customer_threads\helpers\view. Once more, it’s named view.tpl.
You can find any spot you like for the new button, I added it at the very beginning, before the div with class “well”

	<div class="well">
		<form action="{$link->getAdminLink('AdminCustomerThreads')|escape:'html':'UTF-8'}&amp;viewcustomer_thread&amp;id_customer_thread={$id_customer_thread|intval}" method="post" class="form-horizontal">
			<div class="row">
				<div class="col-sm-3">
					<select name="id_contact">
						{foreach from=$contacts item=dept}
							<option value="{$dept.id_contact}" {if $dept.name == $contact}selected="selected"{/if}>
								{$dept.name}
							</option>
						{/foreach}
					</select>
				</div>
				<div class="col-sm-3">
					<button class="btn btn-default" type="submit">
						{l s='Change Department'}
					</button>
				</div>
			</div>
		</form>
	</div>

Save and refresh, we should be done! We didn’t have to add any post processing code, simply because it’s already present, at the very beginning of the postProcess method of the AdminCustomerThreadsController.

The post Change department for customer threads in PrestaShop 1.6 appeared first on NemoPS.

Starting with a simple module

First, download the project file, and place the module you will find inside the “start” folder in the modules/ folder of your prestashop installation.

Open up displaybocategorytut.php, it’s just a very basic module structure.

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

class displayBoCategoryTut extends Module
{

	protected $_errors = array();
	protected $_html = '';


	public function __construct()
	{
		$this->name = 'displaybocategorytut';
		$this->tab = 'front_office_features';
		$this->version = '1.0';
		$this->author = 'Nemo';
		$this->need_instance = 0;
		
		$this->bootstrap = true;

	 	parent::__construct();

		$this->displayName = $this->l('Display BO Category Tutorial');
		$this->description = $this->l('Displays an additional field in the category back office');
	}
	
	public function install()
	{
		if (!parent::install())
			return false;
		return true;
	}

	public function uninstall()
	{
		if (!parent::uninstall())
			return false;
		return true;
	}

}

The first thing we need is of course some additional data we want to save and retrieve. For this reason, we need an extra method to modify the database, and add a further column to the category table:

	public function alterTable($method = 'add')
	{
		if($method == 'add')
			$sql = 'ALTER TABLE ' . _DB_PREFIX_ . 'category ADD `myowninput` VARCHAR (255) NOT NULL';
		else 
			$sql = 'ALTER TABLE ' . _DB_PREFIX_ . 'category DROP COLUMN `myowninput`';

		if(!Db::getInstance()->Execute($sql))
			return false;
		return true;
	}

Explanation: since we need the extra column, we are using a single method to add and remove it. We are passing in a “method” parameter, so that we can switch between actions depending on our needs.

As mentioned, we need this column to be added when installing, and removed when uninstalling, so let’s amend the install and uninstall methods as well:

	public function install()
	{
		if (!parent::install() OR
			!$this->alterTable() OR
			!$this->registerHook('displayBackOfficeCategory') OR
			!$this->registerHook('categoryAddition') OR
			!$this->registerHook('categoryUpdate')
			)
			return false;
		return true;
	}

	public function uninstall()
	{
		if (!parent::uninstall() OR
			!$this->alterTable('remove'))
			return false;
		return true;
	}

Additionally, I am registering two hooks to update the field’s value. This would not be necessary if we had a Category class override to take care of the extra field (see more on Extending PrestaShop Objects).

Next, we will need some way to retrieve our custom field from the database

	public function getMyOwnInput($id_category)
	{
		return Db::getInstance()->getValue('SELECT myowninput FROM '._DB_PREFIX_.'category WHERE id_category = '. (int)$id_category);
	}

Then, it’s time to display something in the category back office. Let’s create the hooking method:

	public function hookDisplayBackOfficeCategory($params)
	{

		// we need an actual id, otherwise if we are just adding the category this field can be left empty
		if(Tools::getValue('id_category'))
			$myowninput = $this->getMyOwnInput(Tools::getValue('id_category'));
		else $myowninput = '';

		$this->context->smarty->assign(array(
			'myowninput'=> $myowninput
		));


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

Explanation: First off, we make sure we have a category ID that we can use to retrieve the value from the database. We use a switch to prevent the script from causing trouble in case there is none (that is, we are just creating a new category). Then, we assign the input value to the template, and return it. We don’t have it yet, so let’s create a new file inside views\templates\hook, naming it backoffice.tpl

Let’s add some simple markup:

<div class="form-group">
	<label class="control-label col-lg-3">
		<span class="label-tooltip">
			{l s='Custom Input' mod='displaybocategorytut'}
		</span>
	</label>
	<div class="col-lg-4">
		<input type="text" name="myowninput" value="{$myowninput}">
	</div>
	<div class="col-lg-6 col-lg-offset-3">
	</div>
</div>

We are ready to install the module! Go ahead and do it from the modules page. If everything goes smoothly as it should, reach a category and click edit (or add one). It should display our new field:

It won’t do much at the time being, since we are not saving the value on submit. For this, we need another couple of methods that will take advantage of the hooks we registered upon install:

	public function hookCategoryAddition($params)
	{
		Db::getInstance()->update('category', array('myowninput' => pSQL(Tools::getValue('myowninput'))), 'id_category = ' . $params['category']->id);
	}

	public function hookCategoryUpdate($params)
	{
		$this->hookCategoryAddition($params);
	}

Explanation: here we are using some standard code to update the database: the myowninput value is sent over via POST when submitting the page, and the $params variable passed to the method contains a useful Category object, from which we are taking the ID.

Now write something in the field and save, it should be stored in the database! To make sure everything runs smoothly, create a new category as well, adding content to our field before submitting the page.

Once everything works, you can try to expand the module with hooks, in the front office as well, and take full advantage of the new value.

Additional Resources

• Learn how to develop PrestaShop Modules with my PrestaShop Modules Course

The post Hooking modules to the Category Back Office in Prestashop appeared first on NemoPS.

Adding an extra field to PrestaShop objects

Before doing anything with CSVs or the importer, we need a field to fill with your data. If you don’t know how to add one, here is a tutorial on How to extend PrestaShop Objects, and add new fields to them.
In this example, we will use that extrafield one added in the tutorial.
As a side note, it’s not strictly necessary to add the extra field to the product object, as we will see, but it’s essential to have a database column we can use.

Two approaches

Given that the Product class override is not strictly necessary, we can proceed in two ways, depending on our needs: the first, is to complete the previous tutorial, and add the field to the Product Object; the second is to stop after adding the database column, and override an extra method of the AdminImportController, to manually update the new field. We will cover both to see how they work.

The AdminImportController override

Let’s start playing with the real file. First of all, create a new file in override/controllers/admin, and name it AdminImportController.php

Open it up, and add some standard override code within PHP tags

class AdminImportController extends AdminImportControllerCore
{

}

Next, we want to tell the Importer we have an extra field for products. To do this, we have to override the whole construct method, since it’s the one defining available fields for all entities. It’s too long to copy it here, to make sure you grab yours from the original Controller, and drop it into the override.

class AdminImportController extends AdminImportControllerCore
{
        $this->bootstrap = true;
        $this->entities = array(
            $this->l('Categories'),
            $this->l('Products'),
            $this->l('Combinations'),
            $this->l('Customers'),
            $this->l('Addresses'),
            $this->l('Manufacturers'),
            $this->l('Suppliers'),
            $this->l('Alias'),
        );
        // more code here

        $this->separator = ($separator = Tools::substr(strval(trim(Tools::getValue('separator'))), 0, 1)) ? $separator :  ';';
        $this->multiple_value_separator = ($separator = Tools::substr(strval(trim(Tools::getValue('multiple_value_separator'))), 0, 1)) ? $separator :  ',';
        AdminController::__construct();
}

Make absolutely sure you change the very last call to AdminController::__construct(); to avoid losing any modification to the product properties.

Now that the override is in place, we must let it know about our field. Locate the following snippet:

            case $this->entities[$this->l('Products')]:
                self::$validators['image'] = array(
                    'AdminImportController',
                    'split'
                );

You will notice it’s followed by an array defining available fields:

               $this->available_fields = array(
                    'no' => array('label' => $this->l('Ignore this column')),
                    'id' => array('label' => $this->l('ID')),
                    'active' => array('label' => $this->l('Active (0/1)')),
                    'name' => array('label' => $this->l('Name')),
                    'category' => array('label' => $this->l('Categories (x,y,z...)')),
                    'price_tex' => array('label' => $this->l('Price tax excluded')),
                    'price_tin' => array('label' => $this->l('Price tax included')),
                    'id_tax_rules_group' => array('label' => $this->l('Tax rules ID')),
                    'wholesale_price' => array('label' => $this->l('Wholesale price')),
                    'on_sale' => array('label' => $this->l('On sale (0/1)')),
                    'reduction_price' => array('label' => $this->l('Discount amount')),
                    'reduction_percent' => array('label' => $this->l('Discount percent')),
                    'reduction_from' => array('label' => $this->l('Discount from (yyyy-mm-dd)')),
                    'reduction_to' => array('label' => $this->l('Discount to (yyyy-mm-dd)')),
                    'reference' => array('label' => $this->l('Reference #')),
                    'supplier_reference' => array('label' => $this->l('Supplier reference #')),
                    'supplier' => array('label' => $this->l('Supplier')),
                    'manufacturer' => array('label' => $this->l('Manufacturer')),
                    'ean13' => array('label' => $this->l('EAN13')),
                    'upc' => array('label' => $this->l('UPC')),
                    'ecotax' => array('label' => $this->l('Ecotax')),
                    'width' => array('label' => $this->l('Width')),
                    'height' => array('label' => $this->l('Height')),
                    'depth' => array('label' => $this->l('Depth')),
                    'weight' => array('label' => $this->l('Weight')),
                    'quantity' => array('label' => $this->l('Quantity')),
                    'minimal_quantity' => array('label' => $this->l('Minimal quantity')),
                    'visibility' => array('label' => $this->l('Visibility')),
                    'additional_shipping_cost' => array('label' => $this->l('Additional shipping cost')),
                    'unity' => array('label' => $this->l('Unit for the unit price')),
                    'unit_price' => array('label' => $this->l('Unit price')),
                    'description_short' => array('label' => $this->l('Short description')),
                    'description' => array('label' => $this->l('Description')),
                    'tags' => array('label' => $this->l('Tags (x,y,z...)')),
                    'meta_title' => array('label' => $this->l('Meta title')),
                    'meta_keywords' => array('label' => $this->l('Meta keywords')),
                    'meta_description' => array('label' => $this->l('Meta description')),
                    'link_rewrite' => array('label' => $this->l('URL rewritten')),
                    'available_now' => array('label' => $this->l('Text when in stock')),
                    'available_later' => array('label' => $this->l('Text when backorder allowed')),
                    'available_for_order' => array('label' => $this->l('Available for order (0 = No, 1 = Yes)')),
                    'available_date' => array('label' => $this->l('Product availability date')),
                    'date_add' => array('label' => $this->l('Product creation date')),
                    'show_price' => array('label' => $this->l('Show price (0 = No, 1 = Yes)')),
                    'image' => array('label' => $this->l('Image URLs (x,y,z...)')),
                    'delete_existing_images' => array(
                        'label' => $this->l('Delete existing images (0 = No, 1 = Yes)')
                    ),
                    'features' => array('label' => $this->l('Feature (Name:Value:Position:Customized)')),
                    'online_only' => array('label' => $this->l('Available online only (0 = No, 1 = Yes)')),
                    'condition' => array('label' => $this->l('Condition')),
                    'customizable' => array('label' => $this->l('Customizable (0 = No, 1 = Yes)')),
                    'uploadable_files' => array('label' => $this->l('Uploadable files (0 = No, 1 = Yes)')),
                    'text_fields' => array('label' => $this->l('Text fields (0 = No, 1 = Yes)')),
                    'out_of_stock' => array('label' => $this->l('Action when out of stock')),
                    'shop' => array(
                        'label' => $this->l('ID / Name of shop'),
                        'help' => $this->l('Ignore this field if you don\'t use the Multistore tool. If you leave this field empty, the default shop will be used.'),
                    ),
                    'advanced_stock_management' => array(
                        'label' => $this->l('Advanced Stock Management'),
                        'help' => $this->l('Enable Advanced Stock Management on product (0 = No, 1 = Yes).')
                    ),
                    'depends_on_stock' => array(
                        'label' => $this->l('Depends on stock'),
                        'help' => $this->l('0 = Use quantity set in product, 1 = Use quantity from warehouse.')
                    ),
                    'warehouse' => array(
                        'label' => $this->l('Warehouse'),
                        'help' => $this->l('ID of the warehouse to set as storage.')
                    )
                );

This represents all of the fields, or columns, that you can map to every column of your csv file. At this point, it’s enough to append our element to the array:

                    'depends_on_stock' => array(
                        'label' => $this->l('Depends on stock'),
                        'help' => $this->l('0 = Use quantity set in product, 1 = Use quantity from warehouse.')
                    ),
                    'warehouse' => array(
                        'label' => $this->l('Warehouse'),
                        'help' => $this->l('ID of the warehouse to set as storage.')
                    ),
                    'extrafield' => array(
                        'label' => $this->l('Extrafield'),
                        'help' => $this->l('Something')
                    )
                );

Save, then reach the cache folder and delete class_index.php, so that the override file is loaded.

If you added the Product class override, you can skip to Testing The Import

Otherwise, there is a little snippet you need to add. Unfortunately, in order to do it we have to override the whole ProductImport() method. Therefore, copy and paste yours into the override file we created; then, reach the very end of it, where it reads:

        $this->closeCsvFile($handle);
        Module::processDeferedFuncCall();
        Module::processDeferedClearCache();
        Tag::updateTagCount();

Right before, add the following statement

Db::getInstance()->update('product', array('extrafield' => $info['extrafield']), 'id_product = ' . (int)$product->id);

This will manually update the field, in case it was not part of the product object.

Testing The Import

Before proceeding: Make sure you do not have a product with the same ID of the sample one, or it will be overridden.

We are ready for a test run. Download the product csv sample from Advanced Parameters > CSV Import

Open up the file in any text editor, get rid of all lines apart from the heading and first product. Then, add a new heading after “Warehouse”, and a value for it on the next line:

Save the file. Now load it up in the importer. Make sure you select Products as entity, and leave all other settings as default. Hit Next.

On the next screen, hit the next arrow until you reach the end of the file. You should see the new column popping up:

Now proceed and simply hit import to complete the process. You will probably get an error because of the broken image url, but the new field should be added to the database:

We are done! Now you can display the extra field the way you like, whether it is with a module or following the previously linked tutorial.

Additional Resources on CSV Import in PrestaShop

• How to extend PrestaShop Objects
• Prestashop: Import CSV data in 1.6

The post Adding new fields to the PrestaShop CSV Importer appeared first on NemoPS.

Watch the screencast

More about PrestaShop 1.7

• PrestaShop 1.7’s new theme Preview
• PrestaShop 1.7 will be a catastrophe. Here is why

The post PrestaShop 1.7 Pre-Beta video Preview appeared first on NemoPS.

Watch the screencast

The post How to upload new file types with the Prestashop Filemanager appeared first on NemoPS.

Watch the Screencast

Text version

Open up classes/Notification.php, and locate the getLastElements method:

	public function getLastElements()
	{
		global $cookie;

		$notifications = array();

		$employee_infos = Db::getInstance(_PS_USE_SQL_SLAVE_)->getRow('
		SELECT id_last_order, id_last_customer_message, id_last_customer
		FROM `'._DB_PREFIX_.'employee`
		WHERE `id_employee` = '.(int)$cookie->id_employee);

		foreach ($this->types as $type)
			$notifications[$type] = Notification::getLastElementsIdsByType($type, $employee_infos['id_last_'.$type]);

		return $notifications;
	}

Modify as follows

	public function getLastElements()
	{
		global $cookie;

		$notifications = array();

		foreach($this->types as $type)
			$notifications[$type] = array();

		return $notifications;

		$employee_infos = Db::getInstance(_PS_USE_SQL_SLAVE_)->getRow('
		SELECT id_last_order, id_last_customer_message, id_last_customer
		FROM `'._DB_PREFIX_.'employee`
		WHERE `id_employee` = '.(int)$cookie->id_employee);

		foreach ($this->types as $type)
			$notifications[$type] = Notification::getLastElementsIdsByType($type, $employee_infos['id_last_'.$type]);

		return $notifications;
	}

This way, we are effectively saving lots of resources as we don’t query the database for new items.

The post How to disable top notifications in the Prestashop back office appeared first on NemoPS.

Watch the Screencast

The post Faster Prestashop Back Office #1: removing modules and themes Ads appeared first on NemoPS.

Update: possible Fix on Git

Here is a fix that came out recently, you can try replacing the red lines with green ones, or simply download the file and replace yours:

https://github.com/PrestaShop/PrestaShop/commit/5a0d4c90ff95332d8a03df84c5821c730a95087d

The issue: Save buttons on the Prestashop Product back office keep spinning (almost) forver

Ever since the release of Prestashop 1.6.0.11, many users of the Prestashop forums have reported the same, big issue that seemed to be affecting all upgraded versions of the software. The fearsome glitch being an absolute catastrophe for merchants, since it made it impossible to save the product page in the back office. Thus, impossible to edit or add products whatsoever.
Given that is one of the worst issues the Prestashop back office ever had, what is the cause of it? I fired an out-of-the-box 1.6.0.11 myself on my localhost and sought for a reasonable explanation: the save button keeps spinning until all tabs are loaded via ajax. This means that until all of them (Information, Prices, Combinations and so on) are fully loaded, it won’t be possible to even save the product. Let’s have a look at a screenshot to better understand what’s going on under the hood while the button is disabled:

Notice how many ajax calls to the same page are performed, with the last one still pending response. Each of them fetches the content of a tab, and it won’t ever be possible to save the page before everything has been loaded.

Unfortunately, the back office being slower and slower the more Prestashop versions are released, the waiting time might become unsustainable. It took 10 seconds on that localhost test, but it can grow up to one minute, or even more, on shared, medium quality hostings.

The reason behind it

In the end, it all comes down to a question: why wasn’t this happening before? Simple: it was indeed possible to save before all tabs had been loaded, however this ended up spawning the well known “Product must be in the default category” or “link_rewrite field is required” errors, which were indeed caused by saving the product form without all the necessary fields having been filled with the required data yet. We can think of the spinning button as a measure to prevent this kind of error.

Troubleshooting the issue

Given that it’s a matter of timing, let’s try to go over some possible fixes that came up in the constantly updating forum thread (Prestashop 1.6.0.11 problem with saving products).
Make sure you also enable error reporting by setting PS_MODE_DEV to true in config/defines.inc.php before even thinking of troubleshooting.

Identifying the source

There are three possible scenarios: a broken entry in the ajax requests queue, that will show up in red (see previous screenshot) in the list mentioned above; a forever pending request; lastly, a really slow request. It is important to understand which of these is preventing the button from being clickable, as the long-term fix will vary depending on it. Make sure you wait a couple of minutes and keep an eye on the following timing column as well:

Once we are relatively sure about the type of issue, how can we find out the source?

First, you can tell the tab name by the url:

index.php?controller=AdminProducts&token=aeaf41a133dadba136c21930b7caa933&id_product=1&action=Suppliers&updateproduct&ajax=1&rand=1423043161452&_=1423043155352

In this case, you can see action=Suppliers, so we’re dealing with the suppliers table. If it’s a module, it will be action=Module*ModuleName* without asterisks of course.

In the case of a red entry make sure you check out the ajax response by clicking on the broken url itself, it should give you more insights on what’s wrong with it.

Case 1: Broken Module

The most common source of the error is a broken module. Inspect the name as above, and if it really is a module go ahead and disable it; it should fix the big issue while you figure out the underlying cause.

Case 2: broken product tab

This is worse than the previous, as it can’t be solved by simply disabling a module. Once you are sure it really is a tab (see above), there are multiple things you can do. If it’s a red entry and the response is a Prestashop Exception or PHP error, follow the hints given by the error itself. Common issues might come from:

• A hard-modified AdminProductsController.php
• AdminProductsController.php override
• Broken/incompatible methods coming from other overrides

If you didn’t modify the original controller, you can temporarily disable all overrides by reaching Advanced Parameters > Performance and setting Disable all overrides to yes.

If you are not using overrides, the issue might be coming, yet again, from a module. Reach Modules > Positions, check “Display non-positionable hooks”, and then look for modules hooked to one of the following:

• actionAdminControllerSetMedia
• displayBackOfficeHeader
• actionProductUpdate
• actionProductAdd
• actionCategoryUpdate

Wrapping it up

This post was not meant to give you a 100% reliable solution, since it’s impossible to predict every single scenario. Still, I hope it pointed you to the right direction in case you were facing the never-ending spinning save button issue in Prestashop 1.6.0.11 and newer.

The post Troubleshooting the spinning save button in Prestashop 1.6.0.11 and above appeared first on NemoPS.

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.

<?php

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

class newFieldsTut extends Module
{
	/* @var boolean error */
	protected $_errors = false;
	
	public function __construct()
	{
		$this->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:

<h4>{l s='New Fields Tutorial' mod='newfieldstut'}</h4>
<div class="separation"></div>
<table>
	<tr>
		<td class="col-left">
			<label>{l s='Our New Field:'}</label>
		</td>
		<td>
			{include file="controllers/products/input_text_lang.tpl"
				languages=$languages
				input_name='custom_field'
				input_value=$custom_field}
			<p class="preference_description">{l s='Simply a new custom field'}. <strong>{l s='ie: something here as a hint'}</strong></p>
		</td>
	</tr>
</table>

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.