When you update Drupal core or any contributed module, it's a good idea to review the Recent log messages page (admin/reports/dblog) a few hours after the update. You want to make sure that there are no major PHP errors being generated after a deployment.

You can also use the log page to see who has logged in, modified content or created a comment. Often when I have to fix a bug on a production site, the Recent log messages page is the first place where I start my investigations.

But keeping track of the recently generated logs can be difficult, this is where you should look at using the Logging and alerts module to setup email notifications.

Honoured.

I'm honoured to accept Dries Buytaert’s invitation to become a Drupal 8 co-maintainer.

When I was contacted by Dries asking to have a chat about Drupal 8 I never dreamed that he would ask me to become a co-maintainer. I was ready for a conversation focusing on issues blocking progress in the Drupal 8 Configuration Management Initiative (CMI) such as how are we going to deal with dependencies, disabled modules and the config import process. I was prepared to talk about how the Drupal 8 performance concerns he aired at DrupalCon Munich are close to my heart, and about my plans to try and to make regular performance testing of Drupal 8 easier. Instead, Dries has offered me the opportunity to make a real difference on a much bigger scale by unblocking the work of others.

As luck would have it, I've recently resigned from Capgemini, so I have plenty of time to both continue to work on CMI, and take this amazing opportunity to work with and for the community to deliver a rocking Drupal 8!

http://buytaert.net/alex-pott

• Drupal

Honoured.

I'm honoured to accept Dries Buytaert’s invitation to become a Drupal 8 co-maintainer.

When I was contacted by Dries asking to have a chat about Drupal 8 I never dreamed that he would ask me to become a co-maintainer. I was ready for a conversation focusing on issues blocking progress in the Drupal 8 Configuration Management Initiative (CMI) such as how are we going to deal with dependencies, disabled modules and the config import process. I was prepared to talk about how the Drupal 8 performance concerns he aired at DrupalCon Munich are close to my heart, and about my plans to try and to make regular performance testing of Drupal 8 easier. Instead, Dries has offered me the opportunity to make a real difference on a much bigger scale by unblocking the work of others.

As luck would have it, I've recently resigned from Capgemini, so I have plenty of time to both continue to work on CMI, and take this amazing opportunity to work with and for the community to deliver a rocking Drupal 8!

http://buytaert.net/alex-pott

• Drupal

One of our students is learning Drupal and trying to master Views. They wanted to know how to style different areas of each Views. We wrote this tutorial as an introduction for them to templates and theming for Views.

As our example, we're going to use the "Front page" view, which is on the defaults available when you first intall Views.

The monthly Drupal core bug fix release window is this Wednesday, and since it has been a while since the last Drupal 7 bug fix release, I've decided to go ahead and plan to release Drupal 7.22 on that date. Per our release policy, this will be a bug fix release only (no security fixes).

The final patches for 7.22 have been committed and the code is frozen (excluding documentation fixes and fixes for any regressions that may be found in the next couple days). So, now is a wonderful time to update your development/staging servers to the latest 7.x code and help us catch any regressions in advance.

The relevant change records for Drupal 7.22 are listed below. This is not the full list of changes, rather only a list of notable API additions and data structure changes that might affect a number of other modules, so it's a good place to start looking for any problems:

• The Field API's memory usage has been optimized (includes recommended changes to contributed modules to leverage the changes)
• The Locale module has changed its handling of comment field language
• The number of parameters that can be passed by reference to drupal_alter() has changed (affects hook_file_download_access_alter() in Drupal 7 core)
• More Field API functions are allowed to act on a single field within an entity

You might also be interested in the tentative CHANGELOG.txt for Drupal 7.22 and the corresponding list of important issues that will be highlighted in the Drupal 7.22 release notes.

If you do find any regressions, please report them in the issue queue. Thanks!

Upcoming release windows after this week include:

• Wednesday, April 17 (security release window)
• Wednesday, May 1 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

We are excited to officially announce the DrupalCon Portland 2013 schedule. This conference program features keynotes from Dries Buytaert, Karen McGrane, and Michael Lopp, critical D8 updates by Drupal core maintainers, updates on the modules you use every day, and of course, some incredible after hours events. Make sure to check out the schedule so you don’t miss a thing!

