Common refactoring for migrations

The following are some common tasks you might need to carry out in order to adapt your Silverstripe project for Silverstripe Cloud compatibility.

Database Credentials

Database parameters are configured outside of your project in the environment file.

Scripts to BuildTasks

The correct way to create compatible automated tasks that will work on Silverstripe Cloud is to make use of BuildTasks. This is because the infrastructure on Silverstripe Cloud is automatically configured and there is no access directly to the terminal of these servers (to setup cronjobs/manually run scripts).

BuildTasks can be accessed through http://yourwebsite/dev/tasks or scheduled to run by setting up a CronTask (see later on in this documentation).

You may already have scripts you have used on past servers that you will have to convert to BuildTasks in order to continue using them.

If your script is php based (a single php procedural file), you should be able to simply copy this code into the BuildTask::run method. In some cases you may have had database connections and SQL calls, if these connect direct to your main Silverstripe CMS you also may wish to refactor these to make use of the ORM classes built into Silverstripe Framework.

For example:

// Old php script
<?php
$conn = new mysqli($servername, $username, $password, $dbname);
$sql = "SELECT * FROM Member";
$result = $conn->query($sql);
print_r($result);
$conn->close();
// New BuildTask
<?php
use SilverStripe\Dev\BuildTask;
use SilverStripe\Security\Member;

class MemberListTask extends BuildTask {
 
    protected $title = 'MemberList';
 
    protected $description = 'Fetch a list of Members in the database';
    
    private static $segment = 'MemberListTask';
 
    protected $enabled = true;
 
    function run($request) {
       $members_orm = Member::get();
    }
}

(You would then be able to run the new task through the browser as http://yourwebsite/dev/tasks/MemberListTask)

If your script included the use of command line such as git and other linux commands, you may still be able to execute these using the php exec() and chdir() commands. While the these commands will run on Cloud they will only be able to affect files within the web root of the site and can only run the command as the default apache user on the system (this is the ‘www-data’ user).

For example:

. . .
     function run($request) {
        chdir(ASSETS_PATH);
        exec('git clone git://github.com/somevendor/somerepo.git foldername');   
     }
. . .

If you need output from these scripts for debugging you can either log these to the Silverstripe Cloud logging tool (Graylog) or look to email yourself the outputs from these build tasks using php’s mail() function or some other method;

If you have any more advanced scripts that are essential to the operation of your website being migrated on to Silverstripe Cloud please discuss with our support team to see if it is possible.

Cron jobs to CronTask module

For setting up cronjob like tasks on Silverstripe Cloud you’ll need to ensure your project has the mandatory CronTask module installed.

Next, you need to define your CronTask, this uses a combination of the familiar Cronjob style scheduling format alongside a php method that will trigger code once the schedule is met. You can use CronTask to trigger your BuildTasks. For example, continuing our example from above:

class DailyCron implements CronTask {

    public function getSchedule() {
        return "0 1 * * *";
    }

    public function process() {
        $task = new MemberListTask()
        $task->run(null); //run() takes an argument of the current request, use null if there is no expected request data to pass in.
        
        //You can run other things here too...
        
    }
}

Silverstripe Cloud Stacks are preconfigured to run CronTasks every minute, these check the schedule you have set up in your CronTask class and if the time of the next run time is met or exceeded (by max of 1 min) the code in the process() method executes (triggering a BuildTask or some other code).

For more information about CronTask visit the CronTask Documentation

Technical note for CronTask: Load balanced Silverstripe Cloud Stacks only trigger CronTasks on one (1) server, any file changes made on that server are then synchronised across the remaining servers. Be aware in some cases there can be a short delay while this sync occurs.

CronTask considerations for virtual stacks

Any CronTasks that run from multiple websites at the same time, will use up a higher amount of resources to process the task. You may want to review the websites running on virtual stacks and their CronTask setups holistically and plan to stagger when the tasks will be run to make best use of the shared Stack resources.

Please see Solr documentation.

Alternative search options

If you don’t require the power or advanced configuration of Solr search, you may want to consider some other options.

External box or third party service - You could connect your Silverstripe Cloud website to an external server or service (such as Google Custom Search or Swiftype)

Internal search - Make use of the built in database powered search (FulltextSearchable::enable();). See https://docs.silverstripe.org/en/developer_guides/search/fulltextsearch/

Frequently Asked Questions

Question: I customised the code in a module or Silverstripe CMS core, what do I do?

Answer: Ideally, it’s best to leave Silverstripe CMS code and module code as is to allow for easy future upgrades. If you can possibly get back to this state, it’s the best option (by moving your customisations into your project code in “mysite”). Alternatively, you can either continue to keep the module as part of your project code, or move your custom version of the module to it’s own git repository and then reference this in your composer.json file with a custom repository reference.

Question: The module I’m using is not registered with Packagist/does not have a composer.json file what now?

Answer: Use the same approach as above, either continue to include the code in your project repository or reference the module in your composer.json using a custom repository reference (you may need to make a fork/copy of the module and add your own composer.json file for this to work).

Was this answer helpful? Yes No

Sorry we couldn't be helpful. Help us improve this article with your feedback.