Verifying/Troubleshooting Woocommerce configuration for Codisto LINQ
If you encounter any of the following:
- Problems accessing Codisto LINQ screens
- Catalog synchronisation (Discrepancies between the WooCommerce catalog and what is shown in the Marketplace Listings screen)
- Order synchronisation (Failure to push orders to WooCommerce)
- Reduced server performance
- Duplicated orders
- Custom templates not synchronising
Check the following:
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 Wordpress host called phpinfo.php with the following content:
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 Wordpress site is better as you can be certain that the settings associated with the Wordpress instance are displayed.
Checking if memory limit needs increasing
Turn on system logging and look for exceptions relating to out of memory in PHP
Ensure proc_open is enabled. The synchronisation calls in to the Wordpress 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 Wordpress site to test if proc_open is functioning in that context.
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 LINQ plugin runs the following in the router, which handles communication:
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:
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:
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_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
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:
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:
User Agent blocking
Codisto LINQ sends the following as user agent:
Ensure that nothing is blocking requests based on unknown user agents and whitelist the Codisto user agent if required.
Codisto LINQ 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 because our plugin code already has duplicate order prevention, which only commits the order if it was all successful. A non transactional 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.
Custom template files not synchronising
Codisto LINQ uses SQLite to store details of template files needing to be synchronised. If template files don't synchronise, the most likely reason is that the server doesn't have PDO SQLite drivers installed. Ask your host to install them to get template synchronisation working.
404 Error when accessing Amazon & eBay pages
When accessing the pages of the plugin, such as the Marketplace Listings page, the request should be routed to the plugin, which proxies that request to our servers to render the UI. If you see an error page like this:
that means the Wordpress server is not routing the request to the plugin. There are two things that can be done quickly to try to get it going.
1) Navigate to Settings > Permalinks and save without making any changes. That rewrites Permalinks and may fix the problem
2) Deactivate and reactivate the plugin. This will get the plugin to re-register it's URLs and may fix the problem.
If neither of these steps fix the problem, then it is likely a configuration issue, which will need to be referred to your Wordpress developer. Things to check are:
- .htaccess file or web server configuration for any rules which default to 404 for unrecognized URLs
- Security or redirect plugins configured to return 404 for anything unrecognised