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

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 Wordpress host called phpinfo.php with the following content:

<?php
phpinfo();

Then navigate to that file on your site (e.g. http://ebaydemo.codisto.com/phpinfo.php). You will find the memory_limit setting under Core (http://ebaydemo.codisto.com/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

Function Security

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.

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) - http://ebaydemo.codisto.com/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:

@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 which look at the number of requests from an IP address. Please make sure IP address 54.201.114.220 is whitelisted.

User Agent blocking

Codisto LINQ 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.