Блог: Перевожу старые посты на новый формат фоток и Long Read

Число просмотров: 3 426 

Фотографии к посту в старом формате мини-галереи

Фотографии к посту в старом формате мини-галереи

Хэй, ребята! Затеял я ОЧЕНЬ сложную и ОЧЕНЬ большую работу, к которой собирался подойти уже как года четыре — переделать фотки во всех старых постах на новый формат! А под эту переделку ещё и некоторые короткие посты склеить так, чтобы разрозненные их кусочки шли подряд в одном общем посте!

Процесс этот будет не моментальный, потому что постов со старыми фотками — около 150 штук. Некоторые из них простые и переделываются легко, а в некоторых (например про Музей Метро в Питере от 2009 года или 19″ шкаф в квартире в Реутове) придётся вычитывать пост и чуть ли не заново вставлять фотки по тексту поста.

Что это за старый формат фоток и постов? А вот посмотрите на заглавную фотку этого поста, который вы читаете! Вот таким образом раньше я вставлял фотки в редакторе постов — делал из них маленькие превьюшки 150х150 пикселей и вставлял их по две-три штуки в ряд через пробелы. А кое-где вообще ставил в режиме обтекания текста.

Первая жопа была в том, что в 2009 году, когда я запустил блог (вот самый первый пост об этом — блогу уже 11 ЛЕТ; юбилей мы проебали, и никто не устроил мне пышное шоу с фейерверками), я не думал о том, что я буду писать длинные и вдумчивые посты. Я вёл его как дневник, и поэтому посты имели формат вида «Во! Заменил розетку!» — там и рассказывать было нечего. Вот я и делал кусочек текста и несколько фоток в линеечку. Иногда и без смысла.

Раньше, 10 лет назад, народ в основном сёрфил блог с компов. И поэтому навести мышку, прочитать описание фотки во всплывающей подсказке, потом нажать на фотку, чтобы увеличить её, было не так сложно. Сейчас же всё поменялось — иногда мышки-то и даже нет…

Примерно с 2012-2013 года я начал вставлять в блог фотки полной ширины (при текущей вёрстке это 600 пикселей), чтобы можно было не нажимать на них для увеличения, а рассматривать общий вид фотки сразу, как есть. Увеличение фоток по клику мышкой осталось — оно стало удобно, если надо было рассмотреть больше деталей.

А недавно, в 2019 году, я выдумал автоматическую вставку подписей под фотками (отсылаю вас к посту, в котором я про это рассказал). Это было круто и удобно, но вся эта вставка подписей полностью поломала старый формат фоток в виде превьюшек. Смотрите, в какую жопу это превратилось:

То, как такие мини-галереи отображаются с подписями - всё портится

То, как такие мини-галереи отображаются с подписями - всё портится

Мне народ через Орфус (тоже напоминаю пост) даже опечатки присылал вида «…на левой фотке ниже» с комментарием «Блядь, ты охуел, где тут левая нахуй сука нижняя фотка? А где правая?!» =)

Короче, рано или поздно это надо было сделать! =) Уже как с неделю назад я пролистал ВСЕ посты, начиная от самого первого и выписал ссылки на те, в которых фотки вставлены по-старому. Вышло ровно 156 штук! Оххх! =) И потихоньку, неспешно, я начал править фотки. Многое можно будет оптимизировать простой заменой текста, но где-то нужно будет думать и переставлять фотки по контексту поста. Так что это будет работа не на неделю и даже не на месяц!

А вторая жопа — в том, что раньше, когда на блоге было 100 человек и 40 постов — вы были более в курсе моей жизни, потому что успевали всё прочитать. И идея вести блог как дневник тогда работала. Я писал пост вида «Во! Купил 19″ шкаф«, потом писал пост «Во! А теперь к шкафу купил 19″ полку!» — и вы были в курсе всего происходящего, потому что читали всё.

Сейчас же на блоге (на момент этого поста) 709 опубликованных постов и 33 черновика. И 50-60 тысяч уникальных посетителей в месяц. И хрен кто прочитает посты типа «Новость: АББ изменило порядок цветов в трёхцветной лампочке, я недавно заходил к Валентинычу и узнал». Более того — не все сообразят, про какого Валентиныча идёт речь, читая такой пост вырванным из контекста блога.

Поэтому вторая операция, которую я делаю над постами — это перевод их в формат «Long Read» — длинное чтиво. Некоторые посты, которые имеют общую тему, но разрознены по кускам, я склеиваю вместе. Это — тоже сложная операция, потому что надо не просто копирнуть одни пост в другой, а ещё и склеить все комментарии и все прицепленные к постам медиа-файлы (например картинки для Faster Images Insert, про который я упоминал тут и патчил его тут). Без лазанья запросами и руками в MySQL-базе не обходится.

Пожалуйста не пугайтесь: всё, что склеено, не потеряет исходных ссылок, так как я прямо на хостинге обвешиваю блог кучей Redirect 301.

