31
Linux Apache VirtualHost PHP wird nicht geladen
Hallo,
ich verwenden einen Apache mit Wordpress. Ich habe, um nicht www.meine-Domain.de/wordpress einzugeben, einen VirtualHost eintrag erzeugt.
So sieht er aus.
Der Eintrag funktioniert, da beim Aufrufen von www.meine-domain.de die Wordpress Seite angezeigt wird - ABER - die Seite wird "unformatiert" geladen. Ich vermute, dass das PHP nicht geladen wird. Wahrscheinlich fehlt im VirtualHost Block noch ein Eintrag dafür oder eventuell Rechte?
Was muss hier noch gemacht werden?
Gruß,
mexx
ich verwenden einen Apache mit Wordpress. Ich habe, um nicht www.meine-Domain.de/wordpress einzugeben, einen VirtualHost eintrag erzeugt.
So sieht er aus.
NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.meine-domain.de
ServerAlias www.meine-domain.de
DocumentRoot "/volume1/web/wordpress"
<Directory /volume1/web/wordpress>
php_admin_flag engine on
AllowOverride AuthConfig FileInfo
Order allow,deny
allow from all
</Directory>
</VirtualHost>Was muss hier noch gemacht werden?
Gruß,
mexx
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 225716
Url: https://administrator.de/contentid/225716
Printed on: April 19, 2024 at 18:04 o'clock
31 Comments
Latest comment
Hallo,
nein, du wirst einfach die css Verweise neu setzen müssen. Diese laufen nun eben nicht mehr auf domain.de/wordpress sondern auf domain.de/$random.
nein, du wirst einfach die css Verweise neu setzen müssen. Diese laufen nun eben nicht mehr auf domain.de/wordpress sondern auf domain.de/$random.
1
Das war mal eine schnelle Antwort. Ich ändere die CSS Verweise im Wordpress? Oder anders, wo ändere ich Sie?
Poste mal bitte temporär nen Link zu deiner Seite.
Ich habe Dir eine PN geschickt.
Exakt das war das Problem, du verweisst auf die IP http://192.1xx.x.x/wordpress ändern das und es sollte gehen und nächstes mal keine Harten Verweise mehr.
Ihr hängt mich total ab. 
In den CSS Dateien steht keine Angabe der URL. Ich verstehe die Aufforderung CSS Verweise ändern nicht und was mir ein Link im Wordpress Ordner bringen soll verstehe ich auch nicht.
In den CSS Dateien steht keine Angabe der URL. Ich verstehe die Aufforderung CSS Verweise ändern nicht und was mir ein Link im Wordpress Ordner bringen soll verstehe ich auch nicht.
Okay, jetzt sind wir bei einander. Dann reden wir aber nicht von Apache Konfigurationen, sondern von Wordpress Konfigurationen.
Damit meine Seite per externer URL erreichbar ist, habe ich mich an diese Anleitung gehalten.
http://codex.wordpress.org/Changing_The_Site_URL
Ich habe nur den Eintrag define('WP_SITEURL','http://example.com'); geändert. Das hat zur Folge, dass im Wordpress unter Einstellungen -> Allgemein unter Seiten-Adresse (URL) die externe URL drin steht. Welchen Eintrag muss ich noch ändern, damit restliche Verweise greifen?
Damit meine Seite per externer URL erreichbar ist, habe ich mich an diese Anleitung gehalten.
http://codex.wordpress.org/Changing_The_Site_URL
Ich habe nur den Eintrag define('WP_SITEURL','http://example.com'); geändert. Das hat zur Folge, dass im Wordpress unter Einstellungen -> Allgemein unter Seiten-Adresse (URL) die externe URL drin steht. Welchen Eintrag muss ich noch ändern, damit restliche Verweise greifen?
Aufgrund deines jetztigen Systems vermute ich doppelte Probleme (Das Kopfbild bitte nie Hardcoden) Da verweisst du weiterhin auf die interne IP.Was den Rest angeht: Verschiebe am besten das ganze Wordpress Verzeichnis in ./wp/ und lege darauf dein ReWrite und vHost. Damit sollte es gehen.
Im code selbst ändere ich nichts. Ich vermute ich mache etwas beim Ändern der Seiten URL falsch. Die Verweise auf interne IP Adressen stammen nicht von mir, sondern vom wordpress. Da muss ich noch mal in die Tiefe.
Den Ordner ./wp gibt es bei mir nicht. Deine Aussage impliziert, dass es Ihn schon gibt?! O.o Was sollte das ändern, wenn ich den vHost auf ein neues Verzeichnis lege?
Den Ordner ./wp gibt es bei mir nicht. Deine Aussage impliziert, dass es Ihn schon gibt?! O.o Was sollte das ändern, wenn ich den vHost auf ein neues Verzeichnis lege?
Nein. erstelle wp
schiebe Wordpress in wp
erstelle vhost mit ziel auf wp ;)
Dann sollte alles so sein,wie du es willst (zu99%)
schiebe Wordpress in wp
erstelle vhost mit ziel auf wp ;)
Dann sollte alles so sein,wie du es willst (zu99%)
Aber dann ändert sich doch nichts, ausser der Name des Ordners. Warum glaubst Du, dass der Ordnername wp etwas positives bewirkt?
Probier es mal bitte über die Methode ;)
Der Ordner muss unter /web stehen? Auf der selben ebene wie wordpress nur eben wp?!
bisher (denke ich)
webroot/wordpress
zusätzlich
webroot/wp/
und dann den o.g. Ordner nach
webroot/wp/ verschieben daher
webroot/wp/wordpress
auf webroot/wp/ setzt du den vHost.
webroot/wordpress
zusätzlich
webroot/wp/
und dann den o.g. Ordner nach
webroot/wp/ verschieben daher
webroot/wp/wordpress
auf webroot/wp/ setzt du den vHost.
Zitat von @mexx:
Ihr hängt mich total ab.
In den CSS Dateien steht keine Angabe der URL. Ich verstehe die Aufforderung CSS Verweise ändern nicht und was mir ein Link
im Wordpress Ordner bringen soll verstehe ich auch nicht.
Ihr hängt mich total ab.
In den CSS Dateien steht keine Angabe der URL. Ich verstehe die Aufforderung CSS Verweise ändern nicht und was mir ein Link
im Wordpress Ordner bringen soll verstehe ich auch nicht.
Hast Du mal versuch tin dem worppress Verzeichnis einfach mal ein :
ln -s wordpress . Wenn das vorher mit www.meine-Domain.de/wordpress geklappt hat, sollte es hinterher auch klappen. Ist zwar ein "q&d-hack", sollte aber auf die schnelle helfen.
lks
Er wird auf dem Ding nicht per Shell arbeiten (Annahme ;))
Entweder ich habe jetzt irgendetwas nicht berücksichtigt - oder ihr 
Der TE hat seinen VirtualHost eingerichtet, damit in seinen URLs kein 'wordpress' mehr erscheint. Wenn er allerdings diesen wordpress-Ordner jetzt wieder in das webroot des neuen VHost verschieben soll, ändert sich daran doch mal schlicht gar nichts. Oder doch?
@TE: Wenn es unformatiert erscheint, dann liegt das ganze in der Regel tatsächlich daran, dass die Dateien, die zur Definition des Aussehens notwendig sind, nicht gefunden werden. In der Regel richtet man es so ein, dass im Quellcode im Abschnitt zwischen <head> und </head> ein Element wie z.B. <base href="http://www.example.org"> erscheint, und alle Bilder (bzw. allgemeiner Dateien) und Verlinkungen auf andere Seiten nur noch relativ verknüpft werden, d.h. dass da der Anfangsteil weggelassen wird, der schon im href-Attribut des base-Tag steht, weil sich der verbleibende Teil auf dieses base bezieht.
Für eine css-Datei sieht das ganze dann z.B. so aus: (wenn Du in den Quelltext der Seite schaust, wirst Du sowas entdecken)
Mit absolutem Pfad: <link rel="stylesheet" type="text/css" href="http://192.168.32.5/css/stylesheet.css" />
Aufgeteilt auf Basis und relativen Pfadwird: <base href="http://192.168.32.5"> und <link rel="stylesheet" type="text/css" href="/css/stylesheet />.
Der Browser weiß dann, dass er die Links zusammen bauen muss, wenn er die Dateien oder Seiten erreichen will, die sich dahinter verbergen. Und Du musst die Links nicht ändern, wenn Du die ganze Wordpress-Installation verschiebst oder die Adresse änderst, unter der sie zu erreichen ist.
Der Vollständigkeit halber sei übrigens noch gesagt, dass es oft sogar ohne base-Tag geht - in diesem Fall nimmt der Browser dann wohl einfach die Adresse, die er gerade aufgerufen hat, als Basisadresse an.
Ich hoffe, das hilft Dir ein bißchen zum Verständnis - und wenn Du es schon wusstest, kannst Du es ja einfach ignorieren...
Der TE hat seinen VirtualHost eingerichtet, damit in seinen URLs kein 'wordpress' mehr erscheint. Wenn er allerdings diesen wordpress-Ordner jetzt wieder in das webroot des neuen VHost verschieben soll, ändert sich daran doch mal schlicht gar nichts. Oder doch?
@TE: Wenn es unformatiert erscheint, dann liegt das ganze in der Regel tatsächlich daran, dass die Dateien, die zur Definition des Aussehens notwendig sind, nicht gefunden werden. In der Regel richtet man es so ein, dass im Quellcode im Abschnitt zwischen <head> und </head> ein Element wie z.B. <base href="http://www.example.org"> erscheint, und alle Bilder (bzw. allgemeiner Dateien) und Verlinkungen auf andere Seiten nur noch relativ verknüpft werden, d.h. dass da der Anfangsteil weggelassen wird, der schon im href-Attribut des base-Tag steht, weil sich der verbleibende Teil auf dieses base bezieht.
Für eine css-Datei sieht das ganze dann z.B. so aus: (wenn Du in den Quelltext der Seite schaust, wirst Du sowas entdecken)
Mit absolutem Pfad: <link rel="stylesheet" type="text/css" href="http://192.168.32.5/css/stylesheet.css" />
Aufgeteilt auf Basis und relativen Pfadwird: <base href="http://192.168.32.5"> und <link rel="stylesheet" type="text/css" href="/css/stylesheet />.
Der Browser weiß dann, dass er die Links zusammen bauen muss, wenn er die Dateien oder Seiten erreichen will, die sich dahinter verbergen. Und Du musst die Links nicht ändern, wenn Du die ganze Wordpress-Installation verschiebst oder die Adresse änderst, unter der sie zu erreichen ist.
Der Vollständigkeit halber sei übrigens noch gesagt, dass es oft sogar ohne base-Tag geht - in diesem Fall nimmt der Browser dann wohl einfach die Adresse, die er gerade aufgerufen hat, als Basisadresse an.
Ich hoffe, das hilft Dir ein bißchen zum Verständnis - und wenn Du es schon wusstest, kannst Du es ja einfach ignorieren...
Nein, die Daten liegen dann unter wp der virtualhost verweisst auf wp, daher ist der pfad unsichtbar. Nur wordpress existiert als unterverzeichnis nach wie vor. Daher keine Zerstückelten Verweise -> alles geht.
Ich habe mich an Deine Anweisung gehalten. wordpress befindet sich nun unterhalb von webroot/wp
Beim Aufruf der Wordpress Verwaltung erhalte ich nun diese Fehlermeldung.
Warning: require(/var/services/web/wordpress/wp-blog-header.php): failed to open stream: No such file or directory in /volume1/web/wordpress/index.php on line 17 Fatal error: require(): Failed opening required '/var/services/web/wordpress/wp-blog-header.php' (include_path='.:/usr/syno/php/lib/php') in /volume1/web/wordpress/index.php on line 17
Beim Aufruf der Wordpress Verwaltung erhalte ich nun diese Fehlermeldung.
Warning: require(/var/services/web/wordpress/wp-blog-header.php): failed to open stream: No such file or directory in /volume1/web/wordpress/index.php on line 17 Fatal error: require(): Failed opening required '/var/services/web/wordpress/wp-blog-header.php' (include_path='.:/usr/syno/php/lib/php') in /volume1/web/wordpress/index.php on line 17
Ich denke mein primäres Problem sind die verweise im Quelltext. Die von Wordpress erstellte Seite trägt an vielen Stellen eine lokale IP Adresse. Das kann so nicht funktionieren. Ich habe diese Anleitung gefunden, um die IP Adresse in die öffentliche zu ändern.
http://codex.wordpress.org/Changing_The_Site_URL
Ich finde den Weg aber sehr aufwendig und ich kann mir einfach nicht vorstellen, dass das der richtige Weg ist. Immerhin müsste das doch dann jeder Admin machen, denn ein Server ist ja immer Zweibeinig unterwegs. Ich will nicht glauben, dass jeder Admin die externe IP über den beschriebenen Weg in Wordpress einbinden muss.
http://codex.wordpress.org/Changing_The_Site_URL
Ich finde den Weg aber sehr aufwendig und ich kann mir einfach nicht vorstellen, dass das der richtige Weg ist. Immerhin müsste das doch dann jeder Admin machen, denn ein Server ist ja immer Zweibeinig unterwegs. Ich will nicht glauben, dass jeder Admin die externe IP über den beschriebenen Weg in Wordpress einbinden muss.
Ich habe bisher nicht viel mit Wordpress zu tun gehabt, aber ich vermute dass dir hier direkt zu Beginn ein Einrichtungsfaux-pas unterlaufen ist. Sind denn schon größere Datenmengen in der Installation? Wenn nicht: Schmeiss es runter und Installier es neu.
Den Weg werde ich auch bald gehen, aber vielleicht fällt Dir hierzu was ein. Das Ändern der URL scheint bei Wordpress tatsächlich etwas eklig zu sein, aber nicht so aufwändig wie gedacht. Siehe hier:
http://www.scriptease.de/phpmyadmin-anpassung-nach-wordpress-umzug/
http://faq.wpde.org/wordpress-url-aendern/
Obwohl die Links in der Datenbank, welche ich mit PHPMyAdmin einsehen kann alle stimmen, also http://meine-domain.de/wordpress/artikel... hat die Änderung der Seiten URL zur Folge, dass der Link meine Domain zwei mal enthält. Also so http://meine-domain.de/wordpress/meine-domain.de/wordpress/artikel..
Dieser Link steht so nicht in der Datenbank. Auch nicht im Quelltext. Das verstehe ich nicht.
http://www.scriptease.de/phpmyadmin-anpassung-nach-wordpress-umzug/
http://faq.wpde.org/wordpress-url-aendern/
Obwohl die Links in der Datenbank, welche ich mit PHPMyAdmin einsehen kann alle stimmen, also http://meine-domain.de/wordpress/artikel... hat die Änderung der Seiten URL zur Folge, dass der Link meine Domain zwei mal enthält. Also so http://meine-domain.de/wordpress/meine-domain.de/wordpress/artikel..
Dieser Link steht so nicht in der Datenbank. Auch nicht im Quelltext. Das verstehe ich nicht.
macht nichts, dann benuzt man eben php:
symlink("myOriginalFileOrDirectory", "mySymbolicLink"); lks
Zitat von @Lochkartenstanzer:
> Zitat von @falscher-sperrstatus:
>
> Er wird auf dem Ding nicht per Shell arbeiten (Annahme ;))
macht nichts, dann benuzt man eben php:
lks
> Zitat von @falscher-sperrstatus:
>
> Er wird auf dem Ding nicht per Shell arbeiten (Annahme ;))
macht nichts, dann benuzt man eben php:
symlink("myOriginalFileOrDirectory", "mySymbolicLink"); lks
Doch doch, ich bin per SSH auf der Maschine drauf. PHP und Web (CMS) sind nicht meine stärke. Mir sagt dein symlink Befehl nichts. Was kann/soll ich damit bewirken?
Zitat von @mexx:
Doch doch, ich bin per SSH auf der Maschine drauf. PHP und Web (CMS) sind nicht meine stärke. Mir sagt dein symlink Befehl
nichts. Was kann/soll ich damit bewirken?
Doch doch, ich bin per SSH auf der Maschine drauf. PHP und Web (CMS) sind nicht meine stärke. Mir sagt dein symlink Befehl
nichts. Was kann/soll ich damit bewirken?
So wie ich Dein problem verstanden habe, hast Du zuerste deine webseite mit
http://domainname/wordpress Dann hast du den documentroot eine Ebene tiefer angesetzt, weil du nur
http://domainname/ Nun war mein Vorschlag, wohlgemerkt ein quick & dirty - hack, einfach einen link im documentroot zu setzen.
Also:
cd /volume1/web/wordpress
ln -s . wordpress
in der shell eintippen und dann mal schauen, ob es geht. durch den link ist es möglich auf das verzeichnis sowohl mit http://domainname/ als auch mit http://domainname/wordpress zuzugreifen. dadurch sollte der Pfad wieder eingiermaßen passen.
Wie gesagt, ein quick'ndirty-hack der auf die schnelle helfen soll.
lks
PS: das
symlink("myOriginalFileOrDirectory", "mySymbolicLink"); symlink("/volume1/web/wordpress", "/volume1/web/wordpress/wordpress"); PP: wenn man keinen ssh-Zugriff hat, kann man immer noch zut Not die PHP-Shell verwenden.
ich geb dir prinzipiell Recht. Nur in der Zeit, in der er hier bereits herumdoktort kann man zig^n Wordpressinstallationen hochziehen und ist weiter als wir hier.
Zitat von @falscher-sperrstatus:
ich geb dir prinzipiell Recht. Nur in der Zeit, in der er hier bereits herumdoktort kann man zig^n Wordpressinstallationen
hochziehen und ist weiter als wir hier.
ich geb dir prinzipiell Recht. Nur in der Zeit, in der er hier bereits herumdoktort kann man zig^n Wordpressinstallationen
hochziehen und ist weiter als wir hier.
Klar sauber neu aufsetzen ist hier sinnvoller, Mein Vorschlag war nur dazu gedacht, "schnell" Abhilfe zu schaffen, wenn er in Zeitnot gewesen wäre. Wär es nur was für den Übergang, bis man die saubere Version hochgezogen hat.
lks
ZWISCHENSTAND FÜR ZUKÜNFTIGE LESER
Meine Herren, vorab vielen Dank für Ihre Geduld.
Es ist nicht ganz so komplex, wie Sie beide denken. Ich hatte bei der Wordpressinstallation nicht die Möglichkeit die Seiten URL zu konfigurieren. Die Installation hat einfach die LAN IP des Servers genommen. Eine Veröffentlichung ist damit natürlich nicht möglich, da alle Links auf die LAN IP verwiesen. Der einzig mir bekannte weg, auch nach langer Recherche, ist ein SQL Command. Damit könne man die Links auf eine öffentliche Adresse umschreiben.
Hier die SQL: UPDATE wp_options SET option_value = replace(option_value, 'http://192.168.xxx.xxx/wordpress', 'meine-domain.de/wordpress');
Dieser Befehl funktionierte sehr gut. Nun bleiben aber noch zwei Probleme.
1. Menüs haben als Link nicht "meine-domain.de/wordpress/seite" sondern "meine-domain.de/wordpress/meine-domain.de/wordpress/seite" also 2 mal mein-domain.de/wordpress. Im Quelltext steht das aber nicht.
2. Das ursprüngliche Problem, der fehlenden Formatierung beim Verwenden eines virtuellen Host in der apache Konfiguration, führe ich die fehlerhaften Seiten URLs hin. Lokale IPs haben da nichts zu suchen.
Wenn ich Problem 1. behoben habe, denke ich Problem 2 schnell lösen zu können. Im Augenblick habe ich aus Backups den first install Zustand zurückgeholt. Es gibt im Augenblick keine virtuellen Host und keine andere Konfiguration bis auf den update Befehl zum Ändern der Seiten URL.
Hat jemand eine Idee, warum diese Änderung das in Punkt 1 beschriebene Problem verursacht?
Meine Herren, vorab vielen Dank für Ihre Geduld.
Es ist nicht ganz so komplex, wie Sie beide denken. Ich hatte bei der Wordpressinstallation nicht die Möglichkeit die Seiten URL zu konfigurieren. Die Installation hat einfach die LAN IP des Servers genommen. Eine Veröffentlichung ist damit natürlich nicht möglich, da alle Links auf die LAN IP verwiesen. Der einzig mir bekannte weg, auch nach langer Recherche, ist ein SQL Command. Damit könne man die Links auf eine öffentliche Adresse umschreiben.
Hier die SQL: UPDATE wp_options SET option_value = replace(option_value, 'http://192.168.xxx.xxx/wordpress', 'meine-domain.de/wordpress');
Dieser Befehl funktionierte sehr gut. Nun bleiben aber noch zwei Probleme.
1. Menüs haben als Link nicht "meine-domain.de/wordpress/seite" sondern "meine-domain.de/wordpress/meine-domain.de/wordpress/seite" also 2 mal mein-domain.de/wordpress. Im Quelltext steht das aber nicht.
2. Das ursprüngliche Problem, der fehlenden Formatierung beim Verwenden eines virtuellen Host in der apache Konfiguration, führe ich die fehlerhaften Seiten URLs hin. Lokale IPs haben da nichts zu suchen.
Wenn ich Problem 1. behoben habe, denke ich Problem 2 schnell lösen zu können. Im Augenblick habe ich aus Backups den first install Zustand zurückgeholt. Es gibt im Augenblick keine virtuellen Host und keine andere Konfiguration bis auf den update Befehl zum Ändern der Seiten URL.
Hat jemand eine Idee, warum diese Änderung das in Punkt 1 beschriebene Problem verursacht?
LÖSUNG
1. In meinen Fall wird bei der Installation von Wordpress keine Konfiguration während der Installation angezeigt. Die Installation nimmt sich die URL vom Server als HOME und SITE URL. Wenn ich die Installation also mit der lokalen LAN IP des Servers durchführe, ist SITE UND HOME URL die LAN IP. Bei der Installation per öffentlicher URL oder WAN IP, so stimmen die Einträge.
2. In meinen Fall habe ich im Admin Menü von Wordpress, die SITE URL von www.meine-domaine.de/wordpress auf www.meine-domain.de gelegt und den Inhalt aus wordpress im DocumentRoot von Apache, in meinen Fall /volume1/web kopiert.
3. Nach dieser Änderung ist in der wp-config.php der Eintrag define('RELOCATE', true) notwendig, um die Änderungen der Adresse in alle Seiten durchzureichen.
An dieser Stelle vielen Dank an alle helfenden und besonders certifiedit! ;)
1. In meinen Fall wird bei der Installation von Wordpress keine Konfiguration während der Installation angezeigt. Die Installation nimmt sich die URL vom Server als HOME und SITE URL. Wenn ich die Installation also mit der lokalen LAN IP des Servers durchführe, ist SITE UND HOME URL die LAN IP. Bei der Installation per öffentlicher URL oder WAN IP, so stimmen die Einträge.
2. In meinen Fall habe ich im Admin Menü von Wordpress, die SITE URL von www.meine-domaine.de/wordpress auf www.meine-domain.de gelegt und den Inhalt aus wordpress im DocumentRoot von Apache, in meinen Fall /volume1/web kopiert.
3. Nach dieser Änderung ist in der wp-config.php der Eintrag define('RELOCATE', true) notwendig, um die Änderungen der Adresse in alle Seiten durchzureichen.
An dieser Stelle vielen Dank an alle helfenden und besonders certifiedit! ;)
gerne, jetzt noch als gelöst und ggf als zur Lösung beigetragen markieren und einen schönen Abend.
