RexSEO und Community: Neue Versionen, altes Problem

[der_bär]

Hallo zusammen,

bin grade wieder über ein Problem gestolpert, das eigentlich schon einmal gelöst war, konkret: Im Community-Addon wird bei der Verwendung von RexSEO der Seitenschutz ausgehebelt.

Was läuft?
Redaxo 4.5
RexSEO 1.6.1 (neueste Version von git)
Community-Addon (ebenfalls neueste git-Version)

Wenn ich unter System das Mod-Rewrite auf FALSE stelle, werden die Seiten, die nur für eingeloggte User sichtbar sein sollen, geschützt, bei TRUE sind sie erreichbar. Scheint so, als ob das Rewriting greift, bevor die Seitenberechtigung abgefragt wird.

Meine Frage natürlich: hab ich was übersehen oder mögen die beiden Addons wirklich nicht zusammen? Gibts dafür einen Fix?

Danke & Grüße
der Bär

[jdlx]

Meines Wissens unterstützt community das original RexSEO nicht mehr.. fixen kann man -> Markus Lorch fragen, bzw. mal in seinen fork kucken.

[Ingo]

Meines Wissens unterstützt community das original RexSEO nicht mehr

RexSEO ist der Rewriter für Redaxo. Den nicht mehr zu unterstützen heisst Entwicklern vorsätzlich einen Knüppel zwischen die Beine zu schmeissen. Manchmal muss man sich schon fragen, was manche Leute sich in ihr Pfeifchen stopfen...

[Thomas.Blum]

@Ingo … Irgendetwas bringst du da durcheinander.

[Gregor.Harlan]

@ingo: Vorschlag: erst informieren, wie genau die Lage ist, und dann bei Bedarf meckern. Und vielleicht etwas sachlicher…

Kurze Zusammenfassung:
Die Rewriter-Addons müssen sich in ADDONS_INCLUDED ganz an den Anfang hängen, da sie die Artikel-ID dort setzen und andere Addons darauf angewiesen sind. Die Community kommt wegen ihres Namens aber vor den Rewritern, daher hat die Community in einer älteren Version einen Rexseo-EP verwendet. In R4.5 haben wir aber dann eine allgemeine Lösung geschaffen, damit es nicht von einem bestimmten Rewriter abhängt. Außerdem sollte es auch allgemein so sein, dass das Community-Addon sich gar nicht für Rewriter interessieren muss. Hier das Issue dazu: https://github.com/redaxo/redaxo4/pull/54
Die anderen Rewriter-Addons verwenden die neue Lösung schon, Rexseo eben nicht. Aber JanK hat nun ein Pull-Request erstellt: https://github.com/gn2netwerk/rexseo/pull/49

[jdlx]

Aber JanK hat nun ein Pull-Request erstellt: https://github.com/gn2netwerk/rexseo/pull/49

Na also... lieber spät als nie. Is gemerged, gehe davon aus das es tested is..

-> 1.6.3 @ https://github.com/gn2netwerk/rexseo/releases

[Jan.Kristinus]

Hallo,

hättest du auch selbst machen können .. so schwer war das gar nicht..
ich habs nicht getestet sondern nur runtergeschrieben - besser nochmal prüfen.

lg

[jdlx]

hättest du auch selbst machen können ;) .. so schwer war das gar nicht..

Es gab bereits eine Lösung.. die war auch < 4.5 compat und keine code hexerei für die COM.. die flog raus.. dito die sitemap func: d.h. das Thema ist nachwievor offen wenn ich mich nicht täusche..

[Ingo]

@ingo: Vorschlag: erst informieren, wie genau die Lage ist, und dann bei Bedarf meckern. … Aber JanK hat nun ein Pull-Request erstellt: https://github.com/gn2netwerk/rexseo/pull/49

Das Problem war wie der Fix schon länger bekannt. Der Fix hat weniger Zeichen, als deine Erklärung der technischen Ursache des Problems. Trotzdem musste erst ein Entwickler auf die Nase fallen und hier im Forum posten, damit sich jemand der Sache annimmt. Findest du das professionell oder effizient?

