CONTENIDO Forum

Hi,
bei einer Mandanten-Installation wird eine ähnlich lautende Kategorie nicht als Link akzeptiert und ein ursprünglicher Alias wird nicht zurück gesetzt.

Folgendes ist in einem Mandanten einer Contenido-Installation:
Eine Kategorie z.B. namens "category" sollte parallel eine Kategorie namens "category2" bekommen, jeweils auch mit Artikelnamen z.B. "datei" und "datei2".
Das AMR hat "category2" wegen ähnlich lautender URL auf "category" geleitet.
Nun habe ich die Einstellung von 75% auf 100% gesetzt, damit das Zeichen "2" als Unterschied in der URL vom AMR wahrgenommen wird.
Nun findet es aber die Seite nicht mehr und leitet auf die Startseite um.

Rufe ich den Link über /front_content.php?xxx=yyy auf, dann erscheint die Seite und in dem Breadcrump Menü wird als Alias "category 2.x" angezeigt, das als erstes bei der Kategorie- und Seiten-Erstellung eingegeben wurde.
Das heißt, alle späteren Änderungen der Alias-Namen wurden nicht mitgezogen im URL-Building.
Benütze ich die Bereinigungsfunktion und leere Con_code, Cache und auch im AMR die Alias, passiert trotzdem nichts.

Nun gab es noch einen Fehler in einem Menü-Modul, dort war das "MR" nicht eingetragen und im Menü erscheinen dann Links wie .../xxx.html?a=100&level=1
Das ist meistens der Fall, wenn im Modul oder einem der Menü-Funktions das MR nicht eingetragen wurde.
Das hatte ich gefunden und nachgetragen, trotzdem erscheint immer noch dieses ?a=100&level=1 obwohl ich Cache und Con-Code geleert hatte.
Es ändert sich nichts.
Alle anderen Menü-Module funktionieren einwandfrei mit dem AMR und auch im Hauptmandanten gibt es dieses ?a=100&level=1 nicht, obwohl dort die gleichen Module verwendet werden.

Was könnte da das Problem sein?

Die <basehref> wird auch nicht zurück gesetzt

Die Menü-Fehler haben wohl eine klare Ursache: Die bearbeiteten Dateien wurden nicht überschrieben.
Mir wurde zwar angezeigt, dass die Dateien neueren Datums sind und überschrieben wurden, heute aber finde ich das alte Datum wieder vom letzten Jahr.
Und in den Dateien fehlt natürlich wieder dieses "|| $aCfg['url_builder']['name'] == 'MR'".
Da kann ich natürlich Cache löschen wie ich will.

Kennt sich jemand mit dem spinnerten WebDAV-Programm Bitkinex aus?
Warum täuscht es mir eine Datei-Überschreibung an die es gar nicht gibt?
Warum fügt es beim Down- und Uploaden jedesmal neue Leerzeilen ein?
Ein paar mal hin und her und die Datei ist nicht mehr lesbar weil sie tausende von Zeilen hat.

Aber was hat das mit dem Cache und den Mandanten-Angaben zu tun?
Zumindest die Mandanten-Einstellungen sollten doch in der Datenbank statt finden und nicht auf dem Webspace?
Auch die Kategorie-Einträge müssten doch in der DB stehen, warum nimmt dann das AMR die Änderungen trotzdem nicht?

Ich glaube, dass es hier auch keine richtige Trennung zwischen den Mandanten gibt.
So wird die <basehref> in den Systemeinstellungen gesetzt und nicht im Mandanten, aber die Seitenausgabe ist definitiv Mandanten bezogen (anders darf es ja nicht sein).
Dann könnte es auch sein, wenn ich den Cache im Mandanten in den Systemeinstellungen leere, dass das gar keine Auswirkung auf den Mandanten hat, weil nur der Hauptmandant irgendwelche solche Aktionen durchführen kann.

