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
Issue fork anchor_link-3460457
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
Comment #2
styx1983 commentedComment #3
styx1983 commentedComment #5
rajab natshahComment #6
rajab natshahComment #7
rajab natshahComment #8
megakeegman commentedGlad to find this. Will rebase and review today.
Comment #9
megakeegman commentedThis 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.
Comment #10
megakeegman commentedEh, 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?
Comment #11
rajab natshahThank 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.
Comment #12
rajab natshahAfter 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.