PHP-Fehler nach Wechsel der Theme

    Hallo liebe Community,

    bin nun auch zu Wordpress gewechselt, nachdem ich bei all-inkl eine Woche den Testaccount strapeziert habe. Mit meinem Webspace habe ich auch zu all-inkl gewechselt und habe dort den Tarif "WebPrivat XL" abgeschlossen.

    Soweit so gut, Wordpress läuft wunderbar...bis ich die BinaryBlue Theme installiere. Dann erhalte ich auf der Startseite eine Fehlermeldung nach der Anderen. Das ist mir aber vollkommen rätselhaft, lief haargenau dasselbe Theme doch auch innerhalb des Testaccounts und unter meiner lokalen Wordpress-Installation.

    Die Meldungen lauten wie folgt:


    [size=8][COLOR=Blue] Warning: main() [function.main]: open_basedir restriction in effect. File(../calendar-common.php) is not within the allowed path(s): (/www/htdocs/xxxxxxxx/) in /www/htdocs/xxxxxxxx/wp-content/themes/binaryblue/plugins/plugins.php on line 338

    Warning: main(calendar-common.php) [function.main]: failed to create stream: Operation not permitted in /www/htdocs/xxxxxxxx/wp-content/themes/binaryblue/plugins/plugins.php on line 338

    Warning: main() [function.main]: open_basedir restriction in effect. File(../calendar-common.php) is not within the allowed path(s): (/www/htdocs/xxxxxxxx/) in /www/htdocs/xxxxxxxx/wp-content/themes/binaryblue/plugins/plugins.php on line 338

    Warning: main(calendar-common.php) [function.main]: failed to create stream: Operation not permitted in /www/htdocs/xxxxxxxx/wp-content/themes/binaryblue/plugins/plugins.php on line 338

    Warning: main() [function.main]: Failed opening 'calendar-common.php' for inclusion (include_path='.:/usr/share/php:..') in /www/htdocs/xxxxxxxx/wp-content/themes/binaryblue/plugins/plugins.php on line 338

    Warning: main() [function.main]: open_basedir restriction in effect. File(../style-switcher.php) is not within the allowed path(s): (/www/htdocs/xxxxxxxx/) in /www/htdocs/xxxxxxxx/wp-content/themes/binaryblue/header.php on line 4

    Warning: main(style-switcher.php) [function.main]: failed to create stream: Operation not permitted in /www/htdocs/xxxxxxxx/wp-content/themes/binaryblue/header.php on line 4

    Fatal error: main() [function.main]: Failed opening required 'style-switcher.php' (include_path='.:/usr/share/php:..') in /www/htdocs/xxxxxxxx/wp-content/themes/binaryblue/header.php on line 4[/COLOR][/SIZE]

    :?:

    Leider bin ich in PHP noch ein wenig unbeleckt, für mich sieht es wie ein "Sicherheitsfeature" aus. Hab auch schon eine Mail an den Support von all-inkl geschrieben, eine Antwort steht aber noch aus.

    PHP ist Version 4.3.1, Wordpress ist 2.0.5 und BinaryBlue 1.4.0.
    Habt Ihr vielleicht einen Tipp?

    Thanx 1stBoomer

    • Gerade eben
    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

    Wenn im Theme ein Unterordner Plugins drin ist, dann schiebe den Inhalt dieses Ordners mal in den richtigen Pluginordner (in wp-content) und aktiviere der Plugins. Er vermisst wohl diverse Dateien.

    "Eine gut gestellte Frage ist schon halb beantwortet."

    Ich hab den Inhalt des Plugin-Ordners mal nach wp-content/plugins kopiert.
    Leider hat's das nicht gebracht.

    Danke für den Tipp, aber ehrlich gesagt hätte mich das auch gewundert, denn wie schon gesagt, hat die Theme auf dem Testaccount und meiner lokalen Installation funktioniert. Ich kann z.B. den Theme-Ordner von meinem Webspace auf meine lokale Wordpress Installation ziehen und dort funktioniert sie. Also sollte an der Theme als Solches alles passen.

    Irgendwie schleierhaft... Ich Unwissender vermute, dass es serverseitig irgendeine Einstellung ist. :???:

    1stBoomer

    Einmal editiert, zuletzt von 1stBoomer (1. Dezember 2006 um 22:47)

    Hast Du Punkt 9 der Installationsanleitung beachtet?

    Zitat


    You need to create a directory named calendar-cache in the theme directory you’ve created on your webserver, and it must have write access for the webserver (chmod 777 in most environments - this may vary from system to system) to make sure that the AJAX calendar cache works as expected.

    Wenn ich helfen konnte, bitte [ Gefällt mir ] klicken. :-)

    Jupp, den Ordner gibt es unterhalb der Theme (/wp-content/themes/binaryblue/calendar-cache/) und die Berechtigungen lauten 777, hab es eben noch einmal überprüft.

    Thanx 1stBoomer

    Drollig, oder? Bist Du bei all-inkl?

    Ich hab eben noch einen Eintrag auf der Binary Blue Community Seite gefunden, der auf den 1. Blick wie mein Problem aussieht. So richtig schlau bin ich noch nicht draus geworden, aber den folgenden Teil kann man - glaub ich - bei all-inkl über die .htaccess steuern...

    http://www.4null4.de/forum/viewtopic.php?p=445

    Zitat

    a good provider doesn't run PHP as a webserver module but as CGI instead (which would render the openbasedir restriction useless!)

    Bei all-inkl steht in den FAQ z.B.:

    Zitat

    Wie kann ich PHP im CGI-Mode ausführen?

    Damit PHP in CGI-Mode ausgeführt wird erstellen Sie im FTP-Hauptverzeichnis Ihrer Domain eine .htaccess Datei mit folgendem Inhalt:

    AddHandler php-fastcgi .php .php4 .php3

    Mir ist PHP und Co. zwar noch etwas fremd und vielleicht hat's damit auch gar nichts zu tun, aber ich probier das jetzt einfach mal aus... 8-)

    Bis gleich...

    1stBoomer

    Ja, ich bin auch bei all-inkl. Habe dort das WebPrivat XXL, ist ja praktisch wie Deins, nur mit ein bissl mehr Speicher und so.
    Das einizige was ich dort konfiguriert habe, sind ein paar Einträge in der .htaccess, die sieht bei mir so aus:

    Das unten ist von Wordpress, und die anderen Dinge sind für SSI zuständig, was ich früher mal verwendet habe, daran sollt es aber nicht liegen.

    Außerdem ist mein "Root"-Verzeichnis der Webseite nicht das Basisverzeichnis /www/htdocs/xxxxxx sondern ein Unterverzeichnis in diesem.

    Wenn ich helfen konnte, bitte [ Gefällt mir ] klicken. :-)

    Hmm, hat auch nichts gebracht. Ich steh vor einem Rätsel, auf dem Testaccount von all-inkl hat es ja auch ohne Probleme funktioniert. Dort bin ich noch unbedarfter ran gegangen und habe die .htaccess überhaupt nicht angefasst.

    Meine .htaccess sieht jetzt wieder so aus:

    Apache Configuration
    <IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

    Ich glaub ich beweg mich jetzt vorerst in die Horizontale... Morgen ist auch noch ein Tag.

    Erstmal Danke für die Hilfe!
    1stBoomer

    Hallo,

    bin leider noch nicht wirklich weiter gekommen. Aus purer Verzweiflung hab ich mich jetzt in die Tiefen von PHP gestürzt.

    Die Meldungen ...

    Zitat

    open_basedir restriction in effect. File(../calendar-common.php) is not within the allowed path(s)

    Zitat

    Failed opening 'calendar-common.php' for inclusion (include_path='.:/usr/share/php:..')

    ... sagen mir, dass der Include-Aufruf innerhalb der PHP-Datei gegen die open_basedir restriction in der globalen PHP-Konfiguration verstösst. Aber das File plugins.php liegt im selben Verzeichnis wie calendar-common.php und header.php im selben wie style-switcher.php. Der Include-Aufruf ruft auch nur das File auf, ohne eine Pfadangabe.


    Jetzt hab ich die infophp-Seite mit der aus dem Testaccount verglichen und siehe da ... ich sehe keinen Unterschied (na toll) bei open_basedir und include_path. Die einzigen Unterschiede die mir spontan auffallen, die Apache und PHP-Version unterscheiden sich minimal (Apache 1.3.27 <> 1.3.36 & PHP 4.3.1 <> 4.4.4) und der Apache mit dem Testaccount hat das Modul "mod_fastcgi" geladen, der Apache mit meinem Webspace nicht.

    Irgendwie werd ich das Gefühl nicht los, damit habe ich nutzloses Wissen angehäuft. :confused:

    Bin ich voll auf dem Holzweg, gefangen im PHP-Dschungel? Leider hat sich all-inkl noch nicht zu dem Problem geäußert.

    Thanx 1stBoomer

    Einmal editiert, zuletzt von 1stBoomer (2. Dezember 2006 um 23:14)

    Hallo Community,

    das Problem ist gelöst und es lag, wie ich schon vermutet habe, an der PHP Version auf dem Server.
    Ich habe vorhin mit dem Support von all-inkl telefoniert und der Admin hat im Hintergrund den Server aktualisiert.

    von:

    Zitat

    Apache/1.3.27 FrontPage/4.0.4.3 mod_python/2.7.10 Python/2.2.2 PHP/4.3.1 mod_perl/1.27 mod_ssl/2.8.12 OpenSSL/0.9.6i

    auf:

    Zitat

    Apache/1.3.37 PHP/4.4.4 with Suhosin-Patch FrontPage/5.0.2.4803 mod_fastcgi/mod_fastcgi-SNAP-0404142202 mod_ssl/2.8.28 OpenSSL/0.9.6i

    Und siehe da...es funktioniert 8-)

    Alle Achtung, der Support von all-inkl ist wirklich klasse...bei meinem alten Provider hätte ich mir bestimmt den Mund fusselig gequatscht...

    Gruß 1stBoomer

    Aha, na super. Muß ich doch gleich mal gucken, was auf "meinem" Server läuft:

    Code
    Apache/1.3.27 (Linux/SuSE) mod_fastcgi/2.4.2 FrontPage/4.0.4.3 PHP/4.4.1 mod_perl/1.27 mod_ssl/2.8.12 OpenSSL/0.9.6i

    Naja, nicht so hochaktuell wie bei Dir, aber für einen reibungslosen Wordpress-Betrieb jedenfalls ausreichend.

    Und was ist ein "Suhosin-Patch", klingt für mich ein bißchen wie Sushi oder so :-)

    Gruß
    Ingo

    Wenn ich helfen konnte, bitte [ Gefällt mir ] klicken. :-)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden