bis 5.4.4 hatte ich beim Warmup immer genau zwei “warnings”, wegen zwei inaktiver / nicht zugewiesener Shopseiten - ist ja auch so ne Unsitte, inaktive Shopseiten aufzuwärmen…
Jetzt nach dem Update auf 5.4.5 erhalte ich für einmal Warmup satte 42 Einträge im Log - wechsel zwischen “Error” und “Critical.” - also 40 zusätzliche!
Und zwar allesamt bezogen auf 20 Blog-Einträge, die ich anfang des Jahres gelöscht hatte!
Im Januar hatte ich mal groß umgeräumt: Inhalte vom “Hauptshop” wurden gelöscht, und “Inhalte” vom Subshop wurden dem Hauptshop zugewiesen, und danach der Subshop gelöscht. Bis einschließlich 5.4.4. gab es Null Probleme - und nun einmal Cach-Aufwärmen 40 Einträge im Log?
Das sind allesamt Blogs, die Shopware nun “aufwärmen” will, die schon seit fast 6 Monate im Backend gelöscht sind nun nicht mehr angezeigt werden.
Was ist das für ein Murks - und warum zeigt der Log-Eintrag im backend nur eine “gefilterte” Meldung an?
Jetzt würde ich gerne mal wissen, wie ich die 40 Meldungen - also 20 Blogeinträge - wieder los werde
Edit: Changed error handling of missing blog articles or CMS pages, the configured setting in the backend is now respected
Edit2: in s_blog sind die Einträge nicht mehr vorhanden, wohl aber in s_core_rewrite_urls - macht ja keinen Sinn, die Urls zu gelöschten Blogeinträgen in den rewrite-urls stehen zu lassen und dann auch noch aufwärmen zu wollen…
Edit3: Da müsst Ihr noch mal ran… alle “gelöschten” Blogbeiträge aus der s_core_rewrite_urls gelöscht => Fehler weniger. Zwei Blogeinträge haben den Status “inaktiv” => Die werfen jeweils einen Error und einen Critical. Weiter habe ich noch einen auf Shopseite “/hilfe/support” - der ist deaktiviert und “/aktuelles” ebenfalls deaktiviert und auch “Error” und “Critical”. Da scheint “… now respect” in 5.4.5 ja wohl sowas von in die Hose gegangen zu sein
Edit4: Würde ich die SEO-Urls via Cron erstellen lassen, würden wohl auch die Blogs etc. aus der Tabelle verschwinden - wie geschrieben: würde - warum passiert das dann nicht bei der “Aktualisierungsstrategie: Manuell” ???
Hab dafür mal ein Ticket aufgemacht: Shopware Issuetracker
Das die URLs erstmal nicht freigegeben werden ist korrekt und auch so gewollt, dass brauchst du ja bspw. wenn ein Artikel umbenannt wird. Für 5.5 ist geplant, dass auch nur aktive URLs aufgewärmt werden, damit hätte sich das zweite Problem dann eh erledigt.
Habs grad als Edit 4 eingetragen.
Aber nochmal: Die Blog waren gelöscht, würde die „Seo-Aktualisierung“ über den Cron laufen, würden auch die alten Einträge zu den Blog gelöscht werden. Jetzt habe ich aber die Strategie „Manuell“ und den Cron deaktiviert. Das Problem sind ja auch nicht „Artikel“ - das Problem sind verwaiste Blogeinträge. Die werden ja auch über die ID in der Tabelle abgelegt - und da wäre eine Umbenennung ja egal Das „Problem“ beim Warmup ist ein nachgelagertes. Ich dachte „SEO-Urls“ generieren „Manuell“ würde sich so verhalten, wie ein Cron, aber offenbar liege ich hier falsch. Der „Cron“ scheint wohl alte Blog-Einträge zu löschen, was beim „manuellen Erstellen“ nicht passiert. Wieder was gelernt Nachdem der Cron einmal lief, bleiben 5 Paarungen „Critical / Error“ - 3 Seiten und zwei Blogs. Naja - vor dem Update war es zu den Seiten jeweils nur ein Warning und ohne Blog.
Noch eine letzte Fragerunde:
Die Argumentation mit “Umbenennen” etc. kann ich nachvollziehen, darum geht es aber nicht.
Wird ein “Objekt” - sei es ein Artikel, ein Seiteneintrag oder Blogeintrag - gelöscht, ist die Url dauerhaft unbrauchbar, somal die Einträge in org_path “sViewport=detail&sArticle=ID”, “sViewport=custom&sCustom=ID” oder “sViewport=blog&sAction=detail&sCategory=cID&blogArticle=ID” sind - also eindeutig. Ist das “Objekt” gelöscht, ist auch der Verweis durch die “ID” obsolet. Warum werden beim Löschen von “Seiten”, “Blogeinträge” und “Artikel” nicht gleich die paar Einträge aus der “s_core_rewrite_urls” gelöscht? Warum was altes aufheben, warum für so einen Einzeiler im Model gleich einen ganzen Cron drauf ansetzen? Wer denkt sich sowas krankes aus? Sorgt doch immer nur für nachgelagerte Probleme so ein “Vorgehen”.
Was genau macht “leeren” von “Index SEO-Urls Cache für SEO-Routen und Index” unter Performance / Cache denn genau? Nur verwaiste löschen? Alle “alten” löschen => also Umleitungen, etc?
ich glaube mich zu erinnern dass ich in der Datenbank rumgefummelt habe: s_core_rewrite_url genau die gelöscht die „bemängelt“ wurden. Genau wie Du es im letzten post beschreibst.
Hab mir grad noch einmal CleanUp angeguckt (Cron) - da werden leider nur Einträge von Blog-Artikel gelöscht, wenn die Blog-Kategorie nicht mehr vorhanden ist. Nicht aber Blog-Artikel die gelöscht wurden wenn die Kategorie aber noch vorhanden ist. Der Weg über den Cron hilft da auch nicht weiter.
Warum Einträge nicht gleich aus der s_core_rewrite_url gelöscht werden, wenn im Backend der Blogeintrag gelöscht wurde, bleibt mir ein Rätsel. Ein *popeliges* zusätzliches Delete im Backend-Controller sollte doch wohl kein Problem sein
Hole den Thread noch mal hoch…bei uns auf SW 5.6.6 das gleiche: Beim Cache aufwärmen gibt es einen Fehler, das Aufwärmen läuft aber muter weiter. Nur im html Verzeichnis des Cachordners füllt sich nichts auf!
Im Systemlog steht nichts drin, wenn ich alle Seitentypen auf einmal aufwärmen will. Wähle ich einzeln z.B. nur die Kategorien aus steht im Log wengstens etwas:
CRITICAL Category page not found
Hier wäre es natürlich hilfreich zu erfahren welche Kategorie den Fehler verursacht. Genau das gleiche bei den statischen Seiten: Custom page not found -> Welche denn?
Das „Problem“ beim Warmup ist ein nachgelagertes. Ich dachte „SEO-Urls“ generieren „Manuell“ würde sich so verhalten, wie ein Cron, aber offenbar liege ich hier falsch. Der „Cron“ scheint wohl alte Blog-Einträge zu löschen, was beim „manuellen Erstellen“ nicht passiert. Wieder was gelernt 
Nachdem der Cron einmal lief, bleiben 5 Paarungen „Critical / Error“ - 3 Seiten und zwei Blogs. Naja - vor dem Update war es zu den Seiten jeweils nur ein Warning und ohne Blog. 