The "Drupal" plug-in allows AE users to define which tags are allowed in a specific editable (this maps to Drupal's text formats/filter system). Currently, the Drupal plug-in for AE has to maintain its own (HTML tag -> AE UI elements) mapping, so that it knows which UI elements to hide/disable whenever the corresponding HTML tag is disallowed by the current text format.

To ease our implementation, each UI element should at least be "tagged" to correlate with a certain HTML tag. That would mean we would no longer have to maintain our own mapping. Less maintenance, but also far less fragile (i.e. it currently breaks down if you install new plug-ins, whose UI elements we obviously cannot magically know).

It would be ideal if AE would incorporate such a system itself. Then it's no longer an afterthought and can be architected in a much better way.

Comments

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented
Title: Make the "Drupal" plug-in for AE obsolete or at least significantly easier to maintain » Make the 'Drupal' plug-in for AE obsolete or at least significantly easier to maintain
Version: 8.x-2.x-dev » 7.x-2.x-dev
Status: Postponed » Patch (to be ported)

Please also read @quicksketch's excellent rant: #1825214-1: Block-level tag drop-down not correctly showing/filtering options based on enabled tags.

Context:

We went to Vienna in July to do a code sprint with them, and they helped us write the "drupal" plug-in, which handles the hiding of buttons that shouldn't be used by users because the currently active text format doesn't support it and all that.
However, "per-editable config" was added in response to our needs, we just haven't found the time yet to migrate our code to use that instead. (Related discussion over at #1786550: Plugin configuration — though I warn you that it's very dense.)

I created this issue just before I knew that per-editable configuration was supported (it was added at a point during Spark development where I wasn't working on Aloha, thus I missed it — I take the blame for that). What I say in that issue still stands though: Aloha's configuration system should be better. I brought this up with them earlier today and they agree: https://github.com/alohaeditor/Aloha-Editor/issues/794.

But now, I'm happy to say I've actually fixed the way we deal with this. No more hacky stuff. No more global configuration. It's still not optimal, but now it's definitely bearable. All the Drupal plug-in does right now, is provide two repositories: one with links, one with images.

See http://drupalcode.org/project/aloha.git/commit/7f5ada0.

While doing this, I ran into some issues though:
- I fixed it for the Image plug-in: https://github.com/alohaeditor/Aloha-Editor/issues/786.
- I reported it for the Align plug-in: https://github.com/alohaeditor/Aloha-Editor/issues/793.
- Paste handling is broken due to an upstream bug (in the ContentHandler system), Rene Kapusta of Aloha Editor is investigating this right now.

Also note once more that implementing this in a more clean manner will only be possible once https://github.com/alohaeditor/Aloha-Editor/issues/794 is solved. Marking this issue as fixed, I left a @todo in the code to make sure I don't forget.