Software

Episode Number: 166

In this episode you will learn how the Drupal 7 Node Class module works with the basic page content type. The simplicity of the Node Class module provides an easy way for site builders and themers to add a CSS class directly to the wrapper on the node. Using this module allows for various different layouts and styles to be called based on defined CSS rules.

Tags: DrupalContent TypesDrupal 7Layout ToolsDrupal PlanetCSS

What's new with Drupal 8?

It has been a month since the last update on Drupal core development. In the meantime we met and worked hard together at TCDrupal and Drupalaton at the start of August triaging outstanding critical issues and resolving some. Also we collaborated on making Drupal's frontend better at Frontend United at the end of the month.

We've been doing such a great job taking care of the beta blocker issues that we are currently down to only one beta blocker as of this writing. What does this mean? Once we are down to no beta blockers left, a final alpha release is published. If there are no more beta blockers identified during a two-week window, the first beta release is published. Then we'll focus on resolving the hundred or so remaining critical issues to get to release candidates (once all of them are resolved).

Right now, help with the remaining beta blocker as well beta deadline and beta target issues is most welcome. Beta target issues may get in anytime later, but beta deadlines may not unless re-evaluated for inclusion regardless.

The best opportunity to get to work with Drupal developers in person is the 9 (nine) days of sprint opportunities coming up at the end of September at and around DrupalCon Amsterdam. It is the best way to learn Drupal 8 hands-on and help on the way.

Where's Drupal 8 at in terms of release?

Last week, we fixed 8 critical issues and 12 major issues, and opened 4 criticals and 7 majors. That puts us overall at 104 release-blocking critical issues and 644 major issues.

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem-space of one of these issues and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record, we could use your help!

• Issue #2330121: Replace ContentEntityDatabaseStorage::getSchema() with a new EntityTypeListenerInterface implemented by SqlContentEntityStorageSchema is part of our only remaining beta blocker, in which we factor out the SQL database creation from going through the ModuleHandler and instead introduce onEntityType(Create|Update|Delete)() methods to cover our use cases. The beta blocker is purposely broken to smaller issues to help reviewers. Look for more sub-issues under #1498720: Make the entity storage system handle changes in the entity and field schema definitions later on.
• Issue #2313159: [meta] Make multilingual views work is a collection of problems related to making multi-lingual views in Drupal 8. A number of the sub-issues are "Major", meaning they have significant repercussions but do not render the whole system unusable.

More ways to help

• Pick a critical issue or beta deadline issue, take the time to thoroughly read the issue (including doing some background reading if necessary to understand the problem space), and then update the issue summary for the issue. Include a summary of the current status and remaining tasks for the issue, and identify any API changes the issue would introduce. Consider whether the change would require a change record or updates to existing change records. Consider what the implications of not resolving the issue would be, or of resolving it after the first beta or after release.
• We also need help writing help text for core modules like Field UI, Image, Taxonomy and Toolbar. This is an easy way to learn the Drupal Core contribution process and start contributing to Drupal Core.

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

You can also help by sponsoring individual Drupal core development.

Notable Commits

Some of the best of git log --since "August 4, 2014" --pretty=oneline (277 commits in total):

