Watch the screencast

Let’s get started! Create a new php file in the override/controllers/front folder, and name it: ContactController.php and add the following inside php tags:

class ContactController extends ContactControllerCore
{
}

We need to latch into the postProcess method, so let’s extend it:

public function postProcess()
{
    if(Tools::isSubmit('submitMessage'))
    {
    }
}

We want to save the submitted message to a variable first, and then the email:

    	$message = Tools::getValue('message');
        $from = trim(Tools::getValue('from'))

Now to keep things tidy we will create two new arrays, one will contain the list of strings to ban from emails, the other the ones to ban from the content:

            $banned_in_email = ['.ru', 'qq.com', '.vn'];
            $banned_content = ['email marketing'];

Please Note: make sure you use strings that are related to the spam you are actually getting. I am getting spam from .ru, qq.com and .vn domains, so that’s what I am blocking. I also get a lot of emails containing “email marketing” in the text, and am unlikely to get anything real with that type of content.
Make sure you do not ban real customers!

We want to loop through both and spawn an error if anything is contained in the submitted variables:

            foreach ($banned_in_email as $string) {
                if(strstr($from, $string))
                    $this->errors[] = Tools::displayError('This email address is not allowed');
            }
            foreach ($banned_content as $string) {
                if(strstr($message, $string))
                    $this->errors[] = Tools::displayError('Invalid content');
            }

And that’s basically it, we just need to call the parent at the very end of the method:

parent::postProcess();

And we are done! Here is the complete override:

class ContactController extends ContactControllerCore
{
    public function postProcess()
    {
        if(Tools::isSubmit('submitMessage')) {

            $message = Tools::getValue('message');
            $from = Tools::getValue('from');

            $banned_in_email = ['.ru', 'qq.com', '.vn'];
            $banned_content = ['email marketing'];

            foreach ($banned_in_email as $string) {
                if(strstr($from, $string))
                    $this->errors[] = Tools::displayError('This email address is not allowed');
            }

            foreach ($banned_content as $string) {
                if(strstr($message, $string))
                    $this->errors[] = Tools::displayError('Invalid Content');
            }
        }
        parent::postProcess();
    }
}

Before you test, make sure you erase cache/class_index.php, so that the new override is loaded in the system.

The post Blocking spam emails in PrestaShop appeared first on NemoPS.

Watch the screencast

Text Version

METHOD 1 – Selectively enabling catalog mode

If we don’t need to display prices to our visitors, the simplest and quickest way to proceed is by selectively enable catalog mode. Open classes/controller/FrontController.php, and locate the following string, inside the init method:

'PS_CATALOG_MODE' => (bool)Configuration::get('PS_CATALOG_MODE') || (Group::isFeatureActive() && !(bool)Group::getCurrent()->show_prices),

Replace it with the following:

'PS_CATALOG_MODE' => $catalog_mode || (Group::isFeatureActive() && !(bool)Group::getCurrent()->show_prices),

We need to create that $catalog_mode variable of course, so let’s add this before the whole assign block:

$catalog_mode = (bool)Configuration::get('PS_CATALOG_MODE');
if(!$this->context->customer->id)
    $catalog_mode = true;

As you can see, we simply check if the customer id is set (that is, if the user is logged in) and if so, we set catalog mode to true, effectively disabling all cart functionalities. This however left us with a useless cart block, and without prices. Let’s see how to handle it differently then!

METHOD 2 – Selectively disable products

I will create an override for this one, so in override/classes, let’s create a new file named Product.php.

Let’s open it up, and copy over the construct method from the core product class. Get rid of everything inside it, and simply add the following:

Class Product extends ProductCore
{
    public function __construct($id_product = null, $full = false, $id_lang = null, $id_shop = null, Context $context = null)
    {
        parent::__construct($id_product, $id_lang, $id_shop);

        if(!Context::getContext()->customer->id)
            $this->available_for_order = false;
    }
}

This will take care of the product page. Now for the product list, the property is set elsewhere, and specifically in the getProductProperties method (without s). Copy the whole method from the original class again, but this time leave the content, and just append the following code at the end, right before self::$producPropertiesCache[$cache_key] = $row;

if(!$context->customer->id)
    $row['available_for_order'] = false;

And that’s all we need! Since we created a new override, remember it’s necessary to erase cache/class_index.php in order for the changes to take place.

The post Private Orders Shop in PrestaShop and thirty bees part 2: hide shopping options for visitors appeared first on NemoPS.

Watch the screencast

Text Version

I will use PrestaShop 1.6 for the demo but the modification works in thirty bees as well. Bear in mind it DOES NOT work in PrestaShop 1.7.

Open up controllers/front/AuthController.php

Look for the following code, around line 455. If it’s not in those whereabouts, just make sure you change every instance

$customer->active = 1;

set to 0, so that the user cannot perform any action right away.

