• Posted on
    October 26, 2017
  • Tags
  • Author

Today, I’ve discovered not yet described problem with Magento 1 PHP 7 compatibility.
On our of stores we care, after PHP 7.0.9 update admin panel resulted in 503 with info:

AH01067: Failed to read FastCGI header

in logs.

Issue was caused by following bug


and the solution is to patch Varien_Http_Adapter_Curl

--- <html>Curl.php (<b>f8d9852</b>)</html>
+++ <html><b>Current File</b></html>
@@ -188,7 +188,7 @@
         } elseif ($method == Zend_Http_Client::GET) {
             $options[CURLOPT_HTTPGET]       = true;
-        if (is_array($headers)) {
+        if ($headers && is_array($headers)) {
             $options[CURLOPT_HTTPHEADER]    = $headers;

If you have some CLI commands that generates a massive amount of output in the console, you can avoid it using the following command

nohup php bin/magento module:status

it will create an nohup.out file in which all the output data will be stored
also we can use it the & (&amp) operator to keep alive the command even if we will logout from the server

php bin/magento Import:import &

hit enter afterwards

Two days after update to Magento 2.2 we encountered this error in the admin panel “Unable to unserialize value.”
Serialization error

After quick debugging it turns out that the error was coused by incorrect value stored in core_config_data table of our magento instalation :

so to solve it set the corresponding values to NULL (via update script or directly in DB) – after this proccess the page should render normally.

Sample install script:

public function install(ModuleDataSetupInterface $setup, ModuleContextInterface $context){






Unfortunately after that we have to setup our configuration all over again – so make sure you made a backup of the data.

  • Posted on
    September 27, 2017
  • Tags
  • Author

Today, immediately after 2.2 official release we decided to update one of the in development project hoping to fix some ongoing issues.

Our stack behind the store was:

– Some Amasty plugins
– Elasticsearch
– Custom theme developed on less preprocessor

Problems spotted and solved:

		Incompatible argument type: Required type: \Magento\Framework\DB\Adapter\AdapterInterface. Actual type: \Magento\Framework\Model\ResourceModel\Db\AbstractDb; File

Update your Amasty modules to newest edition, they have Magento 2.2 support already included

Exception #0 (Exception): Notice: Undefined variable: imageBlockBuilder in /var/www/emilebakker/app/design/frontend/Emile/bakker/Magento_Catalog/templates/product/list.phtml on line 53

Some of the theme overwritten templates can be out of date. There’s no other option then to fix them manually adjusting code with vendor usage.

Errors during compilation:
		Incompatible argument type: Required type: \Magento\Contact\Model\ConfigInterface. Actual type: \Magento\Framework\Mail\Template\TransportBuilder; File: 

Changes are related to custom plugins as well, spending some time for adjusting Dependency Injections and methods.

Compilation from source: /home/eb/domains/emilebakker.ditowebdevelopment.nl/public_html/vendor/magento/theme-frontend-blank/web/css/styles-l.less
variable @copyright__background-color is undefined in file /home/eb/domains/emilebakker.ditowebdevelopment.nl/public_html/var/view_preprocessed/pub/static/frontend/Emile/bakker/en_US/Magento_Theme/css/source/_module.less in _module.less on line 438, column 40
436|     body {
437|         .ie9 & {
438|             .lib-css(background-color, @copyright__background-color);
439|         }
440|     }
441|  in _responsive.less

Remove your var/view_preprocessed dir and let it rebuild. If the problem would persist and you are in hurry try to remove all @copyright__background-color references in vendor (like vendor/magento/theme-frontend-luma/Magento_Theme/web/css/source/_module.less.

Magento 2.2 seems to be bit faster and less buggy out of the box. I regret only that nobody could say the release date on last Meet Magento conference we’ve attended in Krakow speaking only ‘soon’ like year ago. Well, good job anyway that solved lot of bugs well known for months not officially solved until today such as MAGETWO-60602

Don’t forget to check if new Magento 2 folder /generated containing generated di classes is gitignored and would not be pushed to your code source repository

I was working on magento2 and encountered error “Communication link failure: 1153 Got a packet bigger than ‘max_allowed_packet’ bytes”. The shop was quite big because more than 75000 products with a lot of custom attributes more than 150. When I tried to move category I couldn’t and there was no erros, page just reloaded itself after moving and category was back to previous place, when I tried to delete product from admin panel I had above error but after small digging I found a solution. All you need to do is set “net_buffer_length” and “max_allowed_packet”.

Example mysql:
1. set global net_buffer_length=1000000;
2. set global max_allowed_packet=1000000000;


  • Posted on
    May 24, 2017
  • Tags
  • Author

Gitmodule is a powerful feature for keeping all project git hosted repos on their original repositories.

For Magento 1 usage along with modman deployment process it takes following commands:

git submodule add https://github.com/lcbrq/magento-LCB_Faq.git LCB_Faq
git submodule init

modman deploy LCB_Faq

Next, after adding symlinks to .gitgnore file the submodule info could be safely pushed to repository.

git add .modman/LCB_Faq
git add .gitignore
git add .gitmodules

git commit -m “Add LCB_Faq plugin as project submodule”

In your repo the data would be shown as something like Subproject commit ea7099ee02ab3593fe7ae59ee7ec129c54749ec8 instead files.

  • Posted on
    May 17, 2017
  • Tags
  • Author

Today I’ve struggled with very unusual hack. I’ve got a request from my partner to fix one of his clients Magento stores recently listed on Google as hacked site.
My antimalware tools showed nothing wrong in the code, I’ve found nothing wrong in the git repository (later it appeared that the buddy before committed the malware with git add -A from server).

There was nothing wrong with the SEO content in the source code. Usual meta name and description but fetching the site in Google Webmaster tools as Google showed some Viagra etc. words there.

I’ve realized finally, that the hack is good enough to stay visible only for robots which I’ve managed to debug quickly using:

curl -sD – -L -A "Mozilla/5.0 (compatible; Googlebot/2.1;  +http://www.google.com/bot.html)" http://somewebsite.com/customer/account/login/

Indeed, the site content was completely different for human visitor and Google robots indexing the store. Debugging file after file from template to controller and repeating the curl call I’ve found out that app/Mage.php had an addition:

@include_once BP . DS . 'app' . DS . 'etc' . DS . 'modules' . DS . "include.php";

Replacing site content only for robots.
Damn people, always watch what you commit from the server to the repo.

“Share” any kind of data to all views within a controller in Laravel framework

public function __construct()
        //Get from Database some options, for example the header and title of your site
        $site_options = Admin::where('status','active')->first();
        $header = $site_options->site_header;
        $title = $site_options->site_title;

         $data = [


for example set header and title from an active options set.

We had small issue with Cron not working on one of freshly installed Magento 2 store last days. First of all, it’s often to forgot that M2 cron setup requires more than one entry, for not only php /bin/magento cron:run but also php update/cron.php to get rid of that annoying “Cron not working” message readiness check in Component Manager.

Later, checking it manually I’ve found out that php update/cron.php call throws out:

PHP Fatal error: require_once(): Failed opening required '/home/www-data/magento2/update/vendor/autoload.php' (include_path='.:/usr/share/php') in /home/www-data/magento2/update/app/bootstrap.php on line 13 

The repository cloned didn’t have the update packages installed and to solve it it was necessary to run composer install not only in the Magento2 root directory but also update subfolder.

Unusual subfolders (not subdomains) M2 setup can be achievied exactly same way M1 was done.
First of all, create store in your Magento 2 admin, then directory folder.
Two files are required for the operation. Index.php and .htaccess copied from your store.
To run certain M2 store view, it’s enough to replace:

$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $_SERVER);


$params = $_SERVER;
$params[\Magento\Store\Model\StoreManager::PARAM_RUN_CODE] = 'your_store_code'; $params[\Magento\Store\Model\StoreManager::PARAM_RUN_TYPE] = 'store';
$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $params);

Then, set the store url as for subfolder and what’s most important – set base url for static view files to:


and base url for media to


Where example.com is of course your main domain name for the store.

Valid configuration for Nginx can be alike:

location ~ ^/(?<uri_prefix>(en)) {
    rewrite / /$uri_prefix/index.php break;
    echo_exec @phpfpm; 

location ~ ^/(?<uri_prefix>(fr)) {
    rewrite / /$uri_prefix/index.php break;
    echo_exec @phpfpm; 

o.grand_total AS 'Order Total',
o.created_at AS 'Payment Day',
p.method AS 'Payment Method',
CONCAT_WS(' ', o.customer_firstname, o.customer_lastname) AS 'Customer Name',
o.increment_id AS 'Order Number'

FROM sales_flat_order o
LEFT JOIN sales_flat_order_payment p ON p.entity_id = o.entity_id
WHERE (o.created_at BETWEEN '2016-01-01' AND '2016-12-31')

Thank’s to the Hypemedia teamwork we managed to discover very dangerous bug in IWD_ProductLabel 1.4.0 plugin.
The module adds modal on admin pages with some not unique ids like `size`. Because of that, mass attributes update marking attributes not to update via javascript could get unblocked targeting wrong id=”size” node while having one of the following on the store: bg, size, color and padding specified in app/design/adminhtml/default/default/template/productlabel/modal.phtml

The solution to fix it can be very simple. Seems that these IWD productlabel ids are used only to target input for label properly so change them to stay different that any attribute used in your shop.
Here’s the sample git diff:

<label for="bg">Bg color</label>
<input id="bg" class=" input-text" name="text" type="text" value="" />
<p class="note"></p>
<label for="iwd_productlabel_bg">Bg color</label>
<input id="&quot;<br" class=" input-text" name="text" type="text" value="" /> 

Well, we couldn’t figure it out for a while then, suddenly it was clear that PHP allows for a new self directive.

foreach($array as $item){
$entity = new self;
$entity->name = $item->name;
  • Posted on
    September 7, 2014
  • Tags
  • Author

Today, we’ve finally managed to complete our Woocommerce to Magento migration tool. We consider Magento migration a good choice for more demanding customers, offering a fast migration service involving products, attributes and categories.

As the Magento is developed as the ecommerce engine and the Woocommerce is an addon to the great WordPress page/blog cms we always try to research consumers’ needs and the sales concept.

After some brand register related task, we are happy to announce our website launch

Fork us on GitHub