Configuration

Missing required argument $name of Xtento\ProductExport\Logger\Logger.

If you are using Xtento in combination with an automated product importer, you may have seen the following error before.

Missing required argument $name of Xtento\ProductExport\Logger\Logger.

1	Missing required argument $name of Xtento\ProductExport\Logger\Logger.

The error message appears right after saving a product. The reason is that, at least one of your products in Products > Catalog has no Name. To fix this, you can update the name manually via MySQL queries or simply delete the products and import again correctly.

Bulk Update Customizable Product Options in Magento2

Today I had to bulk-update the Price and Max Characters in the tab Customizable Options for hundreds of simple products based on the title.

I knew that it could be done programmatically but I figured out that it can be done just by updating the table catalog_product_option and catalog_product_option_price. First I got a comma separated list of option_id’s based on a specific title.

SELECT GROUP_CONCAT(option_id SEPARATOR ",") AS option_ids FROM catalog_product_option_title WHERE title = 'Some Message';

1	SELECT GROUP_CONCAT(option_id SEPARATOR ",") AS option_ids FROM catalog_product_option_title WHERE title = 'Some Message';

277,281,284,286,289,292,293,294,295

1	277,281,284,286,289,292,293,294,295

With the comma separated list I was able to update the value of the Price and Max Characters as follows.

1. Price

UPDATE catalog_product_option_price SET price = 5.000 WHERE option_id IN (277,281,284,286,289,292,293,294,295);

1	UPDATE catalog_product_option_price SET price = 5.000 WHERE option_id IN (277,281,284,286,289,292,293,294,295);

2. Max Characters

UPDATE catalog_product_option SET max_characters = 300 WHERE option_id IN (277,281,284,286,289,292,293,294,295);

1	UPDATE catalog_product_option SET max_characters = 300 WHERE option_id IN (277,281,284,286,289,292,293,294,295);

Possible that you have to flush the cache ( php/magento cache:flush ) and re-index everything ( php/magento indexer:reindex ) to see the results.

Change Order, Invoice, Credit Memo or Shipment Number Prefix or Suffix in Magento2

In some cases shop owners have to change their default order number with a custom prefix or suffix. Customising order numbers sounds complicated, but it can be done with only few MySQL queries.

First, backup your database. After that, get a list of meta_id’s and store_id’s with the following query for order numbers only.

SELECT * FROM sales_sequence_meta WHERE entity_type = 'order';

1	SELECT * FROM sales_sequence_meta WHERE entity_type = 'order';

+---------+-------------+----------+------------------+
| meta_id | entity_type | store_id | sequence_table   |
+---------+-------------+----------+------------------+
|       1 | order       |        0 | sequence_order_0 |
|       5 | order       |        1 | sequence_order_1 |
+---------+-------------+----------+------------------+
2 rows in set (0.00 sec)

+---------+-------------+----------+------------------+

+---------+-------------+----------+------------------+

| 1 | order | 0 | sequence_order_0 |

| 5 | order | 1 | sequence_order_1 |

+---------+-------------+----------+------------------+

2 rows in set (0.00 sec)

The meta_id is pretty much the identifier you need for the next UPDATE query which will add the letter A as a prefix. For example: A100000001

UPDATE sales_sequence_profile SET prefix = 'A' WHERE meta_id = 1;

1	UPDATE sales_sequence_profile SET prefix = 'A' WHERE meta_id = 1;

The same query can be used to change the suffix. Also, you can change the prefix or suffix for any entity_type such as invoice, creditmemo or shipment.

That’s it. Create a new order to see the results.

Algolia and Undefined index: store_id

Today I have setup the Algolia Queue Runner ( algolia_queue_runner ) which was working fine for all projects I have worked with before. However, today it was different. The Algolia Queue Runner didn’t work at all. Here is what happened every time when the cronjob was running.

$ php /var/www/src/bin/magento indexer:reindex algolia_queue_runner
Algolia Search Queue Runner indexer process unknown error:
Notice: Undefined index: store_id in /var/www/src/vendor/algolia/algoliasearch-magento-2/Model/Queue.php on line 163

