There are two use cases I can think of, but could be more: - The contact form - Pages rendered by Views (the respective header and footer settings in the Views UI) - ???
There are various questions in the d.org forums and elsewhere about how to go about achieving such tasks:
Add text to a view output page How do I display some introductory text before a view? Add Node Content Before A view? - Drupal Answers ...
For the contact form, the easier way I have found so far is to create a custom "Contact form header" block and add a visibility condition for it to be shown only when the URL path is contact
. Relatively easy to be done, but not that intuitive and with a few drawbacks:
1. If the path of the contact form changes for some reason, the visibility condition will not apply any more and the header block with the introductory/summary will not be rendered in the contact form page.
2. You need specific administrative permissions in order to be able to a) create and place that block as a header/footer and b) edit that text.
For the case of views-rendered pages, we do have the header/footer options available, and so this task once again was easy to achieve for me personally (an avid Drupal user with years of experience). Again though, drawbacks: 1. The user needs to have the permission to edit views -> DANGER!!! 2. Even if the site admin decides to grant that permission to specific people -> bad UX because the Views UI is overwhelming and intimidating
Now, we could have it so that these summary texts used for header/footer were actually nodes (could be a separate content type entirely actually for the sole purpose of being able to get granular with permissions of who can edit such text). Pieces of content that the users could easily edit to their liking. Nothing odd there. Just ordinary workflow they are used to, so... good UX. This would also reduce admin headache because they wouldn't have to grant dangerous permissions (edit block/views) to non-admin people.
The above solution would have a node be "tied" to the contact form, so even if the contact form path changed, the summary text would still show up there. Again, we are being "smart" about it and this is good UX. This could be an option on the contact form settings page. Something like a "Contact form header" (we could also have a footer). For the more advanced users, we could have it so that they could assign specific nodes as contact form header/footer. For those that prefer to be "old school" or for cases where the site admin is also the site owner (thus they have all the right permissions), they can still go with using custom blocks with proper visibility conditions.
The option to have a node "tied" to the contact form and to be able to change it to another node would be a great addition to the options available for the views header/footer:
Isn't there a module that does this already that we could merge into core? And anyways, why assume that people would always want to render a node/block at the top of a view? They might expect to render a view after/before a specific node. This is about discoverability of features and (quoting @jenlampton) "putting things where people expect to find them". So, I say we offer both options: a way for site admins to be able to define a specific node to be used as a view header/footer (that content editors or site owners can edit) as well as a way for site admins to attach a specific view to a node. Yes, we can achieve this already by using views blocks and proper visibility conditions, but doesn't this (for any Drupal/Backdrop newcomer) seem like an odd thing? I mean the fact that in a specific layout, you have a block that does not get rendered all the times - only with a specific node. Isn't that stranger than simply going to the node in question and finding the view that is rendered with it simply attached to it?
Similarly with the contact form. For the end-user/editor (not the site builder/admin) we could have an "Edit contact form description/summary/header/footer" link that would not expose anything else but this text to be edited. We could additionally have this be an actual node that they can search for (in the content manage form) and edit if they want. We could have an option for the admin to be able to define a different node as the contact form header/footer.
Here are a few interesting contrib modules...
Provides a Views attachment display type which displays the body of a node.
This allows you to allow users to edit the header and footer of Views without giving them access to the full Views admin UI.
Views UI: Edit Basic Settings:
Does your client want to modify the header, footer, title, or empty text of a view, but you don't want to train them on the rather intimidating Views UI admin interface or give them access to pages that may allow them to mess up their site? Then this handy little module is the solution for you!
"Views UI: Edit Basic Settings" places edit tabs on Views pages, similar to node pages, and allows users with the correct permission to modify their header, footer, title, empty text, or number of items to display. This module also provides a separate interface that displays a list of views. All Views are defined by you, so you can exclude certain Views.
Recent comments
Olaf, I had hoped I could download/export the danish language file, get AI to translate untranslated strings, import/upload the translations. Seems the download only have the...
Ubercart in Danish?
Yes, let's work to provide contributed modules on the translation server, not only Ubercart. I think it's an important project, and I hope we can make it possible. Probably not this year, but...
Ubercart in Danish?
I will look into it - and get back on the horse re translating Backdrop (hope I can remember how)
Ubercart in Danish?