This document discusses ideas for improving Drupal's staging and deployment process. It notes problems with data conflicts, IDs, and APIs. It advocates using universally unique IDs alongside existing keys to avoid query impacts and upgrades. Everything should be exportable in a simple way. Form functions and $_GET are not considered APIs, and the APIs need cleanup. If content cannot be saved, it cannot be imported either. Overall it argues Drupal has an "everything management problem" rather than just a configuration issue.
Introduction, still talking about this four years later\n
Our show tonight is three acts...\nWith assistance from a very special guest\n
Mr. Jeff Eaton. \nI will not spend a lot of time on the problem as we’re all pretty familiar with it\n
Monolithical database with all information\nAutoincrementing IDs\nLack of APIs\n
\n
\n
Our existing tools are focused only on the needs of developers and the ability to deploy configuration. This is understandable but doesn’t fix things.\n
Drupal has never pretended otherwise\nTrend has been to blur this line, not clarify it\nNodequeue example\n\n
\n
We can draw arbitrary lines, but why? Let Drupal be Drupal \n
\n
There is no magic bullet solution. There are too many use cases and workflows for that. This is a list of things we can do to enable people to do what they need.\n
\n
UUIDs everywhere is not necessary or appropriate\nMachine names still have uses in situations where identifier needs to be human-readable (aka CSS class names)\n
UUIDs everywhere is not necessary or appropriate\nMachine names still have uses in situations where identifier needs to be human-readable (aka CSS class names)\n
Prevent ugly paths with pathauto in core\nModules act on node_save() to handle the data they know (relations, etc)\n\n
Prevent ugly paths with pathauto in core\nModules act on node_save() to handle the data they know (relations, etc)\n\n
Prevent ugly paths with pathauto in core\nModules act on node_save() to handle the data they know (relations, etc)\n\n
Prevent ugly paths with pathauto in core\nModules act on node_save() to handle the data they know (relations, etc)\n\n
How can be discussed, we dont have to reinvent most of it. load() vs export(), lets not have two ways to load and save thing for different situations when the functionality is largely the same. \n
How can be discussed, we dont have to reinvent most of it. load() vs export(), lets not have two ways to load and save thing for different situations when the functionality is largely the same. \n
This is not about improving or cleaning up APIs, that stuff is going to get done. It is more about making sure we have actual APIs to load and save things. \n
Lesson here: Form API is not the place to put CRUD functionality, core needs to implement these things consistently and lead the way for contrib. People don’t usually think of this as part of the staging and deployment problem but it is because...\n
Lesson here: Form API is not the place to put CRUD functionality, core needs to implement these things consistently and lead the way for contrib. People don’t usually think of this as part of the staging and deployment problem but it is because...\n
Lesson here: Form API is not the place to put CRUD functionality, core needs to implement these things consistently and lead the way for contrib. People don’t usually think of this as part of the staging and deployment problem but it is because...\n
Right now we have a hard time saving things because there is functionality that exists only in submit and validate functions. Your options are drupal_form_submit() (hack with inconsistent formats) or node_save() (wont catch everything.) So when I talk about API cleanup I mostly mean turning things that aren’t APIs into actual APIs so we can save and load things consistently, and creating APIs for things that don’t have them (cf roles, etc)\n
These three things allow things to actually be deployed. There are lots of workflows and use cases for this, and we don’t need to address them all, let contrib worry about it. But without these changes we can’t address any of them. This is also an approachable set of solutions, if you try to change the world in a core release...\n
