Mehrere WP Instanzen | WordPress.org Deutsch

Gelöst Uwe
(@uweportugal)

vor 2 Jahren, 2 Monaten

Hallo zusammen,
ist es nicht mehr möglich mehrere WordPress Installationen auf eine URL zu legen? Ich habe eine im Hauptverzeichnis und eine im Unterverzeichnis. Die haben über Jahre funktioniert, doch auf einmal, ohne mein Zutun, werden nur noch, mit Ausnahme der Startseite, 404 Seiten im Unterverzeichnis angezeigt. Ich musste dort die Permalinkstruktur verändern (Einfach), damit überhaupt einige Seiten angezeigt werden.
Hat Jemand eine Idee wo das Problem liegt, oder ist es wirklich nicht mehr möglich weitere WP-Installationen in Unterverzeichnissen zu haben?

Die Seite, für die ich Hilfe brauche: [Anmelden, um den Link zu sehen]

Ansicht von 11 Antworten - 1 bis 11 (von insgesamt 11)

Moderator Bego Mario Garde
(@pixolin)

vor 2 Jahren, 2 Monaten

Hast du mal geschaut, ob im Verzeichnis /blog eine .htaccess-Datei liegt?
Was passiert, wenn du für diese Website die Permalinks auf „Beitragsname“ umstellst?
Thread-Starter Uwe
(@uweportugal)

vor 2 Jahren, 2 Monaten
Danke für die Antwort,
ja, die htaccess-Datei ist vorhanden.
Die Einstellungen standen immer auf Beitragsname.
Ohne mein Zutun gab es auf einmal nur noch 404 Seiten, deshalb habe ich auf „Einfach“ umgestellt damit überhaupt etwas angezeigt wird.
Hier die htaccess Datei wie sie ursprünglich war:
```
# BEGIN WordPress
# Die Anweisungen (Zeilen) zwischen „BEGIN WordPress“ und „END WordPress“ sind
# dynamisch generiert und sollten nur über WordPress-Filter geändert werden.
# Alle Änderungen an den Anweisungen zwischen diesen Markierungen werden überschrieben.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>

# END WordPress

Header always unset "X-Powered-By"

## EXPIRES CACHING ##
# BEGIN Expire headers  
<ifModule mod_expires.c>  
        ExpiresActive On  
        ExpiresByType image/x-icon "access plus 1 year"  
        ExpiresByType image/jpeg "access plus 1 year" 
        ExpiresByType image/jpg "access plus 1 year"
        ExpiresByType image/webp "access plus 1 year" 
        ExpiresByType image/png "access plus 1 year"  
        ExpiresByType image/gif "access plus 1 year"  
        ExpiresByType image/svg+xml "access plus 1 month"
        ExpiresByType application/x-font-ttf "access plus 1 year"
        ExpiresByType application/x-font-truetype "access plus 1 year"
        ExpiresByType application/x-font-opentype "access plus 1 year"
        ExpiresByType application/x-font-woff "access plus 1 year"
        ExpiresByType application/font-woff2 "access plus 1 year"
        ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
        ExpiresByType application/font-sfnt "access plus 1 year"
        ExpiresByType application/x-shockwave-flash "access plus 1 year"  
        ExpiresByType text/css "access plus 1 month"  
        ExpiresByType text/javascript "access plus 1 month"  
        ExpiresByType application/javascript "access plus 1 month"  
        ExpiresByType application/x-javascript "access plus 1 month"  
        ExpiresByType text/html "access plus 4 hours"  
        ExpiresByType application/xhtml+xml "access plus 4 hours"
        ExpiresDefault "access 28 days"  
</ifModule>  

<IfModule mod_headers.c>
	<filesMatch "\.(ico|jpe?g|png|gif|webp|swf)$">
		Header set Cache-Control "public"
	</filesMatch>
	<filesMatch "\.(css)$">
		Header set Cache-Control "public"
	</filesMatch>
	<filesMatch "\.(js)$">
		Header set Cache-Control "private"
	</filesMatch>
	<filesMatch "\.(x?html?|php)$">
		Header set Cache-Control "private, must-revalidate"
	</filesMatch>
</IfModule>

# END Expire headers

# BEGINN CACHIFY
 # GZIP FILE
 
 RewriteCond %{REQUEST_URI} /$
 RewriteCond %{REQUEST_URI} !^/wp-admin/.*
 RewriteCond %{REQUEST_METHOD} !=POST
 RewriteCond %{QUERY_STRING} =""
 RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
 RewriteCond %{HTTP:Accept-Encoding} gzip
 RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz -f
 RewriteRule ^(.*) /wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz [L]

 AddType text/html .gz
 AddEncoding gzip .gz
  
 # HTML FILE
 RewriteCond %{REQUEST_URI} /$
 RewriteCond %{REQUEST_URI} !^/wp-admin/.*
 RewriteCond %{REQUEST_METHOD} !=POST
 RewriteCond %{QUERY_STRING} =""
 RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
 RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html -f
 RewriteRule ^(.*) /wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html [L]

# END CACHIFY

# mod_deflate aktivieren
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/vtt 
AddOutputFilterByType DEFLATE text/x-component
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/js
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/atom+xml 
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/ld+json 
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject 
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/font-woff2
AddOutputFilterByType DEFLATE application/x-font-woff
AddOutputFilterByType DEFLATE application/x-web-app-manifest+json font/woff
AddOutputFilterByType DEFLATE font/woff 
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon 
</IfModule>

# END mod_deflate aktivieren

# Disk-Cache aktivieren
<IfModule mod_disk_cache.c>
CacheEnable disk /
CacheRoot "/var/cache/mod_proxy"
</IfModule>

# END Disk-Cache aktivieren

 

# Wordfence WAF
<Files ".user.ini">
<IfModule mod_authz_core.c>
	Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
	Order deny,allow
	Deny from all
</IfModule>
</Files>

# END Wordfence WAF

# BEGIN FRedirect_ErrorDocument
# Die Anweisungen (Zeilen) zwischen „BEGIN FRedirect_ErrorDocument“ und „END FRedirect_ErrorDocument“ sind
# dynamisch generiert und sollten nur über WordPress-Filter geändert werden.
# Alle Änderungen an den Anweisungen zwischen diesen Markierungen werden überschrieben.
ErrorDocument 404 /blog/index.php?error=404
# END FRedirect_ErrorDocument
```
Thread-Starter Uwe
(@uweportugal)

vor 2 Jahren, 2 Monaten
Nachtrag:

Bei Werkzeuge -> Webseite-Zustand im Statusbericht steht:
Der Aufruf der REST-API führte zu folgendem unerwarteten Ergebnis: (404)

Meine bisherigen Versuche das Problem zu beheben:
WP-Optimize war dabei deaktiviert und vorher wurden die Caches geleert.
a) Alle Plugins deaktiviert, auf das aktuelle WP-Theme 20-21 umgestellt und Permalinks auf Beitragsname gespeichert.
b) htaccess-Datei gelöscht und danach Permalinks auf Beitragsname gespeichert.
c) Support vom Hoster angeschrieben, mit der Antwort das es technisch nicht mehr möglich ist eine WP-Installation im Unterverzeichnis zu haben und ich sollte auf Subdomaine umstellen. Diese Antwort erscheint mir nicht korrekt zu sein.
d) In der functions.php habe ich testweise diesen Code eingefügt:
```
add_filter('rest_enabled', '_return_false');
add_filter('rest_jsonp_enabled', '_return_false');
```
- Diese Antwort wurde geändert vor 2 Jahren, 2 Monaten von Bego Mario Garde.
Moderator Bego Mario Garde
(@pixolin)

vor 2 Jahren, 2 Monaten
Ich hab gefragt, was passiert, wenn du die Permalinks auf Beitragsname umstellst. Da hilft mir die Aussage „Die Einstellungen standen immer auf Beitragsname.“ herzlich wenig. 🙂

Angesehen davon sollte der WordPress-Block, der bei dir als erstes in der .htaccess erscheint, erst ganz am Ende stehen. Stell das doch mal um.

Ich würde während der Fehlersuche Firewall- und Cache-Plugins deaktivieren. Du baust sonst zu viele Bauteile ein, die zu einem Fehler führen können.

Das unerwartete Ergebnis bei Aufruf der REST-API bekomme ich auch, wobei das bei Einträgen wie
```
add_filter('rest_enabled', '_return_false');
add_filter('rest_jsonp_enabled', '_return_false');
```
auch nicht sonderlich überrascht. Wie soll etwas gefunden werden, das du ausdrücklich abschaltest?

WP-Optimize war dabei deaktiviert und vorher wurden die Caches geleert.

Das … und Cachify auch noch? Warum nur?

htaccess-Datei gelöscht und danach Permalinks auf Beitragsname gespeichert.

Ja? Und? Und? 🥲

Support vom Hoster angeschrieben, mit der Antwort das es technisch nicht mehr möglich ist eine WP-Installation im Unterverzeichnis zu haben

Das ist, wie wenn du die Autobahnmeisterein fragst, ob ein VW Käfer mit Super E10 fährt. Antwort: in Braunschweig ist der Straßenbelag anders.
Nein, im Ernst: der Webhoster stellt dir gegen Gebühr einen Webserver zur Verfügung. Was du darauf wie installierst, ist deine Sache. Und WordPress im Unterverzeichnis einer WordPress-Installation zu installieren ist zwar eine extrem unsaubere Lösung, geht aber. (Besser, weil mit weniger Verwaltungsaufwand, wäre eine Multisite. Wenn es zwei getrennte Installationen sein sollen, weil z.B. die eine Installation die andere ablösen soll, wäre es besser, beide Installationen parallel in Unterverzeichnissen zu betreiben.)
Thread-Starter Uwe
(@uweportugal)

vor 2 Jahren, 2 Monaten

Sorry, aber es ist nicht immer einfach genaue Infos zu geben. Meine Beschreibungen waren wohl etwas durcheinander. Ich versuche es noch einmal:

Du: Ich hab gefragt, was passiert, wenn du die Permalinks auf Beitragsname umstellst.
Antwort: nur die Startseite wird angezeigt, alle anderen Links führen zur 404 Seite.

Du: Ich würde während der Fehlersuche Firewall- und Cache-Plugins deaktivieren. Du baust sonst zu viele Bauteile ein, die zu einem Fehler führen können.
Ich hatte bei „Meine bisherigen Versuche das Problem zu beheben“ gemeint, dass ich zuerst alle Plugins deaktiviert habe, gleichzeitig auf das aktuelle WP-Theme 20-21 umgestellt habe und sogar die htaccess Datei per FTP gelöscht habe und danach habe ich erst die Permalinks auf Beitragsname gespeichert. Eben damit ich die eventuellen Fehlerquellen htaccess, Plugin und Theme ausschalten kann.
Das Ergebnis war unverändert, nur die Startseite wurde angezeigt, alle anderen Links führten zur 404 Seite.

Die htaccess-Datei sah somit nur noch so aus:
# BEGIN WordPress
# Die Anweisungen (Zeilen) zwischen „BEGIN WordPress“ und „END WordPress“ sind
# dynamisch generiert und sollten nur über WordPress-Filter geändert werden.
# Alle Änderungen an den Anweisungen zwischen diesen Markierungen werden überschrieben.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /blog/
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress

Bei Werkzeuge -> Webseite-Zustand im Statusbericht steht: Der Aufruf der REST-API führte zu folgendem unerwarteten Ergebnis: (404)
Das war der Eintrag bevor ich die Permalinks von „Beitragsname“ auf „Einfach“ gestellt habe und anfing etwas zu versuchen.

Die zweite Installation ins Unterverzeichnis hatte ich wegen der Vorteile wegen der SEO gemacht. Aber das spielt ja zunächst keine Rolle. Es geht darum warum plötzlich die Probleme vorhanden sind und die Seiten nicht mehr funktionieren. Über die Multisites hatte ich vor einigen Tagen zum ersten mal gelesen, wäre weniger Arbeit gewesen. Jetzt umzustellen mit so vielen Blogbeiträgen…?

Moderator Bego Mario Garde
(@pixolin)

vor 2 Jahren, 2 Monaten

Sorry, aber es ist nicht immer einfach genaue Infos zu geben.

Stimmt, das ist mitunter gar nicht so einfach. Geht aber anderen auch so. Deshalb fragen wir ja auch hartnäckig nach (wie du schon gemerkt hast).

… und sogar die htaccess Datei per FTP gelöscht habe …
Das Ergebnis war unverändert, nur die Startseite wurde angezeigt, alle anderen Links führten zur 404 Seite.

Ich würde das nochmal wiederholen, aber vorher die Ninja-Firewall und alle Cache- und Optimierungs-Plugins deaktivieren. Dann erst die .htaccess in no.htaccess umbenennen und danach in Einstellungen > Permalinks die Einstellung erneut auf Beitragsname setzen und sichern. Dabei sollte eine neue .htaccess geschrieben werden (prüfen!). Funktionieren dann die Links?

Über die Multisites hatte ich vor einigen Tagen zum ersten mal gelesen, wäre weniger Arbeit gewesen. Jetzt umzustellen mit so vielen Blogbeiträgen…?

Ich würde erst einmal die vorhandene Website wieder reparieren.
Thread-Starter Uwe
(@uweportugal)

vor 2 Jahren, 2 Monaten
Nun habe ich alles so wiederholt, wie du es mir empfohlen hast, mit demselben Ergebnis, die Links funktionieren nicht, es wird die 404 Seite angezeigt.

Die htaccess-Datei wurde neu geschrieben. Es stand nur das drin:
```
# BEGIN WordPress
# Die Anweisungen (Zeilen) zwischen „BEGIN WordPress“ und „END WordPress“ sind
# dynamisch generiert und sollten nur über WordPress-Filter geändert werden.
# Alle Änderungen an den Anweisungen zwischen diesen Markierungen werden überschrieben.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /blog/
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress
```
Was mir bisher nicht aufgefallen war, dass es sich um die 404 Fehlerseite aus dem Hauptverzeichnis handelt, die immer angezeigt wird. Der Blog im Unterverzeichnis hat eine eigene Fehlerseite.

Ein weiteres Phänomen habe ich festgestellt:
Wenn ich einen Beitrag bearbeiten möchte oder einen neuen Beitrag erstellt habe und ich im Bearbeitungsmodus auf „Vorschau“ oder „Beitrag anzeigen“ klicke, dann erscheint die Fehlermeldung: Du bist leider nicht berechtigt, Entwürfe anzusehen. Oben im Karteireiter steht: WordPress Fehler.

Hilft das weiter um das Problem zu lösen?
Thread-Starter Uwe
(@uweportugal)

vor 2 Jahren, 2 Monaten

Nochmals Danke für die Zeit, die du dir genommen hast.
Das Problem lag in der htaccess-Datei im Hauptverzeichnis.
Dort musste eine weitere Zeile Code eingefügt werden, damit im Unterverzeichnis alle Seiten korrekt angezeigt werden.

Moderator Bego Mario Garde
(@pixolin)

vor 2 Jahren, 2 Monaten

Danke für die Rückmeldung.

procoder2025
(@procoder2025)

vor 2 Jahren, 1 Monat

Hallo Uwe, ich habe genau das gleiche Problem. Welche Zeile Code hat bei dir gefehlt?

Habe drei WordPress-Instanzen auf einer Domain.

Hauptseite / Blog / Rezepte

Plötzlich werden alle Unterseiten von BLOG und Rezepte auf die 404 Fehlerseite von der Hauptseite geleitet. htacces sind bei allen dreien natürlich vorhanden. Wenn ich mir dein Thread durchlese, sieht es nach dem identischen Problem aus.

Daher nochmal meine Frage, was hast du geändert? 🙂
procoder2025
(@procoder2025)

vor 2 Jahren, 1 Monat
Ich habe die Lösung gerade von Uwe per Mail erhalten :). Konnte das Problem somit ebenfalls beheben.

Für alle anderen, die zufällig auf den Thread stoßen. Hier die Lösung.
Einfach die Zeile „RewriteCond %{REQUEST_URI} !^/(blog/.*)$“ in der htaccess der Hauptseite mit dem Verzeichnis der jeweiligen Instanz hinzufügen.
```
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_URI} !^/(blog/.*)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
```
- Diese Antwort wurde geändert vor 2 Jahren, 1 Monat von procoder2025.
- Diese Antwort wurde geändert vor 2 Jahren, 1 Monat von procoder2025.

Ansicht von 11 Antworten - 1 bis 11 (von insgesamt 11)

Das Thema „Mehrere WP Instanzen“ ist für neue Antworten geschlossen.

Ansichten