Drupal Planet

Last week, at the amazing Drupal North regional conference, I gave a talk on Backdrop: an alternative fork of Drupal. The slides from the talk are attached below, in PDF format.

Last week, Nathan Vexler of the University of Waterloo, and Khalid Baheyeldin of 2bits.com presented at the Waterloo Region Drupal Users Group on Backdrop CMS.

Backdrop CMS is a fork of Drupal, based mostly on Drupal 7.x, and mostly compatible with its API. It also has some features from Drupal 8.x. It aims to provide an alternative that reduces the cost of ownership by minimizing the learning curve for developers.

In a previous article from over 5 years ago, we advocated the use of Apache MPM Worker Threaded Server with fcgid over Apache's mod_php.

That was for serveral reasons, including faster handling of static files by Apache threaded server, and lower memory utilization since PHP is not embedded in every Apache process.

However, there were some drawbacks, mainly that APC opcache cache is not shared, and each process has to have its own copy.

We were recently approached by a non-profit site that runs on Drupal.

Major Complaints

Their major complaint was that the "content on the site does not show up". The other main complain is that the site is very slow.

Diagnosis First ...

In order to troubleshoot the disappearing content, we created a copy of the site in our lab, and proceeded to test it, to see if we can replicate the issues.

Everyone needs to have a backup plan for their live site. Not only can your server's disk get corrupted, but you can also erroneously overwrite your site with bad code or bad data, or your site can get hacked. Detecting the latter situations takes some time. Hours or days.

For this reason, you should have multiple backup copies at multiple time points.

The most convenient scheme is to have a 7 day sliding backup: that is, you have one backup snapshot for each day of the week, with today's backup overwriting the backup from 8 days ago.

Most of high traffic or complex Drupal sites use Apache Solr as the search engine. It is much faster and more scaleable than Drupal's search module.

In a previous article on Drupal with Apache Solr 4.x, we described one way to install the latest stable Apache Solr 4.x. That article detailed a lot of manual steps involving downloading, extracting, setting permissions, creating a startup script, ...etc.

Most of high traffic or complex Drupal sites use Apache Solr as the search engine. It is much faster and more scaleable than Drupal's search module.

In this article, we describe one way of many for having a working Apache Solr installation for use with Drupal 7.x, on Ubunutu Server 12.04 LTS. The technique described should work with Ubunut 14.04 LTS as well.

On Friday May 2nd, 2014, Khalid of 2bits.com, Inc. presented on Drupal Performance.

The presentation covered important topics such as:

Khalid of 2bits.com Inc. will be presenting Drupal Performance Tips and Tricks at DrupalCamp Toronto 2014 this coming Friday May 2nd at Humber College, Lakeshore Campus.

See you all there ...

We previously wrote in detail about how botnets hammering a web site can cause outages.

Here is another case that emerged in the past month or so.

Again, it is a distributed attempt from many IP addresses all over the world, most probably from PCs infected with malware.

Their main goal seems to be to add content to a Drupal web site, and trying to register a new user when that attempt is denied because of site permissions.

The pattern is like the following excerpt from the web server's access log.