Programming Tips

Additional Configuration

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:

  • Sync level configurations
    • app.mainio_sync.sync.timeout - The client side timeout for the HTTP calls made to the remote machine’s API during the synchronization process. Defined in seconds.
      • Default: 600 seconds (10 minutes)
    • app.mainio_sync.sync.retry_delay - A delay for waiting before retrying an API call in some failure situations. Defined in seconds.
      • Default: 1 second
    • app.mainio_sync.sync.max_retries - The number of retries that can be made to the API in some failure situations. After this amount is reached, the API call is permanently failed.
      • Default: 5
    • app.mainio_sync.sync.chunksize - The size of the files that get split for easier shipping between the machines. The larger synchronization files are split into parts to avoid issues with PHP maximum execution times. Defined in bytes.
      • Default: 1048576 bytes (1 MB)
  • File level configurations
    • app.mainio_sync.file.base_path - The base path to store the synchronization files in.
      • Default: application/files/mainio_sync
    • app.mainio_sync.file.public_folder - The public folder under the synchronization files folder that is accessible through web requests.
      • Default: public
    • app.mainio_sync.file.protected_folder - The protected folder under the synchronization files folder that is not accessible through web requests.
      • Default: protected

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.

Fix Block Import for Custom Blocks

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:

  • btYourBlock (bID, title)
  • btYourBlockSections (bID, sectionTitle, sectionContent, linkedFileID, linkedPageID)

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:

  1. Using the Add-on
  2. Security
  3. FAQ / Possible Issues
  4. Programming Tips
  5. Additional Information