MleCMS

NaN · 14. März 2011 14:53

Setz mal in der config.php $config['debug'] = true;
Solche Szenarien sind oftmals Resultat irgendeines fatalen Fehlers auf PHP Seite.
Die Fehler sieht man meistens nicht, da muss man sich oftmals den HTML Quelltext im Browser anzeigen lassen.

redigo/ · 14. März 2011 15:00

debug ist true.
Komisch: Ausgerechnet im Admin-Aufruf des Templates /inhalte/mlecms gibt es keinerlei debug-meldung. Überall sonst aber schon.
Was das wohl zu bedeuten hat?

panthus · 14. März 2011 16:38

Nicht besonders hilfreich, aber ich habe auf zwei Websites MLEcms unter 1.9.4 laufen, ohne Probleme. Scheint also keine generelle Inkompatibilität zu sein...

redigo/ · 14. März 2011 16:42

Danke, Panthus, ich denke schon, dass Dein Hinweis hilfreich ist. Ich weiss nur noch nicht wo genau und vor allem wann ;-)

Ps: Würdest Du mir den Link geben zu Deinen zwei Sites mit CMEcms, ich würde es gerne anschauen.
Danke.

NaN · 14. März 2011 16:45

Wenn keine Debug-Ausgabe zu sehen ist, wird das Script bereits mittendrin abgebrochen.
Wenn nirgends Fehlermeldungen zu sehen sind, dann ist error_reporting vermutlich auf off eingestellt.
In der .htaccess mal folgendes einfügen:

php_flag display_errors on
php_flag html_errors on
php_value error_reporting 1 (oder 8191 - dürfte ausnahmslos ALLES anzeigen)

(das sind so kleine Handgriffe, die man sich unbedingt merken sollte: in config.php debug auf true setzen und wenn das nicht hilft, die Anzeige von Fehlermeldungen nochmal explizit in der .htaccess Datei oder - falls möglich - in der php.ini einschalten)

redigo/ · 15. März 2011 08:47

Danke NaN, für Deinen konstruktiven Rat. Die .htaccess habe ich eingefügt, bugreport ist auf "ture", es wird für jede Seite Front- und Backend "debug" aufgelistet. Nur für die mlecms immer noch nicht. Ich habe auch das Modul ganz gelöscht und - via ftp - neu installiert. Keine Wirkung. Das Modul erscheint zwar -wie gehabt - unter "inhalte", aber nur die Reiter sind zu sehen. Öffnen lassen sie sich nicht.

oder - falls möglich - in der php.ini einschalten

Was genau müsste ich in die php.ini schreiben?

Andynium · 15. März 2011 09:18

NaN schrieb:

php_flag display_errors on
php_flag html_errors on
php_value error_reporting 1 (oder 8191 - dürfte ausnahmslos ALLES anzeigen)
(das sind so kleine Handgriffe, die man sich unbedingt merken sollte: in config.php debug auf true setzen und wenn das nicht hilft, die Anzeige von Fehlermeldungen nochmal explizit in der .htaccess Datei oder - falls möglich - in der php.ini einschalten)

Hmm, sollten wir dazu mal ein sticky Posting machen?

redigo/ · 15. März 2011 09:20

sticky Posting

Was ist das?

Andynium · 15. März 2011 09:21

redigo/ schrieb:

Was genau müsste ich in die php.ini schreiben?

http://www.peterkropff.de/tutorials/php … orting.htm

(Punkt 5)

nockenfell · 15. März 2011 09:24

redigo/ schrieb:

sticky Posting
Was ist das?

Ein Posting das fixiert ist und somit immer oben angezeigt wird.

php.ini vs .htaccess:

Wenn man Zugriff auf's php.ini hat, sollte man solche Änderungen am besten dort ausführen. Das .htaccess kann Einstellungen in der php.ini Überschreiben. Allerdings kommt dies ein wenig auf die Konfiguration des Servers an. Restriktive Provider oder solche welche den Zugriff auf die php.ini zulassen, verbieten die php_flag Befehle in der .htaccess.

