Aggregator

How GoTo came to be

3 hours 8 minutes ago
Our top stories this week delve into the decade-long history behind the Gojek-Tokopedia merger and the numbers behind Carro’s unicorn status
Betty C

Drupal Atlanta Medium Publication: Configuration Split in Drupal 8 and 9. How to Add Config To Your Live Environment

18 hours 23 minutes ago
How do enable that module for just the live site again?

Let’s first start off with understanding what the Configuration Split module does. In simple terms, it allows you to have different site configurations for your different environments. For example, you want to turn off the Views UI module on your live site. Or you want to turn off your Google Analytics module on your local, dev, and test environments but still have it active on your live site.

There are so many great articles on setting up configuration split. Here are a few good ones that I suggest reading to get you caught up to speed.

So how do you test and or create new configuration settings for your live environment while working on your local computer?

In other words, say that you have already set up your config-splits a few months ago but now your client wants to add email support using the SMTP module but you only want this enabled on the live site so you don’t accidentally send out an email from your local site to 1000’s of users. ps — I have done it before Ouch :)

Well in order to add to the live configuration you need to enable the live config split. The natural first step is to go to the config-split UI and disable the develop configuration and enable the live config. Click Click Click. But nothing. Such a simple thing but why in the heck are you not able to enable the live configuration?

Ohhh snap, that settings.php file got me again.The settings.php Environment Gotcha

One thing all of these tutorials have in common is that they show you how to set the active and inactive config-splits in your settings.php. For some servers, the code is slightly different but the idea here is that Drupal needs to somehow know what environment you are on in order to import the right configuration.

Yep! That darn settings.php file. The reason you cannot activate the live configuration settings in the UI is that the settings.php file overrides the UI click clicks. So you need to go to your file and either temporarily comment out that code or just reverse the logic. So here is what I do.

  1. Reverse the logic in the settings.php file. For me, I just have to switch out a ! in my code so that my dev and live environments are reversed.
  2. drush cr — Cache rules everything around me — Clear it
  3. Enable my new SMPT module.
  4. Edit the live config split and check the box next to live
  5. drush cex — configuration export
  6. git checkout settings.php so that my file revers back to my old settings
  7. drush cr— you know the drill clear that cache
  8. Uninstall the SMTP module
  9. drush cex — to export the uninstalled module settings to your dev config
  10. git commit my changes

I then check my setting by doing a drush csim live. This command imports the settings from the live config. You can also check your config directories manually or with a git statusto ensure there are new files in both of your dev and live directories.

If any of you have a better way to enable and add some new configuration to the live environment without all of the steps, help a brother out and let me know in the comments.

Configuration Split in Drupal 8 and 9. How to Add Config To Your Live Environment was originally published in Drupal Atlanta on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mediacurrent: Risks of Staying On Drupal 7 After Its End of Life

1 day 21 hours ago

Drupal 7's end of life is scheduled for November 28, 2022. Up until then, the Drupal Security Team will continue to provide patches to Drupal 7 core and contributed projects should any security threats arise. After that point, however, the Drupal Security team will no longer support Drupal 7.

Is it Safe to Stay on Drupal 7?

If your organization is currently running Drupal 7, you’re faced with a decision on whether to upgrade to Drupal 9 or not.

Crafting a business case can help with your decision because it contains projections for initial costs and ongoing costs for making the upgrade investment vs. maintaining the status quo, as well as projections for revenue and savings. The business case exercise can further forecast the break-even point for your upgrade investment. However, in the case of future security threats, we can’t be confident of what the future ongoing costs will be, because we can’t predict when such security threats will arise, nor will we know the severity of them. 

What we can do, however, is make organizations that use Drupal aware of the risks of not upgrading. There are three general areas of risk: security, integrations, and functionality.

Security Risks

After Drupal 7 reaches the end of life, whenever security issues are identified in core or contributed modules, there won't be very much support to fix them. Site maintainers could find themselves in the position of having to spend a lot of time searching for security holes and fixing them. This risk gets compounded if there are a lot of contributed modules in your Drupal configuration. 

