Upgrading from Drupal 10 to Drupal 11: what actually changes
Drupal 11 is a far smaller step than the Drupal 7 to 9 migration was. Here is what the upgrade touches, what breaks, and the order to do it in.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- The content team uses the CMS daily; their experience is a product decision.
- Every optional field is a decision someone has to make without context.
- Workflow states should mirror how approval actually happens.
- Task-based documentation gets used; reference manuals do not.
The editors are users too
A great deal of design attention goes into the public site and almost none into the interface the content team uses every day. The result is a site that looks excellent and is unpleasant to run, which shows up later as out-of-date content.
Spend time watching people publish. The friction is usually obvious within an hour and cheap to fix.
Reduce the number of decisions
Every optional field, every layout choice and every unexplained toggle is a decision an editor has to make, often without enough context. Remove the fields nobody fills in, group what remains sensibly, and write real help text rather than repeating the field label.
- Order fields by the sequence people actually work in.
- Hide advanced options behind a disclosure rather than presenting everything at once.
- Set sensible defaults so the common case needs no input.
Preview and workflow
Editors need to see what they are publishing. Where the theme allows it, keep preview working and accurate; where the site is decoupled, budget for building it.
Content moderation states should reflect how the organisation actually approves content. A workflow with steps nobody uses gets bypassed, and a workflow with missing steps gets worked around in email.
Document and train
Hand over short, task-based documentation — how to publish a news item, how to add a team member — rather than a reference manual. Record a couple of screen captures; they get watched when written guides do not.
Then check back a month after launch. The questions people ask at that point are the best possible list of what to improve.
Measuring whether it is working
Editorial experience is usually discussed in terms of opinion. It can be observed instead, and the observations are more useful than the opinions.
Time how long it takes a competent editor to publish a standard item from scratch. Count how many support questions the content team asks in a month and what they are about. Look at how much content is created by a small number of people, which often indicates that everyone else finds the system too difficult. Check how often content is edited immediately after publishing, which usually means preview is not trustworthy.
Each of these points at a specific fixable problem. Reviewing them a month after launch, and again a year later, keeps a site that was pleasant to use from quietly becoming one that is not.
Frequently asked questions
Less than most projects assume, if the interface is well designed. A short session per role, focused on the tasks that person actually performs, plus written guidance for the handful of things that are genuinely non-obvious, covers most situations.
It depends on the editorial team and on how much visual consistency matters. Giving arbitrary layout control to a large team without design support reliably produces inconsistent pages. Restricting it to specific content types is a good compromise.
Review it periodically as you would any other part of the site. Remove unused content types, fields and views; tidy the administration menu; and set sensible default form displays so editors see the fields they need in a sensible order.
