Без п. 3 - пп. 1 и 2 Гуглем не засчитываются

Что сделал я - использовал обычный дизайн сайта (не этого), просто в CSS дописал такие строчки:

@media screen and (min-width: 800px) {
#wrapper { width:800px; }
#sidebar { width: 170px; }
#content { width: 600px; }
.thumb { width: 260px; margin-right:20px;}
.thumb img { width: 260px;}
}

@media screen and (min-width: 1024px) {
#wrapper { width:1024px; }
#sidebar { width: 200px; }
#content { width: 790px; }
.thumb { width: 250px; margin-right:10px;}
.thumb img { width: 250px;}

}

@media screen and (min-width: 1152px) {
#wrapper { width:1152px; }
#sidebar { width: 220px; }

#content { width:900px; }
.thumbspack { font-size:16px;}
.thumb { width: 280px;}
.thumb img { width: 280px;}

}

@media screen and (max-width: 799px){
#wrapper { width:320px; }
#content { float:none; }
#sidebar { float:none; }
.button { width: auto; }
.button:hover { width: auto; }

.thumb {
display:block;
float:none;
margin-right:auto;
margin-left:auto;
}
}

Первые три @media screen - это для экранов от 800, от 1024 и от 1152, последний - вариант для экранов, которые не набрали и 800px.

Смысл этих штук - адаптировать размеры и поведение главных блоков дизайна (контент, сайдбар, общий враппер) под соответствующие разрешения. Туда же вписал хаки для отдельных элементов, которые “плохо” вели себя на подходящих размерах.

Google сказал, что теперь сайт Mobile Friendly.

ЗЫ:Самое важное! Самое маленькое разрешение должно быть адаптировано под ширину 320 пикселов - ибо, как написано в мобайл-тесте у Гугля, таково “аппаратно-независимое” разрешение у iPhone 5. И именно под него он показывает картинку в тесте. У меня до этого момента стояло 350 пикселов в минимальной ширине (последний media screen), и часть слов при этом обрезалась (а тупой робот Гугля все равно воспринимал как Mobile Friendly). Я поправил на 320 - и картинка стала нормальной.

if ($paged<2) {
//вывод текста для 1 страницы
}
else {
//вывод текста для всех остальных страниц
}

?>

Делает он вот что - убирает стандартный префикс category из урлов рубрик для Wordpress.

Для интереса можете посмотреть мануал по ручной уборке этого префикса без плагинов. Я потратил тогда много времени и потом ещё тратил немного на ручную работу.

А тут просто установил плагинчик и всё.

Для этой цели затестировал несколько плагинов

1. WPEX Replace DB Urls - нихера. То есть вообще не нашёл строку в БД. А она там есть. Посему даже ссылку на это говно недоделанное не даю.

2. Velvet Blues Update URLs - сработал отлично, заменил все данные.

Что немаловажно - плагин обновляется, живёт. В опциях можно выбирать где менять - во всех таблицах или только в постах или только в аттачментах.

Отлично меняет часть URL, то есть то, что как раз было надо сделать. 10 из 10.

Познакомился я с ним так - купил один сайт готовый на ВП и увидел его в списке плагинов. Пригляделся - ба! - да ведь именно так создатель сайта его и подготовил для переноса на мой хостинг. Плагинчик делает дамп SQL-базы и архив всех файлов Вордпресс, складывает в один tar-архивчик и передаёт по FTP на нужный хостинг.

Сейчас тест на стадии “все файлы скопированы”. То есть архивы сделаны, файлы перемещены. Осталось подождать, когда включится DNS для нового домена, чтобы запустить клонер на нём и увидеть, как сайт восстанавливается из бэкапов.

В данном случае у меня был один сайт, совсем уже больной и нерабочий, который требовал обновления. Но какие-то пользователи на нём ещё были. Чтобы минимизировать паузу, я подготовил новый вариант сайта на Wordpress на альтернативном хостинге на другом домене. Если бы делал сразу на оригинальном сайте - юзеры увидели бы много нерабочего. А так я им подсуну новый хороший сайт, сразу готовый к работе. Только паузу в несколько часов придётся выдержать (вместо нескольких дней).

Да, XCloner автоматически меняет URL сайта в дампе базы данных, что очень удобно.

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

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

Это проблема для аркадных игровых сайтов - т.е. таких, которые предоставляют пользователям флеш-игры (или другие приложения).

Плагин Allow Swf Upload решает эту проблему - загрузка становится дозволенной.

Протестировано на 3.9.1

PS: как обычно, некоторое время назад я вручную хакал php вордпресса, вместо того, чтобы искать плагин. А он есть и хакать не надо!

ЗЗЫ: А вот тут описан код, который можно встроить в functions.php своей темы, чтобы разрешить загрузку SWF без установки плагинов.


function demo($mimes) {
if ( function_exists( 'current_user_can' ) )
$unfiltered = $user ? user_can( $user, 'unfiltered_html' ) : current_user_can( 'unfiltered_html' );
if ( !empty( $unfiltered ) ) {
$mimes['swf'] = 'application/x-shockwave-flash';
}
return $mimes;
}
add_filter('upload_mimes','demo');


Аналогично можно расширить под загрузку и чистых EXE-файлов, вписав туда

$mimes[’exe’] = ‘application/x-msdownload’;

А пишу сюда, потому что столкнулся с такой проблемой - все страницы были сделаны на 1 дату. Надо было сделать постепенный постинг и индексацию.

Для этой цели я выбрал плагин Draft Scheduler. Он автоматически создаёт публикации из драфтов. Вот главная няшка в опциях:

То есть, осталось лишь перекинуть полтысячи страниц в драфты - и они будут публиковаться сами по себе.

Если будете ставить и не найдете, где настройки Draft Scheduler - смотрите в глобальном меню Posts, он туда их добавляет, а не в Settings.

PS: до 2015 мне сразу распланировал!
То есть обрабатывает черновики сразу.

ЗЗЫ: Работает с Wordpress 3.9.1 - успешно!

Потому что Quick Edit имеет простой текстовый редактор и при входе в него слетают все теги.

Up:

в русских ВП - это если кликнуть на “Свойства” категории в списке категорий в админке

Пока всё нормально, только пришлось русифицировать html-код (всё в настройках).

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

Надо потестировать его на том же болезном сайте, но логика WP Super Cache с mod_rewrite выглядит такой же:

1. При первом обращении генерируем страницу WP как обычно
2. Записываем сгенеренную страницу как html в папке внутри кэша
3. При повторных обращениях - отдаём страницу в виде html

Плюс он ещё и gzip-ует.

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

Граждане, не ленитесь! Читайте мануалы!

Хотя костыли писать тоже полезно, время от времени - начинаешь лучше понимать механику инвалидности и её лечения.