In my opinion these are the things we should do before Chicago -- and only these aside of course from non API breaking bug fixes. Please edit this list responsibly -- this is not just "chx's favorite topics" (guess what do I care about profile module?). Also please add some important frontend features. I enabled comments too -- do not discuss any specific issue (is it _hook_ or __ ?) but rather what needs to be worked on. Specifics go to the issue queue.
- Change hook_field_op to an array of callbacks in hook_field_type_info (which is now hook_field_info). These dont define fields but field types.
- Tear block module apart into block (providing API), block_ui (providing UI) and block_custom (providing custom blocks). We want drastic block changes in D8 and we are on more firmer footing once this is in.
- Queue.
- Make every queue identity itself via an info hook and a queue running screen with a batch API indicator.
- Use queue API for node and comment, user, node multiple deletes
- Missing EntityFieldUpdateQuery
- Remove hook_node_info, node_invoke etc -- I do not see what can't be done with hook_field_extra_fields as necessary.
- Profile module, die, die
- At least get Make dashboard a fake theme in. We need to discuss the fate of dashboard, that's one item for Chicago!
- Change the hook separator from '_' to '_hook_'. Better do it ASAP.
- Get rid of form_set_error
- Menu system needs to be torn apart. Separate out menu links from hook_menu and Big task cleanup: Remove type and tasks from hook_menu().
Comments
I'd love to see us prioritize
I'd love to see Decide how to use HTML5 in Drupal 8.
And I love the idea of making Drupal 8 be a less-ambitious release. Get it out there much faster. And push big changes to Drupal 9.
The longer Drupal core ships without HTML5 support, the more antiquated it will become.
Jen Simmons
http://jensimmons.com
Maybe
I have significantly edited this thread to stay in focus. Please note how I have tried to put up quick, actionable, ASAP issues in the thread. Most of them have issues with significant agreement (but not all). I feel this more fells in the full-thaw after-Chicago period as significant amount of discussion still needs to happen.
I think reworking settings should be pre or at Chicago
I would like to see a unified system settings API for Drupal 8.
Perhaps depending on tizzo's availability; not sure if there's a d.o issue yet but he has system_settings project on GitHub. I think we know enough about what is needed to put something in before Chicago, and then decide if it's good or if something else is needed in discussion there.
benjamin, agaric
Exportables
No major changes. No central API or so. Just make sure the last major configuration pieces (only user roles at this point?) get exportable. That would be awesome!
Blog, forum, poll, search
The blog, poll, and forum modules should be looked at in D8 - if you want to get rid of the ability for modules to define node types, you'll have to figure out what to do with blog, forum, and poll. I guess they would just need to create content types at install time some other way?
Also, we really need to revamp the Search module for D8. Not sure if it's pre-Chicago or post-Chicago - why is Chicago the milestone here anyway?
Drupal programmer - http://poplarware.com
Drupal author - http://shop.oreilly.com/product/0636920034612.do
Drupal contributor - https://www.drupal.org/u/jhodgdon
Chicago
My plan is to have a partial thaw now where we work on the things decided on here somewhat limiting the API breakage and the usual craziness that goes for a thaw and past-Chicago once we had the chance to discuss things we can do a full - on crazy thaw.
if you want to get rid of the
Is this really a good idea, to remove the possibility to let modules define node types? Why is this necessary?
Alternative: All node types are defined by modules, prefixed with "modulename." to avoid nameclashes.
We add a module named nodetypes_ui, which allows to add custom node types via the backend. These custom node types will be prefixed with nodetypes_ui.
Ok, not sure if the prefixes are really a good idea.
Node types
Forum already lets you choose what node types to use for it so it really doesn't need to make a node type. Blog could do the same. Poll is a little tricky because it's totally different from other node types with the lack of a body. I always thought not having a body on it was a bit silly anyway, though. Personally, though, I'd be surprised if Poll survives. It managed to hang on in D7 but it has a price on its head. LOL!
Michelle
Ok, makes sense. For contrib
Ok, makes sense.
For contrib modules, a feature could do the job of creating that content type. For core modules (blog, forum), this would only make sense if features.module will be included in core.
Why does it make sense?
Nodes and content types are core data structures. Why would you want to remove the APIs for creating new content types?
What is the general thinking
What is the general thinking behind removing node type creation from modules? I'm quite new to Drupal design but this is something I've been trying to understand better, when should a module include a content type, should that be moved out to a feature, etc. Is there a trend being suggested here for D8 that is informed by a more general approach to contrib module design?
Field?
I see the poll content type going away, and a poll fieldtype entering the stage.
API consistency
I'd also vote to do a quick look-over smaller gaps in the D7 APIs, I believe Dave Reid pointed out a few that were denied for inclusion (I don't have issue links off hand).
Fields on their own can't replace content types
Please excuse my ignorance on D7's APIs as I've been too stuck in D6 to catch up yet, but don't you still need a content type to attach fields to? Therefore the node definition should stay, though obviously improved as necessary.