Now we also want to give the user some feedback, so let’s redirect him to a custom page. Scroll down a few lines, and where you see all these redirects:

if (($back = Tools::getValue('back')) && $back == Tools::secureReferrer($back)) {
                            Tools::redirect(html_entity_decode($back));
                        }

And add a new one before

  Tools::redirect($this->context->link->getPageLink('welcome'));

Of course this page does not exist yet but we will create it in a moment.

Before that though, we have to take care of a little issue. Since the user has been created but set to inactive, the system treats it as banned by default. Even if we are to redirect to a page, we would instantly be kicked out of the session and redirected to the login. We want to create an exception so that the welcome page can be displayed.

Let’s go ahead and open up the customer class, so classes/customer.php
Look for the following method:

public static function isBanned($id_customer)

And at the very beginning, add:

        if(Context::getContext()->controller->php_self == 'welcome')
            return false;

That’s settled! Now for our welcome page, I will create a new controller and a template file in the theme folder

Let’s head to controllers/front, and create a new PHP file first, named WelcomeController.php:

class WelcomeControllerCore extends FrontController
{
    public $php_self = 'welcome';


    public function initContent()
    {
        parent::initContent();
        $this->setTemplate(_PS_THEME_DIR_.'welcome.tpl');
    }
}

Then in the theme folder, create a new file named welcome.tpl, adding the following code inside

{capture name="path"} {l s='Welcome'}{/capture}
<h1>{l s='Welcome to'} {$shop_name}! </h1>
<hr>
<p>
	{l s='Your account is currently under review, you will receive an email as soon as it is validated'}
</p>

So let’s go ahead and try it out now… but before let’s clear cache by erasing cache/class_index.php, since we added a new controller and the system wouldn’t read it otherwise.

The next step is to send out and email when a status is changed to active for the customer, in the back office.
Open controllers/admin/admincustomerscontroller.php

We will add a new method, which is inherited from the admincontroller class:

    public function processStatus()
    {
        if($object = parent::processStatus()) {
            if(get_class($object) == 'Customer' && $object->active) // the customer has been activated, send out an email
            {
                Mail::Send($object->id_lang, 'account_activated', $this->l('Your account has been activated'),
                    ['name' => $object->firstname .' '. $object->lastname],
                $object->email,
                $object->firstname .' '. $object->lastname,
                Configuration::get('PS_SHOP_EMAIL'),
                Configuration::get('PS_SHOP_NAME'));
            }
        }

       return $object;
    }

Of course, there is no such email template so we have to create it. I suggest copying an existing one, like the order confirmation, and adding new text, just to be quicker. The code is different for every template, just bear in mind to add the {name} variable inside it, so that the customer name is displayed!

This is it for part 1, make sure you test the email as well since sometimes they do fail for odd reasons, if you don’t see it coming, triple check the template names and make sure they are located in the proper path for each language you use.

In part two we will see how to prevent orders in case a customer is not registered, which is fundamental not to break the system if you have a one page checkout, as right now it would display an error.

The post Private Orders Shop in PrestaShop and thirty bees part 1: manual customer verification appeared first on NemoPS.

Watch the screencast

The post Litespeed module for PrestaShop and thirty bees appeared first on NemoPS.

Watch the screencast

The post Setting up a staging site for PrestaShop and Thirtybees appeared first on NemoPS.

Watch the video guide

Core features

• Unlimited fields: Add as many new fields as you like
• Multiple input types: Choose between text, textarea or select box to perfectly fit the type of data you require from your customers
• Customizable format
• Choose if you want to display the fields in the back office list as well
• Multilanguage labels

The post New module: “Address Fields” just released! appeared first on NemoPS.

Watch the screencast

Duplicating product carriers in PrestaShop and ThirtyBees – text version

Create a new override in override/controllers/admin, and name it AdminProductsController.php:

class AdminProductsController extends AdminProductsControllerCore
{
}

We need to copy the original ProcessDuplicate method, and paste it into our override. You will see it’s calling a bunch of methods that start with “duplicate”. Add the following right after Product::duplicateSuppliers($id_product_old, $product->id):

            && Product::duplicateCarriers($id_product_old, $product->id)

Next, we have to add the method we are calling to the Product class. We will use another override, so let’s create Product.php in override/classes

