If you encounter any of the following:

• Problems accessing Codisto LINQ screens
• Catalog synchronisation (Discrepancies between the Magento catalog and what is shown in the Marketplace Listings screen)
• Order synchronisation (Failure to push orders to Magento)
• 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 Magento 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 Magento site is better as you can be certain that the settings associated with the Magento 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 Magento 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 Magento 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.

File Permissions

Codisto LINQ needs read/write access to /var/codisto and <MAGENTO_BASE_DIR>/app/design/ebay. The web server user needs to have adequate permission for those paths.

Run

ls -la <MAGENTO DIR>var/codisto

Check that it is owned by web user and has user read/write on files and read/write/execute on directories.

Disk Space

Codisto LINQ synchronisation creates a synchronisation database. There needs to be adequate disk space on the server to store this file. It will contain the entire catalog.

You can run the following command in Linux to check available disk space on the volume hosting <MAGENTO_DIR>var/codisto:

df -h

Database Triggers / Magento 2 mview

Codisto LINQ uses incremental synchronisation to get product updates such as price, inventory and other catalog changes as quickly as possible without having to synchronise the entire catalog. It adds triggers to the database to maintain a change table (codisto_product_change), which has the Magento Entity ID added to it when an UPDATE statement runs against a catalog record. There are 2 common problems adversely impacting the incremental synchronisation:

Triggers Missing

Magento 1

Ensure the database user set in the Magento configuration has permissions to create triggers. 

GRANT TRIGGER ON <database> TO <webuser>;
SHOW GRANTS FOR <webuser>;

See the canSyncIncrementally function of the plugin to see how the triggers are checked and created:

https://github.com/CodistoConnect/CodistoConnect/blob/e57f94f1300560994ca8947487a518f062cdba3a/code/community/Codisto/Sync/Helper/Data.php#L336

Magento 2

Ensure that MView is functional. Codisto LINQ subscribes to Magento 2 MView. 

Jobs / Processes updating all products regularly

The incremental synchronisation will not be effective if the change tables fill up with a record for every product in the database as a result of an automation which updates every catalog record. Ensure any jobs which run to update the catalog data only update records if there is a change.

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 the following 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 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.

File system - nfs is not supported

Codisto LINQ uses a SQLite database to synchronise catalog data. SQLite uses reader/writer locks to control access to the database, which nfs doesn't reliably support. Please see https://www.sqlite.org/faq.html#q5 for more information.

The synchronisation files are placed into /var/codisto/. If that folder is on an nfs volume but you have a regular volume available (e.g. /tmp) you can create a codisto folder on that volume and then symlink /var/codisto to that newly created folder.

mkdir /tmp/codisto && ln -s /tmp/codisto /var/codisto

Outbound Connections to api.codisto.com

 The plugin signals https://api.codisto.com to notify updates. We attempt to do that in the background so it usually won't block anything, but if the configuration doesn't allow that (see Function Security above) then blocked outbound connections can block inbound requests, especially orders, which do notify product updates back to Codisto.

To test outbound connections, run the following from the command line on your server:

telnet api.codisto.com 443

Custom admin port causing Codisto UI to fail to load

The Codisto LINQ plugin is designed to handle custom admin ports but uses the following function call to determine what the port is:

$request->getServer('SERVER_PORT');

 If that fails to return the port, the Codisto UI screens can't load as the plugin is unable to reliably determine the full admin URL.