[GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

Klenkes · 06. September 2011 09:30

Ich werd nicht mehr... Das ganze Yoga und autogenes Training, alles umsonst. Nach Stunden der Fehlersuche und Frustration war ich so aggressiv...
Naja! Etwas TV-Berieselung und eine Mütze Schlaf...

Das Phänomen ist bekannt.
Neue Seite anlegen, ist weder im Backend noch im Frontend sichtbar.
Cache löschen und da ist die verflixte Seite.
Seite löschen oder ändern funktioniert allerdings prima.

Nun läuft hier aber PHP 5.2.10-pl0-gentoo und die Timezonegeschichte sollte gar nicht greifen. Setze ich die Timezone auf Europe/Berlin passiert genau nichts.(Server sitzen angeblich in Saarlouis) Lasse ich Timezone leer, genau das Gleiche.

Ich hab heute auch schon die ganze Nacht abgewartet, ob heute morgen der neue Content seine freche Nase zeigen würde, aber auch nichts. Cache geleert - da isser.
Debug zeigt keine Fehler und auch sonst nichts Ungewöhnliches.

Es ist die Seite eines Kunden die bisher mit CMSMS 1.8.2(vorher 1.4.1) lief und ich unter einer Subdomain auf 1.9.4.3 upgedated habe. Das Projekt verlässt sich schwer auf Cataloger und hat ca. 40 Kategorien mit etwa 400 Artikel im Angebot. Ich war schon froh, dass das mit dem Cataloger und 1.9.4.3 "überhaupt" funktionierte.
Im Übrigen ist es egal ob Content-Page, Itempage oder Sectionheader.

Ich weiß es gibt diesen UDT, der jedesmal den Cache löscht, wenn man neuen Inhalt hinzufügt. Möchte ich jedoch nur ungern so machen. Caching hat ja schon seinen Sinn.

Ich weiß nicht mehr weiter - mir fällt nichts mehr ein.
Ich brauche einen frischen Blick von euch.

Edit: Lustig! Lege ich weitere neue Seiten an, erscheint die vorherige plötzlich, aber die Neue noch nicht. Es ist immer die gerade zuletzt angelegte unsichtbar.

--
Bernd

Beitrag geändert von Klenkes (06. September 2011 09:38)

Andynium · 06. September 2011 11:14

Hmm, hast du mal die Einträge in der Datenbank verglichen?

Klenkes · 06. September 2011 11:33

cyberman schrieb:

Hmm, hast du mal die Einträge in der Datenbank verglichen?

Meinst du ob die neue Seite in der DB ist?
Yepp! Ist sofort drin.

Weitere 1 1/2 Stunden des Rumfimmelns brachten folgende Fakten zum Vorschein:
Manuelles Löschen der Dateien in template_c bringt rein gar nichts.
Es passiert wohl in tmp/cache/contentcache.php

Es muss wohl mit der Hierarchie zu tun haben, und damit wohl auch mit dem Cataloger. Cataloger ist jetzt deaktiviert.

Dann, manchmal funktioniert es wieder genau 1 Mal und dann wieder nicht mehr. Erst wenn ich eine andere Seite bearbeite und speichere ist die neue Seite da.

Irgendwie ist da schon ein Muster drin... doch nur welches?

Beitrag geändert von Klenkes (06. September 2011 11:42)

Klenkes · 06. September 2011 12:02

cyberman schrieb:

Hmm, hast du mal die Einträge in der Datenbank verglichen?

Grade mal 2 Datensätze verglichen.

1x Seite sichtbar und 1x Seite noch nicht sichtbar.
Ergebnis: Alles stimmt. content_id, hierarchy und item_order usw... alles korrekt durchnummeriert.
Ich hab selbst kontrolliert ob sich an dem Datensatz was verändert hat, nachdem die Seite sichtbar wurde.
Nein.

Jetzt vergleiche ich mal die contentcache.php

piratos · 06. September 2011 12:20

Ahnliche Probleme gab es schon vor 6 Jahren

Man sollte bei der Anlage, Bearbeitung oder der Löschung von Inhalten nach der daraus folgenden DB Speicherung automatisch und rigoros die contentcache.php löschen, was ja auch logisch ist, denn es könnten sich ja Daten welche die Hierarchie betreffen geändert haben und eigentlich nur dann.

Der Versuch das über einen Zeitstempel zu erledigen scheint offenbar nicht regelmässig zu funktionieren und ist auch vollständig überflüssig.

Klenkes · 06. September 2011 12:28

Klenkes schrieb:

Jetzt vergleiche ich mal die contentcache.php

Mal 2 Versionen davon verglichen.
Neu Seite mit dem alias: 333-2 content_id: 600

Seite im Backend nicht sichtbar: cms_tree _tags";a:2:{s:2:"id";i:0;s:5:"alias";s:5:"333-2";}
Seite im Backend dann sichtbar: cms_tree _tags";a:2:{s:2:"id";i:600;s:5:"alias";s:5:"333-2";}

Während die Seite nicht sichtbar ist, ist i:0
Das kann nicht stimmen.

@piratos:

Hier klicken, um den Code zum Kopieren zu markieren

   $gCms = cmsms();
   $contentops =& $gCms->GetContentOperations();
   $contentops->ClearCache();

Was würde dieser UDT mit einem Event verknüpt tun?
Den ganzen Seitencache löschen?
Kann man dies auch mit contentcache.php tun?

Efferd · 06. September 2011 13:47

so habe ich 200+ seiten angelegt.... oft kommt man auch durcheinander und legt eine Seite doppelt an *g* deshalb habe ich zum Schluss immer eine Seite erstellt, die ich danach wieder gelöscht habe.

Ich dachte, das liegt daran, dass ich zu viel in meinem CMS und der htaccess verstellt hatte ;o)