Open it up, and paste the following, or if you have a product override already in place, just copy over the DuplicateCarriers method:

    public static function duplicateCarriers($id_product_old, $id_product_new)
    {
        $result = Db::getInstance()->executeS('
		SELECT *
		FROM `'._DB_PREFIX_.'product_carrier`
		WHERE `id_product` = '.(int)$id_product_old);

        foreach ($result as $row) {
            unset($row['id_product_carrier']);
            $row['id_product'] = $id_product_new;
            if (!Db::getInstance()->insert('product_carrier', $row)) {
                return false;
            }
        }

        return true;
    }	

Save, then reach the cache/ folder and erase class_index.php, so that the new overrides can get loaded in the system.

The post Duplicating Carriers along with Products in PrestaShop and ThirtyBees appeared first on NemoPS.

Introduction

You might have come across the need to translate the price per unit field in your PrestaShop or Thirtybees, but crashed against the software’s limitation, as that’s a single language property. Any product field can be made multi-language with a simple modification, so let’s see how to do it using the Unity one as example in this tutorial!

Step 1 – Adding the new database column

In order to make the field translatable, we have to add it to the product_lang table in the database. Not only, but we also have to erase the same column in both the product and product_shop tables, to avoid conflicts when retrieving values from the database. Let’s add it first!

Using phpMyAdmin or Adminer, locate the *prefix*product_lang table in your database, and add a new column as VARCHAR, 24 characters long. Once done, it will look like this:

Next, let’s get rid of the leftovers: open the *prefix*product table and drop the unity column first, and then on the product_shop table.
We are done! We just broke the Product class though, and have to compensate by letting it know where to grab the new values from.

Step 2 – Editing the product class

We have a new column in the database, but at this point the Product class would still just ignore it. To have it lookup, and save into the correct table, we must tell it that the property we are wanting to translate is a multilanguage field. To do so, we must change its definition.

Open up Product.php, located in the classes/ folder.

Scroll down until you find the following line, part of the $definition property:

'unity'                     => ['type' => self::TYPE_STRING, 'shop' => true, 'validate' => 'isString'],

To make any field translatable, we can simply add ‘lang’ => true as follows

'unity'                     => ['type' => self::TYPE_STRING, 'shop' => true, 'validate' => 'isString', 'lang' => true],

Please notice that, as always, using an override is strongly recommended, instead of editing core files.

Step 3 – Editing the back office

The controller

This is the most complicated part, as we will have to edit both the admin controller for products, and the correct template. For our example, the template is prices.tpl, but it will be different if the field you want to translate is in another tab.

Let’s start with the controller. The prices template does not offer us any option for translating fields, and therefore misses the indispensable $languages variable.
Open up AdminProductsController, located in controllers/admin

We are interested in the method called initFormPrices, so once you find it you can simply clone that to an override, or continue editing the core.

Right after $data is assigned, at the very beginning of the function, but before $product = $obj, add the following

if (!$this->default_form_language) {
    $this->getLanguages();
}
$data->assign(array(
    'languages'=> $this->_languages,
    'id_lang' => $this->context->language->id,
    'default_form_language' => $this->default_form_language,
));

Explanation: Nothing too complex here, we are first checking if languages are loaded, and if not, assigning them to the controller. Then, we simply assign that class property to the template, along with a few other required ones. Please notice we do not use a common smarty assign, but the $data variable instead.

The template

Time to make our changes visible in the back office! For the unity field, let’s open up *admin folder*/themes/default/template/controllers/products/prices.tpl

Locate the input with id unity, which will look more or less like the following:

<input id="unity" name="unity" type="text" value="{$product->unity|htmlentitiesUTF8}"  maxlength="255" onkeyup="if (isArrowKey(event)) return ;unitySecond();" onchange="unitySecond();"/>

Instead of this input, we will use a handy template PrestaShop makes available to us. Replace the above with the following code:

{include file="controllers/products/input_text_lang.tpl"
languages=$languages
input_class="{$class_input_ajax}{if !$product->id || Configuration::get('PS_FORCE_FRIENDLY_PRODUCT')}copy2friendlyUrl{/if} updateCurrentText"
input_value=$product->unity
input_name="unity"}

Save and refresh, and you will see the new field, translatable, appearing in the prices table of the back office. Time to test it, and see if it’s saving properly.
We can take an extra step and translate the preview below as well:

<span id="unity_second">{$product->unity}</span>

to

<span id="unity_second">{$product->unity.{$id_lang}}</span>

At this point we can go ahead and test the Front Office. If everything has been done correctly, as soon as you change language, the class should automatically pick the correct translation for the field. Neat!

The post Make product fields multi-language in PrestaShop and ThirtyBees appeared first on NemoPS.

Watch the screencast

The post Installing ThirtyBees: e-commerce that works for you appeared first on NemoPS.

Watch the screencast

Code Snippet

	{if $product->date_add}
		<div class="form-group">
			<label class="control-label col-lg-3">
				<span class="label-tooltip" data-toggle="tooltip" title="{l s='Change date for product new from.'}">
					{$bullet_common_field} {l s='New from'}
				</span>
			</label>
			<div class="col-lg-3">
				<input type="text" id="date_add" class="datepicker" name="date_add" value="{$product->date_add|escape:html:'UTF-8'}">
			</div>
		</div>
	{/if}

The post Edit the product creation date in ThirtyBees and PrestaShop appeared first on NemoPS.