Note: Patch Spotlight is deprecated. All initiatives should be catalogued now under sub-pages of http://drupal.org/community-initiatives/drupal-core.
Managing the increasing complexity of Drupal 8 can be a daunting task for anyone. Writing a module involves a lot of boilerplate code. There are also a lot of things you need to know and do, just to get started with building a new module. These tasks can be repetitive and tedious, and can therefore create opportunities for errors. Fortunately, a lot of the new code can be generated automatically using Drupal Console.Read more
There's a new proposal to create a coherent, internationalized Drupal 8 User Manual, which Joe Shindelar (eojthebrave) discussed at DrupalCon Los Angeles recently. Because we want comments on the proposal, it's posted in the Documentation group (the Core group doesn't allow comments):
I thought some other groups might be interested, so I'm posting this quick note to let you know. Follow the link for all the details and discussions.
For a few years I worked for some time trying to setup my own CMS system to handle smaller scale tasks than what Drupal, or even Wordpress is targeted at. While I've moved on after conceding defeat a the enormity of the task (and never really having enough time for it around paying work) there is one concept from it that I feel is ripe from exploration - using a static cache. Not what Drupal does now might you, but a true static cache.Read more
I am not sure if this is the proper place to post this question, so please direct me to the correct group if this is not.
I am curious why fields in Drupal cannot be created through the UI without first creating some entity (i.e. a node)? I have seen the ability to do this in other content management systems, which make it easier to setup a content model where fields are being shared across content types. Not saying that is the best way to architect a CMS, but it seems to be a common feature of other systems that also allow for structured content models.Read more
A few months ago in February we proposed a style guide for the Seven theme, we are now well underway. This is a recap and look ahead.
The objectives of the Style Guide are:
- Identify Drupal core values that we can use to determine the look & feel for the Seven theme.
- Unify the visual language in Seven and ensure the overall look-and-feel supports the core values.
- Identify the visual and UI patterns used by Drupal core so that they form a conscious, shared language for us to built upon.
Come help us convert Drupal 8's theme engine to Twig!
We're nearing the home stretch of Round 1 of the Twig conversion, and it's time to get all hands on deck! If you can create patches, test patches, review patches, convert PHPTemplate to twig, improve documentation, or help us clean up the theme system (there's plenty of non-twig-related work too!) then please, meet us online from 1-5pm on Friday, March 22nd
9 sessions - one (2-3 days) per month
This is the story about a small but imho important issue i want to expose to some people's eyes before D8 doors close.
It's about dataflow and the data providers i talk about are the info hooks. Maybe they will die some day but apparently not in D8.
Think of hook_entity_info(), hook_field_info(), hook_hook_info(), even incognito ones like hook_menu() or hook_permission().
(It's a good idea to change them to a common naming scheme but that's another story.)
So what's wrong with info hooks? Nothing. They are asked, they provide info. That's their job.Read more
We are holding a Drupal Core Sprint from the 1st - 4th November in Gent, Belgium. This is during the same days that BADCamp takes place in San Francisco.
The meeting place for the tour tomorrow is around 10 at 'Het zuid' in Gent (Woodrow Wilson square)Read more
A saw EclipseCG's session at DrupalCon Munich where he demonstrated the great improvement work he has done to Blocks and Layout for D8. I am really looking forward to be able to start experimenting with that.
However, the demo also showed a typical case for where we can greatly improve the usability, and UX feedback for site builders when, as in this demo, adding a new block from the library.
As it works today:
1 - Click the "Add block..." link
2 - The library page replaces the page
3 - Pick a block and you get to a third page
The work being done by Bojhan and others in this group, as well as within the Spark and other initiatives is simply amazing. It will undoubtedly lead to better UX and usability for especially those that will work with content.
As a site builder I am very eager to be able to get more involved in this work. Personally I am most interested in helping to test the usability and UX when constructing these editing interfaces, and provide feedback on that. Especially since it is those interfaces I as a site builder will be using the most in my work.Read more
The short story
The long story
Over the past six months we've been working on designing the experience of getting to where you want within Drupal's admin interface.Read more
while the conversion of OOP code to PSR-0 for D8 is making progress, the original requests for namespaces were all about procedural and hooks:
There have been arguments by the PSR-0 people that this would be a too difficult design task.
There have been other arguments that it is not worth the trouble, and we should rather move our procedural code to OOP. Imo this is certainly a possibility, but a lot of questions about this are not answered or even discussed.
So, what is the future of procedural and hooks?
There's a great event called DrupalCamp Twin Cities going on May 18-19, 2012 in Minneapolis, Minnesota, USA. Since the event is one of my favorites, I've signed up to attend and also will be organizing a Drupal 8 Theme Layer sprint on Sunday, May 20th (as well as during the camp of course!). The specific times and location are still TBD but plan on an approximately 10 AM to 5 PM sprint.
I want to get serious about redoing the information architecture of Drupal. To be frank, it's a problem. Users don't know what's structure and whats content. Neither do we. I see developers all the time asking where their modules belong.Read more
If you have development chops, designers and other contributors of this community need your help bringing designs to life.
Allow me to paint a picture of the need and skills required...
The task of creating content has been redesigned (http://groups.drupal.org/node/217434), and has reached a point of consensus. At this point, the design really needs to interactive to flush out how all of the various interactions will work (or don't). Additionally, once made interactive, we validate the direction by testing the prototype with end users.Read more
Last updated by Christajocelyn on Thu, 2015-07-09 11:18
It's great when we get newly injected energy into usability efforts in Drupal, as happened with the Drupal Usability Study at Google last week. However, these patches always run aground of various "freezes" we put in place in the stable release of Drupal:
- API freeze
- Don't commit patches that break backwards API compatibility within a stable release, for the benefit of contributed module and theme authors.
- String freeze
- Don't change any user-facing text (e.g. anything in a t() function), for the benefit of translation teams.
- UI freeze
- Don't commit patches that affect the user interface, for the benefit of the documentation team, as well as to not invalidate tutorials, screencasts, books, etc.
- Feature freeze
- Don't commit patches that add new features; stick only to bug fixes. Additional functionality gets added in contrib.
As far as I can tell, these guidelines are not actually written down anywhere, but simply passed down word-of-mouth from core generation to core generation. I want to do two things in this thread:
1) Create documentation around these guidelines.
2) Propose that we change these guidelines to make them looser and allow more classes of patches to be backported, particularly minor UI tweaks and string improvements.
Here's a proposal (co-developed by Dries, Moshe, Alex, and I), with the items in bold being ones that we propose to change, the rest being documented to the best of my current understanding. My hope is that this can both help is iterate faster on the core product, and also provide additional incentive for people helping with Drupal 8 core development, as there'd be a chance of them seeing their changes in a version of Drupal sooner than 18+ months away.Read more
Please join us for our 1st bi-weekly meeting to discuss issues and progress related to the Drupal 8 Design initiative. The meeting will be held in #drupal-design in IRC.
PST: 11:00 AM
EST: 2:00 PM
UK: 7:00 PM
CET: 8:00 PM