Możesz to zrobić za pomocą dostosowanego pliku sunrise.php. Zasadniczo działa to wtyczka mapowania domen, jednak stanowi ona całkiem niezły interfejs. Dla czegoś niestandardowego możesz napisać prosty PHP, aby zrobić to samo.
Istotą wielu witryn jest ustalenie, która witryna będzie obsługiwana. Wtyczka mapowania domen robi to, tworząc tabelę wp_domain_mapping i przechowując tam informacje. Dlatego gdy otrzyma żądanie dotyczące witryny xxx.com, przegląda tę tabelę i widzi, że odpowiada to blog_id 123.
Najpierw utwórz konfigurację WordPress i skonfiguruj ją w wielu miejscach. Nie ma znaczenia, gdzie tak naprawdę żyje, ponieważ zamierzamy to wszystko zmienić. Dla uproszczenia umieściłem go na blog.stackexchange.com i uczyniłem go witryną typu podkatalogu (te są łatwiejsze). Utworzone podkatalogi prawdopodobnie byłyby ślimakami. / wordpress, / apple, / cokolwiek.
Więc tak, na początek, naprawdę tworzysz go na blog.stackexchange.com/wordpress. Rozważ to środowisko przejściowe. Podczas tworzenia każdej witryny możesz tutaj robić różne rzeczy, dopóki nie zdecydujesz się włączyć mapowania.
Aby samodzielnie zmapować domenę, bez wtyczki zrobiłbyś coś takiego:
Krok pierwszy: dodaj define( 'SUNRISE', 'on' );na górę pliku wp-config.php.
Krok drugi: utwórz plik sunrise.php w katalogu wp-content. <?phpNa początek postaw na górze.
Krok trzeci: W pliku sunrise.php będzie twoja logika do określania, którą stronę załadować.
Oprzesz to na $_SERVER[ 'HTTP_HOST' ]zmiennej. Sposób, w jaki to robisz, jest łatwy: jednak chcesz to zrobić. Jeśli chcesz napisać wyrażenie regularne w celu wyszukania, '/blog\.(.*)\.stackexchange\.com/'a następnie wyszukać ten bit w bazie danych, możesz to zrobić.
Ponieważ używasz tego samego ślimaka, co „podkatalog”, nie potrzebujesz osobnej tabeli. Możesz po prostu zajrzeć do głównej tabeli wp_blogs, aby znaleźć potrzebną witrynę. Coś podobnego do tego:
$current_blog = $wpdb->get_var( "SELECT blog_id FROM {$wpdb->blogs} WHERE path = '/wordpress/' LIMIT 1" );
Gdy już masz $ current_blog, potrzebujesz następującego kodu:
$current_blog->domain = $_SERVER[ 'HTTP_HOST' ];
$current_blog->path = '/';
$blog_id = $current_blog->blog_id;
$site_id = $current_blog->site_id;
$current_site = $wpdb->get_row( "SELECT * from {$wpdb->site} WHERE id = '{$current_blog->site_id}' LIMIT 0,1" );
$current_site->blog_id = $current_blog->blog_id;
To predefiniuje zmienne globalne $ current_blog i $ current_site zamiast pozwalać na to funkcjom WordPress 'MU.
To wystarczyłoby, aby strona była uruchomiona i działała (po tym, jak DNS wskaże na nią i uporządkuje wirtualny hosting), jednak większość statycznych adresów URL używanych w kodzie HTML nadal wskazywałaby na blog.stackexchange.com / wordpress, ponieważ taka byłaby naprawdę strona. Również funkcja Canonical URL prawdopodobnie nie spodoba się adresowi URL i przekieruje również ciebie.
Aby rozwiązać te problemy, prawdopodobnie zechcesz wstępnie zdefiniować kilka adresów URL powiązanych z witryną. Rzeczy takie jak WP_SITEURL i WP_HOME. Ponadto WP_CONTENT_URL, WP_PLUGIN_URL i WPMU_PLUGIN_URL. Powinno to obejmować większość przypadków dostosowywania adresów URL.
Na koniec będziesz chciał ustawić „COOKIE_DOMAIN”. Ponieważ prawdopodobnie chcesz, aby loginy były współużytkowane przez całą rzecz, możesz ustawić ją na stackexchange.com, lub nawet wyżej, jeśli nie chcesz, aby były to loginy współdzielone.
Jeśli chcesz porozmawiać o integracji normalnego systemu logowania Stackexchange do WordPress, mogę również odpowiedzieć na pytania na ten temat, ale byłoby to bardziej szczegółowe. :)
Jeśli chcesz uzyskać dodatkową pomoc, napisz do mnie e-mail. Cieszę się, że mogę pomóc: otto na wordpress.org.