Multi-Store Synchronization — Installation and Configuration Guide

This guide covers installing the Multi-Store Synchronization module, connecting two PrestaShop installations and fully configuring catalog synchronization.

Requirements

• Two PrestaShop 8.0 to 9.x installations (databases and hosting may be separate).
• The PHP cURL extension enabled on the store that drives the synchronization.
• The webservice enabled on the remote store, with a dedicated access key.

Installing the module

1. In the back office of the driving store, open Modules > Module Manager.
2. Click Upload a module and send the dfmultisync.zip file.
3. Once installed, the module adds the Advanced Parameters > DF Multi-Store Sync menu.

Enabling the webservice on the remote store

On the store to be connected:

1. Open Advanced Parameters > Webservice.
2. Set Enable PrestaShop’s webservice to Yes and save.
3. Click Add new webservice key, generate a key, then grant GET, POST, PUT and DELETE permissions on: categories, products, images, combinations, stock_availables, specific_prices and languages.
4. Save and copy the generated key.

Adding a remote site

1. Go to DF Multi-Store Sync > Remote sites then Add remote site.
2. Enter a name, the remote store’s root URL (e.g. https://store-b.example.com) and the webservice key copied earlier.
3. Save, then click Test in the list to verify the connection.

Creating a sync profile

A profile describes what to synchronize, in which direction and how to arbitrate conflicts.

Direction: push or pull

• Push — the current store is the source and sends its data to the remote site.
• Pull — the remote site is the source; the current store receives its data.

Entities

Select the entities to synchronize. They are always processed in this order to respect dependencies: categories → products → stock → specific prices.

Options

• Sync images — on push, new local images are sent; on pull, images are downloaded when the product is created.
• Sync specific prices — available in push mode only.
• Batch size — number of entities processed per cycle (1 to 25). Lower it if the remote server is slow.

Conflict strategies

A conflict occurs when both stores have edited the same record since the last sync. Four strategies are available:

• Source wins — the source always overwrites the target.
• Target wins — conflicting entities are skipped.
• Newest wins — modification dates are compared.
• Manual — conflicts are queued for arbitration.

Running a first synchronization

1. Open the module Dashboard.
2. On the profile row, click Run now.
3. Synchronization runs in batches: the progress bar shows live counts of created, updated, skipped, conflicting and errored entities.

Automating with cron

1. Enable the Cron option on the relevant profiles.
2. Copy the cron URL shown on the dashboard (secured by a token).
3. Add it to your server’s crontab, for example every fifteen minutes:

*/15 * * * * wget -q -O /dev/null "https://your-store.com/module/dfmultisync/cron?token=YOUR_TOKEN"

Resolving conflicts

With the Manual strategy, conflicts accumulate in the Conflicts tab. For each pending row:

• Keep local — forces the push of the local version.
• Keep remote — forces the pull of the remote version.
• Ignore — marks the conflict as handled without transferring anything.

Logs and monitoring

The Logs tab keeps a history of operations (info, warning, error), filterable by level and date. Logs are purged automatically after 30 days.

Troubleshooting

The connection test fails

Check that the webservice is enabled on the remote side, that the key is correct and that its permission profile covers the resources listed above. Make sure the URL includes https://.

Some products are skipped

The module matches products and combinations by reference. A product without a reference, or whose reference differs between the two stores, cannot be matched for stock. Set consistent references.

Specific prices do not sync

Specific price synchronization is push only and requires the DELETE permission on specific_prices on the remote side.

Synchronization seems slow

Lower the profile’s batch size and let cron chain the cycles. The first run is always the longest; subsequent runs only transfer entities that actually changed.