Du hast erklärt, wo das Problem code-/ systemseitig herkommt; es geht mir aber darum, dass das Problem (obwohl inkl. Lösung bekannt) einen langen Zeitraum ignoriert wird, bis Anwender Probleme kriegen.

[Markus.Staab]

Das Problem war wie der Fix schon länger bekannt. Der Fix hat weniger Zeichen, als deine Erklärung der technischen Ursache des Problems. Trotzdem musste erst ein Entwickler auf die Nase fallen und hier im Forum posten, damit sich jemand der Sache annimmt. Findest du das professionell oder effizient?

Du hast erklärt, wo das Problem code-/ systemseitig herkommt; es geht mir aber darum, dass das Problem (obwohl inkl. Lösung bekannt) einen langen Zeitraum ignoriert wird, bis Anwender Probleme kriegen.

Der fix für dieses Problem hier war rein in RexSEO und hat kein zutun von uns gebraucht.

Wenn du nur 1 zehntel der Zeit in der Du hier Leute beschimpfst dafür aufgewandt hättest die Ursache des Fehlers zu finden, würde dieser Entwickler hier - der Leider für diese ganze unnötige Kommunikation nun sein Thema opfern muss - überhaupt nicht mit dem Thema belastet.

Wenn Du unsere Beiträge lesen würdest und Dir eine Minute Zeit nehmen würdest um Sie auch zu verstehen, hättest Du aber selbst auch gemerkt dass die erklärung von Gregor notwendig war um den Addon Autoren zu helfen, das Zusammenspiel der Addons zu verbessern.

Ich für meinen Teil werden deine Beiträge ab dem heutigen Tag ignorieren, da diese noch nie irgendeine Art von sinnvollem Inhalt transportiert haben. Ich vermute dass die anderen Entwickler dies auch bald tun werden, wenn sie es nicht schon lange tun.

[jdlx]

@OP: sry, aber ich mußte den PR von Jan Kristinus rückgängig machen.. er hat Probleme mit anderen Addons/Plugins hervorgerufen.. und das Sitemap Thema war eh nicht gelöst dadurch.

Eigentlich sinds nur ein paar Zeilen Code die den Unterschied machen.. warum die wieder rausflogen aus der community weiß ich nicht. Mal kucken, evtl. pack ich das mal in ein Diff und stells ins rexseo wiki. Wers eilig hat: mal in Markus Lorchs fork kucken.. primär das auth plugin iirc.

[Thomas.Blum]

zur Vervollständigung:

Wers eilig hat: mal in Markus Lorchs fork kucken

oder einen alternativen Rewriter verwenden. RexSeo42 oder yrewrite

beste Grüße Thomas

[jdlx]

Noch einfacher alles.. ich hab einen PR an Jan Kristinus gesendet, der stellt den code für rexseo wieder her.

[Thomas.Blum]

Kannst du grad mal für mich erklären, warum rexseo die Artikel-Id nicht so früh bereitstellt wie es nur möglich ist? Ist ja nicht nur die Community betroffen sondern ggf. auch andere Addons.

Wir hatten doch grad deshalb diese 3 Levels eingeführt, damit die Addonnamen (siehe Erklärung vom Gregor) weniger eine Rolle spielen.

[jdlx]

Kannst du grad mal für mich erklären, warum rexseo die Artikel-Id nicht so früh bereitstellt wie es nur möglich ist?

Prämisse 1: Will man EPs nutzen, muß man seine Extensions vor den EPs regisriert haben, sonst kommen sie zu spät und werden nicht aufgerufen.
Prämisse 2: Addon-Plugins werden nach dem Eltern-Addon included.

Folge: Plugins können nicht EPs des Eltern-Addons nutzen wenn selbiges seinen Code zu seinem normalen inlcude Zeitpunkt ausführt.

Abhilfe: Ausführung des Addon codes nach hinten verschieben - da es keine autom. Trigger/EPs für das event "Addon incl. seiner Plugins includet" gibt, bleibt nur ein Kandidat: ADDONS_INCLUDED