In this episode we continue learning about the Drupal 7 Panels module and go into how visibility rules can be used to control the display of individual Panels items within your Drupal panels content.

In this episode you will learn:

• What Drupal 7 Panels module visibility rules are
• How Panels visibility rules differ from Panels selection rules
• How to use Drupal Panels visibility rules to hide and show content based on URL path

read more

As part of converting my site from Drupal 7 to Drupal 8, I ran into an issue with the core CKEditor not supporting <code> tags. The tags display fine after the intial node save, but get filtered out on subsequent node edits, regardless of the "Limit allowed HTML tags" option in the text format settings. Google turned up various discussions dating back to Drupal 6 days with this very issue, with finger pointing between Drupal, CK Editor module, and the CK Editor library itself. 

With no concrete solution in sight and not wishing to spend half a day debugging core & CK Editor, I used hook_node_view_alter() to add support for the [code] BB tag:

Note that this will not handle nested [code] tags.

If you're used to relying on $_GET['q'] from Drupal 7 (& earlier), you might be in for a surprise with Drupal 8, as $_GET['q'] is no longer defined for any request. Instead, Drupal 8 ships with a series of helper functions:

current_path() - returns the internal Drupal path (ex. node/123)

request_path() - returns the alias (ex. blog/my-post)

base_path() - returns the base path for your Drupal site (ex. /mysite/, if your site is accessible at foo.com/mysite)

request_uri() - returns the full URI, including base path, alias, and any query arguments (ex. /mysite/blog/my-post?foo=bar)

I thought it would be fun to do a little experiment. I have a project for a client that is wrapping up and one of the final things I'm doing for them is optimizing the site's performance. The client is a good candidate for this little demonstration because they have their Drupal site in a shared hosting environment, something that's quite common, but often limiting with regard to what you can do to improve performance. 

So here's how this will work, I'm going to step through a series of basic performance tweaks and then run the site through the Pingdom Tools page load tester. This will give us a good idea of what sort of improvement we get with each step.

At the end of the post we'll talk about a few other things you might be able to talk your host into providing that will help take your site's performance to the next level.

Let's start by getting a baseline of where things stand with no performance optimization at all. Take a look at the screenshot of the first test result below.

You'll see that the load time was 4.09 seconds and the page size is 1.4 MB. This site has a large image slider and several views on the home page, and those things definitely add bulk. It's interesting to note that the average size of a web page is now over 1MB. There is a lot of talk about mobile first, yet we keeping adding things that end up increasing page size. There are always trade-offs, I suppose.

Anyway, let's start optimizing by simply enabling the basic Drupal performance options.

For an explanation of what these settings actually do, check out this post by Albert Skibinski. Now that we have these enabled, let's head back to Pingdom tools and re-run the test. If you're following along using your own site, be sure you look under the settings and select the server you want to test from. If you don't, the test results may vary considerably due to server location. 

Here's the results of our second test.

Wow, pretty good! We've shaved off almost three seconds from the load time and decreased page size by 300 MB. Obviously this is a big improvement, but let's take this one step further. We're going to enable and configure the Boost module to see if we can get the page load time down even more.

Rather than get into the nitty gritty of installing Boost, I'll just refer you to the this set of instructions, but I do want to leave you with a couple of tips. First, remember to uncheck "Cache pages for anonymous users" under Drupal's performance settings or Boost won't work properly.

Also, if you have any pages you want excluded from Boost's caching, be sure to list them on the main Boost configuration page. Good candidates here are things like shopping cart pages. I learned that one the hard way!

Let's go ahead and see what sort of effect Boost had on the page load time.

The change this time is less dramatic, but the difference of .18 seconds actually represents an improvement of 14% for very little effort. Definitely worth it. Now you may be wondering what the difference is between Drupal's default caching and Boost. With default caching your pages get stored in the database. Boost, on the other hand, stores your pages as static HTML files.

In the case of my client, they're using a cPanel shared hosting environment provided by their university, so they're getting a much better set up than most commercial web hosts will provide. With the $7 a month commercial packages you see offered, the sites are jammed in like sardines. If this is your situation, you'll probably see a bigger improvement with Boost than we did in this example.