Inzwischen wurde der Alias im Link angenommen, aber ich weiß nicht warum.
Und auch nicht, warum es vorher nicht ging.
Ich vermute einfach mal, dass es einen Cache gibt, den ich nicht beeinflussen kann und der einfach nach einer Stunde aus läuft.
Denn ich habe seitdem nichts mehr gemacht außer Emails schreiben, Foren durchforsten und hier zu schreiben.

Funktionieren die Mandanten überhaupt richtig?
Oder sollte man die versuchen auf zu trennen und in jeweils eigenen Contenido Installationen aufbauen?

Ja, es ist fatal: nehme ich innerhalb des Mandanten in den Systemeinstellungen die <basehref> raus, ist es in allen Mandanten draußen.
Der Pfad im basehref ändert sich trotzdem nicht, egal was ich in den Mandanteneinstellungen rein schreibe.

Jetzt nach über einer Stunde hat die Mandanteneinstellung für das <basehref> gegriffen und umgeschaltet.
Fatal ist, dass dadurch die Seite kein Design mehr hat weil scripte und CSS nicht mehr gefunden werden.
Die basehref umzusschalten wird wieder Stunden dauern.

Woran kann das liegen?
Gibt es irgendeinen Contenido Cache, der Dinge wie <basehref> und vielleicht auch Aliasse betrifft, und der nicht durch die System-Bereinigung geleert wird?
Oder ist da irgendeine Server-Geschichte mit Loadbalancer und Schreibrechtkonflikten am Werk?

Ich kann so nicht arbeiten und Fehlersuche betreiben, wenn jede Aktion mal keine Wirkung hat und mal nach Stunden und mal sofort.
Hat jemand einen Tipp?

Hallo Faar,

die basehref wird aus der Mandanteneigenschaft "Web-Adresse" genereriert, das geschieht dann, wenn auch der PHP-Code der Seite generiert wird.

Der PHP-Code der Seite wird in CONTENIDO 4.8 in der Tabelle con_code abgelegt. Das Ändern von Artikel, Kategorie, Layout, Modul sorgt immer dafür, dass der Code des betroffenen Artikels immer neu Generiert wird. Auch Änderungen an Mandanteneigenschaften sollten die erneute Generierung der PHP-Codes erzwingen.

Anders sieht es aber beim Besucher der Seite aus. Jeder Besucher der Seite bekommt in der Regel eine Session. Manche Werte werden dann in dieser Session gespeichert, auch die Web-Adresse des aktuellen Mandanten. Das wurde vor langer Zeit so eingeführt, um bei jedem Besuch der Seite unnötige Datenbankabfragen zu reduzieren.

Änderst du jetzt die Web-Adresse des Mandanten, wirkt sich das nicht auf alle aktuellen Sessions aus. D. h. solange das Cookie des Besuchers noch gültig ist, wird beim Besuch der Seite die alte "Web-Adresse" des Mandaten aus der Session des Users verwendet, auch beim erneuten Generieren des PHP-Codes der Seite.

Das Beste ist, du leerst nach so einer Aktion die Sessionabelle und alle Besucher bekommen eine neue Session und gut ist. Bis du der Einzige, dann lösche einfach das Cookie und du hast beim nächsten Auzfruf der Seite die neuen Daten in der Session.

In 4.9 ist das nicht mehr nötig, da die "Web-Adresse" als Konfigurationsdatei auf dem Dateisystem abgelegt und beim Initialisieren der Seite includiert wird. Es landed nicht mehr in der Session der User und eine Änderung dieser Werte wird in der Regel sofort sichtbar.

Grüße
xmurrix

Hallo Xmurrix,

DAS erklärt mir die Probleme die ich gestern hatte. Es lag wohl an der Session in dem Fall.
Denn ich hatte mehrmals im Mandanten die Webadresse geändert und gespeichert und es tat sich im Seitenquelltext absolut nichts.
Dort stand immer der gleiche <basehref>.

Es half auch nichts, dass ich x-mal versucht habe, die Caches zu leeren (bis auf den Session-Tabelle... die hatte ich nicht im Verdacht ).
Es änderte sich einfach nichts am Seitenquelltext.
Nur irgendwann mal lief wohl der Cache ab und dann griff dummerweise eine unglückliche basehref Einstellung, so dass keine Bilder und kein CSS mehr gefunden wurde.
Im Prinzip war dadurch die Seite untauglich für eine ganze Weile, weil sich auch danach diese falsche <basehref> nicht mehr schnell ändern ließ.
Sie blieb wie eingemauert im Seitenquelltext.
Und irgendwo her muss ja dieser Seitenquelltext kommen? Komplett im Sessioncookie wirds ja nicht gespeichert sein

Dummerweise kam ich eine Zeit lang auch nicht an den Webspace dran, weil aus irgendeinem Grunde die Dateien nicht verändert werden konnten.
Ich weiß nicht was die da alles auf dem Server laufen haben, aber es ist definitiv kein Standard-System.

Das Beste ist, du leerst nach so einer Aktion die Sessionabelle

Kann es sein, dass das Leeren der Cache Tabellen mit dem Befehl TRUNCATE geschieht?
Falls ja, es gibt hier und da so Sicherheitsratschläge für MySQL Client-Privileges, die dazu raten, TRUNCATE nicht zu erlauben. Manche erlauben noch nicht einmal DELETE.
Das würde dann erklären, warum die con_code scheinbar nicht geleert wurde in der System-Bereinigung.
Aber ich komme nicht so einfach an diese Datenbank dran, müsste mir dort erst wieder in einem RZ einen Account verlängern lassen und die VPN-Schleuder anwerfen bevor ich auf die Datenbank zugreifen könnte.
Das dauert und ist umständlich und mit Problemen behaftet.

Ich hatte es dann mal geschafft, mit WebDAV wieder eine Datei verändern zu können und hab in der concache den Wert von 3600 auf 1800 verändert und schwupps, war alles wieder im Lot.
Lag es am Ende doch auch am Code Cache? Oder wird die Session auch von diesem Wert beeinflusst?
Man kann schon konfus werden, wenn man "schnell mal" ein scheinbar kleines Problem lösen soll und es aber an verschiedenen Stellen hakt und man nicht die Möglichkeiten hat wie sonst, der Sache auf die Spur zu gehen.
Wo müsste ich eigentlich zum Testen und Entwickeln alles anders einstellen, damit ich die Änderungen immer sofort sehe?
Ob der Server in der Zeit mehr belastet ist, ist mir dabei egal, weil Seiten die nicht funktionieren, sind schlimmer im Live-System wenn man mit mehreren Besuchern gleichzeitig zu der Zeit rechnen muss.
Reicht es aus, den Wert in der Concache Datei ganz klein zu machen?
Kann man das nicht ins Backend einbauen?

Ich hoffe, dass bei 4.9 auch die Trennung der Mandanten eindeutiger ist.

VG,
Frank

Ach ja, wegen der ALIAS zurücksetzen Funktion im AMR blieb ja noch die Frage, warum das nicht ging?
Das AMR nimmt doch den Alias-Namen der Kategorie, so dass man einmal die Kategorie z.B. mit utf-8 Zeichen benennen kann wie man will und einmal für die URL die Kategorie-Bezeichnung hat?

Wie hängt denn das beim AMR zusammen? Gibt es da eine eigene Tabelle wo diese zwischengespeichert wird oder ist es eine Datei?
Und hängt es irgendwie mit dem Session-Cookie und der con_code zusammen und damit auch mit den Cache-Einstellungen?
Und hängt es zusätzlich dann noch mit der "ähnliche URL" Einstellung zusammen, ob ein Alias angenommen wird oder nicht?

Ich hatte nämlich eine Weile lang versucht, den Alias zu ändern und das nahm das AMR lange Zeit absolut nicht an.

Hallo Faar,

...Kann es sein, dass das Leeren der Cache Tabellen mit dem Befehl TRUNCATE geschieht?...

