mark.ie: Setting up Access Control with Drupal's Workbench Access Module
This is a short video for how to use the LocalGov Content Access Control Module, based on Drupal's Workbench Access module.
This is a short video for how to use the LocalGov Content Access Control Module, based on Drupal's Workbench Access module.
We added Drupal's default pink background to LocalGov Drupal's unpublished pages recently. It didn't go down as well as we might have hoped!
Drupal Commerce is an ecommerce platform that has become the talk of the town. Ecommerce giants including Puma, Timex, and Lush rely on it to ensure top-notch operation of their online stores. Such immense popularity of this ecommerce software piques the curiosity of many. If you are also one of them, this blog will satiate your curiosity by exploring multiple facets of Drupal ecommerce development that make it unmatchable. So, are you ready to dive in?
First of all, let’s delve into what Drupal Commerce is.
The last two weeks the dust settled after an energetic and productive Drupalcon. Now there is a new stable release for all of the three most popular contrib modules Nuvole maintains: Config Filter, Config Split and Config Ignore.
This is the most stable module, its new releases just switch over to Gitlab CI and fix a small inconsistency in how config storages are expected to behave. The first iteration introduced a bug which the second release fixed. Thank you to the early adopters who spotted the bug. Config Filter will remain supported but its relevance is probably going to decrease with the release of stable versions of the modules which used to depend on it but no longer do. For example Config Split 2.x and Config Ignore 3.x do not depend on Config FIlter and both now have a stable release. Modules are encouraged to switch to the Config Storage Transformation API added to Drupal 8.8. Both branches remain supported and recommended on drupal.org since most commits can be cherry picked between the branches. But for performance I would recommend the original 1.x branch. Both branches have exactly the same API, just the behaviour is different when importing or exporting. Other config modules can use either branch for the test traits which facilitate writing tests that pass before and after refactoring from Config Filters API to the core API.
If your site indirectly depends on Config Filter because you use a module which depends on it, you need to explicitly require Config Filter when you upgrade the modules. Drupal can not uninstall a module that is no longer in the codebase. So explicitly require Config Filter, uninstall it and then in a subsequent deployment remove Config Filter.
Our oldest Drupal 8 config module has a new stable 2.0.0 release. In it, bugs and edge cases discovered in last year's release were fixed. It also contains a "new" feature which brings back the functionality of the 1.x branch. This should help sites holding back on upgrading because the functionality changed. With that out of the way the plan is to deprecate the 1.x branch and end support with the end of Drupal 10 support. There will not be any features added to 1.x.
Previous releases of the 3.x branch have not been feature compatible with 2.x. But the stable 3.0 release has been re-written from previous 3.x beta versions. It is configurable so that most use cases can be catered for with enough creativity. One can configure the configuration to ignore for create, update and delete for both import and export. But one can also just keep it simple and then it will be as all the versions before. In particular, however, it can be configured easily to behave like: the last 2.x release, the last 2.x release with the popular patch to allow filtering on export and the previous 3.x release. Because of that the 2.x branch is deprecated as of now and it will be marked as unsupported by the end of the year on Drupal.org. There is a new hook replacing the one which existed in 2.x and which addresses the new capabilities (the old hook is still invoked and will be removed in 4.0.0). With the end of Drupal 9 being supported, PHP 8.1 is now the minimum required version, but 3.0 does not yet take advantage of the new PHP language features. So the plan for 4.0.0 is to switch the string constants to enums and switch to semantic versioning and remove the old hook.
Our Drupal 8 modules have always been maintained "like a php library". The development of UI Patterns was initially hosted on Github among other things for that reason. Config Split and Config Filter shipped with their docker compose files and scripts to symlink the module into the Drupal site. Later the custom scripts were replaced by drupal-spoons. Since the now generally available drupal-gitlab-ci is inspired by spoons and DDEV is likely becoming the recommended development environment for contributing to Drupal, I switched my local environment for maintaining the contrib modules to DDEV with the ddev-drupal-contrib plugin, the spiritual successor of drupal-spoons. For contributing to Drupal core I can only recommend the ddev-drupal-core-dev plugin created by justafish during Drupalcon. I helped beta test it and it works like a charm. That said my PhpStorm configuration had to be updated a bit even though I installed the ddev plugin for it. In particular I had to add a second server mapping for Xdebug to work as described in a comment on the issue. The release notes for the contrib modules were generated with drupal-mrn.dev.
Many thanks to everyone who contributed with feedback, code, ideas or even just listened to my ramblings as I discovered untested edge cases.
Tags: Drupal PlanetDrupalConA roundup from our conference session at DrupalCon Lille
Tamsin Fox-Davies Fri, 11/03/2023 - 12:26The Drupal Association has been working on a monumental effort to migrate away from our bespoke DrupalCI continuous integration system to GitLab CI as part of the GitLab Acceleration Initiative. Drupal core's test runs are five times faster using GitLab CI. I have loosely followed the progress as Drupal moves from our custom-built infrastructure onto GitLab. But someone shared with me a little feature I missed: adding a PHPStan job to the default GitLab CI templates!
This first episode of the Drupal Migration series of Tag1 Team Talks focuses on the intricate process of migrating large-scale applications, especially with the end of life of Drupal 7 and 9 approaching. The hosts, Michael Meyers and Janez Urevc, are joined by a panel of additional experts, Benji Fisher, Lucas Hedding, Mauricio Dinarte, and Mike Ryan, who delve deep into the world of Drupal migrations. This discussion explores the terminology used in migrations and some best practice approaches to the process, aiming to equip you with the knowledge to navigate the upcoming talks on this topic. Overview The panel discusses the nuances of migration, touching upon the differences between terms like upgrade, update, and migration and how they apply in different contexts. They emphasize the complexity of migrating from older systems to newer ones, highlighting the substantial changes in code organization and database structure. The conversation also covers the critical task of porting code and themes, focusing on the challenges and strategies of migrating Drupal themes. The panel shares personal experiences, underscoring the importance of considering the specific circumstances of each project when deciding whether to retain or redesign a theme during migration. The discussion extends to data migration...
Read more michaelemeyers Tue, 11/07/2023 - 06:50