$ php /var/www/src/bin/magento indexer:reindex algolia_queue_runner

Algolia Search Queue Runner indexer process unknown error:

Notice: Undefined index: store_id in /var/www/src/vendor/algolia/algoliasearch-magento-2/Model/Queue.php on line 163

The problem was, one of the store views in Stores > Settings > All Stores was disabled for some reason. After enabling the store view, the problem was fixed.

$ php /var/www/src/bin/magento indexer:reindex algolia_queue_runner
Algolia Search Queue Runner index has been rebuilt successfully in 00:00:00

1 2	$ php /var/www/src/bin/magento indexer:reindex algolia_queue_runner Algolia Search Queue Runner index has been rebuilt successfully in 00:00:00

Captcha Test For Your Contact Form

The following PHP script allows you to test your contact form captcha integration in Magento. If you receive any email after executing this script, you have to review your captcha integration.

<?php

$url = '{base_url}/contacts/index/post/';

$fields = array(
    'name' => urlencode('Bad spam test'),
    'email' => urlencode('somebody@gmail.com'),
    'state' => urlencode('Any State'),
    'postcode' => urlencode(''),
    'telephone' => urlencode(''),
    'comment' => urlencode('Bad spam test'),
    'recaptcha-verification-1' => urlencode('checked'),
);

$query = http_build_query($fields);

$ch = curl_init();
curl_setopt($ch,CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch,CURLOPT_URL, $url);
curl_setopt($ch,CURLOPT_POST, count($fields));
curl_setopt($ch,CURLOPT_POSTFIELDS, $query);

$result = curl_exec($ch);

curl_close($ch);

?>

<?php

$url = '{base_url}/contacts/index/post/';

$fields = array(

'name' => urlencode('Bad spam test'),

'email' => urlencode('somebody@gmail.com'),

'state' => urlencode('Any State'),

'postcode' => urlencode(''),

'telephone' => urlencode(''),

'comment' => urlencode('Bad spam test'),

'recaptcha-verification-1' => urlencode('checked'),

);

$query = http_build_query($fields);

$ch = curl_init();

curl_setopt($ch,CURLOPT_FOLLOWLOCATION, 1);

curl_setopt($ch,CURLOPT_URL, $url);

curl_setopt($ch,CURLOPT_POST, count($fields));

curl_setopt($ch,CURLOPT_POSTFIELDS, $query);

$result = curl_exec($ch);

curl_close($ch);

You may need to add, remove or rename fields in the $field array. Don’t forget to replace {base_url} with your actual URL.

Automatically Update The Year In The Footer

In most of the projects that I am working on, it is still common practice to have the current year of the copyright text stored in System > Configuration > General > Design > Footer.

&copy; 2015 Magento Demo Store. All Rights Reserved.

1	© 2015 Magento Demo Store. All Rights Reserved.

That means, every year somebody has to change the year manually. This is very time consuming, especially if you have to manage ten, twenty or more clients. Here is a quick example of how you can make it dynamic.

1. Set a custom string such as {YEAR}

Edit your footer in System > Configuration > General > Design > Footer and place the {YEAR} somewhere.

&copy; {YEAR} Magento Demo Store. All Rights Reserved.

1	© {YEAR} Magento Demo Store. All Rights Reserved.

2. Replace the {YEAR}

Edit your footer.phtml in your package and replace getCopyright as shown below. For the year I am using Mage::getModel(‘core/date’) to have the correct timezone included.

<div class="footer-container">
    <div class="footer">
        <?php echo $this->getChildHtml() ?>
        <p class="bugs"><?php echo $this->__('Help Us to Keep Magento Healthy') ?> - <a href="http://www.magentocommerce.com/bug-tracking" onclick="this.target='_blank'"><strong><?php echo $this->__('Report All Bugs') ?></strong></a> <?php echo $this->__('(ver. %s)', Mage::getVersion()) ?></p>
        <address><?php echo str_replace('{YEAR}', Mage::getModel('core/date')->date('Y'), $this->getCopyright()); ?></address>
    </div>
</div>

<?php echo $this->getChildHtml() ?>

