phpwcms Support Forum

fracer wrote:Daher ein Versuch auf die Version 1.3.9r182 zu updaten - ab da schmeißt es mir alle Umlaute und viele Seiten bleiben komplett leer. Das gleiche mit der neuesten r213.

Bist du zufällig auch bei Host Europe?

[x]

rudist wrote:Und das Errorlog kann ich nicht lesen, da keine Zugriffsrecht auf die Datei...

unsinn, du kannst alle log files ansehen und/oder als tar.gz downloaden...
was fummelste da eigentlich?

[x]

Jensensen wrote:unsinn, du kannst alle log files ansehen und/oder als tar.gz downloaden...
was fummelste da eigentlich?

Na mal langsam.
das rewrite_error_log.xxx kannst Du eben nicht anschauen (s.o. denn der Support ist ja der Meinung, dass es am Rewrite liegt...). Und das Log hat mir jemand vom Support ins Stammverzeichnis kopiert, allerdings als root. Und dann geht eben gar nichts, nicht runterladen, nicht anschauen, nicht per FTP und auch nicht über SSH.

Was ich also fummle, ist:
Ich habe ein phpwcms installiert und den Content eingegeben (nicht zum ersten mal mit phpwcms!). So weit alles OK. Dann ging das Drama los. Ich wollte das System updaten bevor ich es fertigstelle, weil hier im Forum auch der Hinweis, dass man die 1.3.3 nicht weiter verwenden soll (updates hab ich auch nicht zum ersten mal gemacht).

Also vorher ein Backup angelegt, sowohl von den Dateien als auch von der DB. So weit auch alles OK. Dann hat aber das Update nicht funktioniert. Eben das Problem, dass bestimmte Seiten nicht angezeigt werden. Hier dachte ich noch, es lag an einem fehl geschlagenen Update.

Ist ja kein Problem hab ja ein Backup... Also die 1.3.3 zurück gespielt, DB-Sicherung auch, und: es wurden bestimmte Seiten nicht angezeigt. An dieser Stelle hab ich alles mögliche probiert. Auch die Zeichensatz-Problematik geprüft: MySQL-Zeichensatz, Kollation, Zeichensatz des Dump. Umlaute und Sonderzeichen kommen ja, das ist nicht das Thema.

Nichts zu machen. Also alles von vorne. Dummerweise hab ich das phpwcms local aufgesetzt und den Content eingepflegt. Das mach ich aber auch nicht zum ersten mal so. Local Entwickeln, ein paar Anpassungen und dann alle auf den Live-Server spielen.

Tja, Pustekuchen. Genau das gleiche Problem. Ich bekomme die Daten nicht zu HE.
Jetzt wollte ich es genau wissen und hab die gleichen Daten einmal auf einem 1+1-Server, einmal auf einem Strato-Server und noch einaml auf dem zweiten localen Server installiert. NULL Probleme.

Also was fummle ich??? Oder besser gefragt was dreht HE am Server dermaßen zu, das das nicht geht?
Denn hier am Schluss meiner Weisheit hab ich mich an den Support gewannt. Und die Empfehlungen oder Unterstützung kann ich bisher in der Pfeife rauchen:

1. Mail: es läge an Suhoshin, ich soll per htaccess einige Parameter verändern. Der Witz an der Sache: Änderungen von Suhoshin-Parameter über die htaccess werden vom System nicht übernommen! Dem Support zurück gemeldet, dass das nicht funktioniert.

2. eine Woche Funkstille vom Support. Zwischenzeitlich hab ich noch überlegt ob's ein PHP5-Problem wie bei Fracer ist. Welcher Parser die Scripte verarbeitet, lässt sich bei HE nur über die Administration einstellen, htaccess geht hier auch nicht. Hab ich gemacht - 15 Min. gewartet und: ich krieg die Scripte im Klartext. Ergo: PHP4 nicht oder falsch auf dem Server installiert.

3. Noch mal Druck beim Support gemacht, 2 x angerufen. Jetzt hab ich die Aussage, das es am Rewrite liegt. Also hab ich Rewrite ausgeschaltet. Ergebniss: wie zuvor...

