Wichtige EP's fehlen (Artikel/Kategorie verschieben etc.)

[ghost]

Mir ist aufgefallen dass wenn ich ne Kategorie verschiebe oder einen Artikel zum Startartikel mache sich du URL bei SEO42 (vermutl. auch yRewrite) gar nicht ändert. Erst beim Cache löschen kommt die Url dazu.

Habe herausgefunden dass hier EP's fehlen damit der Rewriter weiss wann er seine Pathlist zu löschen hat. Das solle dringen rein fürs nächste Release finde ich. Also überall wo sich die URL ändern kann sollte ein EP dazu.

[tbaddade]

Zum Umwandeln eines Artikels

• ART_TO_STARTPAGE
• ART_TO_CAT
• CAT_TO_ART

Nach dem Verschieben (wobei die erst greifen, wenn der Article neu erstellt werden)

• CLANG_ARTICLE_GENERATED oder
• ARTICLE_GENERATED

[ghost]

Was heisst wenn der neu erstellt wurde? Kann ich die EPs dann nutzen damit die Pathlist gelöscht wird?

[tbaddade]

Die ersten drei EPs hast du bereits dabei. Funktionieren die nicht? https://github.com/RexDude/seo42/blob/master/classes/class.seo42_utils.inc.php#L31

Kann ich die EPs dann nutzen damit die Pathlist gelöscht wird?

Du brauchst nur einen von beiden zu verwenden. Ich habs aber auch nur überflogen. Sinnvoller wäre schon einen Extension Point ART_MOVED, CAT_MOVED zu haben. Oder eben nochmals ART_UPDATED und CAT_UPDATED zu notieren.

[ghost]

Doch die funzen :)

[ghost]

Ja ART_MOVED, CAT_MOVED fände ich auch sinnvoll.

[ghost]

Aber auch wenn Artikel/Kategorien kopiert werden sollte man das mitbekommen. Auch hier wird meine ich die Pathlist sonst auch nicht aktualisiert.

[staabm]

müsste ARTICLE_GENERATED nicht generell passen? also du generierst die pathlist neu sobald für irgendeinen article ein cache-file (neu)-generiert wurde..

ob es nun durch move/copy o.ä. passiert ist, ist dir ja eigentlich wurscht oder?

[tbaddade]

yrewrite hat den EP rausgenommen https://github.com/yakamara/redaxo_yrewrite/blob/master/config.inc.php#L152

[gharlan]

ARTICLE_GENERATED könnte glaube ich problematisch sein. Wenn noch kein Cache vorhanden ist, ich aber eine URL für einen Artikel verlange, beginnt zunächst der Rewriter. Der fordert dann für die Pathlist-Erzeugung (falls noch nicht vorhanden) die Artikeldaten an, und löst somit selbst ARTICLE_GENERATED aus. Und dann würde dadurch der Rewriter wieder starten und die Pathlist neu erstellen.

EPs für Verschieben/Kopieren sind wohl nötig an der Stelle.

[gharlan]

yrewrite hat den EP rausgenommen

Bzw. direkt auskommentiert eingefügt: https://github.com/yakamara/redaxo_yrewrite/commit/3cd4f34e8b7b09a6d66618170f62bbd97089f86a#diff-2fd9419e43731bf51d68405f5ededb25R33 ;)

[ghost]

Bzw. direkt auskommentiert eingefügt: yakamara/redaxo_yrewrite@3cd4f34#diff-2fd9419e43731bf51d68405f5ededb25R33 ;)

:smile: Da ist wohl schon jemand über diese Sache gestolpert ;)

Danke dudes :)

[tbaddade]

EPs für Verschieben/Kopieren sind wohl nötig an der Stelle.

Wäre ein Verschieben nicht auch ein aktualisieren also ein ART/CAT_UPDATED und ein Kopieren ein ART/CAT_ADDED?

[gharlan]

Kann man so auf jeden Fall sehen. Wenn jemand auf ART_ADDED zum Beispiel reagieren will, ist es ihm ja egal, ob der Artikel direkt neu erzeugt wurde, oder durch Kopieren.

[ghost]

Ich fände schon verschiedene EP's gut für jeden Fall halt eins. So kann man auch besser drauf reagieren was evtl. andere Einsatzszenarien angeht.

[gharlan]

Aber findest du nicht, dass demjenigen, der sich auf ART_ADDED registriert, dann zu Unrecht etwas entgeht? Beim Kopieren wird doch ein neuer Artikel erstellt.

[ghost]

Ja von der sicht eines Programmiers (reine Logik) ist es schon richtig, aber das impliziert halt das man weiss was REDAXO im Hintergrund macht. Und wie gesagt: vielleicht will ich ja explizit nur aufs kopieren reagieren und so würd ich aufs kopieren und normale hinzufügen reagieren bei ART_ADDED.

[ghost]

Ich versuche jetzt gerade ne Variante mit ARTICLE_GENERATED. Bei mir wird der EP aber nicht aufgerufen. Jemand ne Idee?

[gharlan]

Der EP wird aufgerufen, wenn der Cache für einen Artikel neu erstellt wird. Das passiert aber nicht direkt bei der Aktion, da wird nur der Cache gelöscht, sondern erst sobald der Cache wieder benötigt wird (Nutzung von OOArticle/OOCategory).

[ghost]

Achso ich verstehe. Dann ist es glaub ich eher unbrauchbar für meinen Fall. Gibts einen Weg herauszufinden wann immer sich ein Artikel/Kategorie geändert hat sonst? Z.B. wenn man auf CAT_UDPATED reagiert dann gilt das zwar für Katagorie umbennenen aber nicht für Katagorie verschieben, obwohl da ja auch ein Update statfindet, oder?

Also wann immer sich eine Url geändert hat, will ich das irgendwie mitbekommen.

[gharlan]

Z.B. wenn man auf CAT_UDPATED reagiert dann gilt das zwar für Katagorie umbennenen aber nicht für Katagorie verschieben, obwohl da ja auch ein Update statfindet, oder?

Das ist ja genau das, was Thomas anmerkte und wo ich dann zugestimmt habe. Verschieben ist auch ein "Update", und Kopieren ist auch ein "Erstellen".

[ghost]

Yup, aber ist ja so nicht im Core? Will nur wissen ob ich jetzt irgendwie ohne Patch auskommen kann zuerstmal...

[gharlan]

Achso. Wahrscheinlich schwierig. Bzw. kommt drauf an, wie hacky es sein darf. Du kannst dir natürlich die Backend-URL-Parameter anschauen, und daran ausmachen, ob wohl gerade verschoben/kopiert wird, und dann über irgendeinen späten EP deine Pathlist neu erstellen.

[ghost]

Wirklich hacky ;) Bei Kategorie verschieben wäre das dann? Sehe da nur save = 1...

[gharlan]

rex_post('movecategory', 'bool') ist entscheidend.

Hier alle Postparameter beim Kopiervorgang:

[tbaddade]

Ich hab noch mal drüber nachgedacht. Es könnte durchaus sinnvoll sein, dass man auch nur auf einen kopierten/verschobenen Artikel reagieren möchte. Bin daher an der geeigneten Stelle für jeweils beide EPs, also MOVED und UPDATED sowie COPIED und ADDED.

[dergel]

finde ich auch gut ..

[ghost]

Wobei es jetzt aktuell für mein Use Case nicht mehr relevant ist, da ich ne Lösung ohne diese EPs gefunden habe.