Support changing substitution plugins on a matcher without having to re-enter content

Created on 2 June 2019, over 5 years ago
Updated 16 May 2024, 4 months ago

Problem/Motivation

Currently the substitution plugin's id is set on a link when a user adds it with linkit. This means that if the substitution plugin is changed for a matcher, any old link has to be edited and resaved before getting the new substitution plugin. This is not ideal for sites that may have 100s of pages with internal links that need updating.

Proposed resolution

Potentially, we could use the matcher UUID along with the profile id and pull the substitution_type from there.

✨ Feature request
Status

Needs work

Version

7.0

Component

Code

Created by

πŸ‡¦πŸ‡ΊAustralia acbramley

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States mark_fullmer Tucson

    Updating the version this relates to as 6.1.x, and changing the priority to "Major," as this is a blocker for more gracefully resolving ✨ Decoupled website - absolute URL Active .

  • Status changed to Needs work 9 months ago
  • πŸ‡ΊπŸ‡ΈUnited States mark_fullmer Tucson

    I've updated the approach suggested above to work with the latest version of the module (6.1.x). This works with CKEditor 5, as well as with the Linkit field widget/formatter. However, in reviewing this approach, I think it still has one major drawback: in the context of the text format filter (i.e., CKEditor) this change will not allow existing site content to be updated to use a different substitution, derived from the matcher. This is because the implementation relies on knowing what the data-entity-matcher is, and this would not be present in existing data. Since the Linkit field formatter, on the other hand, can find the matcher associated with the selected Linkit Profile, it *can* make previously entered data updated.

    What would need to be possible in order to dynamically derive the currently-associated Substitution plugin from the Matcher would be the ability to find what Drupal text format is executing the filter (since that would have information about which Linkit Profile is used, which would give the Matcher, which would give the Substitution plugin. I don't believe there's a way to access that information at the right point in the rendering process for text format filters.

    So, I'm not optimistic about introducing this change, as I think we want something that will support existing content.

    I've posted the updated patch anyway, in case it prompts ideas from the community.

  • πŸ‡ΊπŸ‡ΈUnited States mark_fullmer Tucson
Production build 0.71.5 2024