Und ich bin mittlerweile überzeugt dass es an Suhoshin liegt.
Bei mir bekomme ich sogar eine Warnung im phpMy Admin: "Server running with Suhosin. Please refer to documentation for possible issues." und: "Can I use phpMyAdmin on a server on which Suhosin is enabled? Yes but the default configuration values of Suhosin are known to cause problems with some operations, for example editing a table with many columns and no primary key. Tuning information is available at http://www.hardened-php.net/hphp/troubleshooting.html, although the parameter names have changed (suhosin instead of hphp)."

Und bei Suhosin selbst: Most applications work without problems. But especially administration interfaces sometimes stop working, because of very long input fields or very long field names.

Da hast du wohl Glück mit HE - ich hab jetzt mit dem S***** mehr als 2 Wochen verloren und etliche Arbeitstage!!!
 

Nun ist HE der Meinung es liegt am CMS:

nach genauer Überprüfung Ihres Anliegens wird das Problem scheinbar durch Ihr CMS verursacht.

Genauere Informationen:
Wenn man in der DB in allen Tabellen nach "unternehmen" sucht gibt es 3 Treffer - davon 2 in der Tabelle phpwcms_articlecat und 1 phpwcms_articlecontent. Sucht man nach einer funktionierende Rubrik wie "ausbildung" gibt es jedoch noch einen Treffer in der Tabelle phpwcms_article. Alle nicht funktionierende Rubriken wie unternehmen, veroeffentlichungen und onlineservice_anmelden_abmelden haben ebenfalls keinen Eintrag in der Tabelle phpwcms_article. Funktionierende Rubriken wie strom_von_den_stadtwerken_traunstein und gas_von_den_stadtwerken_traunstein weisen alle einen Eintrag in dieser Tabelle auf. Anscheinend wird der Eintrag in der Tabelle phpwcms_article benötigt für den Seitenaufruf. Der Datenbankdump in Ihrem Webspace beinhaltet ebenfalls keine Einträge in der Tabelle für die o.g. Rubriken d.h. das CMS mit diesem Datenbankinhalt ist wohl möglich so nicht funktionsfähig.

Das Problem ist nicht zurückzuführen auf eine Fehlfunktion im Rewriting, da die umgeschriebene Adresse korrekt beim Skript ankommt.

Warum funktioniert dann der Dump bei allen andern Hostern?? Liegt das Problem hier wirklich bei phpwcms?
 

Ich hab dann wohl einen "Montags"-Server erwischt...

Unter PHP4 laufen die Seiten. Genau mit diesem Datenbankinhalt der ja laut Support "so nicht funktionsfähig (s.o.)" ist...
Wäre ja so weit alles OK, wäre auch mit PHP4 zufrieden. aber:

Schalte ich unter PHP4 jedoch die RewriteEngine ein, dann kommen die Scripte im Klartext.

So ein Müll!!
Bin gespannt was mich noch erwartet...

Dem Wahnsinn nahe

Aber Danke für die vielen Antworten.
 

[x]

Jensensen wrote:leider blicke ich nicht mehr durch: worin besteht das problem und welchen dump meinst du?

Sorry!

1. Vorgeschichte
Ich hatte funktionierende Seiten mit phpwcms und machte davon ein Backup (Daten und der DB).
Wollte von phpwcms 1.3.3 auf 1.3.9 updaten...
Das Update funktionierte nicht, manche Seiten wurden nicht mehr angezeigt und blieben weiß.
Ich habe das Backup zurückgespielt (Daten und DB) aber das Problem blieb:
Alle Seiten die umfangreicher waren, werden nicht angezeigt.
Keine Fehlermeldungen, Umlaute und Sonderzeichen stimmten.

2. dann noch mal von vorne
Habe also alles noch mal komplett neu installiert (v1.3.9) und den ganzen Content eingegeben.
Jedoch auf einem localen Server hier in meinem Büro.
Die Seiten funktionieren...
Ich mache also jetzt einen DB-Dump, installiere phpwcms auf dem Webserver von HE und will den Dump einspielen.
Geht nicht - selbes Problem wie oben...

3. Testen bis zum erbrechen
Also mache ich die ganze Prozedur testweise auf drei (3) anderen Webservern:
strato, 1+1 und noch ein localer Webserevr hier im Büro.
Alle diese Installationen funktionieren! z.B. -> http://swt.web-test.de/

