Skip to main content

Setting priorities for Drupal 8 in the lead up to code freeze

The Drupal 8 code freeze on July 1st is a bit over a month away.

In light of this fast approaching deadline I felt it was time to reassess my list of 'must haves' to focus my priorities for the next four weeks onto the issues that matter the most to me.

Here are my the ten issues at the top of my list. Want to share yours? Leave us a comment

by lee.rowlands /

1) Decouple comment module from node

Issue link

I first started on this issue in around September 2012. What started out as 'well I've converted forum to CMI, how hard could comment be' turned into a loose thread that took me down the 'well if we designed comment from the ground up how might it look' approach. This issue was first passing tests in November 2012 and with the help of the unbelievable andypost we've been re-rolling it now for over six months. The original issue is near to 400 comments and our helper issue (where we're running tests so we don't pollute the main issue) is now nearing 200 too. I have over 20 Mb of patch files for this issue in my local patches folder. The issue is RTBC. All thats needed here is more re-rolls and more reviews. At 400kb its a significant patch but it brings so much more functionality to comment module. Think admin comments on nodes, comments on users, for and against comment threads - the possibilities are endless.

2 and 3) Convert forum module to WSCCI

Issue links: part 1 part 2 part 3 blocker

When I took over as maintainer of forum module after it was suggested by @chx when I responded to @sun's call out for help maintaining core it was looking really neglected. Do you know that forum module in Drupal 7 uses raw $_POST variables? Yes forum doesn't use the Form API in the Drupal way. My goal for forum is to stem that neglect by bringing it up to date with the latest APIs in Drupal 8. There is really a trio of issues remaining here but I'm counting them as two so I can squeeze in one more into my top 10. There is a patch for one of them, one is postponed on a Taxonomy conversion (which @nick_schuch and I have been working on resolving) and the third one has an original patch that was ambitious and just needs a bit of dialing back (it floated the idea of a Forum entity sub-classing the taxonomy-term entity). These are all part of the WSCCI Meta so given that is critical will have to get in one way or another.

4) Allow DialogController to work with _form and _entity_form routes

Issue link

As shown in one of our recent blog posts, DialogController reacts to the appropriate Accept header on an incoming request and displays it in a dialog. At the moment this only works with the HtmlPageController, ie it is not compatiable with the HtmlFormController (used for displaying forms) and the HtmlEntityFormController (used for entity forms). The initial patch on the issue removes some hard-wiring and makes the DialogController compatible with both the existing RouteEnhancers in core but also any new enhancers that might come from contrib (or the Scotch initiative). Its failing a few tests and needs some more of its own.

5 and 6) Add a UI for custom block revisions

Issue link part 1 part 2

Custom block is a huge win for Drupal 8. It is basically fieldable panel panes or bean in core. Fieldable, revisionable and translatable blocks in core when coupled with views brings some significant site building to vanilla Drupal 8. One of the to-dos for this module is to add a UI for viewing/reverting/editing revisions. Whilst this can come in contrib if we don't get it done, it would be nice to have it in core. There is really two issues here but as they're interlinked, it probably makes sense to merge them into one. One is to add views support for custom block, this will allow us to use Views to make the revision listing page, meaning site-builders can easily customise the display. The other is to add the callbacks for editing/reverting/deleting a revision. 

7) Replace menu node form additions with an Entity Reference field

Issue link

Menu module adds the 'create a menu link' element to node forms using old-fashioned form alters. There are a few drawbacks to this. One is we use CONCAT('node/', nid) when querying the {menu_links} table to ascertain if a node has a menu link. Another is that we only allow one link per node. And yet another is that the current 1:1 ratio doesn't mean we can do multilingual menu links for a node. Moving the menu link form to an entity reference field solves all these. We can auto-create taxonomy terms with the Entity reference field for taxonomy terms so we should be able to do the same for menu links. This issue is probably the least along of the lot has been given some attention (in a local branch) by @amateescu. We also have some groundwork in terms of a wrapper function to create an ER field but there is no public patch as yet. I'm hoping to get to this in the next fortnight and banking on the D8MI cross-over here to give us extra momentum to get this one turned around inside the month.

8) Use UUID instead of serial ids for reference fields

Issue link

At present taxonomy term reference and entity reference fields use id's for keeping track of references. If we're serious about content deployment these need to be UUIDs. Case in point, a default value on a term or ER field will contain the serial id in the config file for the field. This effectively limits the ability for this field to be deployed. When we worked on the Custom Block derivative, we drew on our experiences (read dramas) with deploying features, views, beans and fieldable panels panes in Drupal 7 and made sure that the custom block instance config pointed back to the UUID of the custom block content, not the serial ID. This is a big issue and probably should be higher on the list than 8 but I think warrants is status as Major, in fact I'd argue for Critical on this one, although I doubt many would agree.

9) Add a ::cssSelect helper method to our test classes

Issue link

There are two css select helpers to choose from. There is one in PHP Unit (which is already in core), it is not as powerful as symfony/css-select but its better than trying to teach new contributors xpath. I think we need one or the other to lower the barrier to writing tests for core and more importantly - in contrib. The patch has been to RTBC and back a few times and we've settled on the PHP Unit version so we don't add another library to core just for a single method. It just needs a little more prodding.

10) Rename custom_block module to block_content

Issue link

This one isn't a deal breaker but will limit the ability of some to upgrade from Drupal 7 where custom_block would be a common machine name for a module developed as part of a project that contained custom blocks. No need to change our UI or interfaces, just need to rename the module machine name. There is a patch (an old one) but this issue has the potential for bike shedding.

Share yours

Do you have a hit-list of issues for Drupal 8? Comments on mine? Use the comment form below to let us know.









Posted by lee.rowlands
Senior Drupal Developer



Comment by rooby


That's a large list for a reasonably small amount of time :)

Good luck to you sir.

Comment by Charles


Your doing a great job at making Drupal better and better - Well done!

Comment by We design websites in karachi


Great post..

Comment by custom namespaces


i have to say...i hate projects have modules called 'custom_' -- of course it is!! put them in a FOLDER called custom... like /features or /contrib or even /patched as you may have needed. then of course we'ld have /custom with modules names to help define what the Mod actually is!!

And of course -- still: declare your dependencies in .info!