In the ever-evolving world of web development, a robust and flexible content management system (CMS) is crucial for creating and managing dynamic websites. We are thrilled to announce the release of Drupal CMS, now available at 2020Media, your trusted partner for hosting and domain services.
Why Choose Drupal CMS?
Drupal is a powerful and highly customizable CMS that empowers you to build everything from personal blogs to enterprise-level websites. With its modular architecture, Drupal allows you to extend and tailor your site to meet specific needs, making it a favorite among developers and businesses alike.
Key Features of Drupal CMS:
- Best for: Marketers, content creators and site builders.
- Scalability: Perfect for small projects and large-scale applications, handling high traffic with ease.
- Security: Robust security features to protect your site from vulnerabilities and threats.
- Performance: Optimized for speed and performance, ensuring a seamless user experience.
- Community Support: Benefit from a large and active community offering extensive resources and support.
Get Started with Drupal at 2020Media
At 2020Media, we understand the importance of reliable hosting for your Drupal site. Our Drupal hosting plans are specifically optimized for Drupal, ensuring top-notch performance, security, and support. Whether you’re a seasoned developer or just getting started, our team is here to assist you every step of the way.
Why Choose 2020Media?
- Expert Support: Our knowledgeable team provides personalized support tailored to your needs.
- Reliable Hosting: High-performance servers and 99.9% uptime guarantee for a smooth, uninterrupted experience.
- Affordable Plans: Flexible and competitive pricing to suit businesses of all sizes.
Don’t miss out on the opportunity to leverage the power of Drupal CMS. Visit 2020Media today and explore our hosting plans designed to maximize your site’s potential.
Contact Us:
Ready to get started? Contact our team at 2020Media to learn more about how Drupal CMS can transform your web presence. We look forward to helping you achieve your online goals!
Popular content management systems require updating from time to time. Sometimes this is for new features, often because a security loophole needs patching. In this article we’re not going to look at which CMS most often requires updates, but at the upgrade procedure itself. How easy is it, are the instructions clear and easy to follow, what the potential problems, and what can you do if something goes wrong? At the time of writing new major versions of Drupal (7.0) and Joomla (1.6) have been released and no updates have yet been produced for these releases. We therefore concentrate on the older versions, which run the vast majority of existing sites.
http://www.bbc.com/news/technology-29846539
Mark Stockley, an analyst at security firm Sophos, said the warning was “shocking”. “Many site owners will never have received the announcement and many that did will have been asleep,” he said. “What Drupal badly needs but doesn’t have is an automatic updater that rolls out security updates by default.” There is strong feeling on both sides with many arguing against “dumbing down” Drupal.
Whilst we wait for an auto-update mechanism in Drupal (perhaps in Drupal 8?), we’ve always been able to update Drupal for our customers. It’s a free service but one done “on request”.
We do not apply updates automatically to any and all Drupal sites we host for a very good reason. The risk of breaking a customer’s site is too great. It’s worth noting the Drupalgeddon security problem was the first such in 9 years. So it’s arguable the risk of such a security problem happening again on such a scale is manageably small. Drupal updates typically replace the entire Drupal codebase, leaving just the /sites/ folder untouched. If a customer or their developer has made any changes to a core file, these changes will be wiped out.
Sometimes a bug will be fixed or a feature changed as a result of an update. The site may well have a work around in place already for the bug and the update will then cause the site to break. These are just a few of the reasons.
The problem for us is, we did not build the site in the first place, nor are we familiar with it’s inner workings. So for us to be sure the site is in a working state after an update is very hard to do. A working homepage does not signify the site is 100% working. If the customer is going to be involved, which in our view they have to be, to check the site after the update, they should be involved all the way through – from the point of getting a Drupal notification email of an update, or getting a notification from the Drupal security list through to the timing of the update, to checking the site afterwards in case a roll back is required.
What changes have we made? Actually very little. We have simply streamlined our internal processes to make the technical side of doing the update a lot quicker. A lot of our customers have several sites with us. So we are now using some simply scripting so we can update all a customers sites, once they give us the go ahead.
Inspiration for the scripting came from Dane Powell ‘s blog: http://danepowell.com/node/69
Our version of the script is:
Update Multiple Drupal Sites Script
#!/usr/bin/env bash
installpath[1]=/our/pathtosite1
installpath[2]=/our/pathtosite2
installpath[3]=/our/pathtosite3
for index in 1 2 3
do
filepath=${installpath[index]}
printf "Updating %s\n" "$filepath"
cd $filepath
drush pm-refresh
drush archive-dump --overwrite --destination=/pathforbackups/backup.tar
yes | cp .htaccess ../
drush vset --always-set maintenance_mode 1
drush cache-clear all
drush up drupal --yes
drush vset --always-set maintenance_mode 0
drush cache-clear all
yes | cp ../.htaccess ./
chown -R apache:apache ./
done
Notes on the script.
This script is for discrete Drupal sites, not Drupal multisite.
We copy .htaccess out of the way and put it back afterwards and we noticed Drupal updates sometimes overwrote the original.
The final steps resets the file ownership permissions on the site to whatever your webserver runs as. If using suphp this would need to be changed.
Output is written to the command line so you can see what is going on.
Use at your own risk. Comments and improvements are welcome.