Refactor Link, Linklist Widgets and rex_article_slice table to support links containing anchors

[ynamite]

See also:
#6360

[ynamite]

Sorry für die vielen Commits, mir war erst gar nicht klar, dass ich das vorab lokal hätte testen können. Wieder was gelernt

[tbaddade]

Könntest du bitte Beispielcode liefern?

1. Wie erweiterst du die Linkmap über den EP.
2. Wie sieht die Moduleingabe aus
3. Wie sieht die Modulausgabe aus

Mein Test

boot.php Project AddOn

if (rex::isBackend()) {
    rex_extension::register('LINKMAP_ARTICLE_LIST', static function (rex_extension_point $ep) {
        $subject = $ep->getSubject();
        $subject .= '<li class="list-group-item"><a href="javascript:insertLink(\'redaxo://1#anker\',\'Home\u0020\u005B1\u005D\');" class="rex-offline"><i class="rex-icon rex-icon-sitestartarticle"></i> Home - Anker<span class="list-item-suffix">#</span></a></li>';
        $ep->setSubject($subject);
    });
}

Modulausgabe

$slice = $this->getCurrentSlice();

dump($slice->getLink(1));
// -> 1

echo REX_LINK[id=1 output=url];
// -> ../index.php?article_id=1

Hier fehlt jeweils der Anker. Vermutlich handelst du das aber anders.

Und ich vermute, du befüllst auch die Artikelliste etwas anders. Dieses <li> manuell zu erzeugen, finde ich recht kompliziert. Aber ich bin gespannt wie du es nutzt.

[ynamite]

Den EP nutze ich mehr oder weniger genauso wie in deinem Beispiel oben:

if (rex::isBackend()) {
  rex_extension::register('LINKMAP_ARTICLE_LIST', function (rex_extension_point $ep) {
    $subject = $ep->getSubject();
    $subject.= '<li class="list-group-item"><a href="javascript:insertLink(\'redaxo://1#anker\',\'' . addslashes('Home') . '\u0020\u005B' . '1' . '\u005D #' . addslashes('anker') . '\');" class="rex-online"><i class="rex-icon fa fa-anchor"></i> ' . rex_escape('Anker') . '<span class="list-item-suffix">1</span></a></li>';
    $ep->setSubject($subject);
  });
}

In der Modul-Ausgabe parse ich dann REX_LINK[1] selbst (gibt bei mir dann 1#anker aus).
War mir gar nicht klar, dass es $slice->getLink(1) und output=url gibt :)

Da ich das nun kenne, kann ich gerne für beides eine Lösung liefern. Gibt es noch andere Stellen/Methoden/Ersetzungen, die es zu beachten gäbe?

[ynamite]

Methoden sind ergänzt.

$slice = $this->getCurrentSlice();

dump($slice->getLink(1));
// -> 1#anker

echo REX_LINK[id=1 output=url];
// -> ../index.php?article_id=1#anker

[tbaddade]

@ynamite Gregor und ich haben uns den PR noch einmal angeschaut und würden ihn aktuell erst einmal nicht übernehmen. Nur ein Beispiel: In der Datenbank werden derzeit nur IDs bzw. kommaseparierte IDs gespeichert – bei den nachgelagerten Checks und den verwendeten Regex würde das sonst zu Problemen führen.

Magst du deine Intention hinter dem PR und die Grundidee bitte noch einmal in einem Issue festhalten? Das Thema Anker ist uns bekannt und jeder von uns geht damit im Moment etwas anders um. Vielleicht ergibt sich später noch eine saubere Lösung, um Anker über die Linkmap auswählen zu können.

[ynamite]

@tbaddade Ich kann euren Entscheid verstehen, finde es aber etwas schade. FYI, ich habe das genauso in zwei Projekten im Einsatz und das funktioniert (soweit) problemlos. Mögt ihr genauer beschreiben, wo/wann das zu Problemen führen kann?

Klar, es ist unschön, dass ein ID Feld zweckentfremdet wird. Bei den Link und Linkmap Vars ist das aber eigentlich nicht so tragisch. Hier überwiegt der Nutzen, imo. Ohne signifikante Änderungen an der Tabelle der Slices sehe ich keine andere Möglichkeit, Ankerpunkte vernünftig zu realisieren. Aber ja, ich fände es natürlich super, wenn es eine bessere Lösung gäbe.

Mir stellt sich zudem gerade die Frage, weshalb die Link-Spalten ID-Spalten sein müssen. Wie wäre es mit JSON? Klar, breaking change und so, aber irgendwann muss man die Altlasten loswerden. Es ist tatsächlich so, dass es bis dato in Redaxo bzw. Struktur-Addon keine (standardisierte) Lösung gibt, um Ankerpunkte für Redakteure/Laien bereitzustellen. Bitte nicht als Seitenhieb verstehen, ich liebe Redaxo, aber das ist nach über 20 Jahren schon ein bisschen "naja".

Intention
Die Intention hinter dem PR war eine Lösung für das "Redaxo Ankerproblem" bereitzustellen, welche einfach zu integrieren ist und auf der bestehenden Linkmap und dem Linkfeld aufbaut, ohne dabei möglichst die herkömmliche Funktionalität einzuschränken und ohne tiefgreifende Änderungen auskommt.
Diese Lösung empfinde ich als eine benutzerfreundliche Variante, da die Funktionalität in den bestehenden Link-Dialogen integriert wird und somit aus UX-Sicht am richtigen Ort ist.

[gharlan]

Mögt ihr genauer beschreiben, wo/wann das zu Problemen führen kann?

Ich dachte, wir hätten einen isInUse-Check auch für Artikel, ähnlich wie wir ihn bei Medien haben (lassen sich nicht löschen, wenn noch irgendwo verwendet).
Aber hatte ich wohl falsch in Erinnerung. Wenn wir ihn hätten, dann würde der bei der Linklist vermutlich mit FIND_IN_SET oder REGEXP in der SQL-Query arbeiten, und da würde es dann neu nicht mehr funktionieren, wenn an der ID plötzlich ggf. noch ein Anker hängt.
Bzw. genauso bei einem =-Check bei den Einzel-Link-Feldern.

Somit sehe ich zurzeit aber doch keine existierende Stelle, wo es zu einem Problem führt, sondern nur in der Theorie, bei welcher Art von Abfragen es zu Problemen führen könnte (und evtl. auch führt, je nach Projekt-/Addon-Code).

Bin mir hier noch unsicher. So richtig gefallen will mir das nicht, auch wenn ich generell durchaus Sympathie für pragmatische Lösungen habe und bisher auch noch keine bessere Lösungsidee habe.

[ynamite]

Das Argument leuchtet ein. Wobei vermutlich eine Regexp möglich wäre, die allfällige Anker unterstützt.

Nur als Idee: vielleicht wäre ein zukunftsorientierter Ansatz, wenn alle REX_LINKs in einer eigenen Relations-Tabelle leben würden? Mit einer Relation zu SLICE_ID und entsprechenden Indexes. Keine Ahnung wie man das am besten löst. Oder vielleicht doch in rex_article_slice direkt als JSON-Spalte?