Вот представьте, что написал я пост типа «Регистратор РПМ от НоваТек» и у него есть URL как «registrator-novatek-rpm». А потом через неделю написал пост про то, как установил этот регистратор себе в щит с URL «kak-ya-ustanovil-registrator-v-shhit», причём в стиле «Ага, вот наконец-то поставил регистратор (шшо? кого?) в щит! Держите фотки, зацените как работает, снял первый график».

В этом примере эти посты так и просятся склеиться в один чуть более длинный пост с подзаголовками типа «Часть 1: Покупка регистратора и его внутреннее устройство» и «Часть 2: Подключение регистратора и первый запуск». Причём позже пост можно будет дополнять частями типа «Часть 3: Как я ругался про температуру ГВС и строил графики».

Вот такие посты я и склеиваю. Старые ссылки ведут не на 404 (страница не найдена), а переводят вас на один такой склеенный пост даже если вы зашли по ссылке 10-летней давности из закладок, поисковика, форума или ещё откуда-то. Ура! ^_^

Вот идеи постов, которые я буду склеивать (ради прикола потом сделаю склеенные посты ссылками):

Ну а самый первый бонус — это чтиво, про которые вы могли и не знать. Это (уже склеенный) пост про мой компьютерный шкаф, до 19″ формата! Там вы найдёте целую историю о том, как я первый раз исполнял своё желание избавиться от кучи проводов, роутеров, блоков питания, свитчей, USB-хабов и прочей хероты. Я набрал из РНИИ КП, где тогда работал, корпуса и встроил в них компы и всю периферию:

Все соединения выполнены

Все соединения выполнены

И третья задниц… задача, которую надо будет решить — это выдумать то, как сообщать вам про такие обновления постов, потому что штатно движок WordPress этого делать не умеет. У него есть дата создания и изменения поста — но сортировать посты про дате изменения мне не подходит, потому что эта дата будет обновляться даже если я просто опечатки в посте поправлю. А мне надо показывать вам серьёзные обновления поста.

Мы с Loa уже потрепались про это в комментариях, и я перескажу это здесь своими словами. Loa предлагал просто менять дату у постов на свежую, чтобы пост снова поднимался в ленте. Я не хочу этого делать, потому что оригинальная дата поста для меня важна как дань истории или кошмаринга типа «Да хрен ли ты мне рассказываешь — ты вот этот пост глянь, я про это ещё в 2010 году писал» =)

Поэтому я ща придумываю другое решение. У WordPress есть возможность создавать к каждому посту свои произвольные поля данных (Custom Fields, прочитать про них можно, например, здесь). Я решил создать поле «CS-UpdateDate» и позже сделать ещё один виджет справа в колонке, который будет показывать последние обновления постов за, например три месяца. А дату обновления менять вручную, когда делаю действительно важные изменения.

Произвольные поля WordPress. Добавил поле для даты обновления поста

Произвольные поля WordPress. Добавил поле для даты обновления поста

Блин! Не удержался и ночью, пока создавал этот пост, провёл тест! Получилось! Рассказываю идею и тесты! Обычно гопники от WordPress пытаются использовать штатные функции для доступа к данным движка. А они дико тормозят и даже не всегда имеют нужный функционал. Ещё когда мы общались с Loa в комментах я начал искать функцию типа «Сделать отбор постов по наличию произвольного поля» и встретил рекомендации о том, что это всё дико тормозит, так как произвольные поля хранятся в подчинённой таблице и, мол, не стоит использовать запросы и поиск по ним, иначе это будет сильно нагружать базу.

Базу, базу… блядь! Хули! Просто надо знать, где что как хранится и уметь чуток читать документацию по MySQL и писать свои запросы. Все произвольные поля хранятся в таблице «postmeta», подчинённые по «post_id» к таблице «posts».»id». Моё созданное поле можно отобрать по условию `postmeta`.`meta_key` = ‘CS-UpdateDate’. А дальше делаем финт ушами! Мы ж знаем, что в этом поле будет строго дата и в формате MySQL (YYYY-MM-DD). Значится мы можем преобразовать строковое значение этого поля к дате, вызвав функцию DATE() (капитан очевидность, мать его), а потом сделать по этой дате отбор и сортировку.

А потом, используя подчинение таблиц сказать, чтобы нам в один запрос слили нужные поля из нужных таблиц. Нужные поля — это только те, которые я хочу отображать: URL поста, дату обновления, название поста. Мне не нужны поля, которые содержат весь пост целиком («post_content») и занимают дохрена памяти и ресурсов сервера. А значит мой запрос не будет тормозить.