If you're using shared hosting, the next suggestions might be tough to pull off, but it never hurts to ask! I think that perhaps the most likely thing you'll be able to have implemented is gzip. By using gzip you can significantly decrease the size of your pages - smaller pages = shorter download times.

Another thing you may look into is Memcached. If your host agrees to do this for you, be sure you have the module installed first and let them know you're working with a Drupal site.

Unfortunately, I think these two might be the only server side things you'll get with a basic web hosting account, but there may be exceptions. You can get your own managed virtual server for about $30-$40 per month and in that case you'll likely be able to implement these plus a whole lot of other cool things like APC and Varnish.

Another suggestion is to look for a host that specializes in Drupal. There are some large hosts offering the $7 per month deals that say they specialize in Drupal, but I think that's wishful thinking. I don't want to get into listing web hosting companies in this post, but let Google and your good judgement guide you.

A final thing that may help you out is an article Tim Millwood recently wrote for .NET magazine. It has some good Drupal performance tips that expand on what I've discussed in this post.

If you'd like to comment about what I've written, you can do so here.

read more

If you have a public-facing development site that you don't want search engines to stumble upon and start indexing, here's a method that you can try on your Drupal site (or any other Apache site for that matter). Go through the usual process of adding your normal robots.txt file to your site, but then create an alternate robots.txt file (let's call it "robots-dev.txt") that's specific to the dev site and tells search engines NOT to index your content. Here are the contents of the text file:

#
# robots.txt
#

read more

The Drupal.org D7 upgrade project is active again and we are back with our regular week notes! During the past couple of months we mostly kept quiet because drumm and I were busy with various non-Drupal.org related tasks, such as the DrupalCon websites, association.drupal.org, etc. For the coming weeks the Drupal.org D7 upgrade is our top priority.

Today I'm pleased to share that Dries Buytaert, the project lead of Drupal has invited Oliver Reid to become his first Drupal 9 co-maintainer, and Oliver has accepted! For the duration of one release cycle, he will help Dries coordinate Drupal 9 development.

Dries is quoted about his new co-maintainer and the direction of Drupal 9:

While Oliver hasn't been involved with Drupal as long as most contributors, he brings our community a fresh and newborn perspective of Drupal and our processes. What he lacks in fine motor skills, he makes up for in his creativity and ability to just bang at a keyboard for several hours straight. Some of his code is just so complex but perfect that even I have a hard time understanding it! His experience with working with other babies will really be useful for helping hash out disagreements in the issue queues.

Yes, some people think I'm crazy for selecting a baby. With our newer contributors getting younger every year, Dmitri Gaskin being a great example, I asked myself, why can't we push the boundaries and find someone even younger? And how can you resist that cute, little, squishy face? Who's a good maintainer? Oliver is! That's who!

One of the aspects that I like best about Oliver is that his schedule is pretty wide open for the next couple of years. Finding a new core maintainer is always a tough choice, especially when all the top candidates have full-time jobs, families, and responsibilities outside of Drupal. Even though Drupal 8 hasn't been released yet, it was important to me to select someone who is able to take over pretty much everything I do and has the free time to do it. Except during his nap time. Maybe even mandatory naps would be a good thing to implement when things get heated in core development... Hrm, I'll have to think about that.

Drupal 9 will become a great platform for our future, especially in his tiny little hands.

Congratulations Oliver!

read more

Part II in a series of articles about an online web application I am working on. Read Part I

I'm am currently in the process of making my own web service, which will have a single-page-app (SPA) type of structure/interface. This is exactly the type of project that the bevy of JavaScript frameworks like Backbone.js, Angularjs, Ember.js, Knockout.js, and Meteor are build for, thus I've taken it for granted that I would use one of these frameworks as the client-side infrastructure for my app. After much review and fiddling around it turns out that I will not be using one of them. At least not for now. Below are some of reasons why (note these reasons may not apply to you, you may rightly decide that a Javascript framework is a great choice for your project(s) - these are one person's opinions only):

One of my biggest surprises/disappointments after spending a lot of time with Backbone.js and Angularjs was realizing that my (imho) perfectly awesome JavaScript/jQuery foundation layer, which I just slaved over creating, would not only have to be modified - it would have to be thrown out the window. This is because none of these frameworks are a container for your JavaScript - they are a replacement for it. Sure you might use a little bit of JavaScript/jQuery within any one of the frameworks, but overall you'll be doing-Backbone, or doing-Angular, or doing-Ember, or whatever. It's even common advice for Angular experts to tell newbies to not use jQuery at all while they are getting started, so that they can learn the 'Angular way'. Thanks, but no thanks.

I don't want to abandon my universally usable and performant JavaScript/jQuery that I can take and integrate easily into almost anything (well almost anything but these frameworks, apparently). Maybe in the future as one of the JS frameworks becomes more mature and dominant I will reconsider. Honestly, I think a platform would have be as ubiquitous as jQuery has grown to be, for me to volunteer myself for platform lock-in on the level these frameworks require now.

This is a big one for me. I can do what needs to be done with JavaScript, even reasonably well on a case by case basis. But I want to really master it. I don't want to just know Angular, or Backbone. I want to come up with solutions for the real-world, big-picture DOM/JS obstacles that I run into, presumably like the makers of the Javascript frameworks did. I want to eventually have the knowledge that I *could* make my own framework. And at that point, even if I decide to use someone else's framework I will have much more appreciation for my choice, and I will have more knowledge for how to leverage it.

Don't get me wrong I am really glad I spent the time I did looking into Backbone.js and Angularjs (I actually looked at others, but I spent the most time with Backbone and Angular). They are demystified for me now, and there are a lot of good bits, patterns, and big-picture issues that I'm more informed about now than I was previously. I can easily imagine that someone who isn't a JavaScript expert and who just wants to commit to learning the idiosyncrasies of one of the frameworks can build some really great stuff. I can also imagine that true JavaScript masters might be taking their knowledge and one of these frameworks to bring their projects to an even higher level of organization and efficiency (though I'd actually be interested in hearing from the John Resigs of the world regarding their thoughts on current framework implementations).

TL;DR: A proposal for changes to the scope of the ‘git vetted user’ permission on Drupal.org, and the related project packaging and release capabilities associated with it; changes which would affect not only Drupal’s “new project application” process, but all contrib module authors.

Much has been said about Drupal’s Project Application process as of late. Whether you are for or against it, there is one thing that everyone can agree on … we simply do not have enough volunteers to effectively manage the queue, and the resulting wait times can be somewhat frustrating for new contributors.

Over the last year and a half, we have made a number of tweaks to the process, with items such as the 'Review Bonus' program significantly increasing the number of people providing preliminary structure and code style reviews. Unfortunately, this progress has been offset by a sharp drop in participation by our more experienced reviewers and git administrators. As a result, applications are quickly moving up to RTBC instead of waiting weeks for an initial review ... only to stall out at the 'final approval' step for weeks at a time (or even months, in some cases). The truth is that the changes have not addressed the fundamental issue: it takes a significant investment of time to provide a review detailed enough to meet the standard of quality being enforced in the queue, and the current volunteer-to-applicant ratio is nowhere near what it needs to be to efficiently process applications in a timely manner.

But enough people (myself included) have shared their thoughts regarding ‘what’s wrong’ with the process today … and as the “project apps venting threads” exploded with activity again this winter, I found myself silently wishing we could get past the complaints, and back to focusing on solutions.

Well, simply wishing something does not make it happen. Without a defined end goal in mind, we find ourselves hampered by the ‘inertia of the status quo’, and thus restricted to minor, one-off, incremental changes which i) are small enough in scope to be pulled off by single individuals, and ii) do not significantly change the underlying process.

