Most of the basic block types that only consist of a single block type table are supported by default. Some of the more complex blocks might have issues in case they have been developed by a lazy developer who has not added the support for export and import.
The export and import processes rely on the built-in functionality provided by concrete5. If some block does not implement the support for export or import, it will not be synchronized. All of the core blocks implement the export and import functions. Simple blocks that use a single database table and consist of simple data should also work without issues even if they do not implement the export and import functions.
The following core block types are fully compatible and tested to work properly with the add-on:
In addition to pages and blocks, we also sync the following:
The site structure is preserved during the synchronization. If you try to sync child pages without their parent and the parent is not found on the importing end, the process will be cancelled due to a synchronization error.
The sitemap position of the pages is not preserved during the synchronization unless an existing page is updated. New pages are added to the end of the siblings list. If a page that exists on both sides has been moved, it is treated as a different page. Existing pages are not moved or deleted during import.
URL aliases of pages are synced. In case there are other pages with the same aliases found on the importing end (like in the case of a moved page), those aliases are going to be removed.
As we do not synchronize database tables, there might be cases where a block cannot be synchronized because it uses database records managed through the dashboard. In case the export and import has not been implemented for these records specifically, we also cannot display them in the blocks referring to them.
Comments are not synced or preserved. The discussions block is going to be replaced with a new one. If you have pages with discussions you want to keep, do not synchronize them.
Permissions (on any level: page, area or block) are not currently moved over the two instances you are synchronizing. The permissions will be inherited on the importing end from the current configurations. So, in case you have an existing page with permissions set properly on the importing end, its permissions will not be changed during the content import. However, if you would like your exporting end's permissions to move to the importing end, it is not currently possible. In case you would like to have this feature, feel free to ping us through the support section!
First, a connection is established and activated between the local and the remote machine.
On the exporting side, information about all files is pre-calculated to be able to properly export pages that contain or refer to images and downloadable files. Depending on the amount of files on the website, this process initially might take a significant amount of time. In this case it is recommended to run this process through an automated job provided by this package prior to the synchronization. You will notice if you have issues with this step in case you see an error after trying to run this step of the synchronization.
After the file preparation is completed, the selected pages and the common data are exported in xml format and the related files (e.g. images) are prepared for syncing. The synchronization data files are archived, encrypted, split and sent to the importing end one part at a time. The files to be sent are split into smaller chunks in order to get around possible issues with PHP execution time during the file upload (push) or download (pull).
On the importing end, the chunked archive files are merged and the archive is decrypted and extracted into a protected folder that cannot be accessed with a web browser. Before the actual import, the configuration of the instances is matched as explained under Before Synchronization. After this, the import process continues with the following data import stages:
All page types and global areas are synchronized between the machines during each synchronization, even if the selected pages did not have anything to do with them. This is to avoid issues with the different references to these around the site. For example, in the sample content installation, a blog page contains a page list block that is supposed to list only pages of type “blog post”. If we were syncing that page only and did not synchronize the “blog post” page type, this configuration would not be synchronized properly between the instances.
During the synchronization, new versions are created for the existing pages, global areas and files making it possible to revert the changes made by Mainio Sync.
After the sync is complete, all temporary files are deleted and the connection between the instances is closed.
Please continue to read other parts of the documentation: