TiA

Какой-то конкретный ответ здесь дать крайне сложно, поскольку все определяют детали. Сайты со статьями ведь очень разные бывают.

Одно дело, когда сайт простой, материалов немного, запросы к базе простые и с использованием индексов. Выполняются они мгновенно. Дополнительно заморачиваться с кешированием в этом случае нет смысла. Дерево рубрик, настройки, шаблоны и другие данные можно кешировать, они зачастую занимают немного памяти.

Это же касается случаев, когда материалов очень много. Если их всех кешировать в MemCached, то кеш может получится просто огромным, а поиск по нему сравнительно медленным.

Кеширование на уровне базы данных также имеет смысл включить. Оно помогает ускорить загрузку общих данных (дерево категорий, настройки, данные об авторах и т.д.).

Если вы планируете делать проект на Django, то придется рассматривать в основном VPS. На обычных хостингах поддержка Django - это все же редкость.

Как вариант можете рассмотреть эту библиотеку: https://github.com/phayes/geoPHP

Дублирование контента поисковые системы воспримут именно как дублирование контента. Если это происходит в рамках вашего сайта, то никаких явных санкций не будет, но и по голове вас, условно говоря, не погладят. Если вам в ваших статьях нужна информация с других страниц, то для этого в вебе давно используются ссылки, это их прямое назначение. Можно также попробовать извратиться с загрузкой материалов по AJAX.

<?php

            $category  = get_the_category();

            $category_slug = (isset($category[0]->slug) && !empty($category[0]->slug) ? $category[0]->slug : NULL);

            if ($category_slug == 'one' || $category_slug == 'two') {

                  meta_date();

            }

            ?>

Попробуйте такой код:

<div style="display:<?php if (is_category('one') or is_category('two')) echo 'block'; else echo 'none'; ?>;">



<?php echo twentysixteen_entry_meta(); ?>



</div>

На всех страницах будет скрытый блок с содержимым, которое возвратила функция twentysixteen_entry_meta(). На страницах рубрик со slug равными one или two этот блок будет видимым.

Если я правильно понял задачу, то это проще всего реализовать через регистрацию нового шорткода с обязательным параметром в виде ID-страницы, которую нужно вставить в виде спойлера. Это можно сделать как ручками в functions.php, так и воспользоваться плагинами вроде https://wordpress.org/plugins/insert-pages/ Сам спойлер, правда, придется вручную прикручивать.

Да, это абсолютно нормально.

Не логичней. Если на главной странице изначально выводятся последние записи, а тут вы прописали страницу с таким же адресом, то что должен выводить движок? Какая из страниц должна быть главной? Именно для этого и была введена возможность в явном виде указать главную страницу.

В первую очередь нужно разобраться как именно сохраняется настройка ширины в посте. Возможно, при публикации эта настройка по какой-то причине не сохраняется сразу.

Вам нужно в Настройки - Чтение выбрать указанную страницу в качестве главной. Адрес выбранной страницы в этом случае станет просто site.ru

В этом случае нужно посмотреть какой скрипт занимается непосредственно поиском. Там скорее-всего в том или ином виде будет привычное создание WP_Query или функция get_posts, что в общем-то схожие вещи. И вот туда можно попробовать подсунуть аргументы для фильтрации по таксономии.

Здравствуйте, уважаемые заказчики.

У меня появилась свободная минута и я решил освежить портфолио. В разделе Системы управления (CMS) с шаблонами для WordPress появилось несколько десятков интересных работ с описаниями.

Все зависит от того как именно должен работать поиск. Если вы работаете со своим объектом WP_Query в каком-то цикле, то можно при инициализации объекта добавить параметр "s" со значением фразы, по которой вы собираетесь искать, а также параметр с таксономией. Массив с аргументами будет примерно таким:

'tax_query' => array(
	array(
		'taxonomy' => 'название таксономии',
		'field'    => 'название поля',
		'terms'    => 'значение поля таксономии',
	),
),
's' => 'фраза для поиска'

Если вам нужно, чтобы стандартный поиск работал только по определенным таксономиям, то нужно добавить фильтр на событие pre_get_posts:

add_action('pre_get_posts', 'tw_pre_get', 1);

function tw_pre_get($query) {
	
	if ($query->is_main_query() and is_search()) {
		
		$tax_query = $query->get('tax_query');
			
		$tax_query[] = array(
			'taxonomy' => 'название таксономии',
			'field'    => 'название поля',
			'terms'    => 'значение поля таксономии',
		);
			
		$query->set('tax_query', $tax_query);
			
		return;

	}
		
}

Это одно из самых идеологически верных решений. Еще одно решение - это вручную в коде выводить те или иные ссылки в зависимости от языка (функция pll_current_language)

Если речь идет о получении ссылки на страницу или запись, то вместо прописывания ссылки в явном виде, можно использовать такую конструкцию: get_permalink(pll_get_post(ID записи или страницы)). Для преобразования ID рубрики или термина таксономии можно использовать функцию pll_get_term