Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I'm starting to prepare for Linkit 8.x and would like to share my thoughts about how I see the future and what I see we need to have within the Linkit module project.
But I really need your help and input on this one.
First, let me list and explain the “concepts” we have in Linkit 7.x-3.x
Multiple editor integration
Linkit has from the start supported a minimun of two editors. CKEditor and TinyMCE.
I think that the 6.x version also supported BUEditor.
Profiles
Used to build settings containers. A profile holds configuration about search and input plugins, some BAC settings, and settings to “connect” a profile to a field, or an editor.
Profiles have had a permission/role based system in previous version of Linkit (7.x-2-x and 6.x-1.x). These are now gone in 7.x-3.x and this is controlled by the text_format permissions instead.
I felt that both having permissions/roles inside Linkit and also in the text_formats was a bit overkill and didn't make sense.
Profiles are also exportable with Ctools exportable UI. The main goal for this was to have an integration with the Feature module.
When using the Linkit module with an editor, you can choose to switch between different profiles when searching for results. This feature had a grate purpose, but now I can't remember why I created that feature now.
There is also some issues with it right now.
#2115763: Linkit editor button errors out after switching WYSIWYG text format
#2158115: Switch profile persistence and permission by role
Search plugins
Used to separate search result types. The basic idea behind this was to make it easy to separate configuration and also inherit code.
Most of the search plugins returns some kind of entity and they have their own settings form (used in the profiles).
Uses the Ctools plugin structure to be easily extended and implemented by other modules.
Input plugins
Used to “theme” the result link when inserting it into an editor or a field.
For editors, the default is an HTML link, and for fields, it could be a raw path.
This was mostly created to support field integration and markdown code.
Uses the Ctools plugin structure to be easily extended and implemented by other modules.
There is support for both the wysiwyg module and the ckeditor module.
Field integration
A field integration was first committed into the 7.x-2.x branch, and heavily refactored in the 7.x-3.x version.
The field integration adds support for adding the same (almost) dialog used by editor to a button connected to a field.
Supports text, text_long, text_with_summary and link_field by default.
I have the feeling that this function is commonly used by the Linkit users.
Export UI (with Ctools)
As I mentioned in the profile section, this is used to support feature integration.
BAC
https://github.com/betamos/Better-Autocomplete
This was actually first built to replace the autocomplete widget in Drupal 7 when using Linkit.
#1147136: Proposal for Linkit 2.x UI
#1149488: Develop custom autocompletion
Now to 8.x
How can we use the new APIs and modules in Drupal 8 to build an awesome Linkit module?
Multiple editor integration
I see that there is a dropdown when editing a text format that enables you to select an editor.
CKEditor is the only option here in a clean installation. Will there be more editor here later on?
Should we have multiple editor support at all?
Profiles
Is this a good concept? Shall we remove this and have only one big configuration?
Shall we improve the profiles in some way?
Search plugins
Can we use the plugin API for this?
Can we improve this is any way?
Input plugins
Can we use the plugin API for this?
Can we improve this is any way?
Field integration
I guess this can be done in Drupal 8 as well, but I haven't look into it very close.
Can we improve this is any way?
Export UI (with Ctools)
Drupal 8 has this functionality in core I think.
BAC
Do we still need to use BAC, or can we use the default autocomplete widget, or alter that to fit the needs for Linkit?
Other?
Are there any other things we need to have, remove, or modify to make Linkit a good module?
Comments
Comment #1
anonComment #2
Dom. CreditAttribution: Dom. commentedHi !
I would be interested with helping you to use "Search Autocomplete" module to create the autocompletion features with the complex display (multifield display + sorted by content type or whatever). This would help from not having to code the JS and the callback for this input field. D8 version of Search Autocomplete will indeed ship with an extension of FormAPI to do this out-of-the-box.
Dom.
Comment #3
rocketeerbkw CreditAttribution: rocketeerbkw commentedD8 uses jquery ui autocomplete now #675446: Use jQuery UI Autocomplete. Demo at jqueryui.com/autocomplete, looks like it handles categories and custom data/display which is what linkit needs.
Comment #4
Jody LynnI think linkit should focus on simplicity. Almost every user of linkit would like to just enable it and have it do its job without any configuration.
I would not bother supporting alternative editors in D8. The great thing about finally having a wysiwyg in core is that we can finally develop on top of it. The benefits of nearly every site using the same editor will far outweigh the flexibility of supporting alternative ones.
I would not bother with the idea of profiles. A sitewide configuration for linkit will suffice.
Just focus on the main use case: a link wysiwyg button that makes it easy for editors to add links and makes it difficult/impossible for them to make incorrect in-site links.
Ideally one could install linkit, and it would automatically replace the default link button in the wysiwyg with its improved link button. If it had no settings at all and was difficult to extend I doubt 95% of the users would mind.
Comment #5
Kristen PolFix minor typo
Comment #6
ChristophWeber CreditAttribution: ChristophWeber commentedI'm with Jody, keep it simple and/or make it simple. Linkit works great for all my editors without much special config. Its main benefit is getting links inside the site correct every time.
Comment #7
seanBI agree with Jody as well, but I think that supporting (at least link) fields is also very important.
Global config seems to make sense, but the way links are handled in fields and wysiwyg could be different. Needing profiles just for this small difference could be overkill, but it should be addressed.
I don't know enough on Drupal 8 yet to address the more technical questions, I hope to figure this out soon. Maybe someone else could jump in on those.
Comment #8
anon