Я создаю веб-сайт Angular, на котором также будет небольшая установка WordPress для отдела маркетинга / продаж (для создания целевых страниц). наша маркетинговая команда непреклонна в том, что субдомены вредны для SEO и GA, и хотели бы, чтобы установка WordPress находилась в подкаталоге. пример:
example.com/ <- Угловой example.com/marketing/ <- WordPress
Angular установлен на ведре S3, WordPress установлен на EC2 (за балансировщиком нагрузки), и все это скрыто за распределением Cloudfront! на данный момент у меня почти все работает: example.com/marketing/ Правильно загружает сайт WordPress, и example.com/ ЗАГРУЖАЕТ Angular (и example.com/some-random-path правильно вызывает /index.html Угловой фронт-контроллер). у меня проблема в том, что example.com/marketing/some-random-path ТАКЖЕ вызывает /index.html Угловой фронт-контроллер, т.к. example.com/marketing/some-random-path 404с. но для работы WordPress 404 /marketing/ нужно вместо этого ударить /marketing/index.php Фронт-контроллер WordPress.
Я изучал лямбда-функции Amazon, но не знал, как заставить их работать должным образом в сочетании с WordPress. .htaccess. может быть, решение всех моих проблем там?
а может есть еще способ настроить эту "фейк" /marketing/ подкаталог. Является ли это требованием и / или передовой практикой, чтобы он был заключен в Cloudfront? ни один из других наших сайтов WordPress.
Может быть, я могу сделать какую-нибудь сверхъестественную вещь DNS, о которой я не знаю?
Я открыт для альтернативных конфигураций; тот, который я описал, просто тот, который мне удалось выяснить до сих пор.
еще одно замечание, если это актуально: наши доменные имена зарегистрированы у стороннего регистратора (dnsmadeeasy), а не у Amazon; dnsmadeeasy имеет (немного?) более быстрое разрешение DNS, от чего другие люди, работающие здесь, не хотят отказываться. Я не уверен, что это актуально для этой проблемы, но это сделало настройку немного более сложной для меня, поэтому, если это может быть актуально, я подумал, что упомянул бы об этом.
Я сопоставил поддомены для каждого отдельного приложения (один поддомен для s3 и один для wordpress), а затем ввел прокси-сервер в корневом домене для маршрутизации в логические подкаталоги, которые были перенаправлены на поддомены, которые я ранее сопоставил. Теоретически это также может работать с IP-адресами, но мне проще использовать поддомены при работе с S3 в качестве веб-сайта и с EC2 / ElasticBeanstalk. ПРИМЕЧАНИЕ. Я использовал эту конфигурацию с более чем 20 сайтами S3, отображаемыми как каталоги на настраиваемом прокси-сервере Java. В зависимости от ваших требований вы должны решить, хотите ли вы использовать один сервер для запуска WordPress или будете ли вы участвовать в каком-либо масштабировании с его помощью (например, запускать несколько экземпляров за балансировщиком нагрузки). Если в будущем вы выберете конфигурацию балансировки нагрузки на wordpress, вам следует реализовать отдельный экземпляр для работы в качестве прокси-сервера для маршрутизации путей к каждому источнику вышестоящего приложения. Если вам нужна простота без учета масштабов, вы можете реализовать несколько виртуальных хостов на экземпляре сервера wordpress, а затем настроить пути прокси для s3 и вашей установки WordPress в соответствии со структурой виртуальных каталогов.