The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, there have been three releases (security releases as well as bug fix releases) in the last month and a half, and not as many changes have been committed to the development version since then as would normally warrant yet another new release.
A Drupal 7 bug fix release during the October release window is likely instead.
Upcoming release windows include:
- Wednesday, September 17 (security release window)
- Wednesday, October 1 (bug fix release window)
Here is to clarify once and for all – I maintain 17 packages:
- clzip, lunzip, lzd, lzip, lziprecover, lzlib, pdlzip, plzip, zutils
- live-boot, live-build, live-config, live-images, live-manual, live-tools
Not more, not less, and I also do not intend to upload any new packages to Debian.
About a year ago I wrote a post on my personal blog about theming with Zen versus theming with Omega, and someone pointed out that there was a new release of Omega. However, until now, I've not been able to look and see how it differs. Armed with a free week to do some personal learning and keen to finally try installing and playing with Sass for the first time, Omega 4 became my guinea pig.
This post serves two purposes: it's partly a comparison between Omega 3 and Omega 4, but it also documents how to create an Omega 4 subtheme and set up Sass for the first time.Before we begin About Omega 4.x
Omega is one of the best-known themes for Drupal, with over 80,000 installations at time of writing. Version 4.x takes a huge step away from 3.x. It's not just different: it feels like a whole new piece of software. The project page says:
Omega 4.x is a base theme framework aimed at themers who want to gain full control over the theme through code, rather than a user interface. If you depend on the user interface you can continue using Omega 3.x.
Nearly everything has been rewritten - the CSS has been optimized and cleaned up, partly to conform to new Drupal 8 standards, making it more future-proof; there are premade layouts available; and some functionality has been split out into extensions, while other bits have been combined into the main theme.
There are also some new features, including a browser width indicator (useful if you're doing responsive development in the browser). My favourite thing is the Drush integration: for 3.x you had to install Omega Tools to get Drush commands, but it's now all built in.Differences
While I didn’t like the UI for rearranging components, that's probably one of the features I miss the most. In fact, there are a lot of differences in the theme settings: namely, in Omega 3, you could overlay the grid columns, but all you get in Omega 4 is a region demonstration. Everything else is now handled in code.
I can get this sort of thing from the block page... why do I need it permanently?
That does (in theory) make it easier to create new layouts. One of my biggest criticisms of Omega 3 was that it was so difficult to change the grid, but now you can create multiple layouts . I can see that being useful for a multi-site installation, and, if you pair it with Context , it could be useful for page-by-page layouts. You can also use the ones provided with Omega or its default subtheme Ohm - I've become quite a fan of Hero (above).
There's no more configuration through Delta (although I'm assured that's still possible, despite the project page explicitly stating that "Omega 4.x should NOT be used with Omega Tools and Delta"), but pleasingly, there's no more enormous and unwieldy .info file with two dozen files attached. Everything has been shifted into the backend, and the CSS is all compiled with Sass/Compass now.
It is worth pointing out that the huge, unwieldy .info file will return if you choose to stop serving the theme settings from a variable. This will export the settings and put them into the .info file, improving the performance.
For those who have delved into Sass before, you should find it easy enough to start using Omega 4 straight away. I’ve never used Sass before, so this will be a learning curve for me.
If you're looking for a starting point, you can try looking at the official Omega theme documentation, but I warn you that it's not the best place to go for information about installing Ruby and other component features.Installation
Before I begin I just want to link to this awesome tutorial on creating new Omega subthemes by Daniel Sipos, which cleared up lots of things for me. Without that I'd probably still be trying to install Sass several days later.
So if you're looking for a real tutorial, go there. I'll just skim through basics. I'm not going to hold hands, but I will provide links where possible.Omega itself
First and foremost, you'll need to download and install Omega. Whether you do it through Drush or by visiting the project page and downloading a zip file is up to you.
Why are we installing Omega first? Easy: when you make your subtheme in Drush, it'll tell you what version of Ruby you need to install for Sass to work.Ruby
It's worth pointing out that if you're on a production server it's best practice not to install Sass unless you absolutely have to. Use Sass in your dev environment, fine, but only upload your compiled CSS files to your server.
Alternatively, if you don't want to use Sass at all, don't bother installing Ruby and ignore the contents of the Sass directories.Omega subtheme
Once RVM is set up, create a subtheme. If you're feeling brave you can do it manually , but if you've got Drush installed it's so much easier just to run through the wizard with this command:$ drush omega-wizard
Run that inside the site directory, follow the instructions, and enable it if you want. See? Much easier than copying and renaming files. And all on a new Drupal installation, too: I really appreciated that I didn't have to install anything to create a subtheme.Gems and finishing
Finally, navigate (in your command line) to the base folder for your theme. You should get a notice:ruby-1.9.3-p547 is not installed. To install do: 'rvm install ruby-1.9.3-p547'
If you do, then go ahead and install it. The Ruby version is related to the exact version of Omega you've installed, so pay close attention to the version number and run the command as it’s written.
In the base directory for the theme, you'll see there's a file called "Gemfile". This dictates which gems should be installed for the theme to work. Just run this command:$ bundle install
That should fetch and download everything you need, and that's pretty much it!
The blog post I mentioned has more information about installation and some troubleshooting, so refer to that if you're stuck.
Now you can start editing the files in the themename/sass folder. Run this in your command line:$ compass watch
for live updates (it will "watch" the SCSS files and automatically compile them when you save a change).Creating layouts
Creating a new subtheme is much easier in Omega 4 than in 3 (or even Zen), with a caveat of "if you have Ruby and Sass already installed". If you've got to here and are thinking "yikes, that's a whole lot of work" or "that's too much command line work", you might think about trying Zen or Sasson instead.
But if you've got this far, chances are you want to create a layout that's not a 1-2-1 grid layout. There are a couple of ways to go: you can copy one supplied by Omega/Ohm (such as Hero) and modify it, or you can create your own.
Layout options for Omega 4 - default plus "Hero" from Ohm
I quite like Hero, so I stuck to using that. You can see some of the basic layout options on the Appearance page. This is as close to Omega 3's user interface as you'll get.
Luckily, there are some articles on Drupal.org about creating a new layout for Omega. This first one explains the basics - what you'll need in order for the layout to work - while a second one goes into a little more detail about folder and file structure.
This is much more complicated than Omega 3, but at least you can change the layout and grid if you want to. You could take some inspiration from around the web to create something new - including Gridset - and it seems to be quite similar to creating a new subtheme. They come complete with a pseudo-info file and everything!
It took me a while to get my head around "how Sass works". I understood the variables and mixins - that was what I was most keen to try - but I found it hard to understand partials and compiling the files.
Actually, it was all a lot easier than I expected. You write your SCSS files then add them all to one main file with several @includes in it. Lots of people have written about their chosen directory structures; Omega gives you some folders as a starting point. Check out Stu Robson's "Structuring my Sass 101" post too.
One thing to bear in mind is that many people offering advice about file structures are not using Drupal (or an Omega subtheme)! You might find their advice isn't always relevant.
Finally, it's important to consider how you can integrate your Sass files and your version control. Some suggest only committing the uncompiled files for several reasons, such as forcing other developers to use the “correct”, while others say it doesn't make much difference. Right now I'm primarily a back-end developer, so I'm not sure what the best workflow is, but I’ll be interested to find out what does and doesn’t work.Wrapping it up So who is Omega 4.x for?
You should consider using Omega 4.x if ...
- ...you're comfortable with getting your hands dirty and don't mind coding a layout from scratch.
- ...you like using, have used, or want to start using Sass to write your CSS.
- ...you want to create a whole new layout from scratch, with a custom grid system.
- ...you don't need a user interface to modify the theme settings.
- ...you're making a push towards more modular, SMACSS -based CSS.
Otherwise, you might want to consider using Omega 3.x, or a different theme altogether.Other useful links
- Musings on Preprocessing | CSS-Tricks
- Always Twisted - Sass blogging by Stu Robson
- Omega theming handbook
- Omega 3.x vs. Omega 4.x - Comparing Apples and Oranges
This time, for personal reasons I wasn’t able to attend the full DebConf, which started on the Saturday August 22nd. I arrived at Portland on the Tuesday the 26th by noon, at the 4th of the conference. Even though I would like to arrive earlier, the loss was alleviated by the work of the amazing DebConf video team. I was able to follow remotely most of the sessions I would like to attend if I were there already.
As I will say to everyone, DebConf is for sure the best conference I have ever attended. The technical and philosophical discussions that take place in talks, BoF sessions or even unplanned ad-hoc gathering are deep. The hacking moments where you have a chance to pair with fellow developers, with whom you usually only have contact remotely via IRC or email, are precious.
That is all great. But definitively, catching up with old friends, and making new ones, is what makes DebConf so special. Your old friends are your old friends, and meeting them again after so much time is always a pleasure. New friendships will already start with a powerful bond, which is being part of the Debian community.
Being only 4 hours behind my home time zone, jetlag wasn’t a big problem during the day. However, I was waking up too early in the morning and consequently getting tired very early at night, so I mostly didn’t go out after hacklabs were closed at 10PM.
Despite all of the discussion, being in the audience for several talks, other social interactions and whatnot, during this DebConf I have managed to do quite some useful work.debci and the Debian Continuous Integration project
I gave a talk where I discussed past, present, and future of debci and the Debian Continuous Integration project. The slides are available, as well as the video recording. One thing I want you to take away is that there is a difference between debci and the Debian Continuous Integration project:
- debci is a platform for Continuous Integration specifically tailored for the Debian repository and similar ones. If you work on a Debian derivative, or otherwise provides Debian packages in a repository, you can use debci to run tests for your stuff.
- a (very) few thinks in debci, though, are currently hardcoded for Debian. Other projects using it would be a nice and needed peer pressure to get rid of those.
- Debian Continuous Integration is Debian’s instance of debci, which currently runs tests for all packages in the unstable distribution that provide autopkgtest support. It will be expanded in the future to run tests on other suites and architectures.
A few days before DebConf, Cédric Boutillier managed to extract gem2deb-test-runner from gem2deb, so that autopkgtest tests can be run against any Ruby package that has tests by running gem2deb-test-runner --autopkgtest. gem2deb-test-runner will do the right thing, make sure that the tests don’t use code from the source package, but instead run them against the installed package.
Then, right after my talk I was glad to discover that the Perl team is also working on a similar tool that will automate running tests for their packages against the installed package. We agreed that they will send me a whitelist of packages in which we could just call that tool and have it do The Right Thing.
We might be talking here about getting autopkgtest support (and consequentially continuous integration) for free for almost 2000 4000 packages. The missing bits for this to happen are:
- making debci use a whitelist of packages that, while not having the appropriate Testsuite: autopkgtest field in the Sources file, could be assumed to have autopkgtest support by calling the right tool (gem2deb-test-runner for Ruby, or the Perl team’s new tool for Perl packages).
- make the autopkgtest test runner assume a corresponding, implicit, debian/tests/control when it not exists in those packages
During a few days I have mentored Lucas Kanashiro, who also attended DebConf, on writing a patch to add support for email notifications in debci so maintainers can be pro-actively notified of status changes (pass/fail, fail/pass) in their packages.
I have also started hacking on the support for distributed workers, based on the initial work by Martin Pitt:
- updated the amqp branch against the code in the master branch.
- added a debci enqueue command that can be used to force test runs for packages given on the command line.
- I sent a patch for librabbitmq that adds support for limiting the number of messages the server will send to a connected client. With this patch applied, the debci workers were modified to request being sent only 1 message at a time, so late workers will start to receive packages to process as soon as they are up. Without this, a single connected worker would receive all messages right away, while a second worker that comes up 1 second later would sit idle until new packages are queued for testing.
I had some discusion with Christian about making Rubygems install to $HOME by default when the user is not root. We discussed a few implementation options, and while I don’t have a solution yet, we have a better understanding of the potential pitfalls.
The Ruby BoF session on Friday produced a few interesting discussions. Some take away point include, but are not limited to:
- Since the last DebConf, we were able to remove all obsolete Ruby interpreters, and now only have Ruby 2.1 in unstable. Ruby 2.1 will be the default version in Debian 8 (jessie).
- There is user interest is being able to run the interpreter from Debian, but install everything else from Rubygems.
- We are lacking in all the documentation-related goals for jessie that were proposed at the previous DebConf.
I was able to make Redmine work with the Rails 4 stack we currently have in unstable/testing. This required using a snapshot of the still unreleased version 3.0 based on the rails-4.1 branch in the upstream Subversion repository as source.
I am a little nervous about using a upstream snapshot, though. According to the "roadmap of the project ":http://www.redmine.org/projects/redmine/roadmap the only purpose of the 3.0 release will be to upgrade to Rails 4, but before that happens there should be a 2.6.0 release that is also not released yet. 3.0 should be equivalent to that 2.6.0 version both feature-wise and, specially, bug-wise. The only problem is that we don’t know what that 2.6.0 looks like yet. According to the roadmap it seems there is not much left in term of features for 2.6.0, though.
The updated package is not in unstable yet, but will be soon. It needs more testing, and a good update to the documentation. Those interested in helping to test Redmine on jessie before the freeze please get in touch with me.Noosfero
I gave a lighting talk on Noosfero, a platform for social networking websites I am upstream for. It is a Rails appplication licensed under the AGPLv3, and there are packages for wheezy. You can checkout the slides I used. Video recording is not available yet, but should be soon.
That’s it. I am looking forward to DebConf 15 at Heidelberg. :-)
eCommerce is undergoing rapid change from the traditional search, view, add to cart, and checkout paradigm to one that is rich in content, creates a more engaging and unified user experience, and drives buying decisions within that context. This change will require a shift in thinking around the platforms selected and their ability to support both content and eCommerce needs seamlessly. No longer will silo'd solutions with a long list of features that make vast (and many times incorrect) assumptions about your business provide the tools necessary to respond and adapt quickly to these market changes.
If you already have Drupal to manage content and community interaction for your site, or are considering it for its powerful CMS capabilities, and plan to add or upgrade commerce capabilities, you have two choices:
A separate eCommerce solution that is integrated with or "bolted on" to Drupal. While this can work, it adds unnecessary complexity and results in a disconnected experience for your users that maintains valuable customer data in multiple places. An alternate choice that an increasing number of companies are considering...
Utilizing the power, scalability, and flexibility of Drupal + Drupal Commerce, where content, community, and commerce can all be served natively within a single environment.
Here is why it is important to go beyond features to make the right long-term decision for your business.
Looking Beyond Features when Selecting an eCommerce Solution
All too often, eCommerce selection is based on a long list of features. While features are important, focusing too much on features creates blind spots that prevent focus on other more strategic considerations that have far greater impact on long-term success. The reality is that eCommerce solutions today all do approximately the same thing. General feature parity exists because eCommerce has been around for a long time and there is little in terms of features that differentiates one from the other.
Let's face it, any feature list, and the assumptions they are based on, only reflects requirements that are important at a given point in time. Undoubtedly, those requirements will change over time; sometimes very quickly. As a result, it is increasingly important to consider how well the solution you select can adapt to rapid changes in technology, the market and your business needs. The important choice here is determining how much control and flexibility you want to retain in adapting to these changes versus being dependent on a particular solution vendor to meet those needs.Having the flexibility to implement new features and rapidly innovate in the future to serve the changing needs of your customers and business is a critical consideration when selecting an eCommerce solution.
As businesses focus more on inspirational shopping driven by engaging content, the "feature" that will become increasingly important is a rich CMS that is natively integrated with eCommerce.
Drupal + Drupal Commerce provide seamless Content and Commerce
The importance of content and social engagement in influencing what people buy cannot be overstated. Drupal + Drupal Commerce is the only solution that provides powerful content, community, and commerce functionality all within a single environment. A rich content platform like Drupal is critical to creating an engaging user experience that results in attracting people to your site, keeping them there longer, and spending more money.
Today, there is massive competition for eyeballs and high placement in search results. Google and other search engines now place higher priority on content that exists on your site and how that is shared and linked with other sites. A weak CMS or one that is separate from your eCommerce platform makes it significantly more difficult to get the results necessary for success. And if your online presence is split between two systems, it becomes even more challenging to target and personalize messages and offers since customer data resides in multiple databases.
While many sites bolt together independent CMS and eCommerce solutions, it's not nearly as powerful. A Drupal + Drupal Commerce solution means that you have 1 code base, 1 skill set, 1 backend, and 1 database, resulting in less complexity and a single platform to support your entire online business.
This is the 'almost' monthly update from the Documentation Working Group (DocWG) on what has been going on in Drupal Documentation. Because this is posted in the Core group, comments for this post are disabled, but if you have comments or suggestions, please see the DocWG home page for how to contact us. Enjoy!Notable Documentation Updates
- Kåre Slettnes (kaare) contributed a great number of docs on using emacs for Drupal development: https://www.drupal.org/node/2327707
- owenpm3 updated the documentation for disabling modules: https://www.drupal.org/node/157632
- Jay.Chen wrote documentation for the mmenu module. https://www.drupal.org/node/2324017
- erok415 updated the Open Atrium 2 documentation: https://www.drupal.org/node/2321639
- The installation guide saw quite some updates and progress was also made on the theming documentation for Drupal 8
- Many people updated Drupal 8 documentation about, among others, configuration management, migrate, state & block API
Since our last post from August 1, 223 contributors have made 657 Drupal.org documentation page revisions, including 4 people that made 20 or more edits (thank you erok415, Jay.Chen, iantresman & drumm) and one person that did a whopping 66 revisions (keep rocking kaare!).Report from the Working Group
- We are preparing a Documentation sprint at DrupalCon Amsterdam where we hope to finalize the work on the Drupal 8 help texts (to help out, see https://www.drupal.org/node/1908570). We will also make a start with creating or updating docs for the D8 core modules. We'll be using documentation issue tag "docsprint" to tag issues that we think will be good for sprints, over the next two months especially.
- After an initial period of setting up the DocWG, we have now opened up the monthly meeting of the Documentation Working Group to anyone who would like to attend. Let me know if you want to join the meeting.
The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.
If you're new to contributing to documentation, these projects may seem a bit overwhelming -- so why not try out a New contributor task to get started?
- A few new examples were added or updated, including use of the fabulous new docopt package by Edwin de Jonge which makes command-line parsing a breeze.
- Other new examples show simple calls to help with sweave, knitr, roxygen2, Rcpp's attribute compilation, and more.
- We also wrote an entirely new webpage with usage example.
- A new option -d | --datastdin was added which will read stdin into a data.frame variable X.
- The repository has been move to this GitHub repo.
- With that, the build process was updated both throughout but also to reflect the current git commit at time of build.
Debconf14 was the first Debconf I attended. It was an awesome experience.
Debconf14 started with a Meet and Greet before the Welcome Talk. I got to meet people and find out what they do for Debian. I also got to meet other GSoC students that I had only previously interacted with online. During the Meet and Greet I also met one of my mentors for GSoC, Zack. Later in the conference I met another of my mentors, Piotr. Previously I only interacted with Zack and Piotr online.
On Monday we had the OpenPGP Keysigning. I got to meet people and exchange information so that we could later sign keys. Then on Tuesday I gave my talk about debmetrics as part of the larger GSoC talks.
During the conference I mostly attended talks. Then on Wednesday we had the daytrip. I went hiking at Multnomah Falls, had lunch at Rooster Rock State Park, and then went to Vista House.
Later in the conference, Zack and I did some work on debmetrics. We looked at the tests, which had some issues. I was able to fix most of the issues with the tests while I was there at Debconf. We also moved the debmetrics repository under the qa category of repositories. Previously it was a private repository.
Two of the main things I’ve been working on since I started at Xamarin are making it easier for people to try out the latest bleeding-edge Mono, and making it easier for people on older distributions to upgrade Mono without upgrading their entire OS.Public Jenkins packages
Every time anyone commits to Mono git master or MonoDevelop git master, our public Jenkins will try and turn those into packages, and add them to repositories. There’s a garbage collection policy – currently the 20 most recent builds are always kept, then the first build of the month for everything older than 20 builds.
Because we’re talking potentially broken packages here, I wrote a simple environment mangling script called mono-snapshot. When you install a Jenkins package, mono-snapshot will also be installed and configured. This allows you to have multiple Mono versions installed at once, for easy bug bisecting.directhex@marceline:~$ mono --version Mono JIT compiler version 3.6.0 (tarball Wed Aug 20 13:05:36 UTC 2014) directhex@marceline:~$ . mono-snapshot mono [mono-20140828234844]directhex@marceline:~$ mono --version Mono JIT compiler version 3.8.1 (tarball Fri Aug 29 07:11:20 UTC 2014)
The instructions for setting up the Jenkins packages are on the new Mono web site, specifically here. The packages are built on CentOS 7 x64, Debian 7 x64, and Debian 7 i386 – they should work on most newer distributions or derivatives.Stable release packages
This has taken a bit longer to get working. The aim is to offer packages in our Apt/Yum repositories for every Mono release, in a timely fashion, more or less around the same time as the Mac installers are released. Info for setting this up is, again, on the new website.
Like the Jenkins packages, they are designed as far as I am able to cleanly integrate with different versions of major popular distributions – though there are a few instances of ABI breakage in there which I have opted to fix using one evil method rather than another evil method.
Please note that these are still at “preview” or “beta” quality, and shouldn’t be considered usable in major production environments until I get a bit more user feedback. The RPM packages especially are super new, and I haven’t tested them exhaustively at this point – I’d welcome feedback.
I hope to remove the “testing!!!” warning labels from these packages soon, but that relies on user feedback to my xamarin.com account preferably (jo.shields@)