HtmlInputNodeTable::isAllowed fehlende Implementierung

  • Hallo zusammen,


    in einem meiner Plugins ist es unter anderem möglich den BBCode table zu verbieten. Technisch wird das über BBCodeHandler::getInstance()->setDisallowedBBCodes umgesetzt. HTMLInputNodeProcessor::validate prüft nun je gefundenen HTMLInputNode über die isAllowed Methode ob der Nutzer den BBCode verwenden darf. In einigen HTMLInputNode-Klassen (z.B. HtmlInputNodeTable) liefert die Methode immer ein leeres Array zurück - eine Validierung ist also unmöglich.


    Ich bitte um eine ordentliche Implementierung der isAllowed Methode in allen HTMLInputNode. Folgender Code würde wahrscheinlich hier schon reichen um den BBCode wie gewollt zu verbieten:

    Code
    if (BBCodeHandler::getInstance()->isAvailableBBCode('table')) {
    return [];
    }
    return ['table'];


    Viele Grüße,

    Daniel

    • Official Post

    Die Abschaltung der Tabellen ist gegenwärtig nicht vorgesehen, dies gilt auch für den Entzug der Berechtigung für den BBCode.


    Grundsätzlich stehe ich der Idee eines funktionsreduziertem Editor, z. B. zum Einsatz in Kommentaren, nicht entgegen, insbesondere unter dem Aspekt des angepassten Editors ab der Version 5.2. In der aktuellen Form gehören Tabellen aber zu den Core-Features, die durchgehend unterstützt werden, daher kann dies nur zukünftig im Rahmen eines reduzierten Editors erfolgen.

  • Danke für dein Feedback. Du weißt, dass ich deinen Argumentationen meist folgen kann, aber dafür habe ich kein Verständnis. Da die Methode bereits aufgrund des Interface vorgesehen ist, sollte sie doch auch ordentlich implementiert werden und das konsequenterweise für alle verfügbaren BBCodes - denn dafür sind die entsprechenden Funktionen vom Framework doch gedacht.


    Welche BBCodes sinnvollerweise verboten werden können kannst du dann getrost dem Entwickler überlassen, so wie es sich für ein ordentliches Framework gehört.


    Mein Anspruch ist es dem Nutzer alle sinnvollen Konfigurationsmöglichkeiten zu geben, die er benötigt. Für die Shoutbox war der BBCode Editor das meistgewünschte Festure. Dass dort aber nicht alle Codes sinnvoll sind ist natürlich klar. Welche das sind soll der Admin entscheiden. Nicht ich, und auch nicht WoltLab.


    Ich schlage also nochmal nachdrücklich vor, dass diese Einzeiler konsequenter Weise implementiert werden um für etwas mehr Konsistenz und Flexibilität zu sorgen. Oder spricht etwas dagegen?

    • Official Post

    Das ändert nichts daran, dass Tabellen als Kernfunktion als nicht-abschaltbar konzipiert ist und daher der Einbau einer der von dir gewünschten Änderung dem direkt entgegensteht. Das Problem ist an dieser Stelle, dass ich entweder konsequent alles vollkommen optional gestalten müsste oder eben nicht, denn andernfalls habe ich praktisch sofort die nächste Formatierung auf dem Tisch liegen. Daher auch mein Hinweis darauf, dass ich mir eher einen alternativen, funktionsreduzierten Editor vorstellen kann, der konsequent von Anfang bis Ende diese Einschränkungen umsetzt.


    Davon abgesehen hält dich nichts davon ab, den Einsatz selbstständig abzulehnen, in dem du im Rahmen der Validierung einen Fehler wirfst, sollte es Tabellen im Nachrichtentext geben:

    PHP
    // Initialisierung und process() habe ich ausgelassen
    $tables = $htmlInputProcessor->getHtmlInputNodeProcessor()->getDocument()->getElementsByTagName('table');
    if ($tables->length > 0) {
        // Exception
    }


    Um es nochmals zu unterstreichen: Gerne bin ich bereit, zukünftig einen funktionsreduzierten Editor anzubieten, der unter anderem die Abschaltung von Tabellen sauber umsetzt, über einen passenden Vorschlag können auch andere Entwickler ihre Anforderungen beisteuern. Die aktuelle Fassung des Editors unterstützt standardmäßig Tabellen und sieht eine Abschaltung nicht vor, das Server-seitige Gegenstück orientiert sich am Editor und umgekehrt.

  • Das ändert nichts daran, dass Tabellen als Kernfunktion als nicht-abschaltbar konzipiert ist und daher der Einbau einer der von dir gewünschten Änderung dem direkt entgegensteht.

    Das verstehe ich nicht ganz. Die Shoutbox ist bereits so konzipiert, dass sie wunderbar ohne Tabellen auskommt. Das ermöglichen angepasste Editor-Templates die einfach implementiert werden konnten. Änderungen am Backend kann ich aber leider nicht zu einfach umsetzen, wenn dafür die nötigen EventListener fehlen. Das sollte an dieser Stelle auch garnicht nötig sein, da ein Einzeiler in der dafür vorgesehenen Validierung das bereits ermöglichen würde.


    Quote

    Davon abgesehen hält dich nichts davon ab, den Einsatz selbstständig abzulehnen, in dem du im Rahmen der Validierung einen Fehler wirfst

    Darüber habe ich auch nachgedacht. Das müsste ich dann aber für alle Nodes umsetzen wo das Framework keinen ordentlichen Validator implementiert hat. Arbeit die ich ehrlich gesagt nicht bei mir in einem kostenlosen Update sehe.


    Quote

    Gerne bin ich bereit, zukünftig einen funktionsreduzierten Editor anzubieten, der unter anderem die Abschaltung von Tabellen sauber umsetzt, über einen passenden Vorschlag können auch andere Entwickler ihre Anforderungen beisteuern.

    Tolle Idee - ich unterstelle aber, dass die finale Umsetzung gerne ein Jahr auf sich warten lassen wird. Die Zeit haben die Nutzer leider nicht, die aktuell mit Plugin-Fehlern kämpfen, weil das Framework nicht korrekt validiert. Die Validatoren nachzuziehen wäre hier ein deutlich geringerer Aufwand, der problemlos in ein Minor-Update einfließen kann.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!