Ist ja nicht nur die Community betroffen sondern ggf. auch andere Addons.

Könnte, klar.. wenn mir auch nichts konkretes bekannt ist.. aber: um nicht @ ADDONS_INCLUDED timing mäßig im Trüben zu fischen habe ich - faktisch ob der community als Anlaß - den EP REXSEO_INCLUDED eingebaut. Den kann natürlich jedes Addon nutzen das wissen will ob rewrite/resolve fertig sind.. und weiß dann mit Sicherheit woran es ist.

Wir hatten doch grad deshalb diese 3 Levels eingeführt..

Die levels dividieren das Problem aber nur durch 3.. innerhalb der levels hat man es wieder, und zu einem nachwievor (ADDONS_INCLUDED) eh meist unnötig späten Zeitpunkt. Was man z.b. daran ablesen kann, daß - sobald ich Jans PR gemerged hatte - andere Addons/Plugins timimng mäßig plötzlich probs machten.

[jdlx]

Abschließend: wer die community mit dem orig. RexSEO einsetzen will muß lediglich ein paar Zeilen patchen/hinzufügen.. oder eben die genannten Alternativen nutzen.

[Gregor.Harlan]

Prämisse 1: Will man EPs nutzen, muß man seine Extensions vor den EPs regisriert haben, sonst kommen sie zu spät und werden nicht aufgerufen.
Prämisse 2: Addon-Plugins werden nach dem Eltern-Addon included.

Folge: Plugins können nicht EPs des Eltern-Addons nutzen wenn selbiges seinen Code zu seinem normalen inlcude Zeitpunkt ausführt.

Abhilfe: Ausführung des Addon codes nach hinten verschieben - da es keine autom. Trigger/EPs für das event "Addon incl. seiner Plugins includet" gibt, bleibt nur ein Kandidat: ADDONS_INCLUDED

Bis hierhin sind wir wohl alle einer Meinung. Bloß gibt es eben drei Varianten von ADDONS_INCLUDED, und es geht nur darum, davon die "richtige" zu nehmen.

Könnte, klar.. wenn mir auch nichts konkretes bekannt ist.. aber: um nicht @ ADDONS_INCLUDED timing mäßig im Trüben zu fischen habe ich - faktisch ob der community als Anlaß - den EP REXSEO_INCLUDED eingebaut. Den kann natürlich jedes Addon nutzen das wissen will ob rewrite/resolve fertig sind.. und weiß dann mit Sicherheit woran es ist.

Man müsste nicht im Trüben fischen, wenn klar wäre, dass die Artikel-Id zum Zeitpunkt von ADDONS_INCLUDED/NORMAL gesetzt ist. Der Vorteil ist eben, dass es nicht von einem bestimmten Rewriter-Addon abhängt, und sich andere Addons allgemein gar nicht für den Rewriter interessieren müssen.
Man könnte natürlich auch sagen, dass die Artikel-Id in ADDONS_INCLUDED/LATE gesetzt ist, also alles eins weiter nach hinten verschieben. Aber dann würde man unnötigerweise einen Zeitpunkt auslassen und ist dadurch unflexibler. Ich sehe es auch eher als Aufgabe der Rewriter, dafür zu sorgen, die Artikel-Id möglichst früh zu setzen.

Die levels dividieren das Problem aber nur durch 3.. innerhalb der levels hat man es wieder, und zu einem nachwievor (ADDONS_INCLUDED) eh meist unnötig späten Zeitpunkt.

