🇺🇸United States @texas_tater

Austin, TX
Account created on 17 March 2010, almost 15 years ago
#

Recent comments

🇺🇸United States texas_tater Austin, TX

@wim-leers, MASSIVE THANKS for all your time and energy in making this issue a priority. It’s been a long time coming! As stated eloquently in your issue description, this will go a long way to truly enhance the “M” in CMS.

As for #5 in Proposed Resolution, may I suggest a few adjustments based on many years as a site builder who trains many other site builders. In our enterprise/university setting, we often find that content editing is delegated, but site management is not. This is an effort to protect the site’s integrity, specifically the Information Architecture (IA). By limiting who can add/delete nodes but allowing the content editors to “fill in the blanks”, site managers are able to control the IA while delegating content maintenance. This delegation often reduces the usefulness of entity “author“ and “create datetime”, as they carry little meaning going forward.

With the expectation that we don’t want to overload the dropdown list with too much metadata, I suggest replacing the “who” of entity author with the “status” reflecting the Published/Unpublished state of the node, as mentioned in C2 by my colleague @mark_fullmer https://www.drupal.org/project/drupal/issues/3317769#comment-15132055 Drastically improve the linking experience in CKEditor 5 Needs work

I’m hopeful this is possible/easier with the landing of https://www.drupal.org/project/drupal/issues/3073554 Add a token for publication status Fixed !

With regards “when”, I believe the datetime stamp of the most recent Published/Unpublished status change would be most useful.

Lastly, if a “who” needs to be included, I suggest the last person to change the Published/Unpublished status (which I deduce would involve revisions info and may be too much for this effort).

Again, THANK YOU very much for spearheading this most important feature!

🇺🇸United States texas_tater Austin, TX

Agreed! Remaining open also impacts the perceived preview of visual layout by squishing things unnecessarily. It's already possible that the Preview might be slightly different from completely saving the layout, and this issue just adds another thing getting in the way.

Production build 0.71.5 2024