Problem and Motivation

I tried to use the current implementation of the AnchorLinkMatcher and wasn't really happy with the limitations to the current page and the behavior to just add a "#" to the search string, so I tried to make it usable from everywhere. The module is partially based on the existing EntityMatcher and NodeMatcher provided by Linkit.

The downside of my current solution is the amount and, in bigger systems, the complexity of the created database queries, especially when paragraphs are used. I added the configuration parameter "recursion_active" and "recursion_depth" to the config page of the matcher to mitigate this problem. My prefered solution would have been to add tracking for created and removed anchor links within the database to get rid of the flexible detection and thereby to make the complexity of the query foreseeable, but this kind of solution would have needed more changes to your module.

Manual

Configuration parameters

  • Metadata
    Adds metadata to the suggestions.
  • Bundle filter
    Add/Remove specific bundles to discovery.
  • Bundle grouping
    Groups results by bundle.
  • Limit
    Limit shown results to configured number.
  • Unpublished Nodes
    Add anchors on unpublished nodes to results. The user still needs
    to have the necessary permissions to see the nodes!
  • Recursion
    The SQL-Queries created by the anchor link detection add a JOIN-Statement for
    every textfield an anchor might be discoverable in. In combination with the module 'paragraphs'
    this can create very big SQL-Queries with a high count of JOINs. For this reason, the default configuration
    only takes 1 level of depth into account when analysing paragraphs. E.g.
      - Discovered: field_text (Textfield)
      - Discovered: field_content (Paragraph)
                    referencing field_text (Textfield)
      - NOT Discovered: field_content (Paragraph)
                        referencing field_structured_content (Paragraph)
                        referencing field_text (Textfield)
    
  • Activate recursion
    Activates recursive search, allowing in-depth analysis and high count of JOIN-Statements.
  • Limit recursion depth
    Shown when recursion is activated. If this is empty, the analysis of the depth is unlimited. In case
    of a number being configured, the depth is limited to this number, e.g.
        - Depth 1: field_text (Textfield)
        - Depth 1: field_content (Paragraph)
                   referencing field_text (Textfield)
        - Depth 2: field_content (Paragraph)
                   referencing field_structured_content (Paragraph)
                   referencing field_text (Textfield)
        - Depth 3: field_content (Paragraph)
                   referencing field_structured_content (Paragraph)
                   referencing field_more_structured_content (Paragraph)
                   referencing field_text (Textfield)
    

Usage

Within a textfield with enabled CKEditor and enabled LinkIt-Button.

  • Press LinkIt-Button
  • Either search by word, e.g. "my_anchor", or by anchor, e.g. "#my_anchor"
  • Select suggestion

Proposed resolution

I'll try to create a merge request containing my suggested rework. Either it is deemed to be suitable for your module - then it can be added - or you do not like the suggestion and reject the merge request.

Remaining tasks

  • ✅ File an issue
  • ➖ Addition/Change/Update/Fix
  • ➖ Testing to ensure no regression
  • ➖ Automated unit testing coverage
  • ➖ Automated functional testing coverage
  • ➖ UX/UI designer responsibilities
  • ➖ Readability
  • ➖ Accessibility
  • ➖ Performance
  • ➖ Security
  • ➖ Documentation
  • ➖ Code review by maintainers
  • ➖ Full testing and approval
  • ➖ Credit contributors
  • ➖ Review with the product owner
  • ➖ Release notes snippet
  • ❌ Release
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

Styx1983 created an issue. See original summary.

styx1983’s picture

Issue summary: View changes
styx1983’s picture

Issue summary: View changes

rajab natshah’s picture

Title: Suggestion for rework of CKEditorAnchorLinkMatcher » Rework the CKEditor Anchor Link Matcher class
rajab natshah’s picture

Title: Rework the CKEditor Anchor Link Matcher class » Rework the Suggestion for CKEditor Anchor Link Matcher class for LinkIt
megakeegman’s picture

Glad to find this. Will rebase and review today.

megakeegman’s picture

This is a decent implementation. My biggest complaint is that link it is unable to find anchors on the current page if it has not yet been saved. I wonder if there is a way include a query of the auto-save draft of the current node or something like that.

megakeegman’s picture

Eh, I guess it would probably just be best to use javascript. But yeah, I think anchors on the current page should be the priority, even though I agree that including other anchors is pretty sweet. I mean maybe the in page anchors should even just be an entirely separate feature, which makes me want to look back at the implementation in the previous branch for inspiration. Should we re-open that one and just treat these separately?

rajab natshah’s picture

Thank you, Styx1983 and megakeegman

Good direction, and it is a big change: an entity query, the field manager and a settings form. Worth landing with test coverage rather than as a quick merge.

rajab natshah’s picture

Status: Needs review » Closed (won't fix)

After a further re-think and testing, we went into other logic for this.

MR !12 keys on class="ck-anchor", which library 2.0.5 stopped writing for #3438755: Anchor class should not be added to data view. And as megakeegman said in #6, the anchors people want are on the page being edited, so unsaved — no entity query can see them.

The logic we are going with, same feature as #3557518: Anchors should link to self: read the [id] elements out of the open editor in JavaScript and offer them in the anchor balloon. Current page, no database. That lands in vardot/ckeditor5-anchor-drupal.

Thank you, Styx1983 and megakeegman — the analysis here is what led us there.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.