Testing a lot of pages after small changes in CSS files - again and again... Looks familiar? Gemini gets you rid of this waste of time. We will show you how to write Gemini tests and extend this tool.
Drupal Modules: The One Percent: Drupal Modules: The One Percent —Multiple Registration (video tutorial)
Here is where we seek to bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Multiple Registration, a module which gives you the ability to create role-specific registration pages.
Yesterday a project on github was moved, causing Drupal's own build process, and that of many other websites, to “break”. Here's what happened:
- The coder library was removed from github (it's main home is on drupal.org).
- Drupal core's composer.json had a reference to the now non-existent repository.
- Anyone attempting to obtain Drupal by downloading it's source and running composer install couldn't.
- Many other developers who tried to build their websites were similarly left disappointed.
This seems to be a risk that comes with dependency management, and raises the question of should vendor be committed to version control? I'm hoping that this post will help you answer that.
Here at Aten, we do a lot of work with Drupal, mostly on large redesign projects for nonprofits and universities. We’ve been in the business for a while now (since 2000), and one thing we’ve been talking about for years is the predicament of “buy-maintain-replace” release cycles. Specifically, website redesigns often fall prey to a problematic purchasing cycle that directly counteracts strategic goals.
It goes like this: first there’s a capital campaign, then a big spike in funding to do a redesign project, followed by modest support budget for a few years. During support, things everyone would like to change start to pile up, often beginning as a “backlog” or “wish list,” inevitably becoming a “gripe list” for all the things that are slowly and surely making your website obsolete. Time passes and the gripe list grows. We hear things like, “Our current website is horribly outdated; it isn’t even responsive.” Rather than invest in old technology and continue addressing the growing list of issues, tasks are pushed off for a future redesign. Eventually, there is a new capital campaign. The cycle starts over, rinse and repeat.
If you’re coming from a product background and you’re programmed to value ongoing development and continuous innovation, this already sounds bad. But if you’re from traditional IT management, you might think of redesigns more like purchasing any other technology solution. You buy it, it gets old, you replace it – often with some form of ongoing support between major expenditures. The smaller the support requirement, the more successful the project. Likewise the longer you can go without upgrading, the more successful the project.
The trouble is, your website, app, etc. doesn’t really work that way. Your website shouldn’t just be checking boxes on functionality requirements the way your phone system or workstations do; rather, your website is the public face and voice of your organization. It needs to keep up and tell your story clearly, every day. It needs to evolve as quickly as your organization does. And that requires ongoing investment. More than that, it requires a fundamental shift in the way decision makers think about planning digital projects.
There’s already a ton of fantastic material about the need to adopt a product approach over the more traditional project mindset. One of my favorite posts on the subject was written back in 2015 by the team at Greenpeace titled, “Product teams: The next wave of digital for NGOs?” I especially love this infographic. The illustration is spot on: first, a huge spike in money and time with a brief climax at launch, followed by diminished investment during a prolonged support period with equally diminished satisfaction, all to be repeated over and over again.
Interestingly, this problematic “buy-maintain-replace” cycle actually aligned closely with the release cycle for previous versions of Drupal. For years, timing for the “buy” stage in the cycle aligned surprisingly well with the stable release for major Drupal versions. First, you built a website on Drupal 4. Support phase ensued. Over a few years wish lists turned to gripe lists. Momentum grew behind doing the next major redesign, right on time for the stable release of Drupal 5. Rinse. Drupal 6. Repeat. Drupal 7.
While we were talking more and more about a product approach, the technology actually lent itself to the project mindset. Quick example: retainers are a big part of our business at Aten, and have been important for helping us support clients in the product approach. With retainers, clients invest consistently in their digital platforms over the long term. We identify strategic priorities together, maintain a backlog, organize sprints and deploy iterative releases. But with past versions of Drupal, an organization still needed to invest heavily for major release upgrades. At some point in the cycle, there were diminishing returns associated with ongoing investment in an outdated system. We started prioritizing tasks based on the fact that a large redesign was looming. We said things like, “Let’s just wait on Drupal 7 for that.” In many ways the underlying platform was promoting a “buy-maintain-replace” development cycle. The product approach was still valuable, but hampered by inevitable obsoletion of the technology.
Enter Drupal 8.
With Drupal 8, there’s a lot to be excited about: configuration management, component-based theming, improved performance, content moderation, modernized development tools, support for API-first architecture, and the list goes on. But I want to focus for a minute on Drupal’s release cycle.
Drupal’s vastly improved upgrade path is a huge win for the platform and a major reason organizations should consider migrating to Drupal 8 sooner rather than later.
With past versions of Drupal, major release upgrades (i.e. D6 to D7) required a significant development effort and usually constituted a major technology project. As I’ve touched on already, upgrades would typically coincide with a complete redesign (again, buy-maintain-replace).
With Drupal 8 the release cycle is changing. The short, non-technical version is this: Drupal 8 will eventually become Drupal 9. If you stay up-to-date with underlying changes to the platform as it evolves, upgrading from 8 to 9 should be relatively simple. It’s just another release in your ongoing development cycle.
With Drupal 8, an organization can invest consistently in its digital platform without the problem of diminishing returns. As long as you adopt the product approach, your platform won’t become outdated. And that’s fantastic, because the product approach is what we’re all going for – right?
Resources and Related Reading:
- The product approach to building a website (from atendesigngroup.com)
- Product teams: The next wave of digital for NGOs? (from mobilisationlab.org)
- Drupal 9 and Backwards Compatibility: Why now is the time to upgrade to Drupal 8 (Angie @webchick Byron via slideshare.net)
- Making Drupal upgrades easy forever (from dri.es)
Drupal 8.4 is here! The most current minor release of Drupal 8 officially came out on October 4. This release contains lots of changes that push Drupal 8 forward in some big ways, but what are those changes and what do they mean to you?
The changes introduced in Drupal 8.4 affect everyone from Drupal developers to content administrators and site owners. I’ve broken things down into four categories, and we’ll cover the high points of each one. If you’re interested in really digging into the details, check out the full release notes available on drupal.org.Security
The initial release of Drupal 8.4 doesn’t contain any major security updates that make it a mandatory update in the hours, or days, immediately after release. That being said, this is still an update that is critical for site security because as soon as a new minor release of Drupal comes out, security issues in previous minor releases are no longer patched.
I recommend updating to Drupal 8.4 as soon as possible because there is always a chance of a critical security release. You don’t want to get stuck dealing with the complexities of updating from Drupal 8.3 to 8.4 when you’re also racing the clock that starts ticking when a security vulnerability is made public.Browser Support
Drupal 8.4 made some major updates to the versions of Internet Explorer that are supported out of the box. Previously, Drupal supported Internet Explorer 9 and up. Since Microsoft discontinued all support for Internet Explorer 9 and 10 in April of this year, Drupal has followed suit and will only be supporting Internet Explorer 11 moving forward.
No need to panic yet though - your site won’t cease to function in Internet Explorer 9 and 10 as soon as the 8.4 update is implemented, but bugs related to those browsers will no longer be fixed. Starting in Drupal 8.5, which is currently scheduled for release in March of 2018, existing workarounds for these browsers will be removed. This will impact every site differently, depending on how much support your frontend provides for these older browsers, so start talking to your developer now about the best approach for your site.New and Updated Features
Drupal 8 introduced the idea of experimental modules in core. These are modules the Drupal core team has decided provide valuable functionality and should be included in core but still need testing. Many of them can be used in production releases without any issues, but, until they are officially declared stable core modules in a minor release, there may be breaking changes or non-existent upgrade paths as new minor releases of Drupal come out.
Quite a few notable modules were moved from experimental to stable status in Drupal 8.4, so I’ll provide a quick rundown here.
Datetime Range - Dates are challenging for web developers. Especially when you start dealing with things like ranges and events that span time zones. The Datetime Range module is another great tool in the Drupal developer’s toolbox. The module makes managing date and time ranges and integrating them with other parts of Drupal, much simpler.
Layout Discovery - There isn’t much to see on the frontend with this module, but it’s a really big step forward for Drupal core because standardized layout systems have never been possible with Drupal in the past. This module sets the groundwork for a common layout system across core and contributed modules.
Media - Finally! Media in Drupal core! This is a huge addition and one that will affect the team at Elevated Third in a big way because we have leveraged the contributed Media suite of modules very heavily thanks to its ability to provide a centralized media library that makes media management a breeze for content admins. Transitioning from the contributed Media module to the core Media module will bring it’s own set of challenges, but the good news is that transition does not have to happen immediately.
Inline Form Errors - This is a great little module we’ve used on quite a few sites to make the admin experience better. With Inline Form Errors, we’re able to quickly implement a system for providing users feedback when they fail to complete the necessary actions in a form.
Workflows - This is another piece of functionality lots of Drupal users have been craving. In the past, our team has leveraged the Workbench suite of modules to provide content workflow capability, but now, with Workflows in core, we have the groundwork for providing more advanced content administration experiences without the need for additional contributed modules.Behind the Scenes/Developer Tools
In addition to everything we’ve already walked through, Drupal 8.4 implemented some major changes under the hood that are worth knowing about. These changes most directly affect developers but impact anyone involved in the Drupal ecosystem because they significantly increase the complexity of this update over previous Drupal core updates.
Symfony updated from 2.8 to 3.2 - When Drupal 8 was released, you probably heard a lot about Drupal “getting off the island” and embracing the standards and practices of the larger PHP development community. Incorporating Symfony into Drupal core made this transition much simpler than it would have been to write all of the required backend components from scratch. Symfony is a PHP framework that provides a huge amount of functionality to Drupal under the hood. Just like Drupal, Symfony also has major releases, and Drupal needs to be sure it’s leveraging the latest and greatest from Symfony. This kind of update won’t often happen because Symfony releases major versions every two years. When a Drupal minor release does incorporate a major Symfony version update, the complexity of the update does increase.
Drush support - Drush is a command line tool a huge number of Drupal developers leverage to make day-to-day development work much more efficient and easier to manage. It is an invaluable tool for our development team here at Elevated Third. With Drupal 8.4, Drush version requirements were increased, so our team found that we needed to upgrade our tools, in addition to Drupal core. This requires careful planning to be sure everything plays nicely during the update process, and after the updates have been applied.What happens next?
The Drupal core release cycle works around minor releases every six months. The next expected minor release is Drupal 8.5, in March of 2018. Between now and then, there will likely be multiple patch releases that will introduce bug fixes and security updates, which will be much simpler updates and should be applied as soon as they are released.
Minor release updates introduce more complexity than the Drupal world has ever seen for updates within a major release, but the tradeoff is that when Drupal 9 comes out, you won’t have to completely rebuild!
Stay tuned for my next post detailing the Drupal 8 release cycle, where I’ll dig more into how this works, why and when you should update and what we can expect for the future of Drupal.