Looking back at my original proposal from 18 months ago, if fell apart on two fronts. First, while 'automation' is a noble goal, the proposal lacked definition around the 'next steps' or implementation details needed to achieve that goal. Secondly, discussions on this particular topic tend to go in circles, waiting for someone to say "Yes! Let's do this!" ... but with no obvious 'owner' of the process, that perceived validation/justification never comes.

While evolving governance discussions should help us to address this second concern, we still need to come up with a new model definition ... one which addresses potential concerns around security, code quality, and module duplication; while at the same time eliminating the enormous barrier of entry that the ProjectApps process has created for new contrib module authors.

With this in mind, I would like to propose a fundamental change to the scope of the ‘git vetted user’ permission on Drupal.org, and the related project packaging and release capabilities associated with it. Yes, it's long, but please read on ... this affects all contrib module authors, not just new applicants.

This field stores the proposed 'project shortname' for a given project. For sandboxes, the field would be editable by the project owner, but read-only to all other users. Validation logic on this field would ensure that the shortname does not conflict with any previously established projects. Validation could also go so far as to warn users about namespace conflicts with other sandbox projects, while still allowing the field to be saved.

As soon as the sandbox is created, the project owner may begin committing code to the repository. Each code commit would trigger two automated reviews ... one to validate the repository structure, and one to validate the code style of the included code, using Drupal CodeSniffer. (Automation of these tasks has already been implemented within the Project Applications queue, through the ventral.org PAReview tool ... under this proposal, the same functionality would be ported over onto Drupal's automated testing infrastructure.)

The most recent results from both of these reviews would be collected and displayed within the sandbox administration page for the project, along with a mechanism to re-trigger the reviews (to clear any infrastructure-related failure conditions). In any cases where the reviews fail due to detection of a false positive, an 'override' checkbox would be made available to administrators, which could be used to indicate a manual override of the failed result (triggered via a request to the projectapps or webmasters queue).

As long as both the 'Git Health Check' and 'Code Style' tests are passing (or overriden), the project namespace has been approved, and a valid release tag exists in the repository, a 'promote out of sandbox' link would be made available available to the project owner. This link would basically have the same effect as today's 'promote to full project' link (with one restriction) ... it would move the project over to the final project namespace and enable the creation and packaging of -dev, -alpha, -beta, and -rc releases.

If the project owner is not yet a 'vetted git user':

• The packaging system would allow the creation of -dev, -alpha, -beta, and -rc releases, but no 'final/stable' releases
• A prominent warning notice would be added to the project page, stating that
  1. The module has been contributed by an author who has not yet run through Drupal's one-time peer review process,
  2. It is recommended that the code not be deployed on production sites without a full and thorough code and security review, and
  3. Users installing the code do so at their own risk.

Users wishing to remove this warning from their project pages would need to obtain 'git vetted user' status, which would follow the existing 'project applications' process as it exists today. Given that projects had to pass both a repository health check and code style review before moving out of the 'sandbox' state, they would be entering the process in a much more 'polished' state. In addition, as any stalling at this stage only prevents creation of a 'stable' release, reviewers can enforce a high standard of acceptance; and applicants should be much more tolerant of delays in the review process if the queue does happen to get backed up.

As an added incentive for maintainers to produce 'stable' releases (and for non-vetted users to pursue 'git vetted' status), any projects which do not have a supported 'stable' release would receive another prominent warning notice on their project page:

"This project does not have a stable release on a supported major branch, and thus is thus not subject to release of Security Advisories by the Drupal Security Team. Note that the presence of a stable branch does not guarantee that the code is secure, only that the security team will consider the generation of a security advisory in response to any reported security issues."

This means that non-'git vetted' users will have two warnings displayed on their project pages by default, as they would be prevented from producing stable releases.

Projects which do have a 'full' or 'stable' release would receive a much less prominent notice, stating something along the lines of:

"Only the supported major version branches ([list of branches for the project]) will be considered for Security Advisories in case of any security issues brought forward to the Drupal Security team. Note that the presence of a stable branch does not guarantee that the code is secure, only that the security team will consider generating a security advisory in response to any reported security issues."

The exact contents, location, and formatting of these warnings on the project page would be subject to further debate, but the point would be that the first two are intrusive enough to incent project owners to create stable releases.

I'm throwing this out there for community opinion, feedback, and debate.

I do not have the bandwidth to implement all of the above myself ... but if, after community discussion, the above proposal is perceived to be viable, I will volunteer to take the next step of mapping out an implementation plan. This plan would identify a complete task list, broken down into a series of manageable bite-sized pieces, ready to be tackled by anyone in the community. I will also make myself available as a mentor for anyone who attempts to take on any of the identified tasks, whether it be helping them get set up within the drupal.org development environment, understanding of the project* module data structures, assistance in understanding the required testbot integration pieces (which I will prime), or scheduling meetings and/or sprints as required.

This process is one of the main on-ramps for new Drupal contributors entering our community ... and we have neglected it for far too long. Please take a minute to provide your honest opinions, feedback, and suggestions for improvement related to this proposal ... or maybe even propose an alternative solution of your own. And if you can spare it, spend an hour or so over in the Project Applications issue queue ... because the truth is that no major overhauls are going to happen overnight, and in the meantime, there are a number of poor souls sitting patiently in that queue; waiting for someone to come along, look at their code, and welcome them as they make that crucial next step from Drupal 'user' to Drupal 'contributor'.

Don't worry: There's no April Fools joke in today's announcement! In the spirit of spring, Lullabot's growing, and we're proud to welcome a crowd of new Bots. May we present the class of 2013 (so far)!

Emma Jane Westby (née Hogbin) has been an active member of the Drupal community for more than twelve years. She's a prolific Drupal speaker and teacher, an accomplished beekeeper, and the author of Front End Drupal and Drupal: A User's Guide. She's built in-depth training curriculum for some of the tech industry's largest companies, and she'll be joining the Drupalize.Me team as education development coordinator.

As the leader of Drupal 8's Configuration Management Initative, Greg Dunlap spent two years building a unified, secure API to consolidate Drupal's scattered configuration data. Long before Drupal, he got his start in photojournalism and eventually made his way to the software side of the news industry at The Seattle Times. He's built pinball and slot machines, co-authored the Packt Publishing's Drupal 7 Module Development, moshed his face off at innumerable punk rock shows… and now, he's joining Lullabot as its newest senior drupal architect.

You may know Kris Bulman as the co-maintainer of the popular Zen theme -- he's been designing with Drupal since 2007, and he's Lullabot's newest front-end developer. When he's not wrangling SASS or dabbling in iOS design, he likes hiking and photography near his home: scenic Prince Edward Island.

If you are reading this blog post you must be striving to improve the performance of your site. When we speak about performance two things should be taken into account essentially.

1. Number of requests the site is able to serve (The more, The better)
2. Response time per request (The least, The better)

I guess it is not much needed to stress as how essential the response time plays in deciding the success of a website. Apache the prominent Web server plays a key role in this connection.

Hi, my name is Rodney, and I am a cat.

I have to admit, after my failed #VoteMeow campaign in the 2012 Drupal Association board election, I really just wanted to curl up in a box for a while. And I did! Then I went and napped, played in a box some more, napped some more, ate some food, slept on my humans' heads, etc. You know, typical cat stuff. But apparently I'd made enough waves in the Drupal community (ironic since I hate baths) that the owners and directors at Palantir.net saw great potential in me and my box directing ability. After a long human-chauffeured drive to Chicago, I shared a dinner of milk and tuna with the owners and was made an offer to be Palantir's new Director of Feline Resourcing and Boxes. I couldn't be happier to have accepted and be starting this position today! I even get a swanky cardboard office in Chicago!

I also must speak about the progress that my hire makes in the feline community. I've been able to shatter the cardboard ceiling put above me, because my determination is sharp, as well as my claws. The cat community is commonly misunderstood in the Drupal and larger tech community, mostly because you humans don't speak felinese. Palantir has been missing out on bigger and larger box projects that until now they haven't been able to try and catch. I will be working tirelessly to tear down the walls of this virtual box separating our communication and communities, and allow us both to jump inside to get that red dot, we call synergy. Most of all I'm excited to be a part of this great team, except for the dog.

Taking a cue from Phase2 Technology’s decision to move their corporate website from Drupal to Wordpress, LevelTen Interactive is preparing a new company site utilizing a full suite of non-Drupal technologies. “This is an exciting time for LevelTen, we have really pulled out all the stops”, says founder Tom McCracken, apparently making some sort of pipe organ reference.... Read more