4. Letzte Hilfe: Support
Wende mich jetzt an den Support von HE und habe denen den DB-Dump von Punkt 3 zur Verfügung gestellt.

Der Support sagt nun:

1. Mail: ich soll die Suhoshin-Parameter über die htacces ändern
-> das geht aber nicht, weil der Server so konfiguriert ist, dass die Parameter über die htacces nicht angenommen werden

2. Mail: "ein Überprüfung unserer Technik hat ergeben, dass dies mit dem rewriting zusammenhängt..." und ich soll mir das Rewrite-Logfile anschauen, dass sie mir in das Rootverzeichniss kopiert haben. Aber das konnte ich nicht lesen, weil keine leserechte...

3. Mail: "das CMS mit diesem Datenbankinhalt ist wohl möglich so nicht funktionsfähig"

Um nun den Beweis anzutreten, dass dieser Datenbankinhalt sehr wohl funktionsfähig ist, hab ich auf PHP4 umgestellt. Denn unter PHP4 laufen die Seiten... (Abgesehen davon, dass sie auf den Testserver unter jeder PHP-Version ja auch funktionieren!)

PHP4 funktioniert aber nicht mit dem Rewrite, was wiederum jedoch unter der 5er sehr wohl funktionierte. Wenn unter PHP4 Rewrite an ist, werden die Scripte nicht geparst und ich bekomme diese im Klartext.

Jetzt verständlicher?

Danke für dein Interesse und Grüße!
Rudi
 

rudist wrote:...Ich mache also jetzt einen DB-Dump, installiere phpwcms auf dem Webserver von HE und will den Dump einspielen.
Geht nicht - selbes Problem wie oben...

ich hab's gerade eben mal auf meinem test-server gemacht - und es klappt!

wie lautet denn die fehlermeldung beim einspielen?

Du musst übrigens folgende Zeile aus dem Dump-File löschen:

-- phpMyAdmin SQL Dump
-- version 2.11.5
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Generation Time: Jul 07, 2008 at 03:45 PM
-- Server version: 5.0.32
-- PHP Version: 5.2.6

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

--
-- Database: `db7532123-cms`
--
[x]

-- --------------------------------------------------------

Jensensen wrote:wie lautet denn die fehlermeldung beim einspielen?

Es gibt keine Fehlermeldung - die Daten werden problemlos übernommen. Und ein Teil der Seiten wird danach ohne Einschränkungen incl. Umlaute und Sonderzeichen ausgegeben bzw. angezeigt. z.B. die Startseite - jedoch nicht die Seite "Unternehmen".

Seiten, bei dem der Content (-> Datensatz) eine bestimmte Größe überschreitet sind dann Leer, aber komplett! Nicht einmal das Template wird dann ausgegeben. Wiederum jedoch nur unter PHP5, mit PHP4 funktionieren auch diese Seiten (aktueller Zustand).

Mit PHP 4 gibt’s aber kein Rewrite. Dazu wieder einmal der Support aus einem Auszug meine Mail:

...und unter PHP4 funktionieren die Seiten auch. Also liegt es nicht am Datensatz... Allerdings funktioniert unter PHP4 die RewriteEngine nicht. Sobald diese an ist, werden die Skripte im Klartext ausgegeben...

Das ist korrekt. Mod_rewrite ist nicht voll funktionsfähig in Verbindung mit PHP4 und dem von uns verwendeten Konstrukt.

[x]

Jensensen wrote:Hast Du dort spezielle Replacement-Tags oder Scripte, frontend-render o.ä., wodurch es womöglich zu einem Abbruch kommt?

Hmm, ja gute Frage: Hab's gerade bei http://wp1100855.vwp1218.webpack.hosteu ... n_abmelden getestet. Unter PHP5 geht die Seite nicht, sobald darin mehr als ein Replacement-Tags enthalten ist:

Original-Code: Sollte das doch ein Bug im phpwcms sein???

[x]

[ID ihr_weg_zu_uns]Geschäftsräumen[/ID]
wie sieht es bei einem test mit der ID anstelle des alias aus?

[edit] klappt reibungslos [/edit]