• Issue 1510544 by swentel, Bojhan, Gábor Hojtsy, merlinofchaos, Cottser, Wim Leers, plopesc, aspilicious, sannejanssen, larowlan, tim.plunkett, nod_: Fixed Show previews in front-end theme, able to select different view modes. This was a long time coming. Finally, your node preview will not appear on the backend!
• Issue 2248767 by effulgentsia, beejeebus, alexpott: Use fast, local cache back-end (APCu, if available) for low-write caches (bootstrap, discovery, and config). Improves performance for some critical data a great deal.
• Issue 2224761 by Gábor Hojtsy, alexpott, pfrenssen, effulgentsia, xjm, mlncn: Add a generic way to add third party configuration on configuration entities and implement for field configuration. Resolved a beta blocker by adding a facility for configuration entities to support third party settings. To be used for node types and other things as needed as well. Provides a simple solution when a full-on plugin architecture as in views is not suitable, but extension mechanisms are needed for configuration.
• Issue 1966436 by naveenvalecha, cesarmiquel, Berdir, mr.york, jlbellido, segi, vasi1186, Leksat, Gábor Hojtsy, Schnitzel, grisendo, Aron Novak, likin, penyaskito, vijaycs85, kfritsche, fago: Fixed Default *content* entity languages are not set for entities created with the API. Now made Drupal properly create entities in the right language regardless of through the UI or API (eg. when adding a tag or uploading a file). Also makes entities created from the creation of the site be in the right language always.
• Issue 2295469 by Cottser, dawehner | effulgentsia: Add support for static permission definitions with *.permissions.yml. Makes it possible to simply define permissions in a simple YAML file making this system consistent with several other in Drupal 8.
• Issue 2271529 by attiks, alexpott, Lowell, YesCT, Jelle_S | mdrummond: Move breakpoint settings to theme and module *.breakpoints.yml files at root level. Improves developer experience providing breakpoints.
• Issue 2317085 by pfrenssen | rteijeiro: Added the possibility to create a REST export when creating a new view. Makes it much easier to create simple web service views of Drupal content.
• Issue 2250119 by ParisLiakos, Devin Carlson: Run updates in a full environment. Now that updates are not supposed to operate in API-incompatible environments, their implementation was unified with any other Drupal environment.

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 security

With the API stabilizing we are focusing on security again. In our last issue we already reported on Twig autoescape now being on, sometimes resulting in unwanted HTML strings appearing on the page because of double escape bugs. Please check the meta issue if you see these.

• The router service is now access aware so there is no need now to separately access check the routes returned from it.
• Building on this, now menu links, shortcuts and link fields use a unified path validator service..

Drupal 8 Around the Interwebs

• Drupal.com was relaunched and it runs of course on Drupal 8! Read more about it in Dries Buytaerts' post.
• Adam aka phenaproxima is working on modernizing and extending the Drupal Module Upgrader, so you can get automated help upgrading your Drupal 7 modules.
• There are several good practices you can adapt in your Drupal 7 projects preparing for Drupal 8. One of them is using PHPUnit tests in Drupal 7. Lee Rowlands has a great post about this.
• Tobias Stöckler is explaining a Composer based Drupal 8 workflow for integrating Drupal 8 with other PHP libraries seamlessly.
• In D8FTW: Your Next Drupal Hire Isn't a Drupal Hire Larry Garfield says you should look farther than Drupal developers for hiring and suggests some techniques to connect with the larger PHP community.
• Nuvole's Fabian Bircher posted a teaser to his Drupal 8 training showing a Git workflow for managing Drupal 8 configuration
• Four well known Drupal core contributors Jennifer Hodgdon, Bojhan Somers Alex Pott and Cathy Theys sat down with Brian Lewis to talk about sustainability of core development and the Drupal Core Gittip team.
• Jeffrey A. "jam" McGuire recorded and recently published a video podcast with Joël Pittet and Scott Reeves on Drupal 8's new Twig templating system.

Drupal 8 in "Real Life"

• September 5: First Friday D8 Contrib Sprint in Zurich, Switzerland as part of the regular series.
• September 6-7: Lviv Euro DrupalCamp in Lviv, Ukraine will have a sprint lead by top Drupal contributor andypost.
• September 12: Drupaldelphia in Philadelphia, USA includes sessions on Drupal 8 theming and Migrate.
• September 12-13: DrupalCamp Montreal in Montreal, Canada is full of great Drupal 8 content on theming, services as well as an introduction.
• September 19 - October 3: DrupalCon Amsterdam in Amsterdam, The Netherlands is going to be amazing with lots of opportunities to learn about and get involved with Drupal 8. It includes two hours of updates on propular contributed modules on Drupal 8 and nine days of sprints.

Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.0.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Read more about how you can volunteer to help with these posts!