<p class="bugs"><?php echo $this->__('Help Us to Keep Magento Healthy') ?> - <a href="http://www.magentocommerce.com/bug-tracking" onclick="this.target='_blank'"><strong><?php echo $this->__('Report All Bugs') ?></strong></a> <?php echo $this->__('(ver. %s)', Mage::getVersion()) ?></p>

<address><?php echo str_replace('{YEAR}', Mage::getModel('core/date')->date('Y'), $this->getCopyright()); ?></address>

</div>

File: ./app/design/frontend/{package}/default/template/page/html/footer.phtml

We’re sorry, an error has occurred while generating this email

Today, I was dealing with the following error message on one of our Magento2 production environment.

We're sorry, an error has occurred while generating this email.

1	We're sorry, an error has occurred while generating this email.

After spending 2 hours trying to find the source of the problem in our custom modules, I was able to fix the issue by disabling the core module Magento_SampleData.

$ bin/magento module:disable Magento_SampleData

1	$ bin/magento module:disable Magento_SampleData

What is this module for? This module gives you different sample data ( CMS, Catalog, Customers ) which is useful during development and testing phase. For your production environment it is not necessary and also not recommended to have it installed, as you can read here.

Algolia 1.6.1 or higher automatically update the product index

Algolia 1.6.1 or higher comes with a new feature that automatically updates your product index, every time you save a category. The disadvantage is that it will also update the product index, even if you just change an attribute which has nothing to do with URL rewrites or something else that can break search results. This can increase your indexing operations rapidly, therefore your monthly bills from Algolia as well.

To prevent unnecessary indexing, you should disable the new feature in System > Configuration > Algolia Search 1.x > Advanced > Update product on category products update and manage indexing manually with System > Index Management or simply with cron jobs.

Nginx Docker Container and getpwnam(“www-data”) problem

I am using nginx:1.10.1-alpine to run Nginx as a docker container. Today I have replaced the Nginx container and always got the status Restarting (1) Less than a second ago after starting the container.

CONTAINER ID        IMAGE                          COMMAND                  CREATED             STATUS                                  PORTS                         NAMES
aadc6336a026        docker_nginx                   "nginx -g 'daemon off"   10 minutes ago      Restarting (1) Less than a second ago   0.0.0.0:80->80/tcp, 443/tcp   nginx

1 2	CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES aadc6336a026 docker_nginx "nginx -g 'daemon off" 10 minutes ago Restarting (1) Less than a second ago 0.0.0.0:80->80/tcp, 443/tcp nginx

With the command docker logs nginx I got the following error logs.

2016/09/10 22:58:49 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
2016/09/10 22:58:50 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
2016/09/10 22:58:50 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

2016/09/10 22:58:49 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

2016/09/10 22:58:50 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

2016/09/10 22:58:50 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

The error message basically means that the user www-data which I have defined in /etc/nginx/nginx.conf doesn’t exists in /etc/passwd. That makes sense, because nginx:1.10.1-alpine comes with a minimal setup. I my case I need the user www-data for other linked php-fpm containers. To fix the problem I just added the missing user during the container build.

FROM nginx:1.10.1-alpine
RUN addgroup -g 1000 -S www-data \
 && adduser -u 1000 -D -S -G www-data www-data

FROM nginx:1.10.1-alpine

RUN addgroup -g 1000 -S www-data \

&& adduser -u 1000 -D -S -G www-data www-data

Voilà.

Building nginx
Step 1 : FROM nginx:1.10.1-alpine
 ---> c07e2bb859e2
Step 2 : RUN addgroup -g 1000 -S www-data         && adduser -u 1000 -D -S -G www-data www-data
 ---> Running in c1cd75c7dc52
 ---> 83528539d9c9
Removing intermediate container c1cd75c7dc52
Successfully built 83528539d9c9

Building nginx

Step 1 : FROM nginx:1.10.1-alpine

---> c07e2bb859e2

Step 2 : RUN addgroup -g 1000 -S www-data && adduser -u 1000 -D -S -G www-data www-data

---> Running in c1cd75c7dc52

---> 83528539d9c9

Removing intermediate container c1cd75c7dc52

Successfully built 83528539d9c9