piratos · 06. September 2011 14:34

ClearCache sollte normalerweise die contentcache.php löschen.

Hier klicken, um den Code zum Kopieren zu markieren

if (is_file(TMP_CACHE_LOCATION . '/contentcache.php'))
        {
            unlink(TMP_CACHE_LOCATION . '/contentcache.php');
        }

        @touch(cms_join_path(TMP_CACHE_LOCATION,'index.html'));
....

ich frage mich warum man für die Anlage der index.html über touch join_path verwendet.

Würde daher mal das probieren:

Hier klicken, um den Code zum Kopieren zu markieren

if (is_file(cms_join_path(TMP_CACHE_LOCATION, 'contentcache.php'))) {
    $ok = unlink(cms_join_path(TMP_CACHE_LOCATION, 'contentcache.php'));
    if (!$ok)  die('contentcache.php wurde nicht gelöscht'); // den Teil nach Test entfernen
}

NaN · 06. September 2011 15:16

Sollte man diese contentcache-Geschichte aus Performancegründen nicht ohnehin deaktivieren?

Klenkes · 06. September 2011 15:23

piratos schrieb:

Hier klicken, um den Code zum Kopieren zu markieren

if (is_file(cms_join_path(TMP_CACHE_LOCATION, 'contentcache.php'))) {
    $ok = unlink(cms_join_path(TMP_CACHE_LOCATION, 'contentcache.php'));
    if (!$ok)  die('contentcache.php wurde nicht gelöscht'); // den Teil nach Test entfernen
}

Hey hey hey!
Erste Tests sehen gut aus.
Weitere Tests folgen nun...

Klenkes · 06. September 2011 15:42

Klenkes schrieb:

piratos schrieb:
Hier klicken, um den Code zum Kopieren zu markieren
if (is_file(cms_join_path(TMP_CACHE_LOCATION, 'contentcache.php'))) {
    $ok = unlink(cms_join_path(TMP_CACHE_LOCATION, 'contentcache.php'));
    if (!$ok)  die('contentcache.php wurde nicht gelöscht'); // den Teil nach Test entfernen
}
Hey hey hey!
Erste Tests sehen gut aus.
Weitere Tests folgen nun...

Das isses! Das war's! So mach ich's.
Als UDT "clearcache" mit ContentEditPost verknüpft scheinen die Gremlins vertrieben zu haben.

Danke piratos!
Ich kann wieder an eine Zukunft glauben wink

piratos · 06. September 2011 15:57

Ich unterstelle mal das der Pfad in verschiedenen Klassen in manchen Situationen schlichtweg falsch ist, contentcache.php wird dann als nicht vorhanden ausgewertet und dann auch nicht gelöscht.

Bug in mehreren Files.

NaN · 06. September 2011 16:23

Kann da keinen Fehler finden.
Überall wo contentcache oder TMP_CACHE_LOCATION im Spiel ist, sieht alles korrekt aus.
Beim Erstellen neuer Inhalte wird schlichtweg weder ClearCache() ausgeführt noch die explizit die contentcache.php gelöscht.

NaN · 06. September 2011 17:14

Der Fehler steckt in der Reihenfolge... roll
Beim Speichern von Inhalten werden zunächst über die Funktion ValidateData() die eingegebenen Inhalte auf ihre Richtigkeit geprüft. Dabei wird GetHierarchyManager() aufgerufen. Der wiederum ruft GetAllContentAsHierarchy() auf. Diese Funktion überschreibt die contentcache.php mit den bisher vorhandenen Daten. Zu diesem Zeitpunkt ist der Inhalt aber noch nicht gespeichert! D.h. er hat noch garkeine ID! Daher wird die ID 0 gespeichert. Erst danach wird der Inhalt in die DB geschrieben. Zu sehen in /admin/addcontent.php Zeile 157:

Hier klicken, um den Code zum Kopieren zu markieren