Es wird ein normaler DELETE Statement an die DB abgesetzt, siehe contenido/classes/class.purge.php.

...Ich hatte es dann mal geschafft, mit WebDAV wieder eine Datei verändern zu können und hab in der concache den Wert von 3600 auf 1800 verändert und schwupps, war alles wieder im Lot...

Was meinst du genau mit concache, hast du etwas das Output-Caching aktiviert?
Das kann schon erklären, warum die Änderung der Mandanteneinstellungen nicht im base Tag übernommen wurden.
Concache cacht die Ausgabe der Artikel, also das, was an den Client rausgeht. In der Tabelle con_code wird der PHP-Code der Seite abgelegt.
Bei Änderungen an Artikel, Kategorien, Templates und auch Modulen wird der PHP-Code der Seite neu generiert. Dafür gibt es ein Feld in der Tabelle con_cat_art. Concache prüft diesen Wert, ist der Code der Seite neu zu generieren, dann wird es auch so gemacht.
Allerdings wird nicht jede Änderung an Einstellungen (Mandanteneinstellungen, Systemeinstellungen, usw...) dafür sorgen, dass der Code der Seiten neu generiert wird. Das sollte man als Admin/Entwickler berücksichtigen und vor dem Abmelden im Backend eventuell den Mandanten-cache leeren.

...Wo müsste ich eigentlich zum Testen und Entwickeln alles anders einstellen, damit ich die Änderungen immer sofort sehe?...

In der Konfigurationsdatei des Mandanten (cms/config.php) die Zeile ändern in Ist der Wert auf 1 gesetzt, dann wird die gecachte Ausgabe des Artikels auch jedesmal gelöscht und wieder neu angelegt. Concache kommt also auch damit klar.

Gruß
xmurrix

...Wie hängt denn das beim AMR zusammen? Gibt es da eine eigene Tabelle wo diese zwischengespeichert wird oder ist es eine Datei?...

Artikelaliase findest du in der Tabelle con_art_lang.urlname , die Kategoriealiase in der Tabelle con_cat_lang.urlname.

...Und hängt es irgendwie mit dem Session-Cookie und der con_code zusammen und damit auch mit den Cache-Einstellungen?...

Die Werte in der Tabelle con_art_lang oder con_cat_lang, haben nichts mit Cookie oder Session zu tun. Nur die Mandanteneigenschaften werden in der Session gespeichert, um sie nicht bei jedem Request nochmal zu ermitteln. Auch die Id der Sprache und die Id des Mandanten werden in der Session gespeichert, für den Fall, wenn deine URLs keine lang oder client Parameter haben. Ansonsten müsste man diese auch jedesmal mit DB-Abfragen ermitteln, was nicht unbeding performant ist.

...und hängt es zusätzlich dann noch mit der "ähnliche URL" Einstellung zusammen, ob ein Alias angenommen wird oder nicht?...

Nein, die Aiase haben nichts mit der "ähnliche URL" Einstellung des AMR-Plugins zu tun. Obwohl die Aliase ursprünglich vom AMR-Plugin kommen, sind sie auch für andere mod_rewrite Lösungen verwendbar.
Wie das mit der "ähnlichen URL" funktioniert, ist hier beschrieben:
http://forum.contenido.org/viewtopic.ph ... 45#p157573

Gruß
xmurrix

Moin,

ich war einige Tage weg und konnte nicht mehr ins Forum und darum nicht mehr antworten.
Inzwischen weiß ich, dass dort in den User-Privilegs der Datenbank das TRUNCATE fehlt.

xmurrix hat geschrieben:Hallo Faar,

...Kann es sein, dass das Leeren der Cache Tabellen mit dem Befehl TRUNCATE geschieht?...

Es wird ein normaler DELETE Statement an die DB abgesetzt, siehe contenido/classes/class.purge.php.

