When disaster strikes, strike it back
I knew the moment my laptop didn't wake from sleep mode something was amiss. Having retired to my office safe haven for the evening I just wanted to wrap up a few items, log my time and call it a night - the basic end to any Drupal developer's day. My Macbook, however, had other plans.
It was the quintessential nightmare for those of use who live on our computers, a dream we often visualize as worse-case situations but often do nothing to lessen the pain of actualities: a complete computer crash with limited hope of a reboot. But despite the Macabre vibe usually surrounding such thoughts, it's something that doesn't always have to be the ultimate disaster.
The State of Drupal 7 Contrib
While this article focuses primarily on the state of Drupal “contrib” (modules and themes which are not part of the “core” Drupal download), it also takes a look at the greater “State of Drupal” in terms of sites known to be running on some version of Drupal, comparisons of the rate of uptake after Drupal 6 and Drupal 7 release, and a small case study involving attempting to perform a “major upgrade” from Drupal 6 to Drupal 7 on a site using a significant number of contributed modules.
The recent history of Drupal core usage
As a starting point, I think it is helpful to look at the recent history of Drupal core usage and compare the uptake of Drupal 6, after its release, with the uptake of Drupal 7. On June 22nd, 2008, when Drupal 6.0 was released, there were already significantly more sites using Drupal 6 than Drupal 5 (almost 32,000 on Drupal 6 vs almost 17,000 on Drupal 5). Both core versions of Drupal steadily gained users for a time, with Drupal 5 reaching a peak of about 24,000 sites about 7 months later, but by that time Drupal 6 was running on more than 100,000 sites. By late July 2009 (a similar point to now in terms of months after the major version release), Drupal 5 usage had dropped to about 20,000 sites and Drupal 6 was running on more than 160,000 sites; more than eight times as many installations. Since then, Drupal 5 usage has tapered to about 7,000 sites; a bit more than 1% of total Drupal usage (please note: it’s likely that many of the existing Drupal 5 sites do not report usage back to Drupal.org).
Now let’s look at the usage of Drupal 6 and Drupal 7 since the time of Drupal 7’s release. Drupal 6 peaked with about 355,000 sites, shortly after Drupal 7’s release in January 2011. At that time Drupal 7 was running on about 24,000 sites, a fraction of Drupal 6 usage at that time. Since then, while sites running on Drupal 7 have steadily increased to their present values, about 280,000 sites, Drupal 6 has hovered around the same value, drifting between about 320,000 and 350,000 sites, but not yet significantly dropping. Almost 13 months after Drupal 7’s official release, we still have more sites running Drupal 6 than Drupal 7 (and I suspect that a significant percentage of the Drupal 7 sites are in development rather than production). But what does this really say? Let’s look a bit closer at the numbers and trends:
Note: I banged this graph out in Excel since the Google chart of Drupal usage, normally displayed on project pages, seems to fail as “too large to process” for “core” usage statistics.
Drupal usage has grown by leaps and bounds since Drupal 6’s release. In June 2008, there were fewer than 50,000 sites using Drupal 5 and 6 combined. Now, a bit more than three-and-a-half years later, there are more than 615,000 sites running on some version of Drupal — more than a 12-fold increase in that time period! A year ago, this figure was less than 400,000, so Drupal 7 sites make up a large proportion of the more-than-200,000 Drupal sites added since then. The growth was steeper after Drupal 6’s release, but we still did not have 200,000 sites, total, by July 2009. In any case, it’s safe to say that for most use cases, we have the modules necessary to build a good site based on Drupal 7, so if you are hesitant to use it, don’t be. There are many great advantages to Drupal 7 and with the continual improvement of the contributed modules, we should probably build new sites on Drupal 6, only if modules critical to the use case are lacking for Drupal 7 (or if the “new” site is another site in an existing Drupal 6 “multi-sites” installation). Even if a “critical” module exists for Drupal 6 and not yet for Drupal 7, it may still be worth building the site on Drupal 7 if you have the coding experience to port the Drupal 6 module to Drupal 7, which would help alleviate the current issue that many significant modules are not yet available for Drupal 7.
State of Drupal 7 contrib (modules)Good news: Almost all “Top 100” Drupal 6 Modules are ported to Drupal 7
The good news, especially for site builders creating a new Drupal 7 site, is that most of the top 100 modules are ready for use on Drupal 7. Nine of them are redundant (now included in “core”), 43 have “stable” releases, 23 have beta or RC, 11 have an alpha release, and 9 are in “dev” status, while a couple others recommend using another module which performs similarly.
Drupal Media Initiative - Media Support Squad Formed
SSL certificates switched to Namecheap
Creating your own entities with Entity API
There have been plenty of articles about Drupal 7 and entities already. Entities are great. They provide a unified way to work with different data units in Drupal. Drupal 7 is all about entities. They are everywhere: nodes, users, taxonomy terms, vocabularies...
Let's take a closer look at how developers can create their own entities using the Entity API module, which is a great toolbox.
Drupal Association Elections
I'm running for election as an "At Large" board member of the Drupal Association.
"Meet the candidates" forums were scheduled so members of the Drupal community could ask questions of the nominees. We were all asked to do a brief introduction, then respond to questions either by voice, or by IRC, and then were all asked to make a final statement.
Rather than adding to the already lengthy wiki summary of the candidate meetings, I'm posting the edited version of my responses here instead. See the full IRC transcript, and others summaries here:
http://groups.drupal.org/node/207398
My formal candidate statement is here:
https://association.drupal.org/node/14388
Further information on the election, as well as details on voter eligibility, and how to vote is here:
https://association.drupal.org/2012-elections-voting
General Intro
I'm in Melbourne, Australia. Run my own small business, called creative contingencies. Been using Drupal for about 5 years. I'm really passionate about open source and the fact it enables people to do things they would not otherwise be able to do.
In terms of Drupal and the Drupal association, I'd like to be a voice for the 'small voices'. Small drupal shops, amateurs, hobbyists, non-profits, students and tinkers. Sometimes we get caught up in the commercial opportunities, and forget that Drupal has been an enabler for many people that aren't using it to make a living.
It's important the Drupal Association develops a more global perspective, and that we work together to invite and embrace more people into the Drupal community.
I just helped run Drupal Downunder in Melbourne a couple of weeks back, it was a great success, and like many other camps around the world was driven by the local community to fulfil a need that can't be filled by DrupalCon, because DrupalCon happens on the other side of the world. The DA has already expressed an interest in seeing DrupalCon South America and DrupalCon Asia Pacific - which is fantastic, but I have concerns.
Response to Questions
Harley (Hyperglide)
Regarding emerging markets in asia. Wants to know if any of the candidates have an idea on how to handle outreach to those markets to solve the talent shortage?
Emerging markets are really important for Drupal's growth. There's a pretty critical Drupal skills shortage. Everyone is hitting that. China and India are both huge countries with lots of developers - finding a way to encourage them to participate in the community could help with the global skills shortage. But we also have to acknowledge the economic reality that participating in an open source project as a volunteer doesn't pay the bills. We need to connect with other open source communities in the region, and encourage and support local groups to create and grow their own events, meetups, mentoring, and community learning programs.
The DA can help with some of that, but we're also going to run into some issues. We're going to have address the tension between commercial interests in training and certification with the broad based need for more people to learn Drupal.
tsvenson: What do you see as the biggest obstacles for new Drupal users, especially non coders with small or no budgets, often leading to them quickly going elsewhere? And what will you do to change that?
We need to tackle the issues identified by the documentation team. They are the front line for new users. Our online help and support is where new users and new developers go to learn. Infrastructure bottle necks are a real issue holding us back. That is definitely something the DA should address. Even better, it's on the roadmap for 2012 - which is great. I'd support and champion that element of the 2012 roadmap.
We also need to find how to support documentation translations, and better multi-lingual support, on drupal.org
webchick: For those who want to promote international diversity, explain how a position on the DA helps you do that more effectively.
Actually, this is the core of my platform. International diversity has been identified as a key goal for the DA. Yet the makeup of the current board is largely homogenous. With one exception, all 8 of the current board members lives in North America. One is in Europe.
No doubt these people have an international perspective, but it's one thing to think about, it's another thing to live it. The heated discussion about the need to travel was educational to say the least.
As an example, the 2nd candidates meeting was scheduled at 4am Melb/Sydney time. We weren't expected to be there, but I wondered how failing to show up would hurt our candidacy? I decided to bite the bullet, get up early to be on the call.
If elected, I'll be noisy, opinionated and irritating. I'll reach out to communities in Oceania, Asia and Africa, and encourage them to engage in the community, participate on groups.drupal.org, share their experiences of running local camps, and national associations - as I've started to try and do so with a BoF at London DrupalCon, and International Drupal Associations on G.D.O
Crell: Currently Drupal's face in the world is a mix of face-less Drupal.org and Acquia. Acquia is the face of Drupal, rightly or wrongly, in many eyes, moreso with the new Office of the CTO. Drupal of course is far far more than Acquia. What if anything do you feel the DA can or should do to counter-balance that, or is that even an appropriate role for the DA?
I think the DA needs to look at the apache and gnome foundations. Acquia is incredibly important and powerful - but as far as the DA concerned - Acquia should just be one of many ddrupal companies. The DA needs to focus on the community and the infrastructure the community needs to make drupal better.
tsvenson: We just had a live usability test that showed we have still very much to do. How do you propose we can put more efforts into making Drupal, including contib projects, more user friendly and intuitive?
Continue to improve the infrastrucuture... and invest in the tools we use... eg D.O Conduct further public live streamed usability sessions just like that. Very useful. But the next step is spreading knowledge of what to do with that information amongst the developer community, and ignite their passion to focus on usability challenges.
Slurpee: How many candidates have been to Drupal events outside of their own continent? And can you speak more than 1 language fluently?
I have been to drupalcon sanfrancisco and london - I can't speak another language fluently... but I speak a little bit of Dutch.
Crell: Several of you listed things yo want to do or accomplish. The DA, however, has shifted from a staff board to a policy board, so board members are not directly doing anything, but managing, strategizing, coordinating, etc. Those of you who want to "do", isn't the board the wrong place for what you're describing?
This is exactly why I want to get involved and be a voice for under represented parts of the Drupal community because all too often the policy gets driven without those things being considered.
If you're not loud and you don't put your voice in when the policies being formed, it's much harder to move in that direction afterwards.
rfay: In 30 seconds or less, what are the roles of the DA and what are not the roles?
The DA can amplify the work of local communities and also support and give credibility to them!
The DA has no involvement in driving the Drupal project itself. It is primarily and administrative entity to manage the affairs of a series of large international conferences. Potentially taking over some of the legal intellectual property issues around the trademark which belongs to Dries Buytaert, and employing staff to help ensure DrupalCons happen, and the hardware and Drupal infrastructure keeps working.
Crell: Several candidates said they want to better represent or be a voice for "small shops" and independents. In what way does the DA currently not adequately serve small shops, and what would a better service for small players mean in practice? Be as specific as possible.
I don't know that the DA is failing small shops, I just don't see those voices represented in the current makeup of the board. most are from NA and large organizations so it's not necessarily that there's a huge gap, but there is potentially a huge gap. I have a sense that this is a problem more than specific criticisms.
But we're not just talking about small drupal shops... but people using Drupal who don't have a commercial interest in it... Hobbyists, non-profits staffed by volunteers, clubs and amateurs, and community groups. Tinkerers and students. Many of our contributors have come from this kind of background, it's a valuable proving ground for future Drupal talent.
tsvenson: When do you think the first Asian DrupalCon should be held? Also, should that mean 3 cons/year or should they alternate with 2/year?
DrupalCon Asia?
I was concerned about the idea of "drupalcon asia pacific" somehow being "the rest of the world" except Africa. The AsiaPacific region contains 3 of the 5 most populous nations on earth: India, China and Indonesia. They are all incredibly culturally and linguistically diverse. Trying to create a single event for both continents (ASIA and OCEANIA) is going to be an enormous challenge.
DrupalCon Mumbai, DrupalCon Shanghai, DrupalCon Bali, DrupalCon Manila, DrupalCon Wellington might all happen one day. When? Yes, well that's a very good question. This year? unlikely. Next year? Maybe. And then 2 years after that.
A DrupalCon in our region is going to happen pretty infrequently, I'm more interested in local communities building their own capacity to serve their needs with local events, than sit around waiting for the blessing of the Drupal Association.
Perhaps the US Drupal community should adopt the North American DrupalCon as it's National event? And the Drupal Association should shift it's focus toward developing one International UberDrupalCongress which is on a different continent each year, more like the olympics, and focus all of its attention on that. I don't know. I just think we should question all our assumptions.
jredding: In 30 seconds or less, what would you say is the most important skillset, expertise, or experience that a board member should bring to the Association.
One of the most important things is to bring a sense of collaboration and wilingness to work with the rest of the board on important topics. To try to reach consensus, and ensure we all bring our slightly different perspectives to the table when we're making decisions. People often think consensus is all happy families but you only get there considering many differnt perspectives and figuring out what you can agree on, rather than focussing on what you can't agree on.
carsonblack: Q: What are some (or one) way that DA can help the small user groups throughout the world better serve their local markets?
Perhaps put together an info pack? How to build and grow your local community. How to engage with local businesses, authorities and educational institutions. Often what's holding people back, is just knowing where to begin.
jredding:
When the DA board member is out n the community how would that member represent themselvs in the community? Would they have a title of board member and use that?
I don't know. I think it's an interesting question and would be keen to explore ideas on how best to do this.
Crell: The DA is officially banned from "directing the development of Drupal". What does that mean to you? Are there ways the DA could "support" development without "directing" development? What would you want to do in that regard? Again, be specific as possible.
I like the idea of funding sprints... not directing what happens at them, but helping them happen. Putting effort into the tools the project relies on is borderline... but it's something that needs doing....
tsvenson: Question: Should the DA take a more proactive role about the d.o infrastructure and its improvement needs. Especially in regards to for example content management tools for doumentation and giving better cred/visibility to all those that puts in amazing work that is not project/code related? If so how and what is needed?
Yes! We expend effort and resources on ensuring DrupalCon happens, and that the servers keep running. We should be expending effort on the real heart of the community, drupal.org and groups.drupal.org.
We urgently need to address bottle necks frustrating key community initiatives, such as documentation, support, prairie, some of these have lost momentum because of infrastructure bottlenecks, and the fact we can no longer really innovate on D.O.
Final Statement
I'd like to finish off by saying Drupal is awesome. The community is what makes that true.
I am desperate to give back to this project and this commnuity in the best way I can
I'm not a coder, designer, documenter, but I am good at being committees, organising events. Following through.
I will put in all my energy and efforts to be a useful productive, engaged member of the board.
It's the first time the DA has run broad based elections like this. It is the beginning of a new chapter in terms of how org is structured. There's a a lot of work to do in the future around consolidating the work that's been done and becoming a more open/transparent organization. I'd love to be part of seeing that happen and working for the community by being on the board.
I'd like to add, my fellow nominees are all awesome. Even if not elected, the DA should find a way to co-opt them onto other committees. They've all indicated a willingness to serve - let's harness their commitment, competence and energy.
2012 elections: Voting open for Drupal Association at large directors
Voting is now open for the 2012 election of at large directors of the Drupal Association. Two directors will be elected from among the ten candidates.
About the Drupal Association electionsWhen we designed a new governance structure for the Drupal Association last year, we decided that most of the board is selected through a nominating committee with the goal to carefully balance many factors like needed skills and geographical and sector representation. However, it was also deemed important that we have directors chosen directly by the Drupal community to make sure that the community is always well-represented.
We're holding our first open community elections! Two community "at large" directors will be elected to the Drupal Association Board of Directors, and YOU can get to say who they are!
Where to find out about candidates- Review their nomination profiles.
Updating Drupal Core on Pantheon
With a new Drupal Core release out, it's worth reminding people just how easy it is to pull an update if you're using Pantheon:
One click and you're done! This is the beauty of starting a project off the canonical git history.
Also, of note - updating the stone-age way (unpacking a tarball from Drupal.org and overwriting all your core files) won't give good results. This will stop on the PRESSFLOW_SETTINGS auto-configuration system we use to connect to databases and other external services. Take the path of least resistance: it's also the best practice!
CxO Day on March 19
This one-day event is for business leaders of Drupal businesses (CEO, Partner, President, CMO, etc.) and it provides networking, business training and collaborative problem solving for common business challenges that Drupal-related companies face. There will be sessions on how to retain staff and build teams, plus a half-day moderated forum. The event fee is $150 and will conclude with a cocktail mixer. Register now, limited seats are available.
Following up on New Year's Resolutions at Phase2
Per style private files
Private files are great but they are a huge resource hog. In certain scenarios, lower-resolution versions of the pictures are absolutely fine to be public, only high resolution originals need to be protected. In this case you can use Drupal's private file handling as it is and the following simple trick to make a style public.
Mobile Initiative: Minimal Viable Product
The Drupal 8 Mobile initiative’s goal aims to make Drupal the leading mobile CMS platform. Certainly, there are some fantastic contributed modules that already make Drupal a great starting point for mobile solutions; modules like Mobile Tools, Domain Access, Responsive Images, as well as a whole slew of new ones that have been released in the past few months. But in order for a CMS to earn the moniker "mobile-friendly", setting it all up needs to be easy.
Right now, Web development experts are building mobile apps and websites while looking for integration with existing CMSs. And they are having to build a lot of the tools themselves because there are very few mature tools. The Web development industry as a whole is still trying to figure out the best way to build mobile sites and Drupal needs to engage and become a leader as that work continues.
There are currently at least five different ways to provide mobile solutions:
- Native apps (code compiled to run natively on iPhones, Androids, etc.)
- Web apps (HTML5 and JavaScript-based apps running on mobile browsers)
- Mobile/desktop domain switching (parallel websites: one for desktop and one for mobile, with device detection to switch between the two.)
- Responsive design (a single HTML source that uses CSS3 media queries to respond to different device capabilities)
- RESS: Responsive Design + Server-side Components (a hybrid approach that uses Responsive Design techniques combined with a light amount of device detection to alter the markup before being sent to the user.)
Drupal, whether in core or contrib, should support all of them.
Now that’s a pretty broad spectrum of things to cover and they can’t all be included in core. But, to reach that “mobile-friendly CMS” status, what are the top issues Drupal 8 core should provide?
- Web services for native app integration
- HTML5 elements necessary for HTML5 Web apps
- Ability to use Drupal’s administrative forms in mobile devices
- All of Drupal 8’s core themes should be responsive
- Front-end performance improvements
Fortunately, the first two points are already covered by the Web Services and Context Core Initiative and the HTML5 Initiative.
That just leaves the last three items for the Drupal 8 Mobile Initiative to focus on.
Objectives
Responsive Web design
Responsive design is the hottest technique in producing mobile friendly websites because, relative to traditional mobile building techniques, it lowers the development cost for including mobile device support. Websites that only support large screens will become an anachronism, so converting all of core’s current themes to have mobile-first responsive designs is essential for Drupal to remain relevant. (Incidentally, the Drupal 8 Design Initiative, which is focusing on building new themes for Drupal 8, will also ensure its themes are responsive.)
Mobile-friendly forms
If users can’t create content or administer a Drupal site while on a mobile device, we have a serious problem. Those are the first tasks attempted by users on new Drupal websites. Much as the “ugly themes in Drupal 6” made a bad first impression of Drupal to Web designers, not providing mobile administrative solutions will leave a sour taste in the mouths of mobile developers evaluating CMS solutions. To complete this task, we’ll have to look at the complete stack for administrative tasks, including form definitions, form submit handlers, the Toolbar, the Overlay, and the Seven theme.
The target is 100% mobile-friendly administration via responsive design, but we recognize that certain pages, e.g., the permissions page, may require a dedicated mobile presentation.
Front-end performance
Lastly, performance has always been a priority for websites, but with mobile it becomes critical. Some studies show up to 97% of a page’s render time takes place in the front-end. There are a laundry list of best practices for front-end performance that will help mobile and desktop users. And I’ve seen several members of the Drupal community speak about these issues multiple times this past year.
However, when dealing with responsive design, the single biggest performance concern is image handling. The first demo of responsive design had over-large images being sent to mobile devices. While no single best solution has yet been found, we intend to leverage Drupal 7’s image styles to solve this issue.
Program tasks
Program tasks are defined in the following way:
- Must have (essential to success)
- Should have (significant impact to success)
- Could have (should be done, but are not essential)
- Won’t have (future functionality)
-
Must have / Critical
Responsive Web design
- Seven converted: http://drupal.org/node/1088792
- Stark converted: http://drupal.org/node/1322794
- Bartik converted: http://drupal.org/node/1192044
Mobile-friendly administration
- For all content editing and workflow related pages (adding users, taxonomy terms, menu items, new content, moderating content, etc.)
- Review of the Toolbar
- Review of the Overlay
Front-end performance
- Responsive images: As the layout is resized, the browser will serve the proper image size (“real” size, not height/width attributes) See Responsive image discussion for current status.
- Optimized images
- Sprites used wherever appropriate
- Optimized css: Evaluate the css aggregation process and adjust where improvements can be made.
One of the first issues that needs tackling is determining a dependencies list so the critical tasks can be done as quickly as possible. For example, all mobile-friendly admin tasks are dependent on Seven being responsive.
-
Should have / Major
Front end performance
- Documentation of the use cases that css aggregation serves.
- Documentation for how to optimize for other use cases.
- Documentation for how to make contributed projects mobile friendly. http://drupal.org/node/1341310
Mobile-friendly administration
Configuration pages converted (creating a new content type; adding fields to a user profile, etc.)
Front-end performance
- Document the use cases that css aggregation serves.
- Document how to optimize for other use cases.
- Document how to make contributed projects mobile friendly.
-
Could have / Normal & Minor
TBD
-
Won’t have
- Any impact on Drupal.org; See http://drupal.org/node/951114
Mobile Initiative: Minimal Viable Product
The Drupal 8 Mobile initiative’s goal aims to make Drupal the leading mobile CMS platform. Certainly, there are some fantastic contributed modules that already make Drupal a great starting point for mobile solutions; modules like Mobile Tools, Domain Access, Responsive Images, as well as a whole slew of new ones that have been released in the past few months. But in order for a CMS to earn the moniker "mobile-friendly", setting it all up needs to be easy.
Right now, Web development experts are building mobile apps and websites while looking for integration with existing CMSs. And they are having to build a lot of the tools themselves because there are very few mature tools. The Web development industry as a whole is still trying to figure out the best way to build mobile sites and Drupal needs to engage and become a leader as that work continues.
There are currently at least five different ways to provide mobile solutions:
- Native apps (code compiled to run natively on iPhones, Androids, etc.)
- Web apps (HTML5 and JavaScript-based apps running on mobile browsers)
- Mobile/desktop domain switching (parallel websites: one for desktop and one for mobile, with device detection to switch between the two.)
- Responsive design (a single HTML source that uses CSS3 media queries to respond to different device capabilities)
- RESS: Responsive Design + Server-side Components (a hybrid approach that uses Responsive Design techniques combined with a light amount of device detection to alter the markup before being sent to the user.)
Drupal, whether in core or contrib, should support all of them.
Now that’s a pretty broad spectrum of things to cover and they can’t all be included in core. But, to reach that “mobile-friendly CMS” status, what are the top issues Drupal 8 core should provide?
- Web services for native app integration
- HTML5 elements necessary for HTML5 Web apps
- Ability to use Drupal’s administrative forms in mobile devices
- All of Drupal 8’s core themes should be responsive
- Front-end performance improvements
Fortunately, the first two points are already covered by the Web Services and Context Core Initiative and the HTML5 Initiative.
That just leaves the last three items for the Drupal 8 Mobile Initiative to focus on.
Objectives
Responsive Web design
Responsive design is the hottest technique in producing mobile friendly websites because, relative to traditional mobile building techniques, it lowers the development cost for including mobile device support. Websites that only support large screens will become an anachronism, so converting all of core’s current themes to have mobile-first responsive designs is essential for Drupal to remain relevant. (Incidentally, the Drupal 8 Design Initiative, which is focusing on building new themes for Drupal 8, will also ensure its themes are responsive.)
Mobile-friendly forms
If users can’t create content or administer a Drupal site while on a mobile device, we have a serious problem. Those are the first tasks attempted by users on new Drupal websites. Much as the “ugly themes in Drupal 6” made a bad first impression of Drupal to Web designers, not providing mobile administrative solutions will leave a sour taste in the mouths of mobile developers evaluating CMS solutions. To complete this task, we’ll have to look at the complete stack for administrative tasks, including form definitions, form submit handlers, the Toolbar, the Overlay, and the Seven theme.
The target is 100% mobile-friendly administration via responsive design, but we recognize that certain pages, e.g., the permissions page, may require a dedicated mobile presentation.
Front-end performance
Lastly, performance has always been a priority for websites, but with mobile it becomes critical. Some studies show up to 97% of a page’s render time takes place in the front-end. There are a laundry list of best practices for front-end performance that will help mobile and desktop users. And I’ve seen several members of the Drupal community speak about these issues multiple times this past year.
However, when dealing with responsive design, the single biggest performance concern is image handling. The first demo of responsive design had over-large images being sent to mobile devices. While no single best solution has yet been found, we intend to leverage Drupal 7’s image styles to solve this issue.
Program tasks
Program tasks are defined in the following way:
- Must have (essential to success)
- Should have (significant impact to success)
- Could have (should be done, but are not essential)
- Won’t have (future functionality)
-
Must have / Critical
Responsive Web design
- Seven converted: http://drupal.org/node/1088792
- Stark converted: http://drupal.org/node/1322794
- Bartik converted: http://drupal.org/node/1192044
Mobile-friendly administration
- For all content editing and workflow related pages (adding users, taxonomy terms, menu items, new content, moderating content, etc.)
- Review of the Toolbar
- Review of the Overlay
Front-end performance
- Responsive images: As the layout is resized, the browser will serve the proper image size (“real” size, not height/width attributes) See Responsive image discussion for current status.
- Optimized images
- Sprites used wherever appropriate
- Optimized css: Evaluate the css aggregation process and adjust where improvements can be made.
One of the first issues that needs tackling is determining a dependencies list so the critical tasks can be done as quickly as possible. For example, all mobile-friendly admin tasks are dependent on Seven being responsive.
-
Should have / Major
Front end performance
- Documentation of the use cases that css aggregation serves.
- Documentation for how to optimize for other use cases.
- Documentation for how to make contributed projects mobile friendly. http://drupal.org/node/1341310
Mobile-friendly administration
Configuration pages converted (creating a new content type; adding fields to a user profile, etc.)
Front-end performance
- Document the use cases that css aggregation serves.
- Document how to optimize for other use cases.
- Document how to make contributed projects mobile friendly.
-
Could have / Normal & Minor
TBD
-
Won’t have
- Any impact on Drupal.org; See http://drupal.org/node/951114
Mobile Initiative: Minimal Viable Product
The Drupal 8 Mobile initiative’s goal aims to make Drupal the leading mobile CMS platform. Certainly, there are some fantastic contributed modules that already make Drupal a great starting point for mobile solutions; modules like Mobile Tools, Domain Access, Responsive Images, as well as a whole slew of new ones that have been released in the past few months. But in order for a CMS to earn the moniker "mobile-friendly", setting it all up needs to be easy.
Right now, Web development experts are building mobile apps and websites while looking for integration with existing CMSs. And they are having to build a lot of the tools themselves because there are very few mature tools. The Web development industry as a whole is still trying to figure out the best way to build mobile sites and Drupal needs to engage and become a leader as that work continues.
There are currently at least five different ways to provide mobile solutions:
- Native apps (code compiled to run natively on iPhones, Androids, etc.)
- Web apps (HTML5 and JavaScript-based apps running on mobile browsers)
- Mobile/desktop domain switching (parallel websites: one for desktop and one for mobile, with device detection to switch between the two.)
- Responsive design (a single HTML source that uses CSS3 media queries to respond to different device capabilities)
- RESS: Responsive Design + Server-side Components (a hybrid approach that uses Responsive Design techniques combined with a light amount of device detection to alter the markup before being sent to the user.)
Drupal, whether in core or contrib, should support all of them.
Now that’s a pretty broad spectrum of things to cover and they can’t all be included in core. But, to reach that “mobile-friendly CMS” status, what are the top issues Drupal 8 core should provide?
- Web services for native app integration
- HTML5 elements necessary for HTML5 Web apps
- Ability to use Drupal’s administrative forms in mobile devices
- All of Drupal 8’s core themes should be responsive
- Front-end performance improvements
Fortunately, the first two points are already covered by the Web Services and Context Core Initiative and the HTML5 Initiative.
That just leaves the last three items for the Drupal 8 Mobile Initiative to focus on.
Objectives
Responsive Web design
Responsive design is the hottest technique in producing mobile friendly websites because, relative to traditional mobile building techniques, it lowers the development cost for including mobile device support. Websites that only support large screens will become an anachronism, so converting all of core’s current themes to have mobile-first responsive designs is essential for Drupal to remain relevant. (Incidentally, the Drupal 8 Design Initiative, which is focusing on building new themes for Drupal 8, will also ensure its themes are responsive.)
Mobile-friendly forms
If users can’t create content or administer a Drupal site while on a mobile device, we have a serious problem. Those are the first tasks attempted by users on new Drupal websites. Much as the “ugly themes in Drupal 6” made a bad first impression of Drupal to Web designers, not providing mobile administrative solutions will leave a sour taste in the mouths of mobile developers evaluating CMS solutions. To complete this task, we’ll have to look at the complete stack for administrative tasks, including form definitions, form submit handlers, the Toolbar, the Overlay, and the Seven theme.
The target is 100% mobile-friendly administration via responsive design, but we recognize that certain pages, e.g., the permissions page, may require a dedicated mobile presentation.
Front-end performance
Lastly, performance has always been a priority for websites, but with mobile it becomes critical. Some studies show up to 97% of a page’s render time takes place in the front-end. There are a laundry list of best practices for front-end performance that will help mobile and desktop users. And I’ve seen several members of the Drupal community speak about these issues multiple times this past year.
However, when dealing with responsive design, the single biggest performance concern is image handling. The first demo of responsive design had over-large images being sent to mobile devices. While no single best solution has yet been found, we intend to leverage Drupal 7’s image styles to solve this issue.
Program tasks
Program tasks are defined in the following way:
- Must have (essential to success)
- Should have (significant impact to success)
- Could have (should be done, but are not essential)
- Won’t have (future functionality)
-
Must have / Critical
Responsive Web design
- Seven converted: http://drupal.org/node/1088792
- Stark converted: http://drupal.org/node/1322794
- Bartik converted: http://drupal.org/node/1192044
Mobile-friendly administration
- For all content editing and workflow related pages (adding users, taxonomy terms, menu items, new content, moderating content, etc.)
- Review of the Toolbar
- Review of the Overlay
Front-end performance
- Responsive images: As the layout is resized, the browser will serve the proper image size (“real” size, not height/width attributes) See Responsive image discussion for current status.
- Optimized images
- Sprites used wherever appropriate
- Optimized css: Evaluate the css aggregation process and adjust where improvements can be made.
One of the first issues that needs tackling is determining a dependencies list so the critical tasks can be done as quickly as possible. For example, all mobile-friendly admin tasks are dependent on Seven being responsive.
-
Should have / Major
Front end performance
- Documentation of the use cases that css aggregation serves.
- Documentation for how to optimize for other use cases.
- Documentation for how to make contributed projects mobile friendly. http://drupal.org/node/1341310
Mobile-friendly administration
Configuration pages converted (creating a new content type; adding fields to a user profile, etc.)
Front-end performance
- Document the use cases that css aggregation serves.
- Document how to optimize for other use cases.
- Document how to make contributed projects mobile friendly.
-
Could have / Normal & Minor
TBD
-
Won’t have
- Any impact on Drupal.org; See http://drupal.org/node/951114
Rules and referenced user tokens
Rules are great for workflows. We have about 30 rules in place on our intranet to help almost every part of our daily workflow, and as with most offices communication between we mere mortals and our fearless leaders is critical. With the help of realname and realname user rereference we create a convenient user interface for data entry,
Realname User Reference Widget
After that we work with Rules and Tokens to create a more automated workflow. For the Video types there’s a brief ~3 minute video.
The important thing to remember when working with user references in rules is that you must load the user reference BEFORE those that user and the associated tokens become available. Give your user reference a handy name to create your unique tokens and you’re ok. Once you have loaded the referenced user into your rule, the tokens are available to use – any information stored in the referenced user’s profile is there too. Also used in this tutorial though not mentioned explicitly is html mail for sending prettier emails through rules.
This is how our rule looked at the end
Debugging: If you find yourself in trouble remember that in the settings page you may turn on the rules debugger (which, depending on the number of rules may churn out a rather lengthy list… ). In the settings there’s also an option to turn off token warnings. This may tell you whether or not you’ve done your job with the use of tokens.
Debugging Rules - tokens have options too
Caching failed with panels in legacy mode
Did an deploy on one of the sites that we are working with, we did not get any errors on our staging server, but when we put it out on the production server we really had a big problem with caching. Suddenly cache would choke, display white screens of sadness, just caching part of the page, etc. Crisis. At least. I tracked it down, with beads of sweat running down my face (the problem were on the production server for gods sake), and the problem were that Panels were in legacy mode and our custom layouts did not work. I found a couple of discussion on drupal.org on the subject. I updated the Skinr module to make panels running normal. Updated the database, cleared the cache a couple of times. And then, finally, everything worked ok again. I could wash my face, and make a phone call to the client to say that everything now was ok.
Lessons learned from this are several, but the most important was - never let panels work in legacy mode
PanelsCacheSkinrLegacyScheduling Drupal Site Updates the SysAdmin Way
A client of ours recently had a major business announcement and needed to update their site's theme and publish a node to coincide with the announcement. Had the announcement been scheduled for regular business hours I probably would have made the changes manually, but because it was scheduled for 5:30 am I needed a better solution.
Using Panels and Page Manager with your eyes closed
As the Drupal Core accessibility maintainer, I from time to time have people ask me about the accessibility of different contributed modules. Several times in the past I've been asked about the accessibility of Panels (where I assume the person means cTools Page Manager as well). Only this week have I had the need to use Panels and Page Manager. This is by no means a thorough review, but my observations as a screen-reader user.
I was definitely able to get around Page Manager, to clone and modify some node_view variants. The experience wasn't something that made me super happy, indeed I yelled (quite literally) at my computer several times.
The first major problem I observed was that the 'gear' icons (used to modify regions, to add content, and to modify panels) were read as 'link #'. I didn't go looking into the DOM, but this is generally symptom of an anchor without any text. Screen-reader users should know that the 'link #' prior to a region or panel is the gear that will expose the options for the proceeding object.
The second problem was that I wasn't able to rearrange panels by dragging and dropping. This is pretty obvious, as screen-reader users don't tend to use a mouse. In Drupal Core we mitigated the accessibility barrier caused by tabledrag UIs by implementing 'row weights'. The same thing wouldn't necessarily work here, but it might be possible to expose a weight for each panel in a region through the UI. Perhaps this already exists and I'm just not finding it.
I've filed the following bugs, and will work with the cTools module maintainer to improve the accessibility of the module.
Tags:
Using Drupal Contextual Filters in Views
It can take a while when you're new, but once you start to wrap your head around Views, that is when Drupal gets really fun. In this tutorial, I'll go over how to use Contextual Filters in Views to alter your content dynamically based on information in the URL. If you're a visual learner, you can skip to the video at the end of this post for a detailed walk through of the process.
Donna Benjamin (KatteKrab) on broadening Drupal adoption
In this episode of Drupal Yarns we talk with Donna Benjamin (KatteKrab) about the success of Drupal Downunder and various other Australian Drupal issues.