redigo/ · 15. März 2011 09:26

Ich bitte um Nachsicht für den Contentmenschen: Wo befindet sich die php.ini?

Andynium · 15. März 2011 09:28

redigo/ schrieb:

sticky Posting
Was ist das?

Sorry ... ich verfalle immer wieder mal ins Englische angel .

sticky = fixieren

Damit ist gemeint, dass ein Thema fixiert wird und in der Folge in dem betreffenden Forum IMMER als erstes Thema angezeigt wird (obwohl es möglicherweise schon älter ist), so dass es auch für alle später hinzugekommenen Forenbesucher schnell sichtbar ist, ohne dass diese großartig die Suche bemühen müssen.

Konkret meinte ich, dass möglicherweise ein "Fixiertes Thema" zur Fehlersuche für alle hilfreich sein könnte.

nockenfell · 15. März 2011 09:29

redigo/ schrieb:

Ich bitte um Nachsicht für den Contentmenschen: Wo befindet sich die php.ini?

Diese Frage kann dir das FAQ oder der Support des Hosting-Providers beantworten. Meistens gibt es einen Ordner /etc im Webspace. Dort oder in einem Unterordner kann die php.ini sein. Genaueres erfährst du beim Hosting-Provider.

redigo/ · 15. März 2011 09:42

Ich habe inzwischen das Modul MleCMS in eine Domain - auf dem gleichen Server - installiert, wo es keinerlei Probleme gibt mit "modules": Und siehe da: hier funktioniert das Modul einwandfrei. Bemerkenswert scheint mir: wo MleCMS funktioniert, ist cmsms neu installiert worden, also kein Transfer vom alten Sever, keine DB-Übernahme, alles neu.
Könnte es sein, dass bei mysql "importieren" etwas schief gelaufen ist? Und wenn ja, was?

Andynium · 15. März 2011 09:44

Laufen auf beiden Domains die gleichen Module?

redigo/ · 15. März 2011 09:46

Genaueres erfährst du beim Hosting-Provider.

Danke, Nockenfell. :-)
Es gibt im Hosting-Ordner einen Unterordner "conf". Der ist über ftp für mich aber nicht zugänglich.

redigo/ · 15. März 2011 09:48

Laufen auf beiden Domains die gleichen Module?

Ja. Ich vermute, Konflikte mit anderen Modulen sind es nicht, denn auf dem alten Server mit der gleichen Konf. hat MleCMS einwandfrei funktioniert.

nockenfell · 15. März 2011 09:48

Hast du das MleCMS auch mal ganz neu installiert? Nicht nur die Dateien gelöscht, sondern im ModulManager auch auf "deinstallieren" gegangen?

Damit werden zwar alle Daten des Moduls gelöscht, einen fehlenden DB-Eintrag können wir damit aber nach der erneuten Installation des Moduls ausschliessen.

redigo/ · 15. März 2011 10:08

Hast du das MleCMS auch mal ganz neu installiert? Nicht nur die Dateien gelöscht, sondern im ModulManager auch auf "deinstallieren" gegangen?

Ja, alles gelöscht, auch die Dateien im Ordner "modules" des Servers. Alles neu installiert. Wirkung null. Es ist verhext.

Beitrag geändert von redigo/ (15. März 2011 10:08)

redigo/ · 15. März 2011 11:01

Folgende Situation:
3 Domains, alle mit cmsms 1.9.4.1
2 Domains von altem Server auf neuen disloziert
1 Domain auf neuem Server frisch installiert

Auf den zwei disolozierten Domains identisch (Version)
MleCMS 1.5 neu installiert und die erforderlichen Zusatzmoduls
CGExtension 1.24
ContentCache 1.1
GBFilePicker 1.3
von Grund auf neu installiert.
Ergebnis:
MleCMS läuft einwandfrei auf der neu eingerichteten Domain
MleCMS läuft NICHT auf den zwei dislozierten Domains.
Also muss doch beim Umzug etwas passiert sein. Aber was?

