Blogs

EMAIL: info@example.com

Category: media

  • Specbee: Improving Site Performance with ImageMagick Drupal Module and WebP

    Specbee: Improving Site Performance with ImageMagick Drupal Module and WebP

    Improving Site Performance with ImageMagick Drupal Module and WebP Manish Saharan 27 Oct, 2021

    We often tend to believe that if an image has to be of great quality, it’s got to be heavy –  you cannot compromise on its size. But this isn’t always true. Drupal’s very own ImageMagick module not only integrates with the fantastic ImageMagick tool that can help you create, compose or edit digital images but also let’s you convert images to reduce its size without jeopardizing its quality.

    You cannot have an interactive and engaging website without including high quality digital images. Great quality images usually add a lot of weight, which can lead to a slow performing website. But with tools like ImageMagick and image formats like WebP that can be leveraged in Drupal, you can provide a faster and better performing web. In this article you will learn about using the ImageMagick Drupal module, WebP image format and how you can implement them in your Drupal 8/9 website

    Drupal Imagemagick Module

    What is the ImageMagick Drupal Module

    ImageMagick is an image toolkit for image API in Drupal 7, 8 and 9. It uses Imagick PHP Extension to create and edit images using the Imagemagick API. With ImageMagick, you can compress the image sizes with better quality. Using ImageMagick you can customize the quality of images from 0 to 100. A higher value means better image quality but bigger files. The Drupal module supports both ImageMagick and GraphicsMagick image processing systems.

    Why use ImageMagick

    • Page Optimization
    • Faster website speed
    • Helps increase the number of pages Google can crawl and index
    • Reduce server load
    • The faster your site loads, the lower the bounce rate
    Imagemagick Toolkit

    ImageMagick Toolkit

    Imagemagick supported format

    ImageMagick supports multiple image formats which can be enabled and disabled as required

    Installing the ImageMagick Module

    Before installing the ImageMagick Drupal module, make sure you have installed ImageMagick on your server and the convert binary needs to be accessible and executable with php.

    Configuration

    Navigate to Administration > Configuration > Media > Image Toolkit and change the Image toolkit to ImageMagick.

    If you are not able to find convert binary command in the default shell path then you need to enter the full path of ImageMagick’s convert executable.

    For example:

    Version Information

    How to install ImageMagick on your server

    • Install ImageMagick using homebrew.
    • Or based on your operating system you can download it from here.
    • On successful installation, your php output should look like this (see below image):
    Imagick

    What is WebP

    WebP is an image format employing both lossy and lossless compression. In a lossless compression, the file size is reduced but not the quality of the image. A lossless compressed image can also be decompressed to its original size. But a lossy compression removes data for good, which means you cannot decompress it back.

    WebP is designed to create files that are smaller for the same quality, or of higher quality for the same size, than JPEG, PNG, and GIF formats. It also supports animation and alpha transparency.

    Implementing WebP with ImageMagick

    Step 1: Enable WebP formats from Image Toolkit format options, which was explained previously.

    Step 2: Now, create a new image style or update any old one with a convert effect. For example:

    Edit thumbnail style

     

    Webp

     

    Step 3: After adding the convert effect, use the same image style to display images and you will see the result.

    Let’s take an example of an image with size 1.2 MB (see below image):

     

    Convert Image

     

    Now check out the results after converting the image:

     

    Reduced file size

     

    You can see that the file size is now reduced to 8.6 KB from 1.2 MB, which is a very good reduction.

     

    Continue reading

  • Mediacurrent: Debugging Composer Dependency Conflicts

    Are you ready to upgrade to Drupal 9? If you’re moving from a Drupal 8 site, it needs to be reviewed and updated to remove any deprecated code that will no longer be compatible with Drupal 9. Luckily, there are a few ways to check existing codebases for deprecated code, get a glimpse of what changes need to be made, and even apply the fixes automatically.

    We have other blog posts that go into details about how to plan, prepare, and fix issues with deprecated code in preparation for Drupal 9, so we won’t go into those details here, but rather walk through a Composer issue we recently ran into while trying to get Drupal Check and Rector utilities added to perform our own code deprecation checks.

    We hope that this blog post helps others with similar Composer issues figure out ways to understand and debug these cryptic errors and be aware of some options and things to try in fixing them.

    The Conflict

    The issue we faced was where a developer had already added the Drupal Check utility a while back, and when adding Rector, you may get Composer conflict messages like this:

    “Your requirements could not be resolved to an installable set of packages.

    Problem 1

        - rector/rector-prefixed v0.3.5 requires phpstan/phpstan ^0.11.19 -> satisfiable by phpstan/phpstan[0.11.19] but these conflict with your requirements or minimum-stability.
    
        - Installation request for palantirnet/drupal-rector ^0.5.1 -> satisfiable by palantirnet/drupal-rector[0.5.1].
    
        - Conclusion: remove nikic/php-parser v4.0.2
    
        - Conclusion: don't install nikic/php-parser v4.0.2
    
        - palantirnet/drupal-rector 0.5.1 requires rector/rector-prefixed <0.7.19 -> satisfiable by rector/rector-prefixed[v0.3.5, v0.6.10, v0.6.12, v0.6.13, v0.6.14, v0.6.2, v0.6.4, v0.6.5, v0.6.7, v0.6.8, v0.6.9, v0.7.0, v0.7.1, v0.7.10, v0.7.11, v0.7.12, v0.7.13, v0.7.14, v0.7.15, v0.7.16, v0.7.17, v0.7.18, v0.7.2, v0.7.3, v0.7.4, v0.7.5, v0.7.6, v0.7.7, v0.7.8, v0.7.9].
    
        - rector/rector-prefixed v0.6.10 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.6.12 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.6.13 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.6.14 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.6.2 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.6.4 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.6.5 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.6.7 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.6.8 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.6.9 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.0 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.1 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.10 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.11 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.12 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.13 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.14 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.15 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.16 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.17 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.18 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.2 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.3 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.4 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.5 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.6 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.7 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.8 conflicts with nikic/php-parser[v4.0.2].
    
        - rector/rector-prefixed v0.7.9 conflicts with nikic/php-parser[v4.0.2].
    
        - Installation request for nikic/php-parser 4.0.2 -> satisfiable by nikic/php-parser[v4.0.2].
    
    Installation failed, reverting ./composer.json to its original content.

    This can be pretty scary to look at and digest what it all means. But, let’s just start at the top.

    Step 1

    The first problem stated is:

    - rector/rector-prefixed v0.3.5 requires phpstan/phpstan ^0.11.19 -> satisfiable by phpstan/phpstan[0.11.19] but these conflict with your requirements or minimum-stability.

    So, first, let’s look at the composer.json file. We only really care about the “require-dev” section, since we’re only dealing with the development utility scripts Drupal Check and Rector in this example, but these same investigation and debugging steps in Composer can apply similarly to items in the “require” section as well, like Drupal modules and their dependencies.

    "require-dev": {
    
       "drupal/drupal-extension": "^3.4",
    
       "drush-ops/behat-drush-endpoint": "^8.2.4",
    
       "mediacurrent/ci-scripts": "~1.2",
    
       "mediacurrent/ci-tests": "dev-master",
    
       "mediacurrent/mis_vagrant": "^5.1.0",
    
       "mglaman/drupal-check": "^1.0",
    
       "nikic/php-parser": "4.0.2",
    
       "phpro/grumphp": "^0.11.6",
    
       "phpstan/phpstan": "0.11.9",
    
       "webflo/drupal-core-require-dev": "^8.8.1"
    
    },

    Notice how there is a strict version set for the phpstan package? What’s happening is the Rector tool is trying to add a dependency package, rector/rector-prefixed v0.3.5, but that requires phpstan ^0.11.19 (so 0.11.19 or greater). And because we have a strict 0.11.9 for phpstan in composer.json, it can’t add what it needs.

    A first attempt to fix this would be to try installing a version of phpstan that it wants, so we can try something like:

    composer require --dev phpstan/phpstan:^0.11.19

    After running that, it looks better, but still some issues:

    Your requirements could not be resolved to an installable set of packages.

    Problem 1

     - Can only install one of: nikic/php-parser[v4.0.2, 4.3.x-dev].
    
        - Can only install one of: nikic/php-parser[4.3.x-dev, v4.0.2].
    
        - Can only install one of: nikic/php-parser[4.3.x-dev, v4.0.2].
    
        - phpstan/phpstan 0.11.19 requires nikic/php-parser ^4.2.3 -> satisfiable by nikic/php-parser[4.3.x-dev].
    
        - Installation request for phpstan/phpstan ^0.11.19 -> satisfiable by phpstan/phpstan[0.11.19].
    
        - Installation request for nikic/php-parser 4.0.2 -> satisfiable by nikic/php-parser[v4.0.2].

    That issue is caused because of more strict package versions in composer.json — especially with the nikic/php-parser package.

    "nikic/php-parser": "4.0.2"

    This version constraint is causing this issue:

    - phpstan/phpstan 0.11.19 requires nikic/php-parser ^4.2.3 -> satisfiable by nikic/php-parser[4.3.x-dev].

    Step 2

    Upon further inspection in the repo and commit history, we’ve concluded that the previous developer added those packages manually to the composer.json file (well, Composer-required them), but they shouldn’t have been added in that way, since they should be letting Composer manage them as dependencies.

    Sometimes when debugging Composer dependencies we try one strategy and if that doesn’t work we revert back and try something different.

    Now that it seems that these packages were added manually to the projects in error, we can pull them out of the codebase and let Composer manage them as dependencies in a way it needs.

    Remove the phpstan package from composer.json:

    composer remove phpstan/phpstan

    It looks like this removed the package from composer.json, and updated the package to a newer version because phpstan is still a dependency of Drupal-check’s constraint set at ^0.11.9. And 0.11.12 is the latest version in that constraint.

    But, it’s still not going to be good enough, because remember Drupal Rector rector-prefixed package needs at least 0.11.19 per the ^0.11.19 constraint.

    Step 3

    Remove the php-parser package from composer.json:

    composer remove nikic/php-parser

    It looks like it removed the php-parser package from composer.json, and updated the package to v4.4.0

    Loading composer repositories with package information
    
    Updating dependencies (including require-dev)
    
    Package operations: 0 installs, 1 update, 0 removals
    
    Gathering patches for root package.
    
    Gathering patches for dependencies. This might take a minute.
    
      - Updating nikic/php-parser (v4.0.2 => v4.4.0): Loading from cache

    That’s fine, we’ll just let Composer manage the dependencies itself, but we’ve cleaned up the composer.json of packages that shouldn’t have been there and were conflicting.

    Let’s see if we can get Drupal Rector added now that the conflicting packages are removed:

    composer require --dev palantirnet/drupal-rector

    Nope, still some of the same issues as in the beginning:

    Loading composer repositories with package information
    
    Updating dependencies (including require-dev)
    
    Your requirements could not be resolved to an installable set of packages.

      Problem 1

        - Installation request for palantirnet/drupal-rector ^0.5.1 -> satisfiable by palantirnet/drupal-rector[0.5.1].
    
        - Conclusion: remove phpstan/phpstan 0.11.12
    
        - Conclusion: don't install phpstan/phpstan 0.11.12
    
        - rector/rector-prefixed v0.3.5 requires phpstan/phpstan ^0.11.19 -> satisfiable by phpstan/phpstan[0.11.19].
    
        - palantirnet/drupal-rector 0.5.1 requires rector/rector-prefixed <0.7.19 -> satisfiable by rector/rector-prefixed[v0.3.5, v0.6.10, v0.6.12, v0.6.13, v0.6.14, v0.6.2, v0.6.4, v0.6.5, v0.6.7, v0.6.8, v0.6.9, v0.7.0, v0.7.1, v0.7.10, v0.7.11, v0.7.12, v0.7.13, v0.7.14, v0.7.15, v0.7.16, v0.7.17, v0.7.18, v0.7.2, v0.7.3, v0.7.4, v0.7.5, v0.7.6, v0.7.7, v0.7.8, v0.7.9].
    
        - Can only install one of: phpstan/phpstan[0.11.19, 0.11.12].
    
        - rector/rector-prefixed v0.6.10 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.6.12 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.6.13 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.6.14 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.6.2 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.6.4 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.6.5 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.6.7 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.6.8 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.6.9 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.0 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.1 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.10 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.11 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.12 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.13 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.14 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.15 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.16 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.17 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.18 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.2 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.3 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.4 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.5 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.6 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.7 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.8 conflicts with phpstan/phpstan[0.11.12].
    
        - rector/rector-prefixed v0.7.9 conflicts with phpstan/phpstan[0.11.12].
    
        - Installation request for phpstan/phpstan (locked at 0.11.12) -> satisfiable by phpstan/phpstan[0.11.12].
    
    Installation failed, reverting ./composer.json to its original content.

    Step 4

    So let’s dive deeper. Looking at the Drupal Check’s composer.json, we can see phpstan is listed as a dependency, so why are we including phpstan in our own composer.json?

    "phpstan/phpstan": "^0.12"

    Well, that’s on the latest (master) version of Drupal check:

    https://github.com/mglaman/drupal-check/blob/master/composer.json

    Running this command, we can see the version of Drupal check we’re currently running is:
    ./vendor/bin/drupal-check –version

    Drupal Check 1.0.13

    So, let’s check this version’s composer.json instead:

    https://github.com/mglaman/drupal-check/blob/1.0.13/composer.json

    We can see it’s still 

    "phpstan/phpstan": "^0.11.9"
    Update phpstan
    Loading composer repositories with package information
    
    Updating dependencies (including require-dev)
    
    Package operations: 0 installs, 1 update, 0 removals
    
    Gathering patches for root package.
    
    Gathering patches for dependencies. This might take a minute.
    
      - Updating phpstan/phpstan (0.11.12 => 0.11.19): Loading from cache

    Now we have the right version we’re needing for Drupal Rector.

    Loading composer repositories with package information
    
    Updating dependencies (including require-dev)
    
    Package operations: 3 installs, 0 updates, 0 removals
    
    Gathering patches for root package.
    
    Gathering patches for dependencies. This might take a minute.
    
      - Installing rector/rector-prefixed (v0.3.5): Loading from cache
    
      - Installing jawira/case-converter (v1.2.0): Loading from cache
    
      - Installing palantirnet/drupal-rector (0.5.1): Loading from cache

    Success!

    So that seems fishy — because Drupal Check has a dependency of phpstan ^0.12, but we already have a phpstan 0.11.9 in our composer.json file. Why do we even have phpstan listed in our “require-dev”?

    So next, we’re going to try unwinding some things and see if we can get this working.

    Step 5

    Let’s first remove Drupal Check:

    composer remove phpstan/phpstan

    This results in a few updates, most notably phpstan being updated to 0.11.12, which matches to the ^0.11.9 constraint set forth for the version of Drupal check we’re using.

    Updating dependencies (including require-dev)                                                                         
    
    Package operations: 0 installs, 13 updates, 0 removals
    
    Gathering patches for root package.
    
    Gathering patches for dependencies. This might take a minute.
    
      - Updating ocramius/package-versions (1.4.0 => 1.4.2): Loading from cache
    
      - Updating symfony/debug (v3.4.39 => v3.4.40): Loading from cache
    
      - Updating symfony/finder (v3.4.39 => v3.4.40): Loading from cache
    
      - Updating symfony/console (v3.4.39 => v3.4.40): Loading from cache
    
      - Updating nette/utils (v3.0.1 => v3.1.1): Loading from cache
    
      - Updating nette/schema (v1.0.0 => v1.0.2): Loading from cache
    
      - Updating nette/finder (v2.5.1 => v2.5.2): Loading from cache
    
      - Updating nette/robot-loader (v3.2.0 => v3.2.3): Loading from cache
    
      - Updating nette/php-generator (v3.2.3 => v3.3.4): Loading from cache
    
      - Updating nette/neon (v3.0.0 => v3.1.2): Loading from cache
    
      - Updating nette/di (v3.0.1 => v3.0.3): Loading from cache
    
      - Updating nette/bootstrap (v3.0.0 => v3.0.1): Loading from cache
    
      - Updating phpstan/phpstan (0.11.9 => 0.11.12): Loading from cache

    And we know that this php-parser package was added manually as well, similar to how phpstan was added manually, so we can remove it too. There is no reason to add these dependency packages manually, we can just let Composer manage them.

    composer remove nikic/php-parser
    Running that results in this output:
    Updating dependencies (including require-dev)                                                                         
    
    Package operations: 0 installs, 1 update, 0 removals
    
    Gathering patches for root package.
    
    Gathering patches for dependencies. This might take a minute.
    
      - Updating nikic/php-parser (v4.0.2 => v4.4.0): Loading from cache

    Using Composer why nikic/php-parser, we can see why the nikic/php-parser package is needed

    phpstan/phpstan                    0.11.12  requires  nikic/php-parser (^4.0.2)

    phpstan/phpstan-deprecation-rules  0.11.2   requires  nikic/php-parser (^4.0)

    psy/psysh                          v0.9.9   requires  nikic/php-parser (~1.3|~2.0|~3.0|~4.0)

    Step 6

    Let’s upgrade Drupal check

    composer update mglaman/drupal-check --with-dependencies
    
    Updating dependencies (including require-dev)                                                                         
    
    Package operations: 0 installs, 3 updates, 0 removals
    
    Gathering patches for root package.
    
    Gathering patches for dependencies. This might take a minute.
    
      - Updating phpstan/phpstan (0.11.12 => 0.11.19): Loading from cache
    
      - Updating symfony/yaml (v3.4.39 => v3.4.40): Loading from cache
    
      - Updating mglaman/drupal-check (1.0.13 => 1.0.14): Loading from cache

    Ah ha! It looks like we’re now on the right version of phpstan 0.11.19 that will support us in adding the Drupal Rector

    Let’s try adding Drupal Rector again now:

    composer require --dev palantirnet/drupal-rector
    
    Updating dependencies (including require-dev)                                                                         
    
    Package operations: 3 installs, 0 updates, 0 removals
    
    Gathering patches for root package.
    
    Gathering patches for dependencies. This might take a minute.
    
      - Installing rector/rector-prefixed (v0.3.5): Loading from cache
    
      - Installing jawira/case-converter (v1.2.0): Loading from cache
    
      - Installing palantirnet/drupal-rector (0.5.1): Loading from cache

    Remember back to the first Composer issue we looked at with the “rector/rector-prefixed” package? We can now see that Rector was successfully able to add it.

    Gathering patches for dependencies. This might take a minute.
    
      - Installing rector/rector-prefixed (v0.7.18): Loading from cache
    
      - Installing jawira/case-converter (v1.2.0): Loading from cache
    
      - Installing palantirnet/drupal-rector (0.5.1): Loading from cache

    And there are currently no other Composer issues being thrown at us.

    The Final Step for a Clean Solution

    We discovered that local dependencies were being locked to a specific version and by removing those, Composer was able to correctly reconcile the dependencies for these packages. This is somewhat dependent on and specific to your own build processes and environments, but you should be set to run Drupal Check and Rector and begin your journey and preparations for Drupal 9.

    Final cleanest, best solution in our opinion…

    Packages added manually, but should have just been added as dependencies and managed by Composer:

    composer remove phpstan/phpstan
    
    composer remove nikic/php-parser
    
    
    
    Updated drupal-finder
    
    composer update webflo/drupal-finder
    
    Loading composer repositories with package information
    
    Updating dependencies (including require-dev)
    
    Package operations: 0 installs, 1 update, 0 removals
    
    Gathering patches for root package.
    
    Gathering patches for dependencies. This might take a minute.
    
      - Updating webflo/drupal-finder (1.1.0 => 1.2.0): Loading from cache
    
    
    
    composer update mglaman/drupal-check --with-dependencies
    
    Loading composer repositories with package information
    
    Updating dependencies (including require-dev)
    
    Package operations: 0 installs, 5 updates, 7 removals
    
      - Removing phpstan/phpdoc-parser (0.3.5)
    
      - Removing nette/schema (v1.0.2)
    
      - Removing nette/robot-loader (v3.2.3)
    
      - Removing nette/php-generator (v3.3.4)
    
      - Removing nette/di (v3.0.3)
    
      - Removing nette/bootstrap (v3.0.1)
    
      - Removing mglaman/phpstan-junit (0.11.2)
    
    Gathering patches for root package.
    
    Gathering patches for dependencies. This might take a minute.
    
      - Updating phpstan/phpstan (0.11.12 => 0.12.23): Loading from cache
    
      - Updating phpstan/phpstan-deprecation-rules (0.11.2 => 0.12.2): Loading from cache
    
      - Updating symfony/yaml (v3.4.39 => v3.4.40): Loading from cache
    
      - Updating mglaman/phpstan-drupal (0.11.10 => 0.12.3): Loading from cache
    
      - Updating mglaman/drupal-check (1.0.13 => 1.1.1): Loading from cache
    
    
    
    composer require --dev palantirnet/drupal-rector

    Still not confident about your preparedness to upgrade, or short on time or team capacity? We can help you get ready for Drupal 9

    Continue reading

  • Tag1 Consulting: On 20 Years of Drupal – an interview with James Rutherford

    Tag1 continues its series celebrating 20 Years of Drupal in this Tag1 Team Talk with Pantheon’s Senior Manager of Strategic Partnerships, James Rutherford. Before moving to Pantheon, James was a long time member of Mediacurrent, one of the largest agencies working with and creating Drupal websites. James joins Tag1 Managing Director Michael Meyers for another trip down the halls of Drupal history, from early versions of Drupal, to today’s highly experienced agencies. James’ initial Drupal experience was with Georgia Public Broadcasting. Over the years, James has worked with many clients – some of whom moved to Drupal from their homegrown CMS, to major launches such as weather.com. Join us for this talk, and learn more about how it’s not just the code – it’s the community that makes Drupal successful. — For a transcript of this video, see Transcript – 20 years of Drupal with James Rutherford. — Photo by Moritz Kindler on Unsplash

    lynette@tag1co… Mon, 10/18/2021 – 07:07

    Continue reading

  • OpenSense Labs: Drupal accessibility modules: The essentials

    OpenSense Labs: Drupal accessibility modules: The essentials

    Drupal accessibility modules: The essentials Maitreayee Bora Mon, 10/18/2021 – 16:52

    Web accessibility is always prioritized by Drupal to provide its potential users a decent user-experience. Without any fail, Drupal has succeeded in providing an extensive range of modules that can be downloaded according to user convenience. This platform has consistently put efforts in bringing significant improvements in all its versions when it comes to accessibility modules. So, with this article, I will try to give you an insight of some of the recently refreshed or newly released Drupal modules that will efficiently help you in your various challenging projects. You will also get the answer to a common question that often comes to your mind, “Why Drupal for accessibility”?

    To begin with, for your better understanding, I am describing the Drupal web accessibility modules by categorizing them based on their different functionalities. 

    Illustration diagram describing drupal logo and accessibility symbol


    Accessibility Auditing

    Under this category Drupal has a sufficient number of modules that help in offering you an enhanced accessibility audit for your ambitious projects.

    Illustration diagram describing drupal accessibility auditing modules


    Editoria11y Accessibility Checker

    Editoria11y can be termed as a user-friendly checker that provides support to the content authors and editors. Compatible with Drupal 9, it also looks after the three most vital needs of the content authors. 

    • It makes sure that the spellcheck is constantly running and rectifies the content mistakes when it occurs.
    • It makes sure that no mistakes take place in terms of Views, Layout Builder, Media and other modules, as it runs in context with them and it’s checkers are also constantly on. 
    • It prioritizes content issues by fixing them, also ensuring that the page editors do not omit any issue that is easily rectifiable.

    Monsido Tools

    Monsido helps in smooth optimization of your website, also focusing on web governance, quality assurance, and accessibility compliance. Since accessibility laws differ from country and sector, this module helps in validating your site against the international standard, the WCAG 2.1. This module which is compatible with Drupal 9 provides your site with the scanning facility to identify any difficulties that might further hamper accessibility, and also enhances your search engine rankings by recognizing SEO errors. 

    Siteimprove

    Known as the most comprehensive cloud-based Digital Presence Optimization (DPO) software, Siteimprove enables you in creating high quality content, editing efficiently, driving better traffic, measuring digital performance and working towards regulatory compliance. Siteimprove plugins help in filling the gap between Drupal and the Siteimprove Intelligence Platform, also empowering contributors to test, fix and optimize their work without any hurdles. This module has Drupal 9 compatibility which is an added advantage.

    CKEditor Accessibility Auditor

    CKEditor Accessibility Auditor is a module that has Drupal 9 compatibility and it functions by clicking a button which runs the HTML_CodeSniffer Accessibility Auditor on the source code of the current content. With this module, you get to access a detailed view on any type of specific error, convenient success criteria and suggestions of techniques, and also upon what exactly triggered the error, once you run the auditor. 

    CKEditor Accessibility Checker

    CKEditor Accessibility Checker helps in enabling the Accessibility Checker plugin from CKEditor.com in your WYSIWYG. You can inspect the accessibility level of content that is generated in CKEditor, and resolve any accessibility concerns at the earliest. 

    Sitemorse Lite – a11y Audit

    Integrating Drupal with the inCMS service, this module enables to run the on-page accessibility audits and view results from the Drupal Administration interface. Sitemorse along with Ixis bring you a Drupal connector that provides the facility of checking your content quality before it gets published. Additionally, this module is compatible with Drupal 9 as well. With this module, the content editors can have more command over their content by making it more SEO friendly, accessible and resolving any issues that adversely affect the customer experience. 

    Accessibility

    The Accessibility module is a great support for the content authors and theme developers as it enables them to make their websites accessible to the users regardless of their capabilities and the technologies they prefer. It offers a set of available Accessibility tests that helps in scrutinizing the content for any accessibility errors that are published by the editors. Since this module uses the QUAIL jQuery plugin, it is not covered by Drupal’s security advisory policy.

    Accessibility Scanner

    The Accessibility Scanner module enables you to use Drupal along with Axe toolset to opt for web accessibility scans on local and remote websites within the Drupal admin interface. It is compatible with Drupal 9 but isn’t covered by Drupal’s security advisory policy.

    USWDS Ckeditor Integration

    The USWDS library has become an essential requirement for government websites. This module majorly focuses on making a user to smoothly utilize and inject USWDS classes and components into the ckeditor without even opening the source event for a single time. The USWDS Ckeditor Integration module is compatible with Drupal 9.

    Quail API

    This module is a complete rework of parts of the Drupal 6 project known as “Accessible Content”. It offers an API for the 3rd-party Quail Library to Drupal modules. Quail API has Drupal 8 alpha version as well.

    Site builders

    This is the second category under which Drupal offers exclusive modules to its users which enable them to design and create functional sites without the need of manual code editing.

    Illustration diagram describing drupal site builders modules


    Automatic Alternative Text

    Automatic Alternative Text module allows you to automatically generate an image caption, while none of the Alternative Text has been given by the users. It is made possible by using the Microsoft Azure Cognitive Services API. This module offers one or even more descriptions of an image that are ordered as per their confidence. Although the default descriptions are in English, there is an option of translating them into other languages. This module is also compatible with Drupal 9. 

    iFrame Title Filter

    To comply with WCAG guidelines, the iFrame Title Filter helps in ensuring that embedded tags include a title attribute. When there is no title attribute available in an iFrame, this particular filter parses the src attribute’s URL and also adds a title attribute which reads “Embedded content from [url]”. There are many Drupal filters that generate iframes, for example, media, video_filter but their compliance with iFrame accessibility needs differs. It is compatible with Drupal 9.

    Text field formatter

    Text field formatter module which is compatible with Drupal 9 can be termed as the extension of the plain text formatter. The main concept of creating this module came from another similar module known as String field formatter. The main features of Text field formatter include: 

    • Adding additional wrapper to the text field.
    • Adding classes to this wrapper.
    • Adding any of the attributes to this wrapper and 
    • Ability to override a link label (tokens are supported).

    This module is compatible with Linked Field and Layout Builder. 

    Field Display Kit

    The Field Display Kit module enables fine tune rendering of any field in the system. The main features of this module consist of:

    • Independently changing title (label) of the field in every display (identified as view mode).
    • Ability to change the title (label) element tag, along with adding classes and some other attributes to the wrapper.
    • Ability to change the wrapper element of the field, and also add classes and other attributes to the wrapper.
    • Ability to change the wrapper element of every individual field item, and also add classes and other attributes to the wrapper and
    • Ability to link any field item. Therefore, to build the link, tokens like [node:url] can be used. 

    When authorized, this module helps in facilitating configurations for each field on each entity of your site. It works with fields which are normally displayed or with Layout Builder as well. It is compatible with Drupal 9 but isn’t covered under Drupal’s security advisory policy.

    Block ARIA Landmark Roles

    Taking inspiration from Block class, the Block ARIA Landmark Roles module prioritizes on adding additional elements to the block configuration forms that helps users to assign a ARIA landmark role and/or ARIA labels to a block. It is compatible with Drupal 9.

    A11Y Paragraphs Tabs

    With the A11Y Paragraphs Tabs module, you get the authority to smoothly add tabs through paragraphs to your content which complies with the standards of Accessibility (A11Y). The paragraphs which are already configured, to provide you tabs on desktop and an accordion on mobile are added by this module. There is no need to configure anything from your end. The three new paragraphs created by this module consist of:

    • A11Y Paragraphs Tabs Wrapper
    • A11Y Paragraphs Tabs Panel
    • A11Y Paragraphs Tabs Content

    The wrapper (A11Y Paragraphs Tabs Wrapper) consists of the tab panel (A11Y Paragraphs Tabs Panel) that enables you to add tabs according to your convenience. On the other hand, the tabs panel (A11Y Paragraphs Tabs Panel) consists of a paragraph in which you are able to add the paragraphs you would prefer to use inside the tab panel. It is compatible with Drupal 9.

    Decorative Image Widget

    The Decorative Image Widget proves to be a solution for the site builders that prefers the option of leaving an image’s alternative text blank explicit (by checking a new “Decorative” checkbox) instead of implicit (by simply leaving the alt text field blank). To put it simply, the editors are made to affirm the reason behind leaving alt text empty, which is because of the decorative image that needs to be hidden from the screen readers. The primary features of this module consist of: 

    • Providing an option of a “Decorative” checkbox to image widgets that has to be checked if the user chooses to leave the alt text empty.
    • Forcing users to focus upon alternative text instead of leaving it blank. 
    • Working with any existing image widget which extends from core’s default. For example, it can be used with the default image widget or the one offered by Image Widget Crop.
    • Lastly, there is no need for any kind of data model changes, since the position of the state of the “Decorative” checkbox is completely inferred from the value of the alt text.

    This module is compatible with Drupal 9 but isn’t covered under Drupal’s security advisory policy.

    A11Y: Form helpers

    A11Y: Form helpers module helps you to make forms more accessible in Drupal. Following are the modules features: 

    • You do not need any HTML5 validation.
    • You can include readable inline error messages for screen readers.
    • You can also put in pre-filled attributes to certain form elements.

    This module is compatible with Drupal 9 but isn’t covered under Drupal’s security advisory policy.

    CKEditor Abbreviation

    CKEditor Abbreviation module helps you in adding a button to CKEditor for inserting and editing abbreviations. This module also has an added benefit i.e., the availability of a link to edit the abbreviation. It is compatible with Drupal 9.

    Node Link Report

    Since links within content can take various forms in WYSIWYG, such as link fields, free text, entity reference fields and many more. It might be a difficult task to ensure that links are not broken in your content. But the Node Link Report module offers you a block which displays a link report also including all the links in the rendered note. It enables you to display the links on node view, node edit, and node preview as well. Also, it is compatible with Drupal 9.

    Devel Accessibility

    The Devel Accessibility module offers support to the module developers by providing them an API for aria-live region update announcements. It is compatible with Drupal 9.

    CKEditor Balloon Panel

    CKEditor Balloon Panel module allows the Ballon Panel plugin from CKEditor.com in your WYSIWYG editor. The Balloon Panel plugin offers the capacity for creating a floating, balloon-shaped container that is capable enough of presenting content at the preferred position in the document. The CKEditor Accessibility Checker uses this module to create the floating panels with accessibility tips. 

    Developers

    Under the third category, Drupal provides significant modules to the developers that helps in enhancing their experience in building well-designed and user-friendly websites. 

    Illustration diagram describing drupal developers modules


    WCAG Drawer

    The WCAG Drawer module is compatible with Drupal 9 and has Drupal 8 alpha version. Although it isn’t covered under Drupal’s security advisory policy, you can take the benefit of utilizing the framework offered by this module in order to create easily accessible drawers.

    Color Swatch

    Color Swatch module is considered as an alternative to the Drupal Core color module and color scheme. This module prioritizes supplying a css with the preferred colors. And it is also said to be flexible as the generated css isn’t compiled in the form of a file but rather added as an inline css. Additionally, the css operates via rendering of a twig file with a theme function that provides more control from preprocess functions, and also twig template overrides on a theme level. This module is compatible with Drupal 9 but isn’t covered under Drupal’s security advisory policy.

    End-users

    Under this category, the end-users of Drupal are offered with some unique modules that enable them to witness an excellent experience while building their respective projects.

    Illustration diagram describing drupal end users modules


    Accessibility Enabler

    People with any kind of disability can easily consume and navigate sites in a very effective way with Accessibility Enabler. It also meets the differently abled population in using the preferred content, enhancing accessibility, and increasing the sales and conversation. It helps in making your site more compliant with accessibility regulations of your country, preventing lawsuits and heavy penalties. You get an opportunity to build your brand among your customers, and also exhibit social responsibility by increasing accessibility via this module. The key features includes:

    • Availing accessibility tools for each and every disability.
    • Providing intelligent design for mobile.
    • Availing accessibility presets for each persona.
    • Option to put accessibility triggers anywhere.
    • Ability to change accessibility trigger button position.
    • Facility of making your own custom trigger.
    • Multiple color theme options.
    • Freedom to express your commitment towards accessibility.
    • Enhancing your site navigation to the best of its ability and
    • Ability to return to the top of the page easily.

    This module isn’t covered under Drupal’s security advisory policy.

    Civic Accessibility Toolbar

    Civic Accessibility Toolbar facilitates a block with accessibility utilities to enable end-users switch theme versions with higher color contrast and also change font size of text. You can create a block with both or one of the utilities to allow visually impaired users access Drupal sites without any difficulty. It is further tested with Bartik, Garland, Zen Starterkit, Stark, Oliveiro themes and is compatible with Drupal 9.

    Text Size

    For a better web accessibility, the text size module exhibits an adjustable text size changer or a zoom function on the page. Although, in Firefox 3, the zoom function is comparable to the text zoom function, this module also resizes vector images, variable pixel images and variable media objects. 

    Text Resize

    The Text Resize module provides a great support for the visually impaired people by increasing the accessibility of the pages with necessary text size adjustments. By using jQuery and the jQuery Cookie plugin, this module creates a Drupal block which can be themed. Moreover, it gives the option to resize  images as well. Also, never forget to enable the “Text Resize” block of your theme to help the block appear.

    High contrast

    With the High contrast module, you are able to smoothly switch the active theme and a high contrast version of it. You will only need to press the tab on the keyboard after installing the module and will then get the high contrast pop-up link on the screen. It is compatible with Drupal 9.

    Voice Search Redirect

    The Voice Search Redirect module enables you to redirect on any page with the help of voice command. And there is no need to click manually on the menu. This module isn’t covered under Drupal’s security advisory policy.

    Fluidproject UI Options

    Fluidproject UI Options offers accessibility options to its users to modify a page’s font size, font style, link style, line height and contrast using cookies. But there are some limitations such as:

    • Internationalization is done through JSON files within the module folder instead of the Drupal interface. 
    • Although this module is tested successfully with the most popular themes, some of the themes like Bootstrap require additional CSS for font-sizing or line heights to work. 
    • The contrast settings do not prefer working for elements that use CSS gradients.

     It is compatible with Drupal 9.

    Style Switcher

    The Style Switcher module empowers themers to create themes with alternate stylesheets, and site builders to add other alternate stylesheets in the admin section. It provides all those styles to site visitors in the form of a list which consist of links in a block. This helps the site visitors to select the style of the site they prefer. Cookies are being used by this module so that when people return to the site or even visit a different page they still get their preferred style. It is compatible with Drupal 9.

    Generic HTML validations

    The modules under this category enhance the overall accessibility for screen readers and other non-browser devices.

    Illustration diagram describing drupal generic HTML validations


    htmLawed

    Along with accessibility, the htmLawed module also provides you security. This module restricts and purifies HTML code for compliance with the site administrator policy and standards and for security by using the htmLawed PHP library. In addition to that, you are allowed to autocorrect and beautify HTML markup, restrict HTML elements, attributes and URL protocols in the input. It helps in balancing tags and ensuring that HTML elements are well nested, , transforms deprecated tags and attributes, and many more. It is compatible with Drupal 9.

    HTML Purifier

    Similar to the htmLawed module, the HTMLPurifier library is a great mix of both accessibility and security. Along with removing malicious code from your site, it also ensures your site with W3C standards compliance. Since this module works perfectly with WYSIWYG editors, it proves to be a great fit for Drupal as well. Also, options like custom fonts, tables, inline styling, and many more are offered by this module. It is compatible with Drupal 9.

    Now, what do you think, is Drupal accessible? Undoubtedly, YES, as all the above Drupal accessibility modules prove so. 

    Learn more about accessibility and what Drupal has to offer:

    Conclusion

    With the above mentioned Drupal module list, I tried providing you the essential modules that can efficiently help your developers, content editors and site visitors with better web accessibility. So, now it’s completely up to you how you choose the right modules that fits your project needs and expectations. Without waiting further, take your pick!

    blog banner
    An image with an accessibility symbol
    blog image
    A window image
    Blog Type
    Is it a good read ?
    Off

    Continue reading

  • mcdruid.co.uk: Assessing the likelihood of a Drupal exploit of Ghostscript Zero Day CVE-2021-3781

    Drupal 9 detects a fake image file

    My colleagues and I in the Drupal Security Team recently became aware of a Zero Day RCE vulnerability in Ghostscript. This was later assigned CVE-2021-3781.

    At least one viable Proof of Concept (PoC) was made public not long after the Zero Day which illustrated Scalable Vector Graphics (SVG) handling in Imagemagick being used as an attack vector.

    Drupal core doesn’t use Ghostscript directly, but it’s fairly common for Drupal sites to use Imagemagick in some form.

    As such, we began to look at how an attacker might try to exploit the Ghostscript vulnerability via SVG and Imagemagick on a Drupal site.

    Our goal in such an investigation is to determine whether it would be sufficiently easy, with a common Drupal configuration, that we ought to issue a Public Security Announcement (PSA) warning Drupal users and providing any mitigation steps they might be able to take until an upstream fix was available.

    Here’s a quick write-up of some of the investigation I did.

    We’d determined that SVG is not in the default list of permitted image extensions in Drupal.

    However, the PoC write up showed Imagemagick being tricked into parsing an SVG with a fake jpg extension.

    I verified that in Drupal 9 the built-in file type detection prevented a malicious SVG from being smuggled into an upload with a permitted file extension.

    Drupal 7 core by itself doesn’t have this protection, although modules are available that add e.g. mime-type sniffing such as https://www.drupal.org/project/mimedetect.

    How might an attacker try to take advantage of this?

    Drupal core has built-in support for “image styles” which can perform preset transformations on uploaded images. For example, a thumbnail image is often prepared to show in previews of articles.

    So a Drupal site which uses Imagemagick to handle image processing (GD is the default in core but alternative “image toolkits” are available) might be exploited if an attacker could upload a malicious SVG and have the site try to perform an image manipulation on this, such as resizing it to prepare a thumbnail. This sort of functionality is quite common – for example – when a newly registered user uploads a profile picture. That would make a good target for an attacker.

    I ran through what happens if you smuggle a malicious SVG masquerading as a permitted image type into a D7 upload field. As Drupal tries to record the metadata about the image, it makes a series of API calls which end up invoking image_get_info() which in turn calls image_toolkit_invoke('get_info', $image).

    At that point both the default GD and the alternative Imagemagick toolkits call PHP’s built in getimagesize() on the image. If the image in question is actually an SVG, this will typically return FALSE.

    That means that Drupal will not attempt to perform a transformation on the image – for example to create a thumbnail – because it has not been able to derive the image’s metadata including the dimensions of the original.

    Even on a site which has explicit support for the uploads of SVG files (and you might argue that would be quite unusual for e.g. user profile pics) – because of the nature of SVGs – Drupal’s default behaviour of deriving some image metadata and then deciding whether image transformations should be performed doesn’t work like it does for e.g. jpg and png files.

    At least one popular SVG contrib module tries to derive an SVG image’s dimensions by parsing it as XML, but the malicious files produced by the PoC are not correctly formed for this.

    It doesn’t really make sense to try and run an SVG through Imagemagick’s convert to create a thumbnail or other derivative of a different size – that’s sort of the whole point of Scalable Vector Graphics.

    This investigation had focused on Drupal 7, but it looked like Drupal 9 would be – if anything – better protected because of its built-in file type detection.

    One popular configuration to support SVGs in D8/9 uses a vendored library to validate the XML and rejected the PoC’s malicious SVG during upload validation.

    There are a handful of different ways (as is often the case in Drupal) to set up SVG support in Drupal 9, but in one discussion about SVG support, phenaproxima (one of the media module’s developers) stated:

    The Media module itself has no opinion about SVG images. The Image module, on the other hand, doesn’t normally allow SVG to be uploaded into any image field, due to the various security and integration issues (i.e., image styles).

    So it really didn’t look great for our potential attacker trying to exploit Drupal’s image styles (automatic image transformations) via SVG and an Imagemagick toolkit to take advantage of the Ghostscript Zero Day.

    As it looked like it wouldn’t be easy to exploit this in what we’d consider a common configuration of Drupal, we decided against issuing a PSA.

    This is not to say it’s inconceivable that the vulnerability could be exploited on a Drupal site out there somewhere, but it would likely be considered an “edge case”.

    It’s also possible that I got some of this wrong. If you know of any significant details I missed which mean that exploitation might be easier or more likely than my analysis suggested, please contact me or the Drupal Security Team privately in the first instance. We will credit any researchers who provide information that leads to us issuing a Security Advisory.

    Thanks to Greg Knaddison (greggles) for (suggesting and) reviewing this post.

    Continue reading

  • Drupal blog: State of Drupal presentation (October 2021)

    Drupal blog: State of Drupal presentation (October 2021)

    This blog has been re-posted and edited with permission from Dries Buytaert’s blog.

    Last week, Drupalists around the world gathered virtually for DrupalCon Europe 2021.

    In good tradition, I delivered my State of Drupal keynote. You can watch the video of my keynotedownload my slides (156 MB), or read the brief summary below.

    I talked about end-of-life schedules for various Drupal versions, delivered some exciting updates on Drupal 10 progress, and covered the health of the Drupal community in terms of contributor dynamics. Last but not least, I talked about how we are attracting new users and contributors by making it much easier to contribute to Drupal.

    Drupal 7 and Drupal 8 end-of-life

    If you are using Drupal 7 or Drupal 8, time is of the essence to upgrade to Drupal 9. Drupal 7 end-of-life is scheduled for November 2022.

    Drupal 8’s end-of-life is more pressing, as it is scheduled for November 2nd, 2021 (i.e. in less than a month). If you are wondering why Drupal 8 is end-of-life before Drupal 7, that is because we changed how we develop Drupal in 2016. These changes have been really great for Drupal. They’ve made it much easier to upgrade to the latest version without friction.

    As a community, we’ve spent thousands of hours building tools and automations to make migrating to Drupal 9 as simple as possible.

    Drupal 10 timeline

    Next, I gave an update on Drupal 10 timelines. Timing-wise, our preferred option would be to ship Drupal 10 in June 2022. That date hinges on how much work we can get done in the next few months.

    Drupal 7, 8,9, and 10 timelines

    Drupal core strategic initiatives

    After these timelines, I walked through the six strategic initiatives for Drupal core. We’ve made really great progress on almost all of them. To see our progress in action, I invited key contributors to present video updates.

    Core initiatives progress

    Project Browser

    You may recall that I introduced the Project Browser initiative in my April 2021 State of Drupal presentation. The idea is to make it easy for site builders to find and install modules right from their Drupal site, much like an app store on a smartphone. The goal of this initiative is to help more evaluators and site builders fall in love with Drupal.

    Today, just six months later, we have a working prototype! Take a look at the demo video:

    Decoupled Menus

    Drupal is an excellent headless CMS with support for REST, JSON:API and GraphQL.

    As a next step in our evolution, we want to expand the number of web service endpoints Drupal offers, and build a large repository of web components and JavaScript framework integrations.

    With that big goal in mind, we launched the Decoupled Menus initiative about one year ago. The goal was to create a small web component that could ship quickly and solve a common use case. We focused on one component so we could take all the learnings from that one component to improve our development infrastructure and policies to help us create many more web service end points and JavaScript components.

    I talked about the various improvements we made to Drupal.org to support the development and management of more JavaScript components. I also showed that we’ve now shipped Drupal menu components for ReactSvelte and more. Take a look at the video below to see where we’re at today:

    Our focus on inviting more JavaScript developers to the Drupal community is a transformative step. Why? Headless momentum is growing fast, largely driven by the growth of JavaScript frameworks. Growing right along with it is the trend of composability, or the use of independent, API-first micro-services. Building more web service endpoints and JavaScript components extends Drupal’s leadership in both headless development and composability. This will continue to make Drupal one of the most powerful and flexible tools for developers.

    Easy Out of the Box

    The goal of this initiative is to have Layout BuilderMedia, and Claro added to the Standard Profile. That means these features would be enabled by default for any new Drupal user.

    Unfortunately, we have not made a lot of progress on this initiative. In my presentation, I talked about how I’d like to find a way for us to get it done by Drupal 10. My recommendation is that we reduce the scope of work that is required to get them into Standard Profile.

    Automatic Updates

    The Automatic Updates initiative’s goal is to make it easier to update Drupal sites. Vulnerabilities in software, if left unchecked, can lead to security problems. Automatic updates are an important step toward helping Drupal users keep their sites secure.

    The initiative made excellent progress. For the very first time, I was able to show a working development version:

    Drupal 10 Readiness

    The Drupal 10 Readiness initiative is focused on upgrading the third-party components that Drupal depends on. This initiative has been a lot of work, but we are largely on track.

    Drupal 10 will be 300% more automated

    The most exciting part? The upgrade to Drupal 10 will be easy thanks to careful management of deprecated code and continued investment in Rector. As it stands, upgrading modules from Drupal 9 to Drupal 10 can almost be entirely automated, which is a big 300% improvement compared to the Drupal 8 to Drupal 9 upgrade.

    New front end theme

    We are nearly at the finish line for our new front end theme, Olivero. In the past few months, a lot of effort has gone into ensuring that Olivero is fully accessible, consistent with our commitment to accessibility.

    Olivero already received a glowing review from the National Federation of the Blind (USA):

    Olivero is very well done and low-vision accessible. We are not finding any issues with contrast, focus, or scaling, the forms are very well done, and the content is easy to find and navigate.

    Something to be really proud of!

    The health of Drupal’s contribution dynamics

    Next, I took a look at Drupal’s contribution data. These metrics show that contributions are down. At first I panicked when I saw this data, but then I realized that there are some good explanations for this trend. I also believe this trend could be temporary.

    Contribution metrics

    To learn more about why this was happening, I looked at the attrition rate of Drupal’s contributors — the percentage of individuals and organizations who stopped contributing within the last year. I compared this data to industry averages for software and services companies.

    Contributors attrition
    While typical attrition for software and services companies is considered “good” at 15%, Drupal’s attrition rate for its Top 1,000 contributors is only 7.7%. The attrition rate for Drupal agencies in the Top 250 organizations is only 1.2%.

    I was very encouraged by this data. It shows that we have a very strong, loyal and resilient community of contributors. While many of our top contributors are contributing less (see the full recording for more data), almost none of them are leaving Drupal.

    There are a number of reasons for the slowdown in contribution:

    • The COVID-19 pandemic has made contribution more difficult and/or less desirable.
    • We are in the slow period of the “Drupal Super Cycle” — after every major release, work shifts from active development to maintenance.
    • Anecdotally, many Drupal agencies have told me they have less time to contribute because they are growing so fast (see quotes in image below). That is great news for Drupal adoption.
    • Drupal is a stable and mature software project. Drupal has nearly all the features organizations need to deliver state-of-the-art digital experiences. Because of Drupal’s maturity, there are simply fewer bug fixes and feature improvements to contribute.
    • Rector-automations have led to less contribution. It’s good to work smarter, not harder.

    I’ll expand on this more in my upcoming Who sponsors Drupal development post.

    Drupal Agencies too busy growing

    The magic of contribution

    I wrapped up my presentation by talking about some of the things that we are doing to make it easier to adopt Drupal. I highlighted DrupalPod and Simplytest as two examples of amazing community-driven innovations.

    Drupalpod Simplytest

    After people adopt Drupal, we need to make it easier for them to become contributors. To make contribution easier, Drupal has started adopting GitLab in favor of our home-grown development tools. Many developers outside the Drupal ecosystem are accustomed to using tools like GitLab. Allowing them to use tools with which they are already familiar is an important step to attracting new contributors. Check out this video to get the latest update on our GitLab effort:

    Thank you

    To wrap up I’d like to thank all of the people and organizations who have contributed to Drupal since the last DriesNote. It’s pretty amazing to see the momentum on our core initiatives! As always, your contributions are inspiring to me!

    Thank you to all the contributors

    Continue reading

  • Dries Buytaert: State of Drupal presentation (October 2021)

    Dries Buytaert: State of Drupal presentation (October 2021)

    Last week, Drupalists around the world gathered virtually for DrupalCon Europe 2021.

    In good tradition, I delivered my State of Drupal keynote. You can watch the video of my keynote, download my slides (156 MB), or read the brief summary below.

    I talked about end-of-life schedules for various Drupal versions, delivered some exciting updates on Drupal 10 progress, and covered the health of the Drupal community in terms of contributor dynamics. Last but not least, I talked about how we are attracting new users and contributors by making it much easier to contribute to Drupal.

    Drupal 7 and Drupal 8 end-of-life

    If you are using Drupal 7 or Drupal 8, time is of the essence to upgrade to Drupal 9. Drupal 7 end-of-life is scheduled for November 2022.

    Drupal 8’s end-of-life is more pressing, as it is scheduled for November 2nd, 2021 (i.e. in less than a month). If you are wondering why Drupal 8 is end-of-life before Drupal 7, that is because we changed how we develop Drupal in 2016. These changes have been really great for Drupal. They’ve made it much easier to upgrade to the latest version without friction.

    As a community, we’ve spent thousands of hours building tools and automations to make migrating to Drupal 9 as simple as possible.

    Drupal 10 timeline

    Next, I gave an update on Drupal 10 timelines. Timing-wise, our preferred option would be to ship Drupal 10 in June 2022. That date hinges on how much work we can get done in the next few months.

    Drupal and timelines

    Drupal core strategic initiatives

    After these timelines, I walked through the six strategic initiatives for Drupal core. We’ve made really great progress on almost all of them. To see our progress in action, I invited key contributors to present video updates.

    A slide with progress bars for each of the 6 initiatives; 3 of them are over 80% complete.

    Project Browser

    You may recall that I introduced the Project Browser initiative in my April 2021 State of Drupal presentation. The idea is to make it easy for site builders to find and install modules right from their Drupal site, much like an app store on a smartphone. The goal of this initiative is to help more evaluators and site builders fall in love with Drupal.

    Today, just six months later, we have a working prototype! Take a look at the demo video:

    Decoupled Menus

    Drupal is an excellent headless CMS with support for REST, JSON:API and GraphQL.

    As a next step in our evolution, we want to expand the number of web service endpoints Drupal offers, and build a large repository of web components and JavaScript framework integrations.

    With that big goal in mind, we launched the Decoupled Menus initiative about one year ago. The goal was to create a small web component that could ship quickly and solve a common use case. We focused on one component so we could take all the learnings from that one component to improve our development infrastructure and policies to help us create many more web service end points and JavaScript components.

    I talked about the various improvements we made to Drupal.org to support the development and management of more JavaScript components. I also showed that we’ve now shipped Drupal menu components for React, Svelte and more. Take a look at the video below to see where we’re at today:

    Our focus on inviting more JavaScript developers to the Drupal community is a transformative step. Why? Headless momentum is growing fast, largely driven by the growth of JavaScript frameworks. Growing right along with it is the trend of composability, or the use of independent, API-first micro-services. Building more web service endpoints and JavaScript components extends Drupal’s leadership in both headless development and composability. This will continue to make Drupal one of the most powerful and flexible tools for developers.

    Easy Out of the Box

    The goal of this initiative is to have Layout Builder, Media, and Claro added to the Standard Profile. That means these features would be enabled by default for any new Drupal user.

    Unfortunately, we have not made a lot of progress on this initiative. In my presentation, I talked about how I’d like to find a way for us to get it done by Drupal 10. My recommendation is that we reduce the scope of work that is required to get them into Standard Profile.

    Automatic Updates

    The Automatic Updates initiative’s goal is to make it easier to update Drupal sites. Vulnerabilities in software, if left unchecked, can lead to security problems. Automatic updates are an important step toward helping Drupal users keep their sites secure.

    The initiative made excellent progress. For the very first time, I was able to show a working development version:

    Drupal 10 Readiness

    The Drupal 10 Readiness initiative is focused on upgrading the third-party components that Drupal depends on. This initiative has been a lot of work, but we are largely on track.

    A slide from the DriesNote saying that the Drupal 10 upgrade work is 300% more automated than Drupal 9.

    The most exciting part? The upgrade to Drupal 10 will be easy thanks to careful management of deprecated code and continued investment in Rector. As it stands, upgrading modules from Drupal 9 to Drupal 10 can almost be entirely automated, which is a big 300% improvement compared to the Drupal 8 to Drupal 9 upgrade.

    New front end theme

    We are nearly at the finish line for our new front end theme, Olivero. In the past few months, a lot of effort has gone into ensuring that Olivero is fully accessible, consistent with our commitment to accessibility.

    Olivero already received a glowing review from the National Federation of the Blind (USA):

    Olivero is very well done and low-vision accessible. We are not finding any issues with contrast, focus, or scaling, the forms are very well done, and the content is easy to find and navigate.

    Something to be really proud of!

    The health of Drupal’s contribution dynamics

    Next, I took a look at Drupal’s contribution data. These metrics show that contributions are down. At first I panicked when I saw this data, but then I realized that there are some good explanations for this trend. I also believe this trend could be temporary.

    Contribution metrics

    To learn more about why this was happening, I looked at the attrition rate of Drupal’s contributors — the percentage of individuals and organizations who stopped contributing within the last year. I compared this data to industry averages for software and services companies.

    Slide with data that shows Drupal's top contributors are very loyal
    While typical attrition for software and services companies is considered “good” at 15%, Drupal’s attrition rate for its Top 1,000 contributors is only 7.7%. The attrition rate for Drupal agencies in the Top 250 organizations is only 1.2%.

    I was very encouraged by this data. It shows that we have a very strong, loyal and resilient community of contributors. While many of our top contributors are contributing less (see the full recording for more data), almost none of them are leaving Drupal.

    There are a number of reasons for the slowdown in contribution:

    • The COVID-19 pandemic has made contribution more difficult and/or less desirable.
    • We are in the slow period of the “Drupal Super Cycle” — after every major release, work shifts from active development to maintenance.
    • Anecdotally, many Drupal agencies have told me they have less time to contribute because they are growing so fast (see quotes in image below). That is great news for Drupal adoption.
    • Drupal is a stable and mature software project. Drupal has nearly all the features organizations need to deliver state-of-the-art digital experiences. Because of Drupal’s maturity, there are simply fewer bug fixes and feature improvements to contribute.
    • Rector-automations have led to less contribution. It’s good to work smarter, not harder.

    I’ll expand on this more in my upcoming Who sponsors Drupal development post.

    Slide with quotes from Drupal agencies CEOs stating that they are growing fast

    The magic of contribution

    I wrapped up my presentation by talking about some of the things that we are doing to make it easier to adopt Drupal. I highlighted DrupalPod and Simplytest as two examples of amazing community-driven innovations.

    A slide promoting DrupalPod and Simplytest

    After people adopt Drupal, we need to make it easier for them to become contributors. To make contribution easier, Drupal has started adopting GitLab in favor of our home-grown development tools. Many developers outside the Drupal ecosystem are accustomed to using tools like GitLab. Allowing them to use tools with which they are already familiar is an important step to attracting new contributors. Check out this video to get the latest update on our GitLab effort:

    Thank you

    To wrap up I’d like to thank all of the people and organizations who have contributed to Drupal since the last DriesNote. It’s pretty amazing to see the momentum on our core initiatives! As always, your contributions are inspiring to me!

    Thank you for the many contribution

    Continue reading

  • OpenSense Labs: Drupal 8 end-of-life is just around the corner, what’s your next step?

    OpenSense Labs: Drupal 8 end-of-life is just around the corner, what’s your next step?

    Drupal 8 end-of-life is just around the corner, what’s your next step? Maitreayee Bora Fri, 10/08/2021 – 08:23

    Drupal 8 was launched on November 19, 2015 to support the Drupal community with advanced features and functionalities. But now there is only three months left for it’s end-of-life (EOL) since we already have the end date fixed i.e. November 2nd, 2021. Well, what does Drupal end of life mean? End of life basically is the official date after which Drupal Community stops supporting a certain version of Drupal. This article can be considered as a guide where we will be able to clear all our queries in regards to Drupal 8 end-of-life (EOL). 

    Illustration diagram describing the end of life of Drupal 8


    When’s Drupal 8 going to be End-of-life

    As we have discussed above, Drupal 8’s end-of-life is just a few months away, so are we making our necessary plans for migrating to Drupal 8’s later version? Let us get into a little more detail about Drupal 8’s end-of-life as it will help you in taking any major decisions about the migrating process. So, basically, after November 2nd, 2021, the end date of Drupal 8 version, no security patches will be available to you and along with that you won’t be receiving any vendor extended support program for Drupal 8. 

    You will be surprised to know that Drupal 8’s End of Life happens before Drupal 7. Since, now you have an idea about Drupal 7 and 8 end of life, let us now look into the reasons why Drupal 8’s end of life takes place before Drupal 7. The first reason is that there was not much effort needed in the transition from Drupal 8 to Drupal 9. Since, Drupal 9 was not a reinvention of Drupal but rather it consists of two major differences i.e. updated dependencies and deprecating APIs. Second, Drupal 8 is majorly dependent on Symfony 3 and Symfony 3’s end of life is November 2021.

    Is it still safe to stay on Drupal 8 even if the end of life is approaching?

    If you decide to stay on Drupal 8 even after it’s end-of-life then you will have to go through some difficult consequences. Your website has to be compromised in terms of the security as the community support finishes with Drupal 8 end-of-life. You will have to purchase a vendor extended support program for Drupal 8 instead of depending upon the Drupal community to identify exploits and release patches. Additionally, as the developer community will no longer prioritize on enhancing the Drupal 8 version, so consequently, the existing modules will not receive any further necessary updates from the community as they will be busy focusing on Drupal 9 modules. Let me also tell you that with the growing time Drupal 8 sites tend to disappear and as a result, very few agencies will be available to offer Drupal support for these versions. Therefore, the best option you have is to upgrade to Drupal 9 without any further delay and get the maximum benefits out of it for your aspiring projects. 

    What benefits will I get after migrating to Drupal  9? 

    This section will give you a clarity about the important features that Drupal 9 offers. Once you take a look at them, you won’t regret migrating to this version from your present familiarised version of Drupal 8. 

    Illustration diagram describing the benefits of migrating to Drupal 9


    Availability of intuitive tools

    Enhancing Drupal’s ease-of-use is something that is prioritized in this version of Drupal 9. Some of the promising improvements in regards to the strategic initiatives for Drupal core include automatic updates, Drupal 10 readiness and, decoupled menus.

    Improving future upgrades

    Drupal 9 focuses on making the upgrades smooth for future releases. There won’t be any need to replatform as new versions get released. 

    Enabling you to stay close to innovation

    With Drupal 9, you get access to the latest new feature releases that happen twice a year.

    Front-end facilities

    Drupal’s API-First initiative provides your site more versatility, allowing much better integrations, and also availing the much needed front-end flexibility. 

    Providing richer media management

    Drupal 9 enables you to embed remote content like YouTube and Vimeo videos. Additionally, it also features a Media Library module that helps users to add existing media assets. 

    Accessibility of powerful visual design

    Drupal 9 provides an improved Layout Builder which exclusively offers a single, powerful visual design tool for:

    • Layouts for templated content
    • Customization for templated layouts
    • Custom pages

    Is migrating to Drupal 9 difficult?

    By far we have got familiar with some of the important aspects of Drupal 8’s end-of-life, but now we will get through the most significant aspect i.e. the nature of the migrating process to Drupal 9. Is it easy or difficult? This question might be at the back of your mind, so here I am with the answer you are looking for. Since, Drupal 9 is built on Drupal 8, the technology in Drupal 9 is to be surely, convenient and effective as it has already been used in Drupal 8. Therefore, it gives an understanding that the upgrade to Drupal 9 will be easy. Let me explain this to you in a more detailed way. 

    For Drupal core contributors, it means that there is a limited set of tasks to be done in Drupal 9 itself even before its release. Releasing Drupal 9 solely, depends on removing deprecated functionality and upgrading Drupal’s dependencies, for instance, Symfony. This further helps in making the release timing more predictable and the release quality extremely robust.

    For contributed module authors, the new technology is already available at their service, so they can easily work on Drupal 9 compatibility even before time (e.g., they can start with updating their media modules to use the new media library even before Drupal 9 gets released). Eventually, their Drupal 8 know-how remains extremely relevant in Drupal 9, since there won’t be any major change in building Drupal 9.

    Finally, for Drupal site owners, it means that the upgrading process to Drupal 9 should be much easier in comparison to upgrading to Drupal 8. As Drupal 9 happens to be the last version of Drupal 8, with its deprecations being removed. So, there is no need to introduce new, backwards-compatibility breaking APIs or features in Drupal 9 except for the dependency updates. Until modules and themes stay up-to-date with the latest Drupal 8 APIs, the upgrade to Drupal 9 is set to be easy. Moreover, a 12 to 18 month period is enough for a smooth upgrade. 

    Learn more about Drupal 9 upgrade approaches here:

    What about Drupal 9 end-of-life?

    With all the above discussion, you must be clear about the Drupal 8 end-of-life. But is that all you wanted to know? Or do you have any more curiosity to take a step forward and know about Drupal 9 end-of-life? Well, I’ll give you a little information about it. Drupal 9 support ends in November 2023. Since, Drupal can be seen using a lot of Symfony code, the end of life for Drupal 9 will be when Symfony 4 reaches its end of life in November 2023.

    The Drupal community is planning to release Drupal 10 ahead of the end date of Drupal 9. Therefore, Drupal 10 is estimated to be released in the mid of 2022. But they still haven’t fixed the Drupal 10 release date. And also we are far away from Drupal 10 end of life for sure. 

    You can also see the release cycle overview to get more information on the possible release dates. 

    Learn more about Drupal 9 here:

    Illustration diagram describing Drupal End of Life Cycle

    Conclusion

    With this article, I tried giving you a clear picture of the various risks which you will come across if you choose to stick around Drupal 8 even after it’s end of life (EOL).  You could also possibly see all the important benefits that Drupal 9 has to offer. So, now hopefully, it can be expected that you will take the right step towards Drupal 9 upgrade. But yes, I do agree that upgrading comes with a lot of challenges. Therefore, the first convenient step for you will be to perform a readiness audit. As audit helps in recognizing the work and effort needed on your website, along with recommending you a seamless migration to Drupal 9.

    blog banner
    Autumn leaf
    blog image
    Sunset
    Blog Type
    Is it a good read ?
    Off

    Continue reading

  • Droptica: How to Schedule a Publication in Drupal? Scheduler Module

    Droptica: How to Schedule a Publication in Drupal? Scheduler Module

    .

    When creating content for a website, it is sometimes necessary to plan its publication later down the line. However, taking care of it manually can be both time-consuming and inconvenient. This is when Scheduler comes in handy – a Drupal module that will help you automate this process. Using it will allow us, among other things, to schedule the publication of content for a specific date and time.

    Scheduler module – dates

    The module was released on 23 July 2006, and its latest update was pushed on 19 July 2021. Scheduler has versions for Drupal 7 and 8. What is more, the latest update is compatible with Drupal 9 as well.

    Module popularity

    The module is currently used on more than 85 thousand websites. About 44 thousand of them are running Drupal 7, and more than 37 thousand are on Drupal 8.

    The usage statistics of the Scheduler module aimed for scheduling publication on a Drupal website

    Source: Drupal.org

    Module developers

    Scheduler was originally published by Eric Schaefer. However, the list of people working on its development to date is very long and impossible to establish – we don’t know all the users who contributed to its development.

    Drupal Scheduler module – what does it do?

    As I pointed out in the introduction, the module is used to plan content publication in advance. It also offers you a way to plan unpublishing. If needed – for example, in the case of events, where news will be made obsolete after the end, you can task the module with publishing your content and schedule its removal from your website at a specific day and time.

    Scheduler provides three new permissions, allowing only the selected roles to have access to scheduled publishing. The list of possibilities also includes the so-called Lightweight cron, the configuration of which optimizes resource consumption. Lightweight cron is the developers’ solution to make the cron responsible for publishing and removing content available to be run separately, without the need to initiate all other tasks, as is usually the case in Drupal.

    Unboxing

    Installation is standard. I recommend using Composer.

    composer require drupal/scheduler
    Scheduler composer

     

    Permissions

    Go to

    /admin/people/permissions#module-scheduler 

    – there, you will find a list of permissions that the module provides:

    Permissions available in the Drupal Scheduler module

     

    Administer scheduler

    This setting enables you to configure the Scheduler module, available at

    /admin/config/content/scheduler 

    (see the next section for the description of all the features).

    Scheduler content publication

    Granting this permission allows a role to set scheduled publication, as well as to plan unpublishing.

    View scheduled content list

    Scheduler provides a view, which is available at

    /admin/content/scheduled

    Granting this permission allows you to access this view.

    Settings

    Go to

    /admin/config/content/scheduler

    to find all the global settings for the module. What is more, Scheduler can be configured per content type. Below, you can find a break down the global options.

    Global settings of the Scheduler module

     

    Allow users to enter only a date and provide a default time

    Allows users who have permission to configure scheduled content publishing to specify only the publication date. When this option is selected, the time will be predefined and configurable in the Default time field.

    Defining the publication date of the user-selected content in the Scheduler module.

     

    Hide the second

    Checking this option disables the ability to set seconds when scheduling content publishing.

    Lightweight cron

    As I pointed out earlier, by default, Drupal runs all cron jobs every once in a while. Checking which content needs to be published and unpublished relies on a cron job, which should be run every 1-5 minutes. Configuring Drupal to run all cron jobs every minute is hardly a very good idea, considering its performance, which is why the developers enabled the users to run a single cron job at a suitable interval. To do this, you need to add a new cron job run at a given time. Here is an example of a cron job that is run every minute: 

    * * * * * wget -q -O /dev/null "https://tesd9.lndo.site/scheduler/cron/{access-key}

    Go to

    /admin/config/content/scheduler/cron 

    to find the lightweight cron settings. There, you can enable logging of cron job activation and completion, change access-key and run cron manually.

    Content type

    I’ll illustrate this option with the default content type – Article – available in Drupal default profile. Go to

    /admin/structure/types/manage/{content-type-machine-name} 

    There, you will notice a new Scheduler tab. This is where you’ll find all the module’s configuration options, which you can set for each entity.

    In the Scheduler tab, related to the types of content, you will find all configuration options for the entity

     

    Enable scheduled publishing/unpublishing for this content type

    Enables or disables the ability to set scheduled publication and/or unpublishing.

    Change content creation time to match the scheduled publish time

    Changes the date in the creation time field to the date selected as the planned publication date.

    Require scheduled publishing/unpublishing

    Checking this option makes setting scheduled publication and/or unpublishing required.

    Create a new revision on publishing/unpublishing

    Creates a new revision during scheduled publication and/or unpublishing.

    Action to be taken for publication dates in the past

    This setting enables you to specify what will happen when the editor selects a publication date earlier than the current date. You can choose one of three options here:

    • Display an error message about choosing a date earlier than the current one – in this case, the content won’t be published.
    • Publish content immediately after saving.
    • Schedule your content to be published on the next cron job run.

    Display scheduling options as

    Changes the way Scheduler module options are displayed when creating and editing content. There are two options to choose from – Vertical tab and Separate fieldset.

    Vertical tab

    The vertical tab is one of the possibilities for displaying the Scheduler module options

     

    Separate fieldset

    Separate fieldset is one of the ways to display Scheduler options

     

    Expand fieldset or vertical tab

    Allows you to specify whether the field provided by the Scheduler should be expanded when creating and editing content.

    Show message

    Checking this option displays information about planned publication and unpublishing after saving the content.

    Scheduled publication notification from the Scheduler module

    Module usage

    Let’s assume that our article needs to go live on 1 September 2021 at 9:30 a.m. and won’t have to be unpublished.

    When writing the article, choose Publish on and set it to 01.09.2021 at 9:30 a.m., and then leave Unpublish on empty. In this case, the Require scheduled unpublishing option must be disabled for the Article entity.

    Options for scheduling a publication for a specific date

    Now imagine that our article needs to go live on 1 September 2021 at 9:30 a.m. and has to be unpublished a week later at the same time.

    Let’s start with doing the same thing as we did in the previous example, but this time also set Unpublish on to 08.09.2021 at 9:30 a.m.

    Setting the time of publication of the article and unpublishing in the Drupal Scheduler module

    You may be also interested in: How to Make Content Editing Easier in Drupal – Review of the Simplify Module

    Integrations

    Scheduler offers integrations with several Drupal modules.

    • If you’re using the Content Moderation module, you must enable the Content Moderation Integration sub-module.
    • Scheduler provides additional conditions, actions, and events for the Rules module.
    • It is also integrated with the automatic generation of test content provided by the Devel Generate module. Scheduler can automatically add the planned publication and unpublishing dates.
    • It also creates new tokens for the Token module, containing the planned publication and unpublishing dates.

    The future of the module

    The developers responsible for the Scheduler have announced that they are working on releasing version 2.0 of the module, supporting entities other than nodes, for example, Media, Commerce Products, and more. They also announced that events triggered by the Scheduler module and its integration with the Rules module will from now on be triggered after an entity is saved, rather than before, as was the case until now. The development progress can be followed on the module page.

    Drupal Scheduler module – summary

    Scheduler is a tool that greatly facilitates the scheduling publication of content on your website. Using it allows you to automate the process and makes it possible to do all the steps required to publish content at any time – thus making sure that you won’t have to worry about it when the time comes. At Droptica, we also use Scheduler to schedule publications in advance. This module is extremely popular among Drupal users, and as such, it is constantly developed – with version 2.0 in the works right now. Our team of Drupal developers recommends using the Scheduler module to schedule publications in advance or to publish content for a specific time.

    Continue reading

  • Wim Leers: Acquia Migrate Accelerate: the why and the what

    For the past two years I’ve been working on something less visible but no less important.

    Since DrupalCon Amsterdam 2019 (an actual in-person conference — sounds surreal in 2021, doesn’t it?!) I’ve been working on Acquia Migrate Accelerate, or “AMA” for short. In a few days, another DrupalCon Europe is starting … so perfect timing for a recap! 😀

    Why?

    Drupal 8 comes with an awesome migration system built in, originating in the Migrate Drupal 7 module. It standardized many migration best practices. But it still required a huge time investment to learn it.

    Of course, there’s the “Migrate Drupal UI” (migrate_drupal_ui) module in Drupal core. But that does not allow for granular migrations. It allows for a one-shot migration: you see which things will be migrated and which won’t. You can click a button and hope for the best. It only works for the very simplest of sites. It is impressively minimal in terms of the code it needs, but unfortunately it also means one pretty much needs to be a expert in migrations to use it successfully.

    It will be of little help as soon as you run into important data you want to migrate for which no migration path exists.

    See Mauricio Dinarte’s excellent “31 days of Drupal migrations”. In those 31 blog posts, you’ll learn to know and appreciate the migration system (I sure did!). Unfortunately, that still won’t fully prepare you: you’ll need to decyher/reverse engineer the intricacies of how the data gets stored in Drupal 7 with its entities, revisions and fields — and with each field type having its own intricacies — and map that to Drupal 9 equivalents.

    And how does one migrate straight from Drupal 7 with its more fragmented ecosystem? 1

    For example: media handling. There are easily a dozen approaches possible in Drupal 7. Each in use on tens of thousands of sites. In Drupal 8 & 9, everything has standardized on Media and Media Library. But how do you get your Drupal 7 site’s content in there?

    Another example: location data. location was very popular, but is now dead. geofield was equally popular but still alive. geolocation was less popular but now more. addressfield was popular, address is the successor. None of the Drupal 9 modules offer Location’s feature set. How do you migrate this data?

    Goal

    The goal for AMA (the vision of https://www.drupal.org/u/grasmash and especially https://www.drupal.org/u/webchick!) is to empower the non-technical user to be able to perform migrations. A UI that is aimed at the site builder POV: one should be able to select which content types (also vocabularies, menus, et cetera) make sense to migrate, and then not have to bother with technical details such as “migration plugins” or YAML files.

    Acquia Migrate Accelerate:

    For example, AMA shows just “Page” in the UI. Under the hood (and you can see this in the UI too, but it’s just not prominent), that corresponds to the following migration plugin definitions:

    • d7_node_type:page
    • d7_field_instance:node:page
    • d7_field_formatter_settings:node:page
    • d7_field_instance_widget_settings:node:page
    • d7_node_complete:page
    • d7_url_alias:node:page
    • node_translation_menu_links:node:page

    In other words: the support configuration for nodes of the page bundle (the first 4), then all actual entity/field data (d7_node_complete:page), followed by URL aliases and menu links referencing pages.

    However, to be able to do this, we need many more migrations in Drupal core to be derived: view modes, fields, formatters and widget should all have an entity type+bundle-specific derivative. That’d allow each bundle to be migrated individually. Which enables the site builder to check that their pages and everything related to it has been correctly migrated before moving on to the next data concept to migrate. So far we’ve not yet been able to convince the migration system maintainers of the value of this. 2

    (AMA does many more things, but that’s not in scope of this blog post.)

    Closed & Open

    Acquia understandably wants its customers to be able to use AMA, and not its competitors’ users. The module is GPL-2+

    Like all Drupal modules, the AMA module is GPL 2+ licensed. Only the React UI is closed source. The automated recommendations engine is closed source. Obviously the code to spin up AMA environments in Acquia Cloud is closed source 3.

    But … all of the work that goes into making migrations reliable is open source. At the time of writing, we have ~100 unique patches that are being applied, 39 of which to Drupal core! While I was writing this, https://www.drupal.org/project/drupal/issues/3190818 got committed, plus a few were committed recently but did not yet ship in a 9.2.x point release, so soon that number will be lower 🙂

    An overview

    In the past 20 months we’ve hardened many migrations, and created new ones from scratch. Thousands of Drupal sites have already benefited — many more than there are Acquia customers.

    The highlights:

    Overall, 29 Drupal core patches 4 and 18 Drupal contrib patches have been committed! Plus another 36 core patches 5 and 32 contrib patches are successfully being used, and will hopefully land in the near future. (Not counting commits to the migration modules we now (co-)maintain.) Many dozens of migration paths from Drupal 7 have been stabilized, especially by https://www.drupal.org/project/media_migration.

    A comprehensive overview (all patches are uncommitted unless stated otherwise):

    D7D9 for all

    We aim to continue to do to the work to get patches committed: address feedback, add test coverage, and so on. We want to help everyone migrate from Drupal 7 to 9!

    Teamwork

    These many hardened migrations are thanks to the titanic work of:

    If you found this interesting, check out Gabe’s write-up of the application architecture that powers the awesome React-based UI that Peter built.


    1. Some would say richer↩︎

    2. It also implicitly reveals one of the most fundamental assumptions in the migration system: that only the final state after running all migrations matters. For developers who know both Drupal 7 and 9’s data models really well, this may be fine. But for a non-expert, it’d be simpler if they were able to migrate each the entities of each entity type+bundle and then inspect the results, not to mention that it’d take less time to get some confidence in the migration! For example, first the “tags” taxonomy terms, then the “image” media items, then the “blog post” content items. Verifying the correct validation of each of those clusters of data is simpler conceptually. Site builders, if you want this, please leave a comment in https://www.drupal.org/node/3097336↩︎

    3. Acquia Cloud handles the creation of an ephemeral Drupal 9 migration environment, with a Drupal 9 site automatically generated, with all equivalent D9 modules pre-composer required, and all modules with a vetted migration path pre-installed. For Acquia the value is obvious: its customers are more likely to succesfully mgirate to Drupal 9 sooner, the customer is more likely to stay a customer. We’ve currently got over 100 customers using AMA.) ↩︎

    4. Committed core patches: #3096676, #2814953 (this one has the majority of the work done by the community!), #3122056, #3126063, #3126063, #2834958 (from those first 14), #3152789, #3151980, #3151993, #3153791, #2925899, #3165944, #3176394, #3178966, #3187320, #3187415, #3187418, #3187463, #3189463, #3187263 (from 2020), #3190815, #3190818, #3191490, #3097312, #3212539, #3213616, #3224620, #3227549, #3085192 (from 2021). ↩︎

    5. We started out with 14 core patches. Of those, #3115073, #3122649, #3096972, #3108302, #3097336, #3115938, #3123775 still remain. Other core patches we’ve contributed in 2020 that are not yet committed: #2845340, #3151979, #3051251, #3154156, #3156083, #3156730, #3156733, #3165813, #3166930, #3167267, #3186449, #3187334, #3187419, #3187474, #3187616. And those in 2021: #2859314, #3200949, #3204343, #3198732, #3204212, #3202462, #3118262, #3213636, #3218294, #3219078, #3219140, #3226744, #3227361, #3227660 ↩︎

    Continue reading