Is it a good idea to always add your CKEditor plugin?

Open
#4 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
php
Domain
backend

Research direction

Start with Classes/EventListener/RteConfigEnhancer.php at line 29 to understand how every CKEditor preset is modified. Review the existing extension configuration and the rte_ckeditor documentation context mentioned in the issue. Done means an agreed opt-out approach is implemented and an example is documented, but the requested behavior still needs discussion.

Written by the indexing model from the issue text.

Description

This issue is regarding the event listener, which modifies every CKEditor preset. https://github.com/benjaminkott/syntax/blob/979354c52e199b165570939d776256cfb9d6c908/Classes/EventListener/RteConfigEnhancer.php#L29

To my understanding we have the nice possibility to create many CKEditor presets where you can explicitly fine grade what you need. I often have multiple presets with complete different use cases and very different configs to support the backend editor as much as it is possible. With your approach the adoptions are made ALWAYS, no matter how the preset is configured. This often makes sense in smaller TYPO3 projects, but not for enterprise.

So, what do you think about adding at least an extension configuration setting which can be used to disable the default injection of your extension related CKEditor preset adoptions?

I really would like to discuss this on your implementation. Let's find some way to have an example implementation of the used event listener. We can add examples in the rte_ckeditor documentation afterwards too.

@benjaminkott, what are your backgrounds to the currently implemented approach?

Dominant language
PHP
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.