Was working with a customer who required simple IP-based redirection for Drupal Sites.

Was analyzing the various existing options:

• Smart IP : Looks good. But sets sessions which break Varnish Caching. Most Drupal sites run from behind Varnish Reverse Proxy and using Smart IP would mean either forgoing varnish caching or having to add complex VCL rules.

• Geo-Redirect : Again, would not work well with Varnish. The first redirection will be cached on Varnish and all subsequent users from different countries might be redirected to the cached redirection. Requires additional GeoIP.dat file to be downloaded and this should be updated frequently.

• Using MaxMind API : Most hosts like Acquia allow the Maxmind API to be integrated on the balancers so that Varnish maintains country code in the cache (preventing the same redirection to be cached). The country code is added to the headers in both request and response. This is the ideal way to implement GeoIP for any enterprise site. But it requires dedicated load balancers, and there is no plug-and-play module to utilize the API requiring custom development.

• And a plethora of other modules that break varnish in similar ways..

What I wanted:

• Simple country-based redirection

• Should not break caching / varnish

• Should not require GeoIP datafiles to be downloaded and maintained

• Should be simple and light-weight

• Good-to-have, though not mandatory : Zero or Low subscription cost

A hour-long search resulted in nothing significantly useful for Drupal.

Finally found this API : http://www.telize.com/ . Sounded promising.

• The API powering the site is opensource

• There is no rate limit of any sort at the moment, and the service is free for everyone to use.

• Used GeoLite data created by MaxMind

The API was exciting but still it was not something that could be plug-n-play’ed on Drupal.

Built this module - https://www.drupal.org/project/telize

• Simple Country-based redirection

• Redirection happens at front-end through JS. Works on top of Varnish

• Does not set any session cookies. Won’t break your Varnish

• No subscription required

• No additional files/libraries required

Try it out of you have simple GeoIP redirection requirements.

 

Topic: Drupal

After spending the summer in Boston, I'm ready to fly across the world ... literally, as I'm leaving on a two week trip to China and Japan later this week. I'm very excited about it as I've never had the opportunity to see either of these countries.

I will arrive in Beijing on Saturday, September 6th, for the Young Global Leaders Annual Summit. A private path from where I'll be staying, Commune by the Great Wall, leads to a non-restored section of the epic Great Wall of China. Exploring this truly untouched piece of Chinese history still in its original landscape should be a special experience! Stay tuned for photos.

Following my time in Beijing, I'll transfer to Tianjin to attend Summer Davos. In addition to that, we're organizing a meetup with the local Drupal community - https://groups.drupal.org/node/434658. If you are in the area on September 10th, please stop by for a drink. I'd love to meet you and learn about the State of Drupal in China.

I'll end my two week trip in Tokyo, Japan. My time will be split between meeting the local Drupal community - https://groups.drupal.org/node/440198, understanding the adoption rate of Drupal in the Japanese market, and attending private meetings with digital agencies, Acquia partners and others to learn about the state of the web and digital in Japan.

Xièxiè and dōmo arigatō to those that have helped plan these events and gather the Drupal community for some fun evenings!

If you aren't able to make either Drupal meetup, feel free to leave your thoughts in the comments.

The world is full of Drupal news sources - Planet Drupal, Drupal Fire, Groups.Drupal.Org, and many many more.  So of course we've decided to build another one. 

Why?  Because we can. And because we've been spending a lot of time playing around with Rebelmouse.  So - aggregating content from all over the planet, we bring you Drop News

• Drupal
• Planet
• Planet Drupal

I am unabashedly an engineer. I obsess over the pursuit of finding the most efficient solution to any problem.

In the realm of open source software, this approach has served me well. We read, reverse-engineer, fork, improve, and share. I want my process to be faster, more flexible, and maintainable for the long haul.

