This came up in a Gitter discussion between @laryn and @klonos and it is basically getting https://www.drupal.org/project/better_formats in core. There is a respective D8 core issue: https://www.drupal.org/node/784672 (from where https://www.drupal.org/project/allowed_formats was born). From the issue summary in d.org (some emphasis mine):
Problem/Motivation
Currently text fields can either be restricted to plain text, or the user may select between all accessible text formats independently of the context. This means that a privileged user who needs access to a permissive text formats (for example, to put tables or embedded remote content in basic pages) will get access to that format on every formatted text field (for example on a comment field).
There are three problems with this approach, and most experience Drupal developers have faced at least one of those in the past:
- Consistency At the moment you have to count on competence, good will and diligence of privileged users not to put certain markup in certain places. It would be convenient if a text field could be forced to use a specific text format (other than plain text). For example, you may want to make sure that comments only allow a very limited set of HTML tags ("filtertered HTML" for example) independently of the user's role, even if the same user has access to less restrictive formats in other places.
- Usability The ability to select text formats is a common source of confusion. By limiting the available text formats we also remove confusing user interface elements.
- Security If a privileged user account is taken over (for example, through social engineering), the attack surface is large due to the fact that every single text field can be used for XSS injections. By limiting where a dangerous text format can be used, we restrict the possibilities to inject malicious content.
Proposed resolution
Add an optional setting to the text field types that lets the site-builder determine if the text formats should be restricted. This setting is then used in the default textfield and textarea widgets to remove any non-allowed text formats. If nothing is set, the current behavior is unchanged.
Note that as it uses the underlying
'#allowed_formats'
form API property, the settings can't be used to give access to text formats that the user wouldn't have access to otherwise....
User interface changes
Checkboxes on list of available formats on text field configuration. Reduced set of allowed formats on content edit forms, where used. No fields use the new setting by default, so the patch doesn't affect the user interface for those who don't do anything with this functionality.
API changes
None
Data model changes
One setting is added to the field settings. The structure of the field data is unchanged.
PR: https://github.com/backdrop/backdrop/pull/2894
Advocate: @quicksketch
Recent comments
As some folks have mentioned, some work has gone into this. We actually added the ability to have "draft revisions" into core, BUT we never completed the front end user interface for this...
managing draft revisions while still having a version published
Hi danryan, just to be sure, can you check if the tabs aren't hidden in your layout? Go to the page where you miss the tabs. In the Admin bar at top of the page...
View/Edit tabs missing
The View/Edit tabs that normally appear at the top of any piece of content have disappeared. I'm not sure why you are not seeing the view and edit tabs, but it's worth...
View/Edit tabs missing