Töötan kliendiga, kellel on juba oma domeenis loodud kohandatud e-kaubanduse veebisait, nt. example.com

Soovime võõrustada nende WordPressi ajaveebi nende domeeni alamkataloogis nt. example.com/blog Turvaprobleemide tõttu ei saa me WordPressi hostida ülejäänud saidiga samas serveris.

Oleme loonud eraldi serveri, mis haldab WordPressi ajaveebi, ja andnud sellele ajutise alamdomeeni URL-i.

Kuidas teha nii, et example.com/blog teeniks meie serveris Wordpressi saiti? Me ei soovi ümbersuunamist, vaid seda, et kogu blogi oleks hostitud alamkataloogis '/ blog'. Millised URL-id paneme WordPressi andmebaasi? Kuidas peaksid nad oma alamkataloogi ümber suunama?

Ma tean, et inimesed soovitavad kasutada alamdomeeni (see on meil praegu olemas), kuid klient on SEO parema toimimise tagamiseks spetsiaalselt taotlenud alamkataloogi kasutamist.

  • Alamdomeenid pole SEO jaoks sugugi halvemad. Vaadake: Kas alamdomeenid aitavad / kahjustavad SEO-d?
  • @StephenOstermiller Aitäh! Jah, olen sama kuulnud erinevatest allikatest. Pean selle oma klientidele edasi andma.

Alamdomeen on kindlasti kõige lihtsam valik, kuna soovite hostida saiti mõnes teises serveris. Selle põhjuseks on see, et hostinimi saab kunagi lahendada ainult ühe asukoha. Kui olete muutunud URL-ide pärast SEO pärast mures, võiksite kaaluda selle asemel suunamist alamdomeenile.

Kuna aga otsite konkreetselt alamdomeeni vältimist, keskendutakse ülejäänud vastuses sellele, kuidas seda teha.

Kui soovite, et teenust / blogi / teist serveeritaks teisest serverist, peate looma vastupidise puhverserveri. Sõltuvalt teie juurdepääsutasemest praegusele veebiserverile oleks parim võimalus luua vastupidine puhverserver. Järgmised juhised võivad rakendamiseks ja tõrkeotsinguks vajada mõningaid oskusi serverimuudatustega.

Apache'i kasutamine

Eeldades, et kasutate Apache'i, võite lisada sellise reegli:

ProxyPass /blog/ http://example.com/blog ProxyPassReverse /blog/ http://example.com/blog 

Võite selle asetada oma VirtualHost'i kirjesse või kuhugi oma httpd.conf-i. See eeldab, et teil on mod_proxy installitud ja see nõuab Apache'i taaskäivitamist.

Kui kasutate populaarset cPanelit, võite siit otsida asukohti, kuhu saab paigutada faili, mille nimi lõpeb .conf: https://documentation.cpanel.net/display/EA/Modify+Virtualhost+Containers+With+Include+Files

Kui kasutate cPaneli, mod_proxy peaks olema kaasas, nii et te ei peaks selle pärast muretsema, kuid peate seda tegema /scripts/rebuildhttpdconf ja taaskäivitage Apache.

See võimaldaks teil luua ühenduse teise asukohaga, et haarata tegelikud ajaveebilehed teie praeguse serveri kaudu esitamiseks.

Nagu paljude CMS-ide puhul, on WordPressi probleem see, et see on URL-i jaoks, mida sellele juurde pääsete, väga valiv. See tähendab, et kui loote ühenduse alamdomeeniga, siis kui saidi URL ei ühildu, teenib WordPress 404. Samuti väljastab WordPress sageli ümbersuunamisi koos saidi URL-iga. Seetõttu peate tõenäoliselt serveri arvama, et loote ühenduse sama URL-iga, isegi kui ühendate kaugserveriga. Keeruline on see, et oma serveri muutmiseks vajate ka juurjuurdepääsu hosts faili. Linuxi serveris leiate selle aadressilt /etc/hosts/ja võite lisada järgmise rea:

123.123.123.123 example.com 

Kus 123.123.123.123 oleks selle serveri IP, kus te blogi majutaksite. Loomulikult töötab see ainult siis, kui miski muu selles serveris ei looda ühendust saidiga example.com luua.

Nginxi kasutamine

Kui kasutate Nginxi, mis on natuke vähem levinud, võiksite seda teha natuke lihtsamalt:

upstream blogbackend { server 123.123.123.123:80; } location /blog { proxy_pass http://blogbackend; } 

Kuna Nginx võimaldab teil taustaprogrammi jaoks IP-d määrata, ei peaks te sellega mängima hosts faili.

Siteurl

Mõlemal juhul peaks kaugserver koos ajaveebiga olema konfigureeritud teenima sisu http://example.com/blogja see olgu option_value mõlemale siteurl ja home prefiksis $options tabel. Kui see on algne URL, ei peaks te seda muutma. Kui peate muudatusi tegema, olge valmis kontrollima kõiki kodeeritud URL-e, näiteks üleslaaditud pilte jne.

Järeldus

See lahendus on natuke segane ja palju võib valesti minna. Kuid see on ikkagi tõenäoliselt puhtam kui järgmine alternatiiv, kus teil on sisu / blogi / teenus PHP puhverserveri kaudu, kasutades võib-olla lokke. See on põhjus, miks standardne lähenemine oleks lihtsalt alamdomeeni kasutamine.

  • ProxyPass ja ProxyPassReverse (kui ma õigesti mäletan) nõuavad, et kaasataks moodul, mida kõik installid vaikimisi alati ei sisalda. See nõuab ka Apache taaskäivitamist. Tundub, et mäletan, et pidin konfiguratsiooni muutma enne, kui ProxyPass ja ProxyPassReverse minu test Apache 2.4 installimisel töötaksid. Väärib märkimist oma vastuses. Terviseks !!
  • @closetnoc Aitäh. Mõtlesin, et hakkan süsteemi administreerimisse juba natuke liiga sügavale minema. Lisasin ka natuke lahtiütlemist.
  • Täname selle üksikasjaliku vastuse eest @DKing - minu kliendil on arendaja, kes tegeleb kõigi serverite asjadega, nii et ma arvan, et nad on seda teinud vastupidise puhverserverina Nginxi abil. Uuendasin meie WP andmebaasi URL-e uue alamkataloogi URL-i kasutamiseks. Kõik näib töötavat praegu hästi, kuid wp-adminis on vigu. Täpsemalt Wordpress-postituse loomisel tõrge "502 Bad Gateway nginx". WP-teema suvandite salvestamisel on ka juurdepääs keelatud. Kas need võivad olla põhjustatud teie arvates puhverserverist või wp valest seadistamisest? Aitäh veel kord!
  • @ J.Purcell 502 võib olla seotud nginxiga või mitte, kuid teema valikute salvestamine oleks tõenäoliselt WordPressi probleem, näiteks lubade probleem. Puhverserver edastab lihtsalt teavet, nii et kui teemat muudate, tuleks seda teha ülesvooluserveris, nii et ma uuriksin seda kõigepealt seal. Ma tegeleksin sellega enne 502 väljaande vaatamist.
  • 1 @Baumr Muidugi. Olen postitanud vastuse.

Teie serveril on IP-aadress, nii et saate selle lihtsalt haarata ja seejärel luua alamdomeeni kõikjal, kus domeeni DNS-i hostitakse. Nii et öelge, et soovite luua blog.domain.com, saate selle oma serverite IP-aadressile osutada.

  • Täname vastuse eest, kuid küsimus oli selles, kuidas suunata alamkataloog teise serverisse, mitte alamdomeeni. Kuid minu probleem lahenes minu koostöös teiste arendajatega, kasutades vastupidist puhverserverit. Aitäh!

none: Charles Robertson | none