The monthly Drupal core bug fix release window is this Wednesday, and since it has been a while since the last one, I plan to release Drupal 7.25 on that date. However, in practice the release might not happen until Thursday, due to the holiday and to give people a bit more time to test the latest code. Per our release policy, this will be a bug fix release only (no security fixes).
The final patches for 7.25 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.25 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:
If you do find any regressions, please report them in the issue queue. Thanks!
Upcoming release windows after this week include:
- Wednesday, January 15 (security release window)
- Wednesday, February 5 (bug fix release window)
Contrary to popular belief, the Drupal 8 Configuration Management Initiative (CMI) is not done. In fact, there is still a fair amount of work remaining. To help get some momentum, we are going to start holding CMI IRC meetings in #drupal-cmi every other Monday at 20:00 UTC (3pm Eastern). Our next IRC meeting will be Monday, January 13 at 20:00 UTC. Additional meetings will be on January 27, February 10, 24, etc. All of the Drupal 8 initiative meetings, including the CMI meetings, are listed on the calendar on Drupal 8 Updates and How to Help.
Anyone who is interested in helping to get Drupal 8 closer to having a working configuration system is welcome to join the IRC meetings. That said, we have a lot of complex problems to solve. While it would certainly be helpful to check out the the issues listed under the tabs above (Focus Issues, Beta Blocker, Novice Issues, etc.) our most important issues at the moment are listed on the meta issue Making configuration synchronisation work.Tags:
One of my favorite Drupal moments in 2013 was meeting Gaelan Steele in person at DrupalCon Portland. This was eclipsed very quickly by being present when Gaelan and Dries met for the first time - and having my podcast microphone on! This was probably also eclipsed by Gaelan schooling Dries on how he learned to use Drupal ... see his answer below and in the podcast.
If you’ve been reading my posts for a while, you’ll know that I’m a fan of the Omega base theme and have used it in many of my projects. As I’ve gotten more familiar with it, I’ve noticed it bears a striking resemblance to the latest release of Zen.
For those of you not familiar with Drupal base themes, Zen has long been the most popular. I thought I’d take a look at the two of these themes and see how they really match up and which one might be the better choice for a given project.Big Changes to Omega
First things first - Omega 4 bears only a passing resemblance to Omega 3. It’s essentially a complete re-write (see my overview) and the changes may be jarring for those who’ve become familiar with Omega 3’s UI layout tools.
Those tools are long gone. As I noted above, what you have with Omega 4 is something strikingly similar to Zen in almost every way. Much of this has to do with both maintainers adhering to emerging best practices in front end development, but it's also due to choice of tools.Feature Comparison
Below is a table that shows some of the features of both Zen and Omega.Feature Omega Zen HTML5 Yes Yes Sass + Compass Yes Yes Swappable layouts Yes Yes Default grids Susy Zen Grids Drush support Yes Yes IE conditional classes Yes Yes Mobile first Yes Yes HTML5 shiv, Respond.js Yes Yes
Quite a bit of overlap wouldn’t you say? Having worked with both themes, I can tell you it’s pretty easy jumping back and forth between them. Conceptually, they are essentially the same, with only minor differences in implementation.
One thing that sticks out to me is that both are very flexible. You can create an Omega sub-theme using Zen Grids, for example. Likewise you can create a Zen sub-theme using Omega’s default grid system, Susy.
The SMACSS approach to modular CSS makes it a snap to move some of your boilerplate styles between themes. They’re both put together in a really smart way and offer big improvements over previous approaches to theme development.
And of course, both use Sass + Compass, which seems to be preferred over LESS among Drupal developers.One Difference Between Zen and Omega
We see that the two of these base themes have a lot in common, but in what ways are they different? Well, one difference seems to stem from the choice of default grid system.
Omega 4 uses Susy, and from what I understand, it has frequent updates that may break backward compatibility. This means you’ll need to keep careful track of your Gem versions, particularly when working in a team, if you want your Sass to compile correctly. The maintainer of Omega has explained how to set things up in this comment.
I suppose it could be argued that what he’s describing is a best practice generally, but will most people go through all of that? My experience tells me no. It really seems like a potential trouble spot, but I’m not sure. Perhaps Omega 4 hasn’t been around long enough to hear of missing Gemfiles causing issues - maybe it won’t be a problem at all.
That said, the “ideal set up” is a point of difference. With Zen you can get started with less hassle. Does this mean Zen is better than Omega? I don’t think so. For some, this will fit right in with the way they are already working.The Big Difference
The biggest difference between the two base themes is Omega’s inclusion of layouts. These are predefined, Panels-style layouts that can be used with the Context Omega module to apply layouts to specific pages, content types or whatever other condition you may require.
These layouts can also be used with Panels Everywhere. In fact, the Omega layouts will appear in Panels when you have both Omega and Panels installed. Keep in mind, however, you can’t use these with vanilla Panels - only with Panels Everywhere. This is because Omega 4 layouts are variations on page.tpl.php and therefore control the entire layout of the page rather than just the node.
Sebastian Siemsen, the co-maintainer of Omega, did a long screencast on how to use Omega 4, including strategies for use with Panels for those that are interested.So Which Is Better?
Of course the answer here is, “it depends”. If you like building sites with Panels Everywhere, then Omega 4 might have the edge. If you don’t like the development set up of Omega 4, then Zen might be a better choice. Another thing in Zen's favor is far superior documentation.
However, I think the truth is that it hardly matters which of these two you choose. Personally, I use both and I think that’s rather a good thing. It allows me to easily switch between them depending on the requirements of a given project.
If you have any comments on this post, you may politely leave them below.
This is the 13th issue of the weekly Drupal news round-up and the last one in the year 2013. The last week was pretty silent and it was hard to find something interesting, but in the end I've managed to dig some Drupal gold for you. Today will be no dessert, because of the sad events happening in my country of origin.
Wish you all a Happy New Year! Be healthy and happy, the rest is not so important. Let's Drup Up The Week!Read on about Let's Drup Up The Week. Issue 13
We have created an Eldir sub-theme that adds a Wunderkraut flavour and some other tweaks which make the Ægir UI more friendly and tasty.
Here at Wunderkraut Benelux, we love Ægir. We use to manage some aspects of our development, staging and production environments.
Since we often provide access, documentation, etc to our internal and external clients, we have created an Eldir sub-theme that adds a Wunderkraut flavour and some other tweaks which make the Ægir UI more friendly and tasty.
Weldir, as we've named the theme, builds on the Eldir theme and adds a few things we felt that were missing; buttoned pagers, a better footer position, some breathing room, and so on. Since we also document stuff in Ægir, we've added styling which can be used on links to create in-content buttons - call-to-actions if you will, to spruce up content and draw attention where needed. Simply add the button class to your link.
Weldir is available on GitHub. We hope it provides you with an alternative theme for this great tool.
I've been following HHVM (HipHop Virtual machine) for some time now. Project got a bit more of my attention about a year ago, after session at FOSDEM 2013 by Sara Golemon. PHP has been criticized for quite a lot of it's characteristics, performance definitely being one of those. HHVM seemed to be very promising about fixing it and that's why it got my attention in the first place. Immediately after last year's FOSDEM I tried it with Drupal, but my attempt unfortunately failed miserably. HHVM was simply not yet ready for that.But first a bit of history...
HipHop was initially developed by Facebook (and they are still it's main contributor). Facebook was looking for something that would make their PHP code base perform faster while still retaining benefits that PHP brings (primarily ease of use for developers). Initially they created a compiler (HPHPc) that transformed a PHP script into a C++ program, which was then compiled into a binary. This approach showed dramatic increase in performance, but also had some problems. HPHPc did not fully support PHP language and was not a simple drop-in replacement for "standard" (Zend) PHP.
Facebook decided to deprecate HPHPc, start working on a bit different approach and HHVM was born. HHVM is a Just-in-time compiler (JIT) for PHP. It behaves very similar to standard interpreter when observed from the outside (which means it can be a drop-in replacement for it), but it works quite different internally. It will run a program as an interpreter at the beginning of execution, collect some statistics for optimization and eventually compile it to byte code on the fly. Compiled program will then run much faster than it's interpreted version. It is quite obvious that we get true performance gains with applications that run for a longer period of time (because of initial interpretation phase and on-the-fly compilation). A standard web (Drupal) application, which is deployed to production servers from time to time, is exactly what we're looking for.
Global Sprint Weekend is a worldwide event you can participate in. Small local sprints in lots of locations, over the same time period: Saturday and Sunday January 25 and 26, 2014. These sprints will usually be 2-15 people in one location, together, working to make Drupal better.
You can make your own locations if no location is near you! Currently people have announced locations in Sevilla Spain; Berlin, Mannheim and Schwerin Germany; Ghent Belgium; Budapest Hungary (hosted at Cheppers and led by Gábor Hojtsy); Manchester UK; Vancouver, London (Ontario) and Montréal Canada; Oak Park, Chicago, Milwaukee, Boston, Minneapolis and Austin USA.
At my day job, we've been using the Domain Access module with Drupal 6 for 5 years. Recently, we've decided it's time to rethink our approach to Drupal multisite. In this article, I'll share some of ideal use cases and pitfalls for the Domain module and some alternatives for you to consider.
With Drupal and Views, we are able to configure a View's settings and import/export them across Drupal sites. This allows us to create backup copies of our View's settings and/or move a View between Drupal sites with relative ease.
Typically this is a manual process by using the Views UI to copy the "export" code string from one site:http://dev.example.com/admin/structure/views/view/frontpage/export
..and then paste the string into the "import" form on another site: