Artikelinformationen speichern vs. Cache

Deutsches Forum
1

Hallo,

wir verwenden ein oxid EE 4.6.5 und haben seit kurzem das Problem, dass das Speichern von Artikelinformationen im “Frontend” (isAdmin() == false) nur beim ersten Mal funktioniert, anschließend nicht mehr. Wir haben herausbekommen, dass es etwas mit dem Caching zutun haben muss, da es immer wieder dann geht, wenn wir den Cache löschen.

Das ganze sieht zum Schluss so aus:

		
$oArticle->assign( $aParams );
$oArticle->setArticleLongDesc( $this->_processLongDesc( $aParams['oxarticles__oxlongdesc'] ) );
$oArticle->setLanguage( $this->_iEditLang );
$oArticle = oxUtilsFile::getInstance()->processFiles( $oArticle );	
$oArticle->save();

Im Backend funktioniert das ganze ja einwandfrei, dort gibt es ja auch keinen Cache bzw. wird dieser immer geleert. Immer den Cache bei einer Änderung zu leeren ist aber keine annehmbare Lösung :wink:

Hat jemand von euch schon mal ein ähnliches Problem gehabt, beispielsweise bei einem Tool oder Backend?

Wir leiten unsere View-Klassen von der oxUBase ab und haben zusätzlich das Rechte-System angepasst für diesen Bereich, damit nur autorisierte Benutzer Zugang haben.

2

Hallo,

schwer zu sagen, vor allem, wenn so grundlegende Dinge angepackt wurden. Willst Du vielleicht besser mal beim Support nachfragen, damit die Jungs sich das mal am Objekt anschauen können?

Gruß

3

Hi,

Wenn du im Admin etwas speicherst wird Grundsätzlich der Cache(Frontend) geleert(Außer bei der Einstellung (Cache nur beim Logout Löschen).
Für das Backend gibt es keinen Cache, alles wird aktuelle aus der DB gehohlt.

Wenn nun irgendwer etwas im FE am Artikel ändert, wird also niemals die Function die für das Resetten des FE Caches verantwortlich ist, aufgerufen. Diese sind nur im Admin bereich zu finden:
Schaumal bei admin/oxadminview fnc:: save() && resetContentCache().

Du willst nun aber das sich der Cache nicht löscht aber die Daten aktualisieren, was verständlich ist.
Das geht mit Bordmitteln nicht.
Lösung 1:
Die Inhalte die im FE änderbar sind werden mittels smarty und oxid_include_dynamic auf die Seite gehohlt. Hierfür muss ggf. oxcache angepasst werden.
Vorteil:
Seite Bleibt zum Größten Teil gecached/ ist schneller als ohne Cache.
Nachteil:
Nicht so schnell wie voll gecached.
Lösung 2:
Du löscht bei Änderung am Artikel den Cache für den Artikel(über tbl::oxcache).
Vorteil:
Die Seite ist schneller als die partial gecached Seite.
Nachteil:
Der User die Die Seite nachdem Cache Löschen als erster betritt wartet länger.

Bei beiden Lösungen hast du das Problem das wenn die Information die geändert wurde ebenfalls auf anderen Seiten zu finden sind, werden diese aber nicht resettet.