У вас изначально были поддомены aa.xxx.ru и bb.xxx.ru. Для того, чтобы по ним открывался какой-то другой сайт, нужно в настройках DNS указать две А-записи с именами поддоменов или одну в виде *.xxx.ru, которая указывает на IP-адрес сайта yyy.ru.
После этого в настройках веб-сервера нужно указать для домена yyy.ru псевдонимы (alias) aa.xxx.ru и bb.xxx.ru.
dpcenter, в первую очередь нужно настроить DNS-сервер, который обслуживает ваш основной домен. Для этого нужно добавить А-запись с именем домена или с маской *, чтобы все запросы на поддомен отправлялись на определенный IP-адрес. Это не обязательно адрес основного сайта, он может быть другим.
После этого нужно настроить непосредственно веб-сервер. Он может либо выводить тот же сайт, что и по адресу без домена, так и перенаправлять пользователя на указанный адрес.
Если разработчик всего один и работа ведется в основном с WordPress, то с головой хватит обычной виртуальной машины с Debian. Можно также настроить dnsmasq, чтобы для каждого проекта в зависимости от папки автоматически создавался свой домен.
Docker и Vagrant - это хорошие инструменты, но они созданы немного не для этого.
Это можно сделать. Нужно немного поправить генерацию ссылок.
Да, действительно, на первый взгляд может показаться, что вложения в виде отдельной сущности не нужны, но давайте посмотрим на ситуацию с другой стороны.
С загрузкой картинок в саму запись все более-менее просто и понятно.
Можно загрузить картинку на сервер, вставить в запись, прописать ей описание и srcset.
Это самое можно сделать и с миниатюрой. Проблем здесь нет, все просто и понятно. Именно так это реализовано во многих CMS.
Первые костыли начнут появляться, когда в шаблоне потребуется получать ссылки на разные размеры,
а также обрабатывать ситуацию, когда нужный размер не найден или файл был переименован.
Еще большие костыли придется писать, когда потребуется каким-то образом группировать вложения.
Например, стоит задача получить все картинки какого-то пользователя.
Придется заранее при загрузке выделять для каждого пользователя свою папку для вложений и каким-то образом
обрабатывать ситуации, когда пользователь изменяет ник или группу, загружает файлы с одинаковым именем, а также когда пользователя удаляют.
А ведь и это еще не все. Настоящие проблемы появятся, когда потребуется ввести ограничения по группам пользователей
или по конкретным пользователям. Это могут быть банальные вещи, когда обычные пользователи
не должны видеть все или некоторые файлы, которые загружены редакторами сайта или другими пользователями.
Вот по этой причине в принципе нужно выделение вложения в отдельную сущность. В случае с WordPress было решено выделить их в отдельный тип записи.
По поводу закрытия страниц вложений от индексации. Вариантов тут несколько.
Первый и самый банальный - это редирект на страницу записи. На практике создается шаблон вложения (attachment.php, например), а в него помещается код:
$post = get_queried_object();wp_redirect(get_permalink($post->post_parent));
Второй более-интересный способ - это включение метатега robots со значением noindex,nofollow.
Это можно навесить на соответствующее событие, а можно просто прописать вручную перед wp_head();. Важно также выполнять проверку is_attachment(), чтобы закрыть от индексации только страницы вложений.
В WordPress вложение - это еще один тип записи.
Вообще выделение вложений в отдельную сущность - это отличное архитектурное решение. Таким образом появляется возможность, не только добавлять название, описание и подпись, но и хранить ссылки на изображения в разных размерах, превью для видео, например. Также это позволяет разграничивать доступ, находить предыдущее/следующее вложение и вообще как-то структурировать.
К слову, такой подход позволил с минимальными усилиями реализовать в версии 4.4 адаптивные изображения.
Причин на самом деле много, я уже отписывался на эту тему ранее. Описанные мною моменты особенно актуальны, если речь идет о потоковой разработке и поддержке сайтов.
Здравствуйте, уважаемые заказчики.
С 12 по 15 декабря у меня будет ограниченный доступ к Интернету. Из-за этого я не смогу оперативно отвечать на ваши сообщения.
Заранее извиняюсь за неудобства.
Большую часть из этого можно отключить с помощью
define ('WPCF7_AUTOP', false);
Больше информации в документации: http://contactform7.com/controlling-behavior-by-setting-constants/
Помимо этого вам никто не запрещает написать свой плагин, зарегистрировать AJAX-обработчик и написать скрипт для проверки и отправки данных на почту.
Да, это возможно. Вам нужно получить ID записей из рубрики с помощью get_posts() и передать их в виде массива в функцию get_comments() (имя параметра - post__in).
Среди дополнений для постраничного кеширования лично мне больше всего нравится WP-FFPC и WP Super Cache. Они показывают очень хорошую скорость.
Обратите внимание, что для нормальной работы WooCommerce нужно исключить некоторые страницы из кеша: https://www.keycdn.com/support/setting-up-woocommerce-cache/
Как таковые он запросы не кеширует. Его основная задача - это кеширование сразу всей страницы.
Если стоит цель кешировать не страницы как таковые, а данные, то нужно использовать плагины для объектного кеширования (object cache). Это совершенно иная история.
SQLite отлично подходит для хранения небольших объемов данных с не очень большим числом выборок. Для форума ее лучше не использовать.
