Field Group Elements show on pseudofield

I propose we build a form for this rather than trying to remove appropriate elements from the edit form.

I think you are right on the change in approach, ultrabob. Is there a sprint on this at Florida Drupal Camp? Awesome!

I'm hoping to work on it here today. If anybody pitches in I'll be thrilled.

I finally had time to work on this some more. I think it is ready for review.

This patch adds a dedicated form implementation to handle workflow transitions on entity view pages, addressing several longstanding issues with the current approach.

Changes

New DisplayForm Class

- Added a new DisplayForm class that implements a form specifically for displaying
workflow buttons on entity view pages
- Properly manages transitions, filtering out self-transitions (e.g., draft to draft)
to reduce confusion
- Includes comprehensive unit tests for the new form

Enhanced Entity View Display

- Modified workflow_buttons_entity_view() to use the new DisplayForm instead of reusing
the entity form
- Added pre-check to verify transitions are available before rendering the form
- Significantly simplified the form rendering logic

Improved Code Quality

- Added type declarations and proper docblocks throughout

Unit Tests

- Added comprehensive unit tests that verify:
- Form construction with and without available transitions
- Self-transition filtering
- Form element structure and attributes
- Entity revision creation and state transition handling
- Form submission workflow

Benefits

- More focused implementation that only shows relevant workflow buttons
- Cleaner separation of concerns between entity forms and workflow transition forms
- Improved reliability in displaying workflow buttons on entity view pages

Related Issues

This addresses problems with:
- Workflow buttons sometimes displaying redundant options
- Workflow transition operations not being properly handled
- UI issues with the display of workflow buttons on entity view pages

I should mention, this is a breaking change. The form id changes, so any form alters that were relying on the form _id would cease to work. This is likely slightly lessened by the fact that, at least in my experience, the most common alter is to remove a button for saving into the same state. Still I have projects where I override button labels for some users, and this change would break them. I’m not sure there is an update hook that could remedy that.

This is fantastic. I'll have to test it out later if nobody else gets to that first but the code and tests look great!

We are technically still in beta but we could do a 2.0.x release (side benefit: gets us in modern versioning numbers, away from 8.x-1.x) to avoid people running into form ID troubles without a little warning.

Thank you I was actually going to suggest the same thing. There is one more open issue about removing some variables that were being made available to the theme but not used anywhere, so we could remove those at the same time. I always have the best of intentions to get in and help move these issues forward, but as this issue makes obvious, I'm not very successful with it.

I also wondered whether it would be a better approach to provide a formatter widget for the content moderation display rather than providing a new one, but I couldn't figure out in the time I had remaining how to make that work. I do think that providing options on the widgets that content moderation provides may be a better approach for both edit and display side modes. I can't really think of a scenario where a person would want both if we fixed the capability of showing the current moderation state.