Вот шо он делает в итоге (по порядку алгоритма):

  • Ищет все дополнительные поля с названием «CS-UpdateDate»;
  • Ищет все посты (именно посты, `posts`.`post_type` = ‘post’), ID которых совпадает с `post_id` в таблице дополнительных полей;
  • Проверяет, чтобы ID поста (данные о посте) выдались только один раз без повторений;
  • Преобразовывает моё значение в дату, сравнивает с текущей датой и отбирает посты, у которых дата изменения не более заданной (полгода, например);
  • Сортирует посты по этой же дате из моего поля в обратном порядке (самый свежий будет сверху списка);
  • Ограничивает результаты до указанных — например, последние 15 штук изменений.

Вот как это выглядит в запросе (все префиксы таблиц WordPress убраны):

Написал SQL-запрос, который отбирает из таблиц WordPress посты, у которых есть поле с датой обновления

Написал SQL-запрос, который отбирает из таблиц WordPress посты, у которых есть поле с датой обновления

Самый для меня шок был — это время выполнения этого запроса. Ну, пугали же меня там про всякие тормоза базы, этих произвольных полей. Хрен ли!! Если все вычисления повесить на базу, то всё летает! Время выполнения этого запроса (из MySQL-консоли) — 0,0028-0,0036 секунды. При том что простой запрос на отбор первых 25 записей из таблицы постов работает медленнее — за 0,0092 секунды.

А вот и вывод запроса. Прям идеальная инфа, полностью подготовленная:

Тестовый вывод всех обновлённых (по поему полю даты) постов WordPress

Тестовый вывод всех обновлённых (по поему полю даты) постов WordPress

Дальше останется только выполнить этот запрос штатными средствами WordPress (вот можно почитать здесь про это — как использовать функцию $wpdb->get_results), написать свой простой виджет и вытащить его на колонку справа. Сделаю это на днях, хрен ли уже тянуть-то! Самую главную фишку написал же! =)

Добавил утром. Да-да! Я резко взял, по утру и под чай с имбирём написал виджет и затестил его на блоге. Работает охеренски! Зацените:

Настройки моего виджета вывода обновлений постов и результат его работы

Настройки моего виджета вывода обновлений постов и результат его работы

10 Отзывов на “Блог: Перевожу старые посты на новый формат фоток и Long Read”


  • 1 loa

    Посты я, в принципе, все вижу — падают по rss. Правда, о последующих обновлениях какой-либо рассылки нету. Поэтому о них я могу не узнать, если только не подписан на комментарии и их кто-либо написал.
    Тут как раз такая история: вижу, что что-то новое появилось.

  • 2 CS  [Москва]

    Не, старые посты по RSS не придут — только если я дату поста обновлю, а мне этого не хочется.
    На крупные обновления постов буду писать в правой колонке новость со ссылкой. А мелкие — не. Я ща некоторые склеиваю вместе, чтобы инфа не была разбросана =)

  • 3 loa

    То есть, при обновлении старых постов они не вылезут на главной странице, а останутся там, где и были? (Те, что в новость не попали).

  • 4 CS  [Москва]

    Так и не должны.

  • 5 loa

    Интересный вопрос: как бы сделать, чтобы быть в курсе этих обновлений.

  • 6 CS  [Москва]

    Да блин никак, потому что это надо руками делать. Или какие-то «Новости» херачить. Этого нет в штатной функции движка вообще ну никак.
    При этом автоматически я это сделать не смогу из-за того, что в движке нет понятия — действительно ли «Обновлён» пост или я просто его открыл, опечатку поправил — и тоже «обновил».

  • 7 loa

    Понятно, что тут нетривиально и тратить кучу времени на программирование как-то не айс.
    По-моему, проще было бы сравнительно существенные дополнения в постах сопровождать изменением даты. Что плохого, если старый пост вылез в верх ленты? Ты же что-то полезное добавил.
    Ну а всякие мелкие коррекции, которые по смыслу ни на что не влияют, так и остаются старыми.
    Мне лично кажется, так логично и кодить не надо. Конечно, тебе виднее.

  • 8 CS  [Москва]

    Про дату поста у меня есть два пунктика:
    а) Мне важна оригинальная дата. Прям вот важна. И как для «это было триста лет тому назад» ©, так и для кошмаринга про «А вот пост — я ещё в 2012 году так делал, а ты мне выговариваешь, как будто только первый раз блог читаешь».
    б) ОЧЕНЬ не хочу, чтобы было как у Надёжина в ЖЖ. У него иногда читаешь пост типа «Поставил себе кондей», а потом там приписка «Впервые этот пост был опубликован 12 мая 2007 года». Нахуй такое.

    Гм! Если прогать — то надо занести в список идей вот что. У поста есть кастомные поля со своими названиями и значениями.
    Вот я могу создавать поле типа «CSPostUpdated» и написать скрипт, который будет выдавать список таких постов в виджет справа.

  • 9 loa

    Ну да, ты же выводишь справа свежие комментарии.
    Примерно так же можно сделать список обновлений.

  • По-моему, хорошо получилось.

Оставить отзыв

Вы должны войти на блог, чтобы оставить комментарий.