Създаване на RESTful уеб услуга в PHP

Работя с клиент, който вече има персонализиран уебсайт за електронна търговия, настроен на собствен домейн, напр. example.com

Искаме да хостваме техния блог на WordPress в поддиректория на техния домейн, напр. example.com/blog Поради проблеми със сигурността не можем да хостваме WordPress на същия сървър като останалата част от сайта им.

Създадохме отделен сървър, който ще хоства блога на WordPress, и му дадохме временен URL адрес на поддомейн.

Как да направим така, че example.com/blog да обслужва сайта на Wordpress от нашия сървър? Не искаме пренасочване, искаме то да изглежда така, сякаш целият блог се хоства в поддиректорията „/ blog“. Какви URL адреси поставяме в базата данни на WordPress? Как трябва да пренасочват своя поддиректория?

Знам, че хората препоръчват да се използва поддомейн (това е, което имаме в момента), но клиентът специално е поискал да използва поддиректория за по-добра производителност на SEO.

  • Поддомените не са по-лоши за SEO. Вижте: Поддомените помагат ли / нараняват SEO?
  • @StephenOstermiller Благодаря! Да, чувал съм същото от различни източници. Ще трябва да предам това на клиентите си.

Поддомейнът със сигурност е най-лесният вариант, тъй като искате да хоствате сайта на друг сървър. Причината за това е, че името на хоста може да се разреши само до едно местоположение. Ако се притеснявате за SEO от променените URL адреси, може би бихте могли да помислите за пренасочване към поддомейна.

Тъй като обаче специално се стремите да избегнете поддомейна, останалата част от този отговор ще се съсредоточи върху това как да го направите.

Ако искате / блог / да се обслужва от различен сървър, тогава ще трябва да създадете обратен прокси. В зависимост от нивото на достъп до текущия уеб сървър, най-добрият вариант би бил да се създаде обратен прокси сървър. Следните инструкции може да изискват известни умения за промени в сървъра, за да се приложат и отстранят проблеми.

Използване на Apache

Ако приемем, че използвате Apache, можете да добавите в правило като това:

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

Можете да поставите това във вашия VirtualHost запис или някъде във вашия httpd.conf. Това предполага, че имате mod_proxy инсталиран и ще изисква рестартиране на Apache.

Ако използвате популярния cPanel, можете да потърсите тук места за поставяне на файл с име, завършващо на .conf: https://documentation.cpanel.net/display/EA/Modify+Virtualhost+Containers+With+Include+Files

Ако използвате cPanel, mod_proxy трябва да бъде включен, така че не трябва да се притеснявате с това, но ще трябва /scripts/rebuildhttpdconf и след това рестартирайте Apache.

Това би ви позволило да осъществите връзка с друго място, за да вземете действителните страници на блога, които да обслужвате през текущия си сървър.

Проблемът с WordPress, както и много CMS, е, че е много придирчив към URL адреса, който използвате за достъп до него. Това означава, че ако трябва да се свържете с поддомейн, ако siteurl не съвпада, WordPress ще обслужва 404. Също така WordPress често ще извежда пренасочвания с siteurl в него. Следователно вероятно ще трябва да накарате сървъра да мисли, че се свързвате към същия URL адрес, въпреки че се свързвате с отдалечен сървър. Трудната част е, че ще ви е необходим и root достъп, за да можете да модифицирате сървъра си hosts файл. На Linux сървър ще намерите това на /etc/hosts/, и можете да добавите ред като този:

123.123.123.123 example.com 

Където 123.123.123.123 би бил IP на сървъра, където бихте хоствали блога. Разбира се, това ще работи само ако нищо друго на този сървър не очаква да се свърже с example.com.

Използване на Nginx

Ако използвате Nginx, който е малко по-рядък, можете да направите това малко по-лесно:

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

Тъй като Nginx ви позволява да посочите IP за бекенда, не трябва да играете с hosts файл.

Siteurl

И в двата случая отдалеченият сървър с блога в него трябва да бъде конфигуриран да обслужва съдържание http://example.com/blogи това би могло да бъде option_value за двете siteurl и home в префикса $options маса. Ако това е оригиналният URL адрес, тогава не трябва да го променяте. Ако все пак трябва да направите промени, бъдете готови да проверите всички кодирани URL адреси, като качени изображения и т.н.

Заключение

Това решение е малко объркано и има много неща, които могат да се объркат. Все пак вероятно е по-чист от следващата алтернатива, където имате / блог / обслужвате съдържание чрез PHP прокси, може би с помощта на curl. Това е причината стандартният подход да бъде просто използване на поддомейн.

  • ProxyPass и ProxyPassReverse (ако си спомням правилно) изисква да бъде включен модул, който не винаги е включен по подразбиране при всички инсталации. Той също така изисква рестартиране на Apache. Изглежда си спомням, че трябваше да правя промени в конфигурацията, преди ProxyPass и ProxyPassReverse да работят при моята тестова инсталация на Apache 2.4. Заслужава да се спомене във вашия отговор. Наздраве !!
  • @closetnoc Благодаря. Мислех си, че вече навлизам твърде дълбоко в системната администрация. Добавих и малко отказ от отговорност.
  • Благодаря за този подробен отговор @DKing - Моят клиент има разработчик, който се занимава с всички неща на сървъра, така че мисля, че са направили това като обратен прокси с помощта на Nginx. Актуализирах URL адресите в нашата WP база данни, за да използвам URL адреса на новата поддиректория. Изглежда, че всичко работи добре сега, но в wp-admin има грешки. По-конкретно грешка „502 Bad Gateway nginx“ при опит за създаване на публикация в wordpress. Също така съобщение за отказан достъп при опит за запазване на опции за тема на wp. Възможно ли е те да бъдат причинени от проксито, който мислите, или неправилно конфигуриране на wp? Благодаря отново!
  • @ J.Purcell 502 може да е свързан с nginx, а може и да не е, но запазването на опциите за теми вероятно ще бъде проблем с WordPress, като например проблем с разрешенията. Проксито просто предава информацията, така че след като промените темата, това трябва да се направи на сървъра нагоре по веригата, така че първо бих я проучил там. Бих се справил с това, преди да разгледам проблема 502.
  • 1 @Baumr Разбира се. Публикувал съм отговор.

Вашият сървър има IP адрес, така че можете просто да го вземете и след това да създадете поддомейн навсякъде, където се хоства DNS за домейна. Така че кажете, че искате да създадете blog.domain.com, можете да посочите това към вашия IP адрес на сървърите.

  • Благодаря за отговора, но въпросът беше как да насоча поддиректория към друг сървър, а не към поддомейн. Проблемът ми обаче беше разрешен в сътрудничеството ми с други разработчици, използвайки техника за обратно прокси. Благодаря!

е работил за вас: Charles Robertson | Искате ли да се свържете с нас?