Capturing my answer to a question on a mail list I’m on about paying attention to the Drupal admin and editor experience. Particularly, someone was asking if they should open their allowed HTML to allow pasting form and iframe tags versus the risk of being compromised by the same. My initial reply was:
If your content team is relatively small and you trust them … I think it’s OK to all form and iframe embeds.However, if you can I’d see if you can embed these snippets via some other way, like shortcodes in WordPress or as Paragraphs in Drupal (there are probably a dozen other solutions in Drupal too) which integrate with each of those platforms. HTML is easy to break, you won’t be able to just paste the HTML into your editor, and if they embed code has to change in the future (or be removed) it’ll be tedious to do so.
Which lead to a longer discussion on ensuring the overall Drupal editing experience is not ignored.
First, “locking” clients out of editing templates and configuration values makes sense, if the vendor will be hosting and supporting the site long term. There’s a lot going on in a CMS, and accounting for changes to configuration, CSS, templates introduced only on the production server is a migraine waiting to happen.
That said, it doesn’t mean you should give up a lot of flexibility for controlling the layout of your pages and you shouldn’t have to run to the vendor for every change. Things they and you should be paying attention to:
Ensuring they aren’t hard coding page and node layouts in a template such that changing them later requires a lot of effort. This was a pain on a site I worked on last year and had the Webforms module enabled. Instead of using the Webforms UI to build a form and control how the fields were grouped and displayed, the previous developer did that completely via custom templates. For the client,this meant that any new form had to have a custom template for it and changes made to forms in Drupal’s UI had no apparent effect (which kind of misses the point of having Drupal). Other pages on the site were handled similarly with custom templates.
Just throwing a WYWIWYG editor at your editors is also a big fail. If you have a document type which will have a link to a PDF file, don’t be content with a “file explorer” type plugin for CKEditor. Have a “Related Files” field in the document content type. Editors shouldn’t have to worry about how and where the file link will be rendered. Use Drupal/your CMS to consistently display the links (and integrate the PDF contents with Search, share files with other content types, etc).
For layout control within a page, Drupal has a couple of options which don’t require an editor making the layout in raw HTML. I think there’s a Layout builder in the latest release and there’s always the “Paragraphs” module which lets you define types of blocks you can stack to build an interactive page. Conceptually not unlike Mailchimp’s editor, if your familiar with it or how Gutenberg’s blocks will be handled in WordPress.
Media handling in Drupal has always lagged behind WordPress. I’m not sure what the state of the art is, but the latest release has Media in core. If you’re going to have a lot of photos, audio files, etc… you’re better off managing them as Entities you can tag and manage like a node and not just think of them as a file you upload and link somewhere (much like images I mentioned earlier).
Also if you have some custom workflows for managing the content creation process, you should ask your vendor to use well known modules like Workbench to configure and manage the process. I wouldn’t want to code a custom workflow for a client, since that becomes harder to change whereas Drupal modules exist which can let you manage and tweak those requirements in the UI (see https://www.palantir.net/blog/
Last, I’d say make sure you have a good content model. If you are going to have blog posts, articles, and press releases — each with their own quirks — they should each be a content type in the admin. Don’t make an uber “article” type which behaves differently depending on which fields are filled out. Within each content type, group fields which belong together, use vertical tabs or sidebars to break up forms with a lot of fields, etc… This is a good summary: https://evolvingweb.ca/blog/