A developer utility for automatically upgrading deprecated code for Silverstripe CMS. With rules for upgrades for Silverstripe 6.

rector is a tool for automatic code upgrades and refactorings. See rector homepage for more information.

This module is installable via composer. As Rector uses PHPstan, it's a good idea to install cambis/silverstan, too.

Note: if you need to use PHPStan v1 in your project, use v0.x of this module

composer require phpstan/extension-installer --dev
composer require cambis/silverstan  --dev
composer require wernerkrauss/silverstripe-rector --dev
vendor/bin/rector init

Create a basic phpstan.neon file in your project root:

parameters:
  level: 1
  paths:
    - app/src

This will add all requirements and create a file called rector.php in your project root. You'll need to adjust it, e.g. add the code directories to upgrade and the rules to use.

A basic Rector config can look like

<?php

declare(strict_types=1);

use Netwerkstatt\SilverstripeRector\Set\SilverstripeLevelSetList;
use Netwerkstatt\SilverstripeRector\Set\SilverstripeSetList;
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPreparedSets(
        deadCode: true,
        codeQuality: true,
        codingStyle: true,
        typeDeclarations: true,
        instanceOf: true,
        earlyReturn: true,
        rectorPreset: true
    )
    ->withPhpSets() //automatically gets the PHP version from composer.json
    ->withSets([
        //silverstripe rector
        SilverstripeSetList::CODE_STYLE,
        SilverstripeLevelSetList::UP_TO_SS_6_0
    ]);

Silverstripe-rector comes with two types of SetLists: SilverstripeSetList for single sets of rectors (e.g. upgrading from 5.0 to 5.1 or for general Silverstripe code styles) and SilverstripeLevelSetList for combining all set lists up to a given Silverstripe CMS version, e.g. running all upgrades to Silverstripe 5.1.

See also Rector documentation for more configuration possibilities.

Once it's configured, you can run Rector in the command line using the following command:

vendor/bin/rector --dry-run 

The option --dry-run prints the code changes; if you're happy with the changes, you can remove that option and rector will actually change the files.

• --debug for debugging verbosity. Which files and rules are processed?
• --xdebug switch that allows running xdebug.

See vendor/bin/rector --help for more options.

See a list of custom Silverstripe related rectors in the docs.

• cambis/silverstripe-rector

• rename Foo_Controller to FooController
  • how can this be made dynamically? via config script that scans the current project?
• configure PSR4 Class To File
• maybe add namespace to src dir
• various deprecations.
  • Is it possible to automate stuff that was once configured in PHP and is now configured in YML?
  • easy fix would be to switch to new config layer in PHP and add an annotation to fix this manually
• fix old Image functions in templates that got deprecated in SS3.2
  • this needs another file parser for Silverstripe templates
• class Object to trait, see ParentClassToTraitsRector

• add $table_name if missing - use short classname instead
  • see similar UnifyModelDatesWithCastsRector
• various deprecations
  • to be configured manually in set lists
• fix missing $owns for Image and File relations
  • configurable exclude list if it's not wanted
  • configurable which relations should be automatically owned (e.g. other versioned DataObjects)

• create SetLists for easier configuration

• convert new Foo() to Foo::create() if it's a Silverstripe / Injectable class
  • see NewToStaticCallRector
• add @config param to $db, $has_one, etc.
• use Request handler instead of superglobal $_GET and $_POST

xini for updating this module to Rector V2 and adding a lot of Silverstripe 6 rules.

If you need some help with your Silverstripe project, feel free to contact me ✉️.

See you at next StripeCon 👋