Seit einigen versionen habe ich das problem das es ab und an vorkommt das ein Artikel nicht mehr aufrufbar ist. Leider konnte ich das Problem nicht eingrenzen da kein Fehler in de Logs erscheint.
Zur Abhilfe lösche ich den Artikel über die Api und erstelle ihn neu, dann ist alles wieder in ordnung. Leider kommt es dennoch selten zu dem Probelm das sich der Artikel nicht über die API löschen lässt. Manuell über das Backend klappt es dann aber ohne Probleme.
Da ich dies aber gerne automatsieren will würde ich das nun über SQL lösen, bzw gibt es alternativen?
Welche Tabellen muss ich berücksichtigen um ein rückstandsfreies löschen durchzuführen.
- s_articles
- s_articles_attributtes
- s_articles_categories
- s_articles_categories_ro ??
- s_articles_details
- s_articles_img
- s_articles_prices
- s_articles_top_seller_ro ??
- s_articles_translations
- s_search_index ??
- s_core_rewrite_urls ??
Betrifft es nur neue Artikel? Ist eine Relation von s_articles zu s_articles_attributtes da?
Nein es betrifft immer alte bestehende Artikel die aber regelmässig updates bekommen, Stock, Preis, Lieferzeit und andere Details, je nach Änderung.
Alle Artikel haben bei uns eine Relation zu s_articles_attributes.
Da ist mir auch aufgefallen das scheinbar die Realtion nicht mehr zu s_articles geht sondern über s_articles_details, da in s_articles_attributes.articleID NULL gesetzt wir bei neuanlage. Was aber nicht für die 503 verantwortlich ist.
Benenne, oder lösche den Ordner /var/cache/ production_XXX mal um. So wird ein neuer erstellt und du kannst zunächst ausschließen, ob es am cache liegt.
Hatte ich im Dezember schon mal getestet, erfolglos getestet. Werde es aber nochmals machen. Damals vermutete ich einen Zusammenhang mit dem Update von 5.5.10 auf 5.6.4. Bis letzte Woche war damit ruhe, nun aber 3 Artikel erneut.