Andynium · 15. März 2011 11:16

Hast du auch mal den Zwischenspeicher gelöscht (Webseiten-Administration > Globale Einstellungen > Weitere Einstellungen > Zwischenspeicher löschen)?

redigo/ · 15. März 2011 11:21

Ja, mehrmals, klar.
Inzwischen habe ich einen Blick in die MySql-Admin geworfen, genauer auf den Eintrag cms_modules.
Und da fällt sofort ein gelb-roter Eintrag ins Auge:

Hier klicken, um den Code zum Kopieren zu markieren

Die Index-Typen INDEX und PRIMARY sollten nicht gleichzeitig für die Spalte `module_name` gesetzt sein

Das sieht schwer nach einem Bug aus. Aber ich kenne mich in der MySQL-Welt leider nicht aus.

Andynium · 15. März 2011 11:25

Ist das bei deiner frischen Installation auch so?

redigo/ · 15. März 2011 11:54

Gute Frage. Ich muss präzisieren:
Diese Meldung

Hier klicken, um den Code zum Kopieren zu markieren

Die Index-Typen INDEX und PRIMARY sollten nicht gleichzeitig für die Spalte `module_name` gesetzt sein

steht in der db cms_modules der frisch aufgesetzten domain.
Bei der dislozierteen steht diese meldung NICHT.
Wenn ich die entsprechenden Einträge in der db vergleiche, stelle ich aber noch einen Unterschied fest:
Wo das Modul funktioniert, gibt es unter "indices" ZWEI Einträge plus die zitierte "Fehlermeldung".
Wo das Modul NIHCHT funktioniert, gibt es unter "indices" nur EINEN Eintrag

Ich bin halt leider kein Fachmann für MySQL, kann also die Unterschiede nicht deuten. Aber vorhanden sind sie.

Beitrag geändert von redigo/ (15. März 2011 11:54)

piratos · 15. März 2011 12:15

Das stimmt tatsächlich - da ist ein Index cms_index_modules_by_module_name definiert der auf die Spalte module_name aufsetzt - PRIMARY setzt ebenfalls auf module_name auf.

Aber bis auf Performanceverluste die man kaum bemerken dürfte macht das nichts aus.

Dennoch würde ich den Index cms_index_modules_by_module_name killen, da überflüssig wie ein Kropf.

Forum für CMS/made simple

#26 14. März 2011 14:53

Re: MleCMS

#27 14. März 2011 15:00

Re: MleCMS

#28 14. März 2011 16:38

Re: MleCMS

#29 14. März 2011 16:42

Re: MleCMS

#30 14. März 2011 16:45

Re: MleCMS

#31 15. März 2011 08:47

Re: MleCMS

#32 15. März 2011 09:18

Re: MleCMS

#33 15. März 2011 09:20

Re: MleCMS

#34 15. März 2011 09:21

Re: MleCMS

#35 15. März 2011 09:24

Re: MleCMS

#36 15. März 2011 09:26

Re: MleCMS

#37 15. März 2011 09:28

Re: MleCMS

#38 15. März 2011 09:29

Re: MleCMS

#39 15. März 2011 09:42

Re: MleCMS

#40 15. März 2011 09:44

Re: MleCMS

#41 15. März 2011 09:46

Re: MleCMS

#42 15. März 2011 09:48

Re: MleCMS

#43 15. März 2011 09:48

Re: MleCMS

#44 15. März 2011 10:08

Re: MleCMS

#45 15. März 2011 11:01

Re: MleCMS

#46 15. März 2011 11:16

Re: MleCMS

#47 15. März 2011 11:21

Re: MleCMS

#48 15. März 2011 11:25

Re: MleCMS

#49 15. März 2011 11:54

Re: MleCMS

#50 15. März 2011 12:15

Re: MleCMS

Fußzeile des Forums