If you encounter any of the following:

• Problems accessing Codisto screens
• Catalog synchronisation (Discrepancies between the PrestaShop catalog and what is shown in the Marketplace Listings screen)
• Order synchronisation (Failure to push orders to PrestaShop)
• Reduced server performance
• Duplicated orders
• Custom templates not synchronising

Check the following:

 

php.ini

Ensure Memory Limit is adequately set

PHP needs to have enough memory available. 128MB is usually enough. Consider increasing it if descriptions are very large.

Checking current memory limit

Upload a file to your PrestaShop host called phpinfo.php with the following content:

<?php
phpinfo();

Then navigate to that file on your site (e.g. https://<yoursite>/phpinfo.php). You will find the memory_limit setting under Core ( https://<yoursite>/phpinfo.php#module_Core)

Although it is theoretically possible to check this from the command line, using phpinfo in the context of the PrestaShop site is better as you can be certain that the settings associated with the PrestaShop instance are displayed.

Checking if the memory limit needs increasing

Turn on system logging and look for exceptions relating to out of memory in PHP

Function Security

Ensure proc_open is enabled. The synchronisation calls into the PrestaShop codebase but attempts to launch child processes to free up the parent process running in the context of the web server. Not having proc_open enabled makes all the processes run in the web server context, adversely impacting the performance of the site and the admin.

Checking if proc_open and proc_close is available

Look in phpinfo (as described above) under Core for disable_functions and ensure that neither proc_open nor proc_close are listed.

See http://php.net/manual/en/function.proc-open.php for a description of proc_open. There is a sample program there that could be adapted to run in the context of the PrestaShop site to test if proc_open is functioning in that context.

Compression Settings

Ensure that compression settings are consistent between your web server configuration and php.ini

You can check the current zlib settings of PHP by checking the module_zlib section of phpinfo (described above) - https://<yoursite>/phpinfo.php#module_zlib.

You will see something like:

zlib.output_compression Off Off
zlib.output_compression_level -1 -1
zlib.output_handler no value no value

And under core, the following:

output_buffering 4096 4096
output_handler no value no value

To ensure consistency, the Codisto module runs the following in the router, which handles communication:

@ini_set('zlib.output_compression', 'Off');
@ini_set('output_buffering', 'Off');
@ini_set('output_handler', '');

It is possible to lock those values in php,ini to prevent them from being changed, which would cause an inconsistency that can impact the Codisto UI and/or synchronisation.

You can test to see if the settings do change by adding the following to the top of your phpinfo.php file then checking Local:

@ini_set('zlib.output_compression', 'Off');
@ini_set('output_buffering', 'Off');
@ini_set('output_handler', '');

See http://php.net/manual/en/ini.list.php for a list of php.ini directives and under what circumstances they can be changed. See also http://php.net/manual/en/configuration.changes.modes.php.

Another possible cause of discrepancies is .htaccess (or equivalent) where there may be something like:

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

If that htaccess logic doesn’t honour the fact that our output is already compressed (And signified as such in the response headers) and just double compresses - instead of only compressing only uncompressed, then that configuration is incorrect and will lead to problems.

The above example is for illustrative purposes only as it is actually ok. It shows the type of settings to look out for. This line:

mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*

is actually fine as it skips the web server level compression if it detects the app response is already compressed, but not all web server level compression allows that.

 

Cloudflare / Web Application Firewalls

See the following separate articles:

Configuring Cloudflare

Cache Compatibility Issues

IP Address blocks

We have seen situations where traffic originating from our IP is blocked due to configurations that look at the number of requests from an IP address. Please make sure IP addresses are whitelisted:

• 34.218.24.212
• 54.69.97.25
• 52.42.243.67
• 52.10.83.40
• 54.201.114.220

User Agent blocking

Codisto sends the following as user agent:

CodistoConnect/1.0

Ensure that nothing is blocking requests based on unknown user agents and whitelist the Codisto user agent if required.

Database Engine

Codisto relies on a transactional database to ensure orders are either committed completely or not at all. The reason a transactional database storage engine is so important is that our module code already has duplicate order prevention, which only commits the order if it was all successful. A nontransactional database storage engine causes that protection to become irrelevant because every database insert or update happens in isolation, not in a full successful set.

Most Wordpress installations will use MySQL. There are multiple storage engines available for MySQL, not all of which are transactional. MyISAM is not transactional. InnoDB is. So if you are getting duplicated orders, check the storage engine of MySQL and change it to InnoDB if it is MyISAM.

 

404 Error when accessing Amazon & eBay pages

When accessing the pages of the module, such as the Marketplace Listings page, the request should be routed to the module, which proxies that request to our servers to render the UI. If you see an error page like this:

that means the PrestaShop server is not routing the request to the module. Try deacticating then reactivating the module. This will get the module to re-register it's URLs and may fix the problem.

If this doesn't fix the problem, then it is likely a configuration issue, which will need to be referred to your PrestaShop developer. Things to check are:

• .htaccess file or web server configuration for any rules which default to 404 for unrecognized URLs
• Security or redirect modules configured to return 404 for anything unrecognised

Your catalogue is failing to synchronize error

If Customer Service advises that we are getting a 404 error on sync, use the same troubleshooting guides as above for the following URL:

codisto-sync/