Wie schon damals festgestellt, verschieben die Levels natürlich nur das Problem. Leider ist damals niemand auf mein Wettangebot eingegangen, dass es "genügend weit" verschoben wurde. Natürlich kann sich auch herausstellen, dass ich mich irre, aber bisher sehe ich keinen konkreten, realen Fall, wo die Levels nicht ausreichen. Meiner Meinung nach unterliegt man da leicht einem gedanklichen Irrtum und der Unterschied von drei Runlevels gegenüber einem ist deutlich größer, als es so spontan den Anschein hat.
Leider habe ich auch, wie schon damals, immer noch das Gefühl, dass du nicht verstanden hast, weshalb deine EP-Vorschläge eine unnötige Einschränkung wären und ADDONS_INCLUDED eben nicht ein unnötig später Zeitpunkt, sondern der frühstmögliche ist. Ich versuche es nochmal am Beispiel rexseo: Dein Addon bietet EPs an, damit sich andere Addons und Plugins an verschiedenen Stellen einhaken können. Damit sie dies können, müssen sie aber überhaupt erstmal geladen worden sein. Und wenn du nicht einige ausschließen möchtest, musst du warten, bis auch wirklich alle geladen wurden -> ADDONS_INCLUDED. Würde rexseo bereits arbeiten, sobald die eigenen Plugins eingebunden wurden, könnten Addons, die nach rexseo kommen, deine EPs nicht mehr verwenden…
Natürlich wäre mir auch eine Lösung lieber gewesen, die das Problem ganz beseitigt, aber die sehe ich bisher nun mal nicht.

Was man z.b. daran ablesen kann, daß - sobald ich Jans PR gemerged hatte - andere Addons/Plugins timimng mäßig plötzlich probs machten.

Lass uns doch einfach die Stellen anschauen, woran es da scheitert, und wie man es beheben kann.

[jdlx]

Bis hierhin sind wir wohl alle einer Meinung. Bloß gibt es eben drei Varianten von ADDONS_INCLUDED, und es geht nur darum, davon die "richtige" zu nehmen.

Wie bereits gesagt: dieser "richtige" Weg - nota bene: 4.5 spezifisch - würde für mich bedeuten andere Addons/Plugins bezügl. EP timings neu anfassen zu müssen.. und testen. Auf der anderes Seite bietet RexSEO einen dezierten EP an der das timing sicherstellt und auch < 4.5 funktioniert. Der Code ist getestet, war schon mal in der community, und erfordert keine weiteren Anpassungen sonstwo.

Ich sehe es auch eher als Aufgabe der Rewriter, dafür zu sorgen, die Artikel-Id möglichst früh zu setzen.

Einerseits ja, andererseits: dieser Wunsch kollidiert auch wieder mit "Addons nicht ausschliessen", welche ja ihrerseits u.U. auch schon wieder über ADDONS_INCLUDED code ausführen müssen.. in dieser Hinsicht könnte man auch fürs Gegenteil plädieren: möglichst spät in ADDONS_INLCUDED.. Die Katze beißt sich in den eigenen Schwanz.

Bezügl. des Umstandes, daß ein rewrite ein ziemlich zentrales Thema innerhalb des ganzen frameworks und seiner Addons ist, könnte man z.b. für einen EP plädieren der in Bezug auf die rewrite Funktionalität spezifisch ist und allg. von rewritern gesetzt wird, die sich im core per URL_REWRITE einhängen: URL_REWRITE_DONE .. siehe unten

Und wenn du nicht einige ausschließen möchtest, musst du warten, bis auch wirklich alle geladen wurden -> ADDONS_INCLUDED. ..

Diese Anforderung gilt nicht immer/für jedes Addon. Bezügl. eines Rewriters, sprich einer im framework ziemlich zentralen Funktion: ja.. daher der explizite EP REXSEO_INCLUDED (faktisch oben angesprochenes URL_REWRITE_DONE, nur mit anderem Namen). In meinen Augen die sauberere Lösung und nicht 4.5 spezifisch..

Lass uns doch einfach die Stellen anschauen, woran es da scheitert, und wie man es beheben kann.

Danke fürs Angebot.. aber der Aufwand macht insofern wenig Sinn, da eine volle Unterstützung von RexSEO - sprich incl. Eingriff in die sitemap bezügl. der auth article - nicht allein mit dem passenden EP Zeitpunkt getan ist. Warum sollte ich z.b. den IMM xt (erster offensichtlicher Kandidat der ausstieg) und die diversen Plugins auf EARLY incl. < 4.5 compat umstricken, testen, wenn das Ergebnis doch nur die halbe Miete ist..