DELETE ist aber drin, darum würde mich das jetzt wundern, warum dann die Cache-Tabellen nicht gelöscht wurden.

Was meinst du genau mit concache, hast du etwas das Output-Caching aktiviert?

Wenn, dann hätte das mein Vorgänger aktiviert. Aber die folgende Beschreibung von Dir würde dazu passen.

Das kann schon erklären, warum die Änderung der Mandanteneinstellungen nicht im base Tag übernommen wurden.
Concache cacht die Ausgabe der Artikel, also das, was an den Client rausgeht. In der Tabelle con_code wird der PHP-Code der Seite abgelegt.

Bei Änderungen an Artikel, Kategorien, Templates und auch Modulen wird der PHP-Code der Seite neu generiert. Dafür gibt es ein Feld in der Tabelle con_cat_art. Concache prüft diesen Wert, ist der Code der Seite neu zu generieren, dann wird es auch so gemacht.

Dummerweise habe ich genau dort nur in besonderen Fällen befristeten Datenbank Zugang, sonst hätte ich das mal live nachverfolgen können was sich dort ändert.

Das sollte man als Admin/Entwickler berücksichtigen und vor dem Abmelden im Backend eventuell den Mandanten-cache leeren.

Ja eben, in diese Cache-Leerungen hatten keinen sichtbaren Erfolg.

...Wo müsste ich eigentlich zum Testen und Entwickeln alles anders einstellen, damit ich die Änderungen immer sofort sehe?...

In der Konfigurationsdatei des Mandanten (cms/config.php) die Zeile

Code: Alles auswählen

$force = 0;

ändern in

Code: Alles auswählen

$force = 1;

Ist der Wert auf 1 gesetzt, dann wird die gecachte Ausgabe des Artikels auch jedesmal gelöscht und wieder neu angelegt. Concache kommt also auch damit klar.

Danke, das könnte sehr hilfreich sein.

VG,
Frank

xmurrix hat geschrieben:Nein, die Aiase haben nichts mit der "ähnliche URL" Einstellung des AMR-Plugins zu tun. Obwohl die Aliase ursprünglich vom AMR-Plugin kommen, sind sie auch für andere mod_rewrite Lösungen verwendbar.
Wie das mit der "ähnlichen URL" funktioniert, ist hier beschrieben:
http://forum.contenido.org/viewtopic.ph ... 45#p157573

Also, wenn ich das dort lese, hat es doch mit der Prozent-Einstellung zu tun, oder andersherum, wirkt es sich darauf aus.
Beispiel: Nenne ich eine Kategorie "Haus", dann steht im Kategoriepfad /haus/ drin.
Nenne ich eine zweite Kategorie "Haus2", dann steht im Pfad /haus2/" drin.
Deine Prozentwertermittlung würde dann immer /haus/ nehmen, weil /haus2/ zu ähnlich ist bei 75%.
Obwohl nachfolgend noch ein 100% passender Pfad vorhanden wäre.
Und diese Pfade sind ja bereits die Aliasse, hat also doch was damit zu tun.
Könnte das ein Bug sein?

Jedenfalls hat es nun geklappt nachdem der Wert auf 100% gesetzt wurde.

Danke und Grüße,
Frank

Hallo Frank,

wie das genau mit der "ähnliche URL" Einstellung funktioniert, findest du in contenido/plugins/mod_rewrite/classes/class.modrewrite.php in der Funktion getCatIdByUrlPath().

Diese Funktion bekommt den Pfad und versucht unter Verwendung von similar_text() die beste Möglichkeit zu finden - unter Berücksichtigung der "ähnliche URL" Einstellung.

Man muss halt darauf achten, dass z. B. nicht zwei Kategorien mit dem gleichen Alias in erster Ebene der Kategoriebäume vorkommen, sonst kann es passieren, dass die falsche Kategorie gefunden wird, Beispiel: Hier kann es passieren, dass anstatt News in Hauptkategorie die News in Archiv gefunden wird, oder umgekehrt.

Gruß
Murat