Beiträge von cdetree
-
-
Ich habe so ein Teil seit Jahren im Einsatz. Gleiches Szenario nur gewachsener Content.
Insgesammt so etwa 5.000 Seiten in diversen Sprachen. Nie ein Problem gehabt...Deine Schätzung bzgl. des zeitlichen Aufwands halte ich für gewagt. Dafür brauchst Du garantiert länger, wenn die Daten nicht importierbar sind.
-
Hallo!
Ich verstehe Deine Konfiguration nicht ganz. Dennoch habe ich das Gefühl, "diese Weiterleitungen" Deiner 2. Domain sind nicht zielführend. Stattdessen müssen die Domains für Deine Wordpress-Multisite einfach direkt auf Deinen Wordpress-Ordner gemappt werden.
Wie man dann ein Wordpress Multisite mit Multidomain Setup konfiguriert findest Du z.B. hier: http://interconnectit.com/840/wordpress-…-domains-setup/ -
Salve Forum!
Ich habe ein sehr spezielles Problem und suche einen Tip zur Lösung.
Folgendes Wordpress-Setup:
- Multiblog-Installation in Unterverzeichnisse (als unterschiedliche Sprachversionen des selben Blogs)
- Blog-ID1 liegt auf der Domain http://www.xyz.de
- Blog-ID2 liegt auf http://www.xyz.de/en/
- Blog-ID3 liegt auf http://www.xyz.de/fr/
- Blog-ID4 liegt ...
- ...
- Eine Datenbank (auf separatem DB-Server) und
- eine Installation (auf Web-Server).
Soweit funktioniert alles einwandfrei und das schon seit Jahren.---------
Jetzt kommt der Reverse-Proxy (i.F. RP) ins Spiel.
Die Original-URLs sollen per RP wie folgt umgeschrieben werden:
- Blog-ID1 http://www.xyz.de --> http://www.abc.de/info/
- Blog-ID2 http://www.xyz.de/en/ --> http://www.abc.de/en/info/
- ...
Soweit ist das kein Problem.Der RP funktioniert und ch habe eine kleine Extension geschrieben, die die entsprechenden $_SERVER-Variablen patcht und die internen Links per Filter so umbiegt, dass die aufgerufene Seite innerhalb der RP-Umgebung bleibt.
Die RP-Konfiguration wurde durch meinen Hoster erstellt und mehrfach überprüft. (Managed Hosting!)
Bei Blog-ID1 funktioniert das prächtig.
Bei Blog-ID2,3,4,... jedoch nicht.
Hier wird immer die 404-Seite ausgegeben - egal, welche Inhalte ich abrufe. Einzige Ausnahme ist die interne Suche und damit die Suchergebnisseite. Die liefert zwar keine Ergebnisse, jedoch die (leere) Suchergebnisseite.Meine Vermutung: Irgendeine interne Wordpress-Routine kommt mit den umgeschriebenen Daten nicht klar.
Meine Fragen:
1. Welche Routine könnte das sein?
2. Welche Anpassungen müsste ich noch vornehmen?Vorab schon mal vielen Dank für Eure Unterstützung!
Hier der Quelltext meiner Anpassungsroutine:
PHP
Alles anzeigen/* * # x-forwarded-host.php # * * `HTTP_X_FORWARDED_HOST` header for the duration of a single request in WordPress. * * ## Installation ## * First, put this file into the `wp-includes` folder of a WordPress installation. * Edit `wp-settings.php`. Just before the call to `wp_plugin_directory_constants`, * add this line: require( ABSPATH . WPINC . '/x-forwarded-host.php' ); */ define('XFH_SLUG', 'info'); // Return TRUE if this request has been forwarded. function is_forwarded() { return array_key_exists('HTTP_X_FORWARDED_HOST', $_SERVER); } // Return a short output version of get_locale(). function get_s_locale() { $localeLong = get_locale(); if ($localeLong != '') { $locale = preg_replace('@(?<=^..).*@', '', $localeLong); } else { $locale = 'en'; } return $locale; } // Patch and return 'HTTP_X_FORWARDED_HOST'. function forwarded_host() { if (is_forwarded()) { return $_SERVER['HTTP_X_FORWARDED_HOST']; } } // Patch and return 'REQUEST_URI'. function patch_request_uri() { if (is_forwarded()) { return $_SERVER['REQUEST_URI'] . XFH_SLUG; } } // Patch and return 'SCRIPT_NAME'. function patch_script_name() { if (is_forwarded()) { $locale = get_s_locale(); if ($locale == 'de') { return "/" . XFH_SLUG . $_SERVER['SCRIPT_NAME']; } else { return "/" . $locale . "/" . XFH_SLUG . $_SERVER['SCRIPT_NAME']; } } } // Patch and return 'PHP_SELF'. function patch_php_self() { if (is_forwarded()) { $locale = get_s_locale(); if ($locale == 'de') { return "/" . XFH_SLUG . $_SERVER['PHP_SELF']; } else { return "/" . $locale . "/" . XFH_SLUG . $_SERVER['PHP_SELF']; } } } /* * Create a base URL using the original `Host` header. Rather than trying to sort out * whether to use `http` or `https`, just keep using whatever the scheme was for this * request. This is a good strategy when using a reverse proxy because the proxy can * handle redirecting all requests from http to https, for example. * * Also here the category slug is defined, for example "/category", in case of your * reverse proxy config. */ // Return the forwarded modified and patched URL. function forwarded_url() { if (is_forwarded()) { $host = forwarded_host(); $locale = get_s_locale(); if ($locale == 'de') { $complete = $host . "/" . XFH_SLUG . "/"; } else { $complete = $host . "/" . $locale . "/" . XFH_SLUG; } return "http://$complete"; } } // Patch the `$_SERVER` superglobal, replacing the host with the forwarded host. // Some parts of wordpress (particularly `redirect_canonical`) use ` // $_SERVER['HTTP_HOST'],['HTTP_X_ORIG_HOST'],['REQUEST_URI'], // ['SCRIPT_NAME'],['PHP_SELF'],['REMOTE_ADDR']. function x_host_patch_server() { if (is_forwarded()) { $_SERVER['HTTP_X_ORIG_HOST'] = $_SERVER['HTTP_HOST']; $_SERVER['HTTP_HOST'] = forwarded_host(); $_SERVER['REQUEST_URI'] = patch_request_uri(); $_SERVER['SCRIPT_NAME'] = patch_script_name(); $_SERVER['PHP_SELF'] = patch_php_self(); $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR']; } } // Override the value of `home` and `siteurl`. function x_host_patch_url() { if (!is_forwarded()) { return false; } return forwarded_url(); } add_filter('pre_option_home', 'x_host_patch_url'); add_filter('pre_option_siteurl', 'x_host_patch_url');