[Thomas.Blum]

Ich sehe es auch eher als Aufgabe der Rewriter, dafür zu sorgen, die Artikel-Id möglichst früh zu setzen.

Einerseits ja, andererseits: dieser Wunsch kollidiert auch wieder mit "Addons nicht ausschliessen", welche ja ihrerseits u.U. auch schon wieder über ADDONS_INCLUDED code ausführen müssen.. in dieser Hinsicht könnte man auch fürs Gegenteil plädieren: möglichst spät in ADDONS_INLCUDED.. Die Katze beißt sich in den eigenen Schwanz.

Könntest du hierfür ein Beispiel nennen? Ich versteh grad nicht, warum die Katze sich in den Schwanz beißt.

beste Grüße Thomas

[jdlx]

Könntest du hierfür ein Beispiel nennen? Ich versteh grad nicht, warum die Katze sich in den Schwanz beißt.

* Addon B führt seinen code @ ADDONS_INCLUDED EARLY aus
* Addon C will EPs von B benutzen, muß seinerseits aus irgendwelchen Gründen seinen code auch erst @ ADDONS_INCLUDED ausführen..
Da C hinter B included wurde, kommt es via EP nicht mehr vor B weil vor EARLY kein "slot" mehr ist..

[Gregor.Harlan]

Könntest du hierfür ein Beispiel nennen? Ich versteh grad nicht, warum die Katze sich in den Schwanz beißt.

* Addon B führt seinen code @ ADDONS_INCLUDED EARLY aus
* Addon C will EPs von B benutzen, muß seinerseits aus irgendwelchen Gründen seinen code auch erst @ ADDONS_INCLUDED ausführen..
Da C hinter B included wurde, kommt es via EP nicht mehr vor B weil vor EARLY kein "slot" mehr ist..

Auch wenn Addon C seinen Code auch in ADDONS_INCLUDED ausführen muss, kann es die EPs trotzdem schon direkt in der config.inc.php registrieren.

[jdlx]

Registrieren ja, aber was wenn der code selbst @ A_I arbeiten muß weil er erst etwas abwarten muß um selbst arbeiten zu können..

[der_bär]

Hallo zusammen,

hoppla, hätte nicht gedacht, dass das Thema solche Kreise zieht - aber für mich, der sich mit den inneren Abläufen von Redaxo und Addons jetzt nicht wirklich auskennt, ist die Diskussion sehr erhellend und auch lehrreich (und ein weiterer Tritt in den Hintern, mich damit genauer zu beschäftigen). Deshalb mein Dank an alle, die hier ernsthaft diskutieren und nach Lösungen suchen!

Danke an Jan für den Link zu dem Patch (und Danke an alle, die daran mitgearbeitet haben)!

Grüße in die Runde!
der_bär

[Gregor.Harlan]

Registrieren ja, aber was wenn der code selbst @ A_I arbeiten muß weil er erst etwas abwarten muß um selbst arbeiten zu können..

Welcher Code jetzt? Von C in den EPs von B? Oder anderer Code von C?
Es würde helfen, wenn du ein konkretes Beispiel hättest.
Der Code wird ja so oder so erst in A_I ausgeführt, weil B erst in A_I arbeitet, nur die Registrierung passiert eher.

[Thomas.Blum]

Könntest du hierfür ein Beispiel nennen? Ich versteh grad nicht, warum die Katze sich in den Schwanz beißt.

* Addon B führt seinen code @ ADDONS_INCLUDED EARLY aus
* Addon C will EPs von B benutzen, muß seinerseits aus irgendwelchen Gründen seinen code auch erst @ ADDONS_INCLUDED ausführen..
Da C hinter B included wurde, kommt es via EP nicht mehr vor B weil vor EARLY kein "slot" mehr ist..

Die Theorie ist klar. Ich hatte gehofft du zeigst ein Beispiel aus der Praxis.