Skip to content

Instantly share code, notes, and snippets.

@iboved
Last active November 7, 2019 08:53
Show Gist options
  • Save iboved/939e38f64edb15320d51146affc3bd2f to your computer and use it in GitHub Desktop.
Save iboved/939e38f64edb15320d51146affc3bd2f to your computer and use it in GitHub Desktop.
Upgrade steps

Upgrade steps:

  1. Update the composer.json file in ALL installations. Here is the correct composer.json file. New commands/dependencies have been added to this file (for example, the Package Discovery command). Now Aliases and Service Providers are registered automatically in OctoberCMS if the package uses Package Discovery.

  2. Upgrade OctoberCMS to 458 Build. If you use composer for upgrading (composer update command), make sure you have 'edgeUpdates' => false and 'disableCoreUpdates' => true in your /config/cms.php file. I remember we had some problems with js/css stuff when upgrading OctoberCMS via composer. We used some commands from this list to compile OctoberCMS backend assets. As for me, I didn't have any problems with backend assets and I didn't run these commands. Perhaps because I installed a new OctoberCMS project with the latest 458 Build, and then I just rolled back to the old Build (therefore, I could have the correct compiled files).

  3. Run database migrations with this command: php artisan october:up.

  4. Update all plugins to the latest versions with this command: php artisan october:update --plugins --force.

  5. Make sure you have new config values in your /config/cms.php file. They have been added in a new build but you can already have them. Make sure you take the value from the .env file for databaseTemplates config like in the example below.

    /*
    |--------------------------------------------------------------------------
    | Automatically run migrations on login
    |--------------------------------------------------------------------------
    |
    | If value is true, UpdateMananger will be run on logging in to the backend.
    | It's recommended to set this value to 'null' in production enviroments
    | because it clears the cache every time a user logs in to the backend.
    | If set to null, this setting is enabled when debug mode (app.debug) is enabled
    | and disabled when debug mode is disabled.
    |
    */
    
    'runMigrationsOnLogin' => null,

    /*
    |--------------------------------------------------------------------------
    | Database-driven Themes
    |--------------------------------------------------------------------------
    |
    | Stores theme templates in the database instead of the filesystem.
    |
    | false - All theme templates are sourced from the filesystem.
    |
    | true  - Source theme templates from the database with fallback to the filesytem.
    |
    | null  - Setting equal to the inverse of app.debug: debug enabled, this disabled.
    |
    | The database layer stores all modified CMS files in the database. Files that are
    | not modified continue to be loaded from the filesystem. The `theme:sync $themeDir`
    | console command is available to populate the database from the filesystem with
    | the `--toFile` flag to sync in the other direction (database to filesystem) and
    | the `--paths="/path/to/file.md,/path/to/file2.md" flag to sync only specific files.
    |
    | Files modified in the database are cached to indicate that they should be loaded
    | from the database.
    |
    */
    
    'databaseTemplates' => env('DATABASE_TEMPLATES', false),
    
    /*
    |--------------------------------------------------------------------------
    | Backend Service Worker
    |--------------------------------------------------------------------------
    |
    | Allow plugins to run Service Workers in the backend.
    |
    | WARNING: This should always be disabled for security reasons as Service
    | Workers can be hijacked and used to run XSS into the backend. Turning
    | this feature on can create a conflict if you have a frontend Service
    | Worker running. The 'scope' needs to be correctly set and not have a
    | duplicate subfolder structure on the frontend, otherwise it will run
    | on both the frontend and backend of your website.
    |
    | true  - allow service workers to run in the backend
    |
    | false - disallow service workers to run in the backend
    |
    */
    
    'enableBackendServiceWorkers' => false,
  1. Make sure you have 'temporaryUrlTTL' => 3600 value in your /config/cms.php like so:
    'storage' => [

        'uploads' => [
            'disk'            => 'local',
            'folder'          => 'uploads',
            'path'            => '/storage/app/uploads',
            'temporaryUrlTTL' => 3600,
        ],

        'media' => [
            'disk'   => 'local',
            'folder' => 'media',
            'path'   => '/storage/app/media',
            'ignorePatterns' => [
                '^\..*',
                '_\d+x\d+\.',
            ],
        ],

    ],
  1. Make sure you have new config values in your /config/database.php file. They have been added in a new build but you can already have them. Make sure you take the value from the .env file for useConfigForTesting config like in the example below.
    /*
    |--------------------------------------------------------------------------
    | Use DB configuration for testing
    |--------------------------------------------------------------------------
    |
    | When running plugin tests OctoberCMS by default uses SQLite in memory.
    | You can override this behavior by setting `useConfigForTesting` to true.
    |
    | After that OctoberCMS will take DB parameters from the config.
    | If file `/config/testing/database.php` exists, config will be read from it,
    | but remember that when not specified it will use parameters specified in
    | `/config/database.php`.
    |
    */

    'useConfigForTesting' => env('DB_USE_CONFIG_FOR_TESTING', false),
  1. Add DATABASE_TEMPLATES=false to the .env file.

  2. Add DB_USE_CONFIG_FOR_TESTING=false to the .env file.

  3. Change the backendSkin value from BusyRoomsCMS\Backend\Skins\BusyRooms to Backend\Skins\Standard in the /config/cms.php file.

  4. Run the SeedCustomizeBackend seeder to seed a custom favicon to use in the backend: php artisan db:seed --class="BusyRoomsCMS\Service\Updates\SeedCustomizeBackend".

  5. In the new OctoberCMS Build we don't need to use the ml prefix in field types in the theme's meta/fields.yaml file. It will not work anymore. To make a field translatable, we need to add translatable: true to the field.

This is wrong:

footer_text:
    label: Footer text
    type: mltext

This is correct:

footer_text:
    label: Footer text
    type: text
    translatable: true

Everything else will be done by our script. You don't need to add translatable fields to $translatable array, you don't need to add repeater fields to $jsonable array. This is all done automatically, you just need to add translatable: true to the translatable field. So, we need to check meta/fields.yaml file in all themes, remove ml prefix from fields (if any) and use translatable: true in these fields. I made all needed changes in the following themes: bachbizetcenterhotelskarajanminimalprivatehcpuccinisalieritchaikovskyvouchershopwagner. Please, inform developers who make themes about these changes (they don't need to use ml prefix in translatable fields, they have to specify translatable: true in these fields). They have to make the needed changes in existing themes (in the meta/fields.yaml file), except themes mentioned above. We need to follow this convention only in theme's meta/fields.yaml file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment