Some configuration we do not want to make available through the user interface because we do not want people to mess around with these configurations. In case you misconfigured one of these, you can cause harm to the synchronization process or possibly break it. These are only for some special occasions in case you have problems running the add-on under a specific type of server. The default configuration should be perfectly fine for most of the users.
This configuration can be managed through the “app.php” configuration file located in your application/config folder. An example of the “app.php” configuration file is provided below with all the overridable configuration options. Explanations for each options are available under the configuration example.
<?php return array( ‘mainio_sync’ => array( 'sync' => array( 'timeout' => 300, // 5 minutes 'retry_delay' => 1, // 1 second 'max_retries' => 5, 'chunksize' => 1048576, // in bytes ), 'file' => array( 'base_path' => 'application/files/mainio_sync', 'public_folder' => 'public', 'protected_folder' => 'protected', ), ), );
These configurations allow you to control the following:
For the file level configurations there is currently a restriction that these folders need to be inside the concrete5 installation folder. This is because the files are fetched from these folders during the “Pull” synchronization process.
Some of your custom blocks or blocks provided by packages might not be exporting or importing properly in case they connect to multiple database tables. This is most likely due to the block developer not defining the export tables properly for the block. This should not happen for any blocks that only consist of a single block table but it might be a problem with blocks with multiple linked tables.
Let's say you have a block with the following tables:
And your block controller currently looks like this:
class Controller extends BlockController { public $btTable = 'btYourBlock'; public $btInterfaceWidth = '400'; public $btInterfaceHeight = '500'; // ... some other code }
The developer of this block has not apparently defined the export tables properly, so let's do that. Add the following line to the block controller's properties:
protected $btExportTables = array('btYourBlock', 'btYourBlockSections');
If some of your block tables' columns refer to page or file objects, you also need to tell that to concrete5. Otherwise when your block gets imported, these references might be lost or they might be referring to wrong pages or files after the import. In our example block, we have the "linkedFileID" that is suppsoed to link to a file and "linkedPageID" that is supposed to link to a page. We can fix the export and import of these columns by adding the following lines to the block controller's properties.
protected $btExportPageColumns = array('linkedPageID'); protected $btExportFileColumns = array('linkedFileID');
After these changes the sample block's controller should look something like this:
class Controller extends BlockController { public $btTable = 'btYourBlock'; public $btInterfaceWidth = '400'; public $btInterfaceHeight = '500'; protected $btExportTables = array('btYourBlock', 'btYourBlockSections'); protected $btExportPageColumns = array('linkedPageID'); protected $btExportFileColumns = array('linkedFileID'); // ... some other code }
In case the block has been developed by an external developer and you do not want to touch the block's code, please send a link to this guide to the external developer.
Please continue to read other parts of the documentation: