Drupal

I see a lot of people coming by #centos and similar channels asking for help when they’re experiencing a problem with their Linux system. It amazes me how many people describe their problem, and then say something along the lines of, “and I disabled SELinux...”. Most of the time SELinux has nothing to do with the problem, and if SELinux is the cause of the problem, why would you throw out the extra security by disabling it completely rather than configuring it to work with your application?

DISQUS is a popular "social commenting" platform. It is integrated with many hosted blog platforms and open source CMSes, including Drupal. A client of ours exported the comments from their old Wordpress blog and then imported them into DISQUS. The problem was that the comments were showing up in the DISQUS dashboard, however, when you clicked their corresponding URLs, these imported comments did not appear in Drupal. While the Drupal module looks for comments on the node/X URLs, DISQUS was storing them at the old Wordpress URL which were implemented as path aliases in this case.

Tag1 Consulting is sponsoring my work on Drupal.org Infrastructure. What this means is that instead of working on drupal.org whenever I can, I get to spend 20 paid hours per week on drupal.org infrastructure. In return for this, I have agreed to write a blog entry per month describing some of my work in detail. These will be entries covering security, performance, high-availability configuration and anything else interesting in my work on drupal.org. Hopefully these will be useful.

I look forward to spending more time securing and improving the performance of drupal.org and would like to thank everyone at Tag1 and our clients for this opportunity.

During performance and scalability reviews of sites, we regularly find ourselves submitting patches to contrib modules and core to resolve performance issues.

Most large Drupal installations we work with use a variation of this workflow to track patches:

• Upload the patch to an issue on Drupal.org if it's not already there
• Add the patch to a /patches folder in revision control
• Document what the patch does, the Drupal.org nid, and a reference to the ticket in the client's issue tracker in /patches/README.txt
• Apply the patch to the code base

We're excited to have 7 members of the Tag1 Consulting team attending the DrupalCon in Chicago next week. We are all looking forward to participating in another fantastic Drupal Conference. If you've not already bought your tickets, it's still not too late! Don't miss this one!

In Chicago, Tag1 will be passing out copies of Drupal Watchdog, participating in training courses, sessions, and BoFs, and generally enjoying the two-way sharing of knowledge with our fellow Drupal developers and users.

Drupal Watchdog Volume 1 Issue 1 is on its way to Chicago to greet all attendees of the Chicago DrupalCon. Those that subscribed should receive the first issue within the next two weeks, possibly longer for international subscribers. This issue was made possible by 23 authors, 7 editors, 2 designers, and a 3-person layout team. Its 80 pages were printed on FSC Certified paper stock with soy inks.

I'll be in Chicago attending the DrupalCon, and eager to get feedback from other attendees. Questions I'm looking to get answered include: What did you most enjoy about Drupal Watchdog Issue 1? What do we most need to improve? Is there enough interest to publish quarterly in 2012? What digital formats are people most interested in? And, what topics would you be most interested in seeing covered in Issue #2?

The printer sent me a snapshot of some finished copies of Drupal Watchdog issue #1. The photo was taken from a phone and is not high quality, but it gives you an early sneak peak as to what you can expect:

The copies of Drupal Watchdog that people find in their "tote bag" in Chicago contain an exclusive bonus: Examiner.com put together a full-color 28-page insert titled "#XMNR:CHI The Insider Guide To What To Do And Where To Do It". The insert suggests where to eat, where to drink, and what to see while you're in Chicago. It even includes a map of the area around the Drupal Towers and a list of food within easy walking distance.

Drupal Watchdog is a very content-rich magazine. Our first issue is 80 pages long and includes 7 feature-length articles, 13 standard-length articles, and 6 columns. Read on for the complete table of contents, it's quite likely you'll recognize a great number of our contributors! As a print magazine, Drupal Watchdog strives to bring you relevant information that remains useful to you for a long time to come.

We are pleased to announce Drupal Watchdog as the name of our print magazine dedicated to Drupal! A lot has been happening since our previous announcement, with an impressive array of authors committing to contributing content for our premiere issue. The first issue will focus primarily on all things Drupal 7, and will cover beginner, intermediate and advanced topics.

We are looking to pay talented authors to contribute articles to a print Drupal magazine. Issue #1 will be distributed at the Chicago Drupalcon, and will focus on Drupal 7. The newstand-quality magazine will be a content-rich resource that aims to both introduce Drupal to a wider audience, and be an invaluable resource to existing Drupal users and developers.

While Drupal's performance is always of interest, it has a hard time defending itself against the features people want to add.

There are different ways to address this, but the "less features" approach is usually not defensible.

To defend itself from the feature onslaught, Drupal tries to load as few lines of PHP code as possible, which helps to increase performance. A PHP opcode cache (such as APC) helps even more and points the way to where further improvements can be made: outside of conventional PHP.

I have created a centos/rhel Yum repository for x86_64 architectures containing all of the necessary packages for using HipHop. It depends on the EPEL and IUS repositories.