There will be a few agencies that will offer the service of maintaining your Drupal 7 platform post end-of-life. This will help greatly to secure your site if you’re willing to invest in hiring such an agency. One of their main tasks is to backport fixes for core and contrib issues. These fixes will of course not be included in the D7 upgrade path because there won’t be an upgrade path at all. As a point of reference, after Drupal 6 had reached its end of life, there weren't a disproportionate amount of security fixes needed for its core nor contributed modules. Still, the risk is not zero. Every aspect of a Drupal application must be considered to ensure there are no security gaps.

Another aspect of taking this path is that much of the time maintaining a site like this is spent managing and mitigating security risks rather than making improvements or implementing new features. For a good many developers, this is not rewarding work. 

In the history of previous Drupal security fixes, some have been pretty small -- one-line changes that take an hour to review and fix -- while others have taken days or even weeks of development time to analyze and produce a solution for. 

An advantage of choosing to upgrade a Drupal 7 site to Drupal 9 is that you gain all of the advantages of security improvements that were included in Drupal 8 and each subsequent feature upgrade. In this blog post, Peter Wolanin of Acquia details some significant security improvements included in the initial Drupal 8 release. Drupal 9 has additional advantages such as support for PHP 8.0.

Integration Risks

Certainly, security risks will come along, but another risk area in maintaining the status quo is that key integrations will eventually start to fail. For example, your Drupal environment may be integrated with another platform, and a key API on that platform is getting deprecated. Because the Drupal module that connects to it is no longer being actively maintained, you (or an agency you hire) will have to update the module or write a new custom module to keep integration working.

Functionality Risks

As the Drupal community continues to diminish the amount of activity on Drupal 7 core and contributed modules, especially after end-of-life, you basically lose those “free” updates. This is especially so with bug fixes. This forces you to either live with them or to fix them, or again, hire an agency to do it. If you do hire someone, that person won’t be as familiar with the project as one of the maintainers would be, so you’d have to factor in that additional investment. Indeed, some of these risks can be so critical that you end up rewriting large chunks of code to deal with them.

Not only do you miss out on the security improvements of Drupal 8/9 discussed above, not upgrading means you're missing out on many other improvements. Drupal 8 and 9 are built around a modern PHP stack including features such as Composer compatibility, Symfony components, modern OOP coding techniques, and more. While Drupal 7 has served our community well, it is not built upon the latest PHP libraries and development workflows that developers expect. This allows Drupal 8/9+ site owners the advantage of further enhancing their security posture by adding the Guardr security distro or module. While Drupal 8 and 9 have good security features, Guardr adds additional community vetted modules and settings which meet industry security requirements.

Talk To Us

As already mentioned, there are too many future unknowns to create a blanket business case for an upgrade investment. However, we can craft a business case specific to you based on the complexity of your existing Drupal 7 solution. We will factor in the number of modules you’re using, their complexity, the nature of your integrations with external systems, and more. We at Mediacurrent have performed this type of analysis for some of our clients to help them with their technology investment decisions and can do the same for you. Please contact us to learn more!

Talking Drupal: Talking Drupal #299 - Sustainability of the Webform Module

1 day 22 hours ago

Today we chat with our friend Jacob Rockowitz about the sustainability of the webform module and module maintainership sustainability in general.

www.talkingdrupal.com/299

Topics
  • Jacob's 5th appearance
  • John got a new job!
  • Jason launching 6 sites this week
  • Nic went to the drive-in
  • Jacob no more bike rides, just walks in the park
  • Stephen finding Ansible useful

Story: Recording episode 300 - get your recordings into [email protected]

  • Elevator pitch for webform
  • When did Jacob begin maintaining Webform
  • What is sustainability?
  • Open collective
  • How to make Drupal more sustainable
  • Ways to contribute
  • Donations vs time contribution
  • Why open collective?
  • Is there an exit plan
Resources

https://www.jrockowitz.com/blog/webform-open-collective-funds-spent

Open Collective Promotion: https://www.youtube.com/watch?v=MtlFTwZLKpc&t=1s

jrockowitz.com

Guests

Jacob Rockowitz www.jrockowitz.com @jrockowitz

Hosts

Stephen Cross - www.stephencross.com @stephencross

Nic Laflin - www.nLighteneddevelopment.com @nicxvan

John Picozzi - www.oomphinc.com @johnpicozzi

Jason Pamental - rwt.io @jpamental