View source for ICT:Remove view link in messages - augmented version

= Drupal 11 – Removing the “View” link from node save messages =

== Context ==
In the Heritage Project (Drupal 11.3.x), historian users must **not** be redirected to or encouraged to view the node page after saving content.  
However, Drupal core automatically shows a status message such as:

<pre>
Article “My title” has been updated. View
</pre>

The “View” link is part of the default node save status message.

A custom module (`heritage_tweaks`) modifies this behavior:
* The link is removed for non-administrators
* Administrators retain the default behavior
* Existing date validation logic is untouched

This page documents **why the initial implementation was unreliable** and **what exactly was changed** to make it work consistently in Drupal 11.

---

== Initial implementation (problematic) ==

The original code attached a custom submit handler like this:

<pre>
$form['actions']['submit']['#submit'][] = 'heritage_tweaks_clean_save_message';
</pre>

This assumes that:
* The node form always submits via <code>actions[submit]</code>
* The custom submit handler always runs after Drupal core adds its status message

These assumptions were **sometimes false** in Drupal 11.

---

== Why this failed intermittently ==

=== 1. Node forms can have multiple submit buttons ===
Even if the UI appears to show only one “Save” button, internally Drupal may expose:
* Multiple submit actions
* Workflow or moderation-related submit buttons
* Theme-generated submit wrappers

If the user clicks a submit button that is **not** <code>actions[submit]</code>, then:
* The custom handler is never executed
* The core “Saved … View” message remains unchanged

=== 2. Submit handlers are button-specific ===
In Drupal Form API:
* Submit handlers attached to one button are **not shared** with others
* Attaching to the wrong button means the code simply never runs

This is a common cause of “my submit handler works sometimes” bugs in Drupal.

---

== Final implementation (working) ==

The fix was to attach the cleanup handler to **all submit buttons**, not just one.

Simplified logic:

<pre>
foreach ($form['actions'] as $action) {
  if ($action['#type'] === 'submit') {
    $action['#submit'][] = 'heritage_tweaks_clean_save_message';
  }
}
</pre>

This ensures:
* The handler always runs, regardless of which submit action is used
* The cleanup logic executes after core has added its status message

---

== What did NOT change ==

* The date validation logic (fields ending in <code>_day</code>)
* The placeholder logic (<code>dd/mm/yyyy</code>)
* The use of Drupal’s Messenger API
* The permission check for administrators

Only the **submit-handler attachment strategy** changed.

---

== How the message cleanup works ==

When the submit handler runs:

# If the user has the <code>administer nodes</code> permission, do nothing
# Otherwise:
## Remove all STATUS messages
## Add a new plain-text status message without links

Example replacement message:

<pre>
Article “My title” has been updated.
</pre>

Warnings and errors are preserved because only STATUS messages are removed.

---

== Why this is correct for Drupal 11 ==

Drupal 8.5+ introduced the Messenger service, and Drupal 11 relies fully on it for user messages.

Key points:
* Status messages are stored in a message queue
* Messages must be removed **after** they are added
* Entity hooks (e.g. <code>hook_node_update</code>) run too early
* Form submit handlers run at the correct time

Attaching to all submit buttons is the **recommended defensive pattern** for node forms in modern Drupal.

---

== Summary (one sentence) ==

The fix works because the cleanup logic is now attached to **every submit button**, guaranteeing that the “View” link is removed no matter how the node form is submitted.

---

== Maintenance note ==
If future changes introduce new submit actions (custom workflows, contributed modules, admin themes), this implementation will continue to work without modification.