As I’ve investigated different methodologies, one characteristic I constantly underestimate is the team dynamic. I tend to pigeon-hole my mind into thinking that the solution to a problem is the most important goal.

Hey look! There’s a problem! I must find a solution for it.

• What if complex problems can’t be solved by me?
• What if, when I suggest a tool or a programming philosophy, it masks the need to dive deeply into other factors?

The more I researched my approach, I came across a concept that is vital to team effectiveness when solving complex problems: emotional intelligence.

Emotional Intelligence, sometimes referred to as EQ (emotional intelligence quotient) to complement IQ (intelligence quotient), is the ability to be aware of, express, control, reason, and interpret emotions appropriately.

Within a team, many, many, many studies have shown that EQ, more than IQ, is the key to solving complex problems.

The team dynamic is engrained with the DNA of open-source projects. Any Drupal issue queue or Packagist library commit log supports that.

The better question I ask myself, however, is:

• Are the teams I work on the most emotionally intelligent?
• If not, what am I doing to improve that metric?

Peeling back this onion revealed the societal constructs that affected how I view an effective team.

Typically, I look to the most technical people I know for answers. In some cases, I follow the stereotypical engineer playbook of positing a hypothesis, demanding evidence, and playfully browbeating a decision.

Put another way, how many times have I jokingly used the phrase ” Are You  doing it wrong?” and is that the most effective solution?

As the research suggested, this emotionally oblivious approach was philosophically incongruent with proven science!

• How could I call myself an engineer?!?!
• How could I obsess about the pursuit of efficiency and solution, when my own attitude was blunting my team’s effectiveness?

I needed to do better.

I needed to find something, rooted in math and science, that helped me understand how to refactor my way of thinking.

I then learned about perspective and heuristic techniques. Perspective is how one looks at a problem. Heuristic is the mental shortcut one uses to arrive at a solution. Both are shaped by experience and knowledge, but the nuance in process from a variety of individuals is key.

Dr. Scott Page elaborates :

The diversity of an agent’s problem-solving approach, as embedded in her perspective-heuristic pair, relative to the other problem solvers is an important predictor of her value and may be more relevant than her ability to solve the problem on her own. Thus, even if we were to accept the claim that IQ tests, Scholastic Aptitude Test scores, and college grades predict individual problem-solving ability, they may not be as important in determining a person’s potential contribution as a problem solver as would be measures of how differently that person thinks.

It opened my eyes to how I’ve been going about solving complex problems all wrong.

In the context of a complicated problem, there is a higher likelihood of finding a global optimum (the best solution) when you have a diverse set of team members with local optimum (their best solution). Put simply, I needed to engage more (not less) with people who were different than me.

In essence, given the right conditions, diversity trumps ability!

What’s interesting about this research, however, is the fact that communication among members with different perspectives is very difficult.

In fact, as Dr. Page continues:

Problem solvers with nearly identical perspectives but diverse heuristics should communicate with one another easily. But problem solvers with diverse perspectives may have trouble understanding solutions identified by other agents.

Thus, we’ve come full circle to why EQ is so important.

If team members are not in-tune with each other, the benefits gained from their diversity can be lost. It is vital, therefore, in my unabashed obsession to being an engineer, that I not only need to improve my EQ, but surround myself with colleagues who have a high EQ and learn from them.

So what are the characteristics of high EQ individuals? Statistically, who has high EQ?

Some of our thought leaders here at Phase2 have answered that question.

If you’re interested in learning more, find me as I share my ideas on a building a more inclusive community at various conferences and camps!

By Michael Ross

This article was published in the print magazine Drupal Watchdog, Volume 4 Issue 1, 2014-05, on page 21, by Tag1 Publishing. The magazine was distributed at Drupalcon Austin, 2014-06-02.

Prior to Drupal 8, the core directories (includes, misc, modules, profiles, scripts, and themes) were located in the installation's root directory. Drupal 8 consolidates them into a new "core" subdirectory, which tidies up the root directory and should make it easier to track changes to core versus contrib or custom files. There are still three root subdirectories for modules, profiles, and themes, which can be used for custom and contrib projects. Each directory initially contains only a README.txt file explaining the repurposing and how developers can still use the pre-D8 "sites/all" scheme.

Figure 1. Drupal 8 root directories and files

Copyright © 2014 Michael J. Ross. All rights reserved.

By Michael Ross

This article was published in the print magazine Drupal Watchdog, Volume 4 Issue 1, 2014-05, on page 21, by Tag1 Publishing. The magazine was distributed at Drupalcon Austin, 2014-06-02.

When custom and contributed themes are added to a fresh Drupal installation, the core themes often fade into the background, even though they are valuable, particularly for learning theming. In Drupal 7, those core themes are: Bartik (enabled by default), Garland (Drupal 6's default), Seven (optimized for site administration), and Stark (minimalist and thus useful for module output debugging). The sole template engine is the venerable PHPTemplate. Drupal 8 adds Twig as the canonical template engine. Garland is gone, while Bartik, Seven, and Stark have been HTML5-ified and Twig-ified.

Figure 1. Drupal 8 core themes

Copyright © 2014 Michael J. Ross. All rights reserved.

By Michael Ross

This article was published in the print magazine Drupal Watchdog, Volume 4 Issue 1, 2014-05, on page 20, by Tag1 Publishing. The magazine was distributed at Drupalcon Austin, 2014-06-02.

Compared to its predecessor, Drupal 8 offers website builders far more capabilities without the use of contributed modules, because it incorporates many of the most popular ones into core (e.g., Actions, CKEditor, Configuration Manager, Entity, and Views), as well as useful field types (e.g., Datetime, E-mail, Entity reference, Link, Options, and Telephone). Conversely, less popular core modules (e.g., Dashboard, OpenID, Overlay, PHP, and Poll) have been dropped. These improvements greatly increase the range of websites that can be built with vanilla Drupal, and reduce the time spent downloading commonly-used modules and scrolling past rarely-used ones.

Figure 1. Drupal 8 core modules sample

Copyright © 2014 Michael J. Ross. All rights reserved.

By Michael Ross

This article was published in the print magazine Drupal Watchdog, Volume 4 Issue 1, 2014-05, on page 20, by Tag1 Publishing. The magazine was distributed at Drupalcon Austin, 2014-06-02.

In Drupal 7, site administrators can utilize its core Toolbar module for speeding navigation. Drupal 8's equivalent improves upon it, sporting a more readable interface, with clear icons. Admin menu items are grouped into: "Manage" (encompassing the menu items of its predecessor, with "Modules" renamed to "Extend"), "Shortcuts", and a user menu for profile management and logging out. The toolbar is responsive to the device's screen width, switching to a vertical orientation for narrow displays — which can be forced by clicking the arrow button on the far right of the toolbar's (white) second level.

Figure 1. Drupal 8 admin toolbar vertical

Copyright © 2014 Michael J. Ross. All rights reserved.

Drupal users who want to build or customize displays or layouts, or simply build their own administrative areas will love Views from the Ground Up and now is your chance to attend this training at DrupalCon Amsterdam!

Views from the Ground Up consists of 8 real world (and useful) views that are created with an increasing level of complexity. By the end of this class, students will be able to take almost any views display currently being used in Drupal, and override it, to fit better to their particular admin style and needs.

Meet the Trainer from the NorthCross Group

Chris Porter (netw3rker) has spoken at DrupalCon Barcelona, Munich, and San Francisco and has provided this training for the past four years to a variety of global clients, including Fortune 500 companies.

Attend this Drupal Training

This training will be held on Monday, 29 September from 09:00-17:00 at the Amsterdam RAI during DrupalCon Amsterdam. The cost of attending this training is €400 and includes training materials, meals and coffee breaks. A DrupalCon ticket is not required to register to attend this event.

Our training courses are designed to be small enough to provide attendees plenty of one-on-one time with the instructor, but large enough that they are a good use of the instructor's time. Each training course must meet its minimum sign-up number by 5 September in order for the course to take place. You can help to ensure your training course takes place by registering before this date and reminding friends and colleagues to attend.

Register today

Published: Wed, 09/03/14Download this episodeProject

It’s easier than you think to publish your module on Drupal.org. This is my experience going through the entire process. Sharing this experience I hope to convince you and others to do the same. Contributing back to the community that gives all of us so much, to many of us our livelihood.

• When Doug first recommended that I talk to you about this, I wasn’t really thrilled. But, I took a look at your slides, and thought that it actually looked like really good information. So, what made you decide to put together a presentation on the project application process in the first place?
  My “Why”
  Finally published a module to help solve my own problem
  My project that took me through this process is Display Suite Extra Layouts
  https://www.drupal.org/project/ds_extra_layouts
  Projects don’t have to be the 100% perfect solve for everyone, everywhere
  It’s more about: Giving back, centralizing code, helping others make great projects too.

• So what are the steps to getting a project reviewed and accepted?
  Where to start and basically the entire guide to submitting a module
  “Apply for permissions to create full projects” https://www.drupal.org/node/1011698
  Some things to know
  One time process
  Reviews are primarily by your peers
  Learns/reiterates code standards and best practices
  Do your Research First
  Check if your idea exists already
  Combine efforts where you can
  Volunteer as a co-maintainer where needed

• Okay, let’s get down to the nitty-gritty. What are the technical steps you need to follow to get your project approved?
  Setup Git Access
  Learn some Git basics
  Google is your friend
  Github & Code School’s tutorial http://try.github.io
  Setup your Git Access in your D.o profile
  Basically just need to add an SSH key
  Instructions here: https://www.drupal.org/node/1047190
  Sandboxes
  With Git access setup you can now create sandboxes or “experimental” projects
  Instructions here: https://www.drupal.org/node/1011196
  Take advantage of these, having a commit history of changes is a good thing.
  Use sandboxes to get your code “production ready”
  The Checklist (Pre-Application)
  Before starting the application make sure you run through the checklist
  Setup Readme, Git Branches, well commented, etc...
  Link to checklist: https://www.drupal.org/node/1587704
  The process goes much much faster, many people skip it
  PA Review Bonus
  Part of the checklist asks you to run your sandbox through a bot.
  Catches the majority of problems.
  You can setup your own Review Bot
  https://www.drupal.org/project/pareviewsh
  http://pareview.sh/
  “Full Stop” - Took me a while to figure that out.
  You get a review bonus when everything is fixed.
  The Application
  https://www.drupal.org/project/issues/projectapplications
  READ THE DIRECTIONS!
  In the title include core version: [D7]
  Write a Clear Descriptions… can be the same as your project/sandbox page
  Clear descriptions help people understand better the purpose of your project
  Provide links to your Sandbox, the Git clone command, and PA Review
  When you are ready set the status to “Needs Review”

• I noticed when I looked through your slides that you mentioned reviewing other projects as a part of this. Why is that needed?
  Reviewing other projects
  You must review at least 3 other people’s projects
  Post a link to your reviews in your own project application
  It’s just like trying a new module.
  Download it, enable it, try it
  Report back your findings… good, bad, and suggestions
  I learned a lot from doing this
  Now you wait.
  Others will review your project and post feedback.
  be prompt to fix issues
  Once all is well someone should mark your project “Reviewed and Tested by the Community”
  Then you wait for someone with the “Power” to grant you full project status

• Once someone has approved your project, what’s involved with getting the official project page setup?
  Into the Wild!
  You can now create your project page
  be mindful of your project URL, you can’t change it
  Create a new release on your project page and in Git
  Creating a release: https://www.drupal.org/node/1068944
  Tag Nameing Convention: https://www.drupal.org/node/1015226
  FIN.

Questions from Twitter

• timani.co.zw
  Will this cover D.O vs github for projects? Pros & cons of staying with current design vs migrating to github?
• Joshua Turton

MUP117 When are we going to see movement on the project application issue queue?

• Joshua Turton

MUP117 process seems broken - have to apply... but once past "quality control" you can release any junk u want.

• Joshua Turton

MUP117 Also: encouraged to review others to boost your app's priority, but why would we trust reviews from users who haven't passed through process? (speaking of high priority list/review bonuses) Episode Links: Jeremy on drupal.orgJeremy on TwitterJeremy on Google PlusDrupalCamp Utah Session PageSession SlidesCreating a SandboxApplication ChecklistPareview.shProject ApplicationTags: drupal.orgProjectsplanet-drupal

What do you get when you combine a state-of-the-art open source content management system with a seemingly endless need for developers, an instructor passionate about developing Drupal talent with solid fundamentals and best practices (yours truly), six eager, geographically diverse students (pictured above - more on them in future blog posts), and a modern online classroom environment (the topic of this post)? If the content management system is Drupal, then the only answer is the online version of the Drupal Career Starter Program: Drupal Career Online.

This week marks the start of the first session of Drupal Career Online, an immersive 12-week online training program designed to take people passionate about technology and turn them into Drupal professionals. The curriculum is the result of continuous development and improvement over the past three years, and now features a dedicated web site, PDF handouts and reference documents for every lesson, weekly self-assessment quizzes, screencasts covering important concepts and a healthy dose of Drupal community involvement.

-->

read more

How many hours for multithreading the server? Or: dealing with overly detailed project planning Many developers, me included, dread that moment. Someone sits down with you and wants to know how many “hours” each step of the project will take. And of course the thing is, if you are doing something that has been done many times before, you might be able to provide a detailed estimate. People that build houses work like this, but they still often get it wrong.

Feature

Drupal has long had a strong collaborative culture. We share modules, we share development tasks on core and modules, and we share infrastructure on Drupal.org. That's a critical part of the health of our community: Sharing is how Open Source works.

The broader PHP world, however, has long sucked at sharing. Every project is its own island; sharing code between projects has been difficult, and managing third party libraries a pain. Just about the only option was PEAR, but unless you had root access on every server you needed, and were running only a single application per server, it wasn't really useful.

That was then, this is now. Enter Composer, a PHP dependency management tool that works. Composer began life in late 2011 in the Symfony community but was deliberately built to be project-agnostic, and today is being used by thousands of projects large and small, including Drupal.

Composer Basics

Composer consists of two parts. One is Packagist.org, which is a central clearinghouse of Composer-compatible packages. As of July 2013, Packagist offers over 13,000 packages, ranging from simple libraries to complete frameworks. The other part is Composer itself, a command line PHP application that is dead simple to install. By default, Composer will download packages from Packagist.org but you can also set up your own package server, or even just one-off Git repositories, to host Composer-capable code. All you need to make it work is a simple JSON file.

Let's start off with a trivial example. We’ll write a super-simple script that uses the Guzzle HTTP client (now bundled with Drupal 8). To start off, create your project folder. Inside it, create a directory called src. That's where we'll put all of our code. Now create a file called composer.json with the following contents:

Over the last eight months, I have been a developer at Appnovation.  During my time here, I have learned plenty new things and worked on a lot of different projects.

var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});

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)

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.

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.

Make sure you use the latest development version (20th August) rather than the stable release: it fixes a bug that meant the right extensions weren’t being found.

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

In order to use Sass , make sure you have Ruby installed. If you're on a Mac, it should already be there, although you might want to try installing RVM (Ruby Version Manager) .

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 can be easier to make those grids if you use Susy and Breakpoint , two Sass extensions that'll do the grunt work for you. Then it’s on to the styling!

Sass

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

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.