$error = $contentobj->ValidateData();
if ($error === FALSE)
{
    $contentobj->Save();
    ...

Das ist offenbar ein genereller Fehler im CMS und es wundert mich, dass der nicht öfter auftaucht. Er müsste immer dann auftauchen, wenn man nicht explizit nach "flachen" URLs verlangt (also immer alles hierarchisch hat - was ja standard bei CMSms ist).

Das Datum der letzten Änderung wird erst beim Schreiben in die DB festgestellt (was auch korrekt ist) aber dadurch liegt es nach dem Erstellungsdatum der contentcache.php. Wenn dieser Prozess zu langsam abläuft (Zeitraum zwischen Schreiben der contentcache.php und Schreiben der DB Inhalte > 1s ... weiß jetzt nicht genau wie PHP den Timestamp rundet) - wovon bei einer großen Internetpräsenz und externer DB manchmal leider auszugehen ist - dann werden die Inhalte immer falsch aus der contentcache.php geladen anstelle aus der DB. *

Das würde erklären warum es scheinbar sporadisch auftaucht.

* Edit: Naja, stimmt nicht ganz. Der Absatz ist Blödsinn. Aber der erste Teil stimmt, und da liegt meiner Menung nach auch die Ursache.

Klenkes · 06. September 2011 17:50

NaN schrieb:

Das würde erklären warum es scheinbar sporadisch auftaucht.
* Edit: naja, stimmt nicht ganz. aber der erste teil schon.

Eine geniale Schlußfolgerung, Mr. Holmes.

Sporadisch trifft es schon. Manchmal konnte ich 2 Seiten anlegen und alles funktionierte, und dann ging es wieder nicht. Kein wirkliches Muster! Bei über 400 Seiten kann die Sekunde schon überschritten werden.

Aber das wäre ja ein klassischer Bug?
(Oh Nein. Ich muss das alles irgendwie formulieren...)

NaN · 06. September 2011 19:23

Naja stimmt sowieso noch nicht ganz. Hab was übersehen. Der Fehler tritt schon etwas früher auf und dürfte nur diejenigen betreffen, die die Option "Automatisch Seiten-URLs erstellen" in den globalen Einstellungen auf ja und die Option "Automatisch erstellte URLs sind flach" auf nein gesetzt haben. Wie sehen bei Dir diese Einstellungen aus?

Mal davon abgesehen, dass es ein Fehler ist, die contentcache.php zu schreiben, bevor die Inhalte gespeichert wurden, müsste sich der Fehler beim nächsten Schritt wieder von selbst relativieren, da ja das Änderungsdatum der Inhalte nach dem Datum der contentcache.php liegt. D.h. die Datei müsste korrekt wieder mit den Daten aus der Datenbank überschrieben werden. Warum es das manchmal nicht tut, verstehe ich noch nicht ganz.

Ich suche weiter.

NaN · 07. September 2011 22:04

Hast Du vielleicht noch ein paar Tuning-Tipps umgesetzt?
Z.B. diesen hier: http://www.cmsmadesimple.de/forum/viewt … 9690#p9690

Klenkes · 07. September 2011 08:48

NaN schrieb:

Naja stimmt sowieso noch nicht ganz. Hab was übersehen. Der Fehler tritt schon etwas früher auf und dürfte nur diejenigen betreffen, die die Option "Automatisch Seiten-URLs erstellen" in den globalen Einstellungen auf ja und die Option "Automatisch erstellte URLs sind flach" auf nein gesetzt haben. Wie sehen bei Dir diese Einstellungen aus?

So sind meine Einstellungen:
Automatisch Seiten-URLs erstellen = Nein
Automatisch erstellte URLs sind flach = Nein

NaN schrieb:

Hast Du vielleicht noch ein paar Tuning-Tipps umgesetzt?
Z.B. diesen hier: http://www.cmsmadesimple.de/forum/viewtopic … 9690#p9690

Da bin ich mir nicht mehr ganz sicher... Unsichere Sachen mache ich aber nie.
Beim Update auf 1.9.4.2 wurde die class.contentoprations.inc.php aber sowieso wieder überschrieben.

Edit: Ich hatte weder vorher(1.8.2) noch jetzt(1.9.4.3) eine modifizierte class.contentoprations.inc.php im Einsatz.

Beitrag geändert von Klenkes (07. September 2011 09:06)

Forum für CMS/made simple

#1 06. September 2011 09:30

[GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#2 06. September 2011 11:14

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#3 06. September 2011 11:33

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#4 06. September 2011 12:02

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#5 06. September 2011 12:20

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#6 06. September 2011 12:28

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#7 06. September 2011 13:47

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#8 06. September 2011 14:34

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#9 06. September 2011 15:16

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#10 06. September 2011 15:23

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#11 06. September 2011 15:42

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#12 06. September 2011 15:57

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#13 06. September 2011 16:23

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#14 06. September 2011 17:14

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#15 06. September 2011 17:50

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#16 06. September 2011 19:23

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#17 07. September 2011 22:04

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

#18 07. September 2011 08:48

Re: [GELÖST] Neuer Content nicht sichtbar! Aber Timezone fixt es nicht!

Fußzeile des Forums