autoupdate urls from url addon 2.x #289
Conversation
|
Relevant sind Zeilen 61 bis 77. Bei den anderen habe ich unnötige Leerstellen / Tabs entfernt. |
|
Braucht noch diesen PR: #277 |
|
Du meinst im PR #277? Ja, das ist korrekt und wird benötigt. Dadurch kann man feststellen, ob das Datum der letzten Änderung des Datensatzes im URL Addon neuer ist als das Datum der letzten Indexierung. Nur dann erfolgt eine erneute Indexierung. Lässt man den Teil weg, würde jedes mal die komplette URL Tabelle reindexiert werden. Ich habe hier 800 URLs am Start. In so einem Fall wäre das Backend erst mal ein paar Minuten nicht mehr erreichbar wenn man den Code weg lässt. Vielleicht noch als Hintergrundinfo: das URL Addon ruft den EP nicht nur für die geänderte, neue oder gelöschte URL auf. Das URL Addon befüllt jedes mal die komplette URL Tabelle neu. Bei meinen 800 URLs wird der EP 801 mal aufgerufen. 1 mal zum Löschen der URL Tabelle und dann 800 mal für jede einzelne URL. |
Das stimmt so nicht. Die Urls können pro Datensatz (ein Datensatz kann mehrere Urls besitzen), pro Gruppe (wenn sich der Artikelname in der Struktur ändert) oder komplett neu erstellt werden (Cache löschen zum Bsp.). |
|
Danke für den Hinweis, Thomas! Da hast du natürlich Recht. Der Punkt für uns ist, dass uns der EP nicht auf eine einzelne Änderung hinweisen kann die es zu reindexieren gilt. Deshalb setzen wir im Commit den Trigger und arbeiten ihn ganz zum Schluss mit dem letzten EP ab. |
|
D.h. du brauchst das Datum in der index-tabelle, damit nur wirklich geänderte reindexiert werden, |
|
Ja, ganz genau so ist es. Der Config Value existiert auch nur für die Zeit in der das Skript läuft. Denkbar wäre auch noch ein Limit einzuführen, so dass z.B. maximal 50 Seiten auf einmal indexiert werden. |
|
Meine Idee war ja noch, das Reindexieren von dem Request zu lösen, in dem eben nur der config-Value auf einen timstamp in der Zukunft gesetzt und später ausgelesen wird. Wie ist das denn, wenn man übliche Änderungen mit dem URL-AddOn vornimmt? Wie oft würde die Reindexierung dann triggern? Oder ist sie dann immer so "klein", dass es nicht stört? |
|
Üblicherweise merkt man gar nicht, dass im Hintergrund etwas passiert. Es ist genau so wie wenn ein Artikel geändert wird. Nimmt man Änderungen am URL Addon vor, kann es in wenigen Fällen die Performance drücken. Warum? Angenommen die generierten URLs eines Profils mit vielen Datensatzen ändern sich alle. Dann werden auch alle URLs neu indexiert, da der Bezug zur alten URL nicht hergestellt werden kann. Genauso auch beim Erstellen eines neuen Profils mit vielen Datensätzen. Alles andere läuft so performant, dass man es nicht merkt. |
|
Warum hast du eigentlich einen config-Value genommen? Wäre nicht eine statische Member-Variable das Richtige? |
|
Falls die Skriptlaufzeit überschritten wird, wird die Indexierung beim nächsten mal beendet wenn es in der Config gespeichert wird. Als Member Variable kann etwas verloren gehen. Wenn dir aber eine Member Variable lieber ist mach ich das. |
|
Ist ja schon mal ein Argument. Es geht nur in nachgeordneter Linie darum, was mir lieber ist. Erstmal zählen Argumente. |
Fürs Protokoll: Das wäre vielleicht jedoch wünschenswert, wenn man was davon merkt, das auch einordnen zu können. Beim Ändern von URL-Profilen und beim Ändern von YRewrite-Einstellungen wird eine clientseitige Indexierung angestoßen, indem per GET alle URLs neu angefragt werden. Bei bspw. 300 URLs à 150ms ergibt das 45 Sekunden. Der Entwickler bekommt darüber jedoch keine visuelle Information - es sieht so aus, als wäre YRewrite oder URL einfach langsam oder hätte sich aufgehängt.
|
|
@alxndr-w: Da wir uns in den EP RESPONSE_SHUTDOWN reinhängen, lässt sich da nichts mehr einblenden. |
Mit diesem Update können URLs des URL 2.x Addons automatisch indexiert werden.