Как сделать страницу блога в wordpress

Создание отдельной страницы для записей в блоге

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

В этом руководстве

1. Способ 1. Использование готового макета
2. Способ 2. Используйте блок «Записи в блоге»
3. Способ 3. Создайте пользовательский макет
4. Пользовательские страницы блога | Вебинар по WordPress.com

Способ 1. Использование готового макета

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

1. Перейдите в консоль.
2. Выберите Страницы →Добавить новую, чтобы создать страницу.
3. Выберите один из готовых макетов страниц в категории Блог.
4. Нажмите на макет, который хотите применить к странице. Выбранный макет автоматически будет применен ко всем записям блога, которые вы уже опубликовали на сайте.
5. Внесите желаемые изменения в макет (узнайте, как использовать редактор WordPress).
6. Нажмите Опубликовать, чтобы применить изменения на сайте.
7. Добавьте новую страницу блога в меню сайта.

Способ 2. Используйте блок «Записи в блоге»

Если вы не хотите использовать один из готовых макетов, как описано в предыдущем разделе, вы можете начать с пустой страницы и показать свои записи на ней, используя блок «Записи в блоге». Для этого выполните следующие действия:

1. Перейдите в консоль.
2. Выберите Страницы →Добавить новую, чтобы создать страницу.
3. Нажмите Пустая страница, чтобы начать с пустой страницы без содержимого.
4. Чтобы показывать свои записи на странице, добавьте блок «Записи в блоге». Измените настройки блока нужным образом:
   • Выберите разметку в виде списка или сетки.
   • Решите, нужно ли включать изображения, цитаты, даты и дополнительную информацию.
   • Настройте показ записей из избранных категорий, с определенными тегами или от определенных авторов.
5. Добавьте на страницу любое другое содержимое, например текст и изображения (узнайте, как использовать редактор WordPress).
6. Нажмите Опубликовать, чтобы применить изменения на сайте.
7. Добавьте новую страницу блога в меню сайта.

Способ 3. Создайте пользовательский макет

С помощью редактора WordPress можно создать именно такой макет страницы блога, как вам нужно. Мы покажем вам, как создать пользовательский макет, похожий на этот:

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

В примере выше мы использовали блок «Карусель записей», чтобы создать визуально привлекательный заголовок. В центральной области находится блок «Записи блога». Мы использовали блок «Колонки», чтобы создать боковую панель для блока «Подписка», блока «Последние записи» и блока «Категории».

Чтобы создать этот макет:

1. Перейдите в консоль.
2. Выберите Страницы →Добавить новую, чтобы создать страницу.
3. Нажмите Пустая страница, чтобы начать с пустой страницы без содержимого.
4. Добавьте блок «Карусель записей» и воспользуйтесь опциями из боковой панели блоков, чтобы выбрать конкретные записи для показа. Установите для блока «Карусель записей» параметр «Во всю ширину».

1. Под блоком «Карусель записей» добавьте блок, состоящий из двух столбцов, и выберите вариант, в котором ширина второго столбца будет меньше:

1. В узком столбце:
   • Добавьте заголовок и введите текст «Подписка». Затем под текстом добавьте блок «Подписка».
   • Добавьте Заголовок и введите текст «Последние записи». Затем добавьте блок Последние записи.
   • Добавьте Заголовок и введите текст «Рубрики записей». Затем добавьте блок Рубрики.

Для каждого блока предусмотрено множество пользовательских настроек. Ознакомьтесь с каждой из них в настройках блока и на панели инструментов.

1. В широком столбце добавьте блок «Записи блога» и выберите вариант показа в виде сетки.

1. Нажмите Опубликовать, чтобы применить изменения на сайте.
2. Добавьте новую страницу блога в меню сайта.

Пользовательские страницы блога | Вебинар по WordPress.com

Посмотрите запись вебинара, на котором мы показали весь процесс настройки страницы блога:

Как создать страницу в WordPress

Помимо страницы с детальным просмотром статьи и списком статей в рубрике, на сайтах с WordPress иногда присутствуют статичные страницы. К примеру, страница «Обо мне», которая может содержать информацию об авторе блога. Эта страница, как и остальные, хранятся в базе данных. Но адрес этой страницы в публичном разделе отличается от адреса статьи или рубрики.

Попробуем создать страницу в WordPress. Для этого зайдите в панель администрирования сайта и кликните на пункт «Страницы». Затем кликните на подпункт «Добавить новую»: Откроется форма создания новой страницы. Теперь попробуем создать страницу с заголовком «Обо мне», на которой будет присутствовать описание личности автора блога: После ввода заголовка странице, под полем ввода, будет показан адрес страницы. Можно нажать на кнопку «Изменить» и ввести своё название. Рекомендуем использовать в адресах страниц только латинские буквы. После ввода названия нажмите кнопку «ОК», чтобы сохранить изменения: Рассмотрим внимательнее форму редактирования содержания страницы. С помощью кнопки «Добавить медиафайл» можно вставлять фото в статью. Обратите внимание, что не стоит вставлять фалы фото с очень большим размером. К примеру, файл фото с размером 5 мегабайт — это очень большая фотография для сайта. Из-за неё сайт будет медленно загружаться, потому что в WordPress нет встроенного автоматического изменения размеров фотографий под области, куда они загружаются. Поэтому старайтесь не загружать фотографии размером более 200 килобайт.

Чтобы уменьшить размер файла фотографии (в килобайтах), нужно уменьшить количество пикселей в нём. К примеру, сделать ширину фото не 5 тысяч пикселей, а 2 тысячи. С этой задачей помогут справиться редакторы изображений. В простейшем случае, на операционной системе Windows, это поможет сделать программа «Paint».

Две тысяч пикселей в ширину — это максимальная ширина, которая может понадобится фото для отображения на сайте. Учтите, что более 50% посетителей на сайте заходят через мобильные. А на мобильных устройствах разрешение ещё меньше, поэтому нет никакой необходимости ставить на сайт изображения с разрешением в 5 тысяч пикселей в ширину. Пользователи всё равно не увидят изображение, сжатое под максимальную ширину их устройства. А с другой стороны, посетители не будут долго ждать, пока большая картинка загрузится через медленный мобильный интернет.

Во время написания текст происходит автоматическое сохранение прогресса на сайте, а так же в вашем браузере. Чтобы сделать сохранение вручную, посмотреть как статья будет выглядеть после публикации или опубликовать её, необходимо воспользоваться кнопками в блоке «Опубликовать» (находится справа-сверху на странице добавления страницы): Для страницы можно установить изображение. Точно так же, как для статьи. Делается это с помощью блока «Изображение страницы». Найдите этот блок и нажмите на кнопку «Установить изображение страницы»: Откроется форма «Изображение страницы», в котором есть две закладки: «Загрузить файлы» и «Библиотека файлов»: Если необходимо загрузить новое изображение с вашего компьютера на сайт, то кликните на закладку «Загрузить файлы». Если файл уже загружен на сайт, то выберите закладку «Библиотека файлов» , в которой находится список файлов изображений. которые когда-либо добавлялись на сайт.

После загрузки изображения вкладка «Библиотека файлов» включится автоматически. Кликните мышкой на нужное фото, которое хотите сделать главной картинкой так, чтобы на нём появилась отметка-галочка: Внизу формы загрузки файлов кликните на кнопку «Установить изображение записи». Форма закроется, а в блоке «Изображение записи», в боковом меню, будет показано выбранное изображение: Обратите внимание, что для этого изображения, как и для всех других на сайте, не стоит использовать слишком большие файлы изображений. Уменьшайте их размер при загрузке на сайт. Иначе они будут слишком медленно загружаться и пользователи будут уходить с вашего сайта. Старайтесь не загружать на сайт изображения размером более 200 килобайт.

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

7 основных преимуществ создать свой блог на WordPress

Я точно знаю, что идея создать свой блог приходит на ум каждому человеку. Собственно они это и делают, открывая страницы в социальных сетях. Это конечно не полноценный блог, но делиться с миром своими мыслями позволяет. Однако на полноценный блог страницы в социальных сетях недотягивают. Со временем чувствуешь ограниченность возможностей и присутствующий надзор. Поэтому в этой статье я расскажу, как создать свой блог на WordPress и объясню почему именно на этой платформе. Расширенную информацию по ведению и администрированию блога вы можете, так же найти в блоге wilhard.ru.

Что такое блог и чем он отличается от сайта

С технической точки зрения блог это набор папок и файлов, синхронизированных с базой данных, через систему управления контентом (CMS). Используя языки программирования, CMS формируют страницы блога, которые в удобном виде браузеры показывают пользователям Интернет.

С точки зрения технологической реализации блог и сайт это одно и тоже. Более того и блог и сайт это элементы логической составляющей Интернет технологий в группе «Информационные ресурсы Интернет».

Разница между блогом и сайтом в «первичных признаках». Перечислю самые явные из этих отличий.

• Во-первых, блог ведётся автором, реже, группой авторов. Этим он напоминает личный дневник для общего прочтения. Сайт может быть обезличен. Его вести может безликий «админ», компания, организация, фирма.
• Во-вторых, классика жанра требует в блоге обязательное комментирование. Конечно автор блога может быть букой и может не открывать комментирование. Более того автор может создать свой блог и вести его для очень ограниченного круга читателей и даже для себя одного. Однако это скорее исключения, чем правила.
• В-третьих, блог должен иметь упрощённое администрирование. Никаких языков программирования автору блога знать не нужно. Знаний пользователя должно быть достаточно для создания качественного блога.

Вас может заинтересовать: Реклама в Facebook: facebook pixel

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

Альтернатива WordPress, чтобы создать свой блог

Интернет так устроен, что все мы советуем одно и то же, к сожалению. Вы наверняка встречали «3 популярные CMS» для ведения блога: WordPress, Joomla, Drupal. Спешу вас расстроить, для ведения классического блога подходит только CMS WordPress.

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

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

Кроме этого, в коробочной версии Joomla нет инструмента комментирования, что для блога необходимо и обязательно.

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

Как неплохую альтернативу WordPress могут порекомендовать, для любителей новенького, CMS TYPO3. Она бесплатна, её легко освоить с нуля, но трудно перестроиться с других систем.

Почему WIX и Blogger не нужно использовать, чтобы создать свой блог

WIX это конструктор для создания вебсайтов, в том числе блогов, с ограниченными правами администратора на созданный контент. Похожая SAAS платформа для блога — Ucoz. UMI, InSales, Shopify и Setup тоже SAAS, но для магазина.

Blogger этого уникальная платформа для создания блогов с упрощённым администрированием. Блог на ней можно синхронизировать с сервисами Google через Google аккаунт.

Можно ли на этих платформах создать свой блог? Да, можно. Будет ли таким блогом легко управлять? Научитесь – будет легко. Можно ли такой блог развивать, оптимизировать, продвигать в поиске? Крайне трудно.

Вас может заинтересовать: Чем отличаются контекстная и таргетированная реклама

Преимущество в создании блога на этих и подобных платформах в их бесплатности. Если вы совсем не знаете, как подступиться к созданию своего блога, соблазнительно попробовать свои силы на бесплатной платформе.

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

Со временем понимаешь, что развить блог на такой платформе крайне трудно, а заработать вообще не возможно. Однако кому-то этого хватает, а кому-то хватает блога на LJ.

Свой блог на WordPress.com

Почти такая же история, но с возможно, более счастливым концом, с платформой для создания бесплатных блогов на wordpress.com. (есть русская ветвь).

На ней вы сможете бесплатно создать свой блог, использовать коробочный набор администрирования от CMS WordPress, менять дизайн из набора бесплатных шаблонов и т.д.

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

Создать свой блог на CMS WordPress

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

Затраты на покупку домена и аренду хостинга будут минимальны. Перед вами откроются не только широкие возможности для создания блога, но и его развития и полым контролем над его контентом.

CMS WordPress очень проста в освоении и управлении. Литературы, пособий и инструкций по WordPress в свободном доступе больше всего.

Вас может заинтересовать: Реклама в Facebook: facebook pixel

Популярность WordPress намного превышает все перечисленные здесь и возможные другие платформы.

7 основных преимуществ создать свой блог на WordPress

1. Во-первых, коробочная версия CMS WordPress бесплатна.
2. Во-вторых, она отлично переведена на русский язык.
3. В-третьих, в системе по умолчанию присутствует и настроен инструмент комментирования.
4. В-четвёртых, комментарии не только отлично настраиваются и управляются, но и очищаются от спама.
5. В-пятых, в системе присутствует инструмент позволяющий вести блог с соавторами и редакторами.
6. В-шестых, для расширения возможностей блога есть огромный контролируемый архив плагинов. Сейчас в архиве 56 328 плагинов. Чуть меньше тем WordPress, меняющих внешний вид блога.
7. В-седьмых, CMS WordPress постоянно развивается и будет в фаворе ещё долгие годы.

Еще статьи

• Какой шрифт для сайта лучше выбрать
• Управление виджетами WordPress
• Видео на WordPress сайте: полная информация
• Шаблон Ruby WordPress, универсальный, красочный шаблон для сайта и интернет магазина WordPress
• Как выбрать лучший VPN: несколько советов
• Виртуальный или мобильный номер для вашего телефона
• Установка WordPress через ISPmanager

Похожие посты:

• Перенос сайта с Blogger на WordPress
• Переадресация статей Blogger на WordPress
• Как перенести Joomla на WordPress
• Проверка сайта перед запуском – пошаговое тестирование нового сайта
• Плагин Google AdSense WordPress уникальный инструмент для размещения рекламы Google
• Карта Google maps на WordPress
• Файл robots.txt для wordpress
• Варианты создать сайт для себя
• 27 лучших плагина WordPress, которые вы должны использовать в этом году

Как организовать разработку и поддержку блога на WordPress в 2К19 году и не налажать

Заранее думать о масштабировании, по максимуму использовать стандартные решения WordPress, сделать тему WP своими руками, заботиться об удобстве верстальщика, упороться по мобильности — и обновить блог компании так, чтобы его любили читатели, редакция и руководство. У нас получилось.

Блогу компании Promopult уже 9 лет. За это время он пережил несколько трансформаций. О последней рассказывает Сергей Глазов, технолог нашего блога и других важных штук в системе Promopult.

Это уже не обсуждается, ибо стало нормой: быстрый и простой стандарт для блога компании, персоны, личного, да вообще, какого угодно — WordPress. Можно поспорить, но факт остается фактом.

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

Содержание статьи

Что было на (моем) старте — в 2016 году

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

Я принял блог в 2016 году, когда у него уже была длинная история и не все так прекрасно, как хотелось.

1. Старый дизайн блога с девятилетней историей.
2. Отсутствие мобильной/планшетной версии в каком-либо виде.
3. Больше 600 постов.
4. Структурные проблемы с контентом и его организацией: 20+ категорий и девять с лишним сотен тегов (сейчас больше, но мы уже остановились).
5. В планах уже есть ребрендинг и переезд на новый домен. Блога это тоже касается.
6. Длинная цепочка действий при работе с кодом.
7. Работа без контроля версий (.git).

Первые задачи: мобилизация и дизайн

Первостепенной задачей было добавить в существующую тему блога адаптивности: сделать так, чтобы мобильные пользователи могли адекватно читать посты и пользоваться сайтом — про Mobile First говорили и писали все чаще, да и статистика показывала, что блог читают с мобильных.

Параллельно с этими работами рисовался новый дизайн.

Я как разработчик работал в паре с дизайнером, без лишней цепочки посредников в обсуждении, так что процесс коммуникации был быстрее и живее. Очевидный факт, конечно, но почему-то в многих процессах им пренебрегают. И получается так, что дизайнер делает что-то сильно оторванное от реальности. Разговаривайте ртом и обсуждайте все моменты. Каждый участник процесса заинтересован сделать хорошо и круто. Но не каждый понимает, что процесс — связанная цепочка, и если отдельный исполнитель на своем участке работ что-то упустит или не сделает — следующим в процессе людям будет тяжело.

По ходу работы над мобильной версией я увидел минусы и слабые места организации процесса разработки. Хотелось ускорить и упростить всё.

Как было у нас с работой над кодом в блоге

Существовала DEV-версия блога с отдельной тест-базой данных. Работа с файлами происходила на удалённом сервере, тестирование проходило по отдельному адресу, недоступному во внешнем мире. После работы, тестирования и рождения какой-то единицы смысла — она выкатывалась на боевой блог через обращение к админу. Что делал он — отдельная магия.

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

Что хотелось получить, как говорится, «в идеальном мире»

Весь код лежит в .git-репозитории. Боевой вариант блога — master -ветка этого репозитория. Вся работа с кодом происходит через коммиты в dev -ветку или другие ветки, связанные с отдельными большими задачами.

После того, как задача сделана — создаётся Pull Request (PR) и/или Merge Request (MR) с набором правок. Смысл в MR и PR один и тот же, но в разных сервисах — разное название. У нас GitLab, поэтому — Merge Request.

При создании MR становится доступным временный адрес вида имя-git-ветки-test.dev.blog.promopult.ru , доступный только по IP для живой проверки на тест-окружении.

Код в созданном MR ревьюится и проверяется в автоматическом (линтеры кода, которые проверяю синтаксис по заранее определенным правилами) и в ручном режиме (вертикаль власти в команде, на всё пристально смотрит своим военно-морским выпуклым внимательным глазом тимлид). После прохождения ревью — из интерфейса браузера .git-репозитория нажимается кнопка «Merge» и все изменения появляются в эфире боевого блога через какой-то краткий очевидный промежуток времени.

Редизайн, первый подход

План работ по редизайну блога:

1. Вёрстка статичного прототипа по дизайн-макетам всех страниц;
2. Превращение («натяжка») вёрстки в WordPress-тему.

Вёрстка — отдельный этап работ. Для удобной работы со стилями (CSS), разметкой и JS в проекте был использован набор плагинов и модулей, который собирается через Gulp-задачи, описанные в сборщике SPT (Start Project Template).

Ключевые слова, которые используется в сборщике статичной темы блога: HTML, CSS, JS, Babel, Gulp, PostCSS, SCSS, Nunjucks.

По завершению работы над вёрсткой структура была такой (указаны только каталоги первого уровня):

├── design # Дизайн, макеты и всякое ├── app/ # Исходники проекта: отдельные модули ├── dist/ # Собранный вариант проекта (html-файлы) и вся статика ├── gulpfile.js/ # Конфиг Gulp.js └── package.json # Файл-конфиг сборщика: пакеты, скрипты

Каждый отдельный визуальный смысловой элемент на странице, например, карточка поста ( /components/article_card/ ), представлял из себя папку, в которой был:

— файл разметки ( article_card.html ),

— файл стилей ( article_card.scss ),

— файл JS ( article_card.js ).

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

На выходе сборщик создавал папку dist , в которой содержались готовые html-файлы страниц для наглядного просмотра в браузере на этапе правок и согласований, а также один файл стилей все темы и два JS-файла: один файл ( app.js ) описывал логику и поведение сайта, второй ( vendor.js ) содержал все библиотеки, используемые для сайта (jQuery, fotorama, magnific-popup и другие).

Дальше всё это нужно превратить в WordPress-тему и продумать файловую структуру. Чтобы можно было удобно работать со статичной вёрсткой и рядом же лежала WP-тема.

Список макетов, которые приготовил дизайнер. Они совпадают с файлами WordPress-темы блога:

• Главная страница (файл home.php ).
• Страница отдельной записи/поста ( single.php ).
• Вид отдельной текстовой страницы ( page.php ).
• Страница подписки на рассылку ( subscribe.php ).
• Ошибка 404 ( 404.php ).
• Отдельная страница тега ( tag.php ).
• Отдельная страница категории ( category.php ).
• Поиск и результаты поиска ( search.php ).

Рабочий процесс с таким подходом и разделением на статичный вариант и WordPress-вариант темы происходит так: если нужно что-то поправить в визуальной части — правки вносятся в статичном варианте и после теста переносятся в тему. Если правки нужны в какой-то не визуальной части — то изменяются только файлы WP-темы.

Папка с темой блога — bsp . Она расположена по пути в папке с темами самого блога:

├── wp-content/ # Пользовательские файлы WordPress-сайта │ ├── themes/ # Темы сайта │ │ ├── app/ # Исходники статичной темы │ │ │ ├── gulpfile.js/ # Gulp-задачи для сборки │ │ ├── dist/ # Сборка статичной темы │ │ │ ├── assets/ # Ресурсы: JS, CSS и графика │ │ ├── bsp/ # WP-Тема блога PromoPult │ │ │ ├── assets/ # Ресурсы: JS, CSS и графика, копирование из `/dist/` │ │ │ ├── home.php # Главная страница блога и другие файлы в корне темы

Место wordpress-темы очевидно и предопределено файловой структурой самого WordPress.

Других тем в директории с темами нет — всё стандартное удалено. Есть миф о повышении производительности таким образом, но мы этого не заметили. Это сделано скорее для порядка в коде. Не нужно хранить то, что не используется и точно не будет использовано.

Также в .git лежат и все WP-плагины, которые используются. На нашем сайте это — Google XML Sitemaps, RSS for Yandex Turbo, RusToLat и WP-PostViews.

Статичный, свёрстанный прототип страниц блога и файлы-исходники были перемещены в директорию темы блога: чтобы взаимодействовать было удобно и с логической частью шаблона и со всем тем, что отвечает за внешний вид и поведение элементов на странице.

Статичный вариант сборки проекта — с исходниками и всеми зависимостями в первой попытке организации структуры — был помещен в директорию тем.

То есть рядом с основной темой bsp добавилась директория /app , в которой размещены исходники вёрстки темы и gulp-сборщик. Но в таком варианте был один сложный момент: статичные файлы генерировались в отдельную директорию, и чтобы изменения были в WP-теме, нужно было копировать статичные файлы стилей и скриптов в папку assets внутри темы.

Второй подход: новый вариант структуры

В первые недели это было решено простым консольным скриптом, которые копировал собранные файлы из статичной темы в WP-тему. Лишнее действие влечёт к ошибкам. Поэтому вариант был только в исправлении структуры.

У нас есть три важных директории (все пути от корня):

1. WP-тема: /wp-content/themes/bsp
2. Исходники статичной темы: /app
3. Собранная статичная тема: /dist

А внутри неё — assets с файлами стилей, графикой и JS

Нужно расположить всё так, чтобы файлы статики стилей и скриптов собрались в нужную папку ( /wp-content/themes/bsp/assets ).

Новый вариант структуры оказался таким:

├── gulpfile.js/ # Gulp-задачи для сборки ├── wp-content/ # Пользовательские файлы WordPress-сайта │ ├── plugins/ # WP-плагины │ ├── themes/ # Темы сайта │ │ ├── bsp/ # Тема блога PromoPult │ │ │ ├── app/ # Исходники статичной темы │ │ │ ├── assets/ # Ресурсы: JS, CSS и графика (автогенерация) │ │ │ ├── home.php # Главная страница блога и другие файлы в корне темы ├── wp-admin/ # WP-файлы для админки ├── wp-includes/ # WP-файлы системы

В корне всего проекта лежат gulp-задачи — и исполняются из корня. В конфиге gulp-задач описана структура, что статичные файлы собираются из директории wp-content/themes/bsp/app в wp-content/themes/bsp/assets без каких-то дополнительных действий типа копирования и т.п.

Файлы WP-темы остаются без изменений и работа происходит по старому сценарию: правки в статике → перенос в WP-файлы. Статика CSS и JS генерируется сразу в папке с темой и всё просто работает.

Всё это было про процесс работы. Теперь про то, как устроен сам блог.

Блог PromoPult: как всё устроено

Самая главная сила блога — команда. Редактор, авторы, верстальщики.

Большая задача — сделать работу с контентом блога удобной в админке. А с учётом того, что тема нашего блога сделана специально под задачи контента и запросы редакции — админка была доработана соответствующим образом.

Чек-лист перед публикацией

Любую работу важно контролировать. Вёрстка статьи — стандартный, формализованный процесс, который спокойно можно представить в виде чек-листа.

Идею увидели у ребят из EmailSoldiers. Решили применить у себя.

Если какой-то пункт не отмечен — система предупредит перед публикацией.

По клику на ссылки, подчеркнутые ссылки в элементе списка — подсвечиваем конкретный пункт.

Чек-лист составлен в том же порядке, что и дополнительные настройки поста в админке.

Настройки поста в админке блога

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

При разработке темы я старался не использовать плагины, а сделать простое и лёгкое решение для задач темы. Основные моменты:

• Описания для SEO-мета тегов.
• Описания для OpenGraph-тегов, которые используют соцсети при расшаривании материала и формируют симпатичные карточки статей.
• Удобная работа с картинками-обложками для постов. Одна картинка обязательна — она добавляется в карточку поста в плитке публикаций, которая отображается на главной и на странице рубрики или тега.
• Дополнительные настройки темы: пост может быть с обложкой или без, есть краткий текст-анонс, который мы показываем в шапке с обложкой, и он же используется в описании статьи в рассылке дайджеста.

Раздел настроек поста реализован через мета-боксы и пользовательские поля в WordPress.

Через мета-бокс добавлен и чек-лист публикации.

В шаблонах работа с полями устроена просто: если поле не пустое и заполнено — достаем значение и показываем. Например, вот так выводится блок-реакция на пост:

ID, 'postreaction', true)) < ?> 
ID, 'postreaction', true); ?>
 
  ?>

Пример вывода реакции на карточке поста:

Приятные мелочи

Есть несколько приятных мелочей, которые, может быть, никто и не видит. Но если кто-то заметил — хорошо.

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

Счётчик комментариев поста. Долго спорили о том, что «0 комментариев» или «нет комментариев» очень смущает. Решение очень простое: не показывать счётчик комментариев вообще, если комментариев меньше одного.

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

Свои собственные лайки: комментирование или расшаривание ссылки в соцсетях — долгое дело по меркам темпа потребления контента, а вот жмакнуть «лайк» и дать понять, что статья клёвая — просто и быстро. Мы сделали свои простые лайки и вывели счётчик в карточку поста. И лайки прибывают довольно быстро. А так как они стоят внизу статьи — это еще и сигнал, что текст дочитали.

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

Про интересное техническое

В теме есть минификация кода разметки, CSS и JS. CSS и JS сжимается через gulp-задачи в сборщике статики, а вот минификация разметки сделана через WordPress-хук WP_HTML_Compression .

А в комментарии в разметке мы добавили промокод для тех, кому интересно, как устроен сайт изнутри и кто первым делом идёт смотреть исходный код:

Кэширование CSS и JS. Чтобы файлы стилей и скриптов кэшировались, но всегда были актуальными, если мы что-то переделали — используем filemtime(). Многие в таком случае используют ? . Но такой вариант загружает файл и делает запрос при каждом обращении.

Лучше использовать такой трюк:

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

Какие плагины используем

Несмотря на возможность и желание в некоторых случаях обойтись своим решением, плагины всё же мы используем. Список у нас такой:

• Google XML Sitemaps — для генерации XML-карты сайта для роботов;
• RSS for Yandex Turbo — турбо-страницы для Яндекса;
• RusToLat — транслитерация русских символов URL в английские;
• WP-PostViews — считает просмотры материалов;
• Classic Editor — включает классический WordPress-редактор вместо нового блочного Gutenberg;
• Ограничение попыток авторизации — это для безопасности: при нескольких ошибочных попытках логина — баним входящего на настраиваемый промежуток времени;
• AMP — AMP-страницы для Google.

Советы-выводы для тех, кто работает над блогом компании

• Советую в начале работы над проектом сразу думать о масштабировании.
• Обязательно использовать .git в работе. Для 2019 года, конечно, странный совет, но этот совет может спасти кого-то от седых волос и выговора, когда что-то пойдет не так.
• Разработку и работу над WordPress-темой лучше разделить на два этапа: сначала верстать что-то статичное, а уже свёрстанное «натягивать» как тему на WordPress.
• Если есть возможность — время, команда и понимание того, зачем вам всё это, — делайте тему сами, без использования готовых вариантов. Выиграете в порядке и понимании того, как всё устроено. Не будете плодить костыли.
• Используйте стандартные хуки и возможности WordPress, если ваш блог построен на нём. Кастомизировать и сделать удобное решение можно быстро и просто.
• Делайте удобно для пользователя и редакции.
• Не забывайте про социальные сети и микроразметку.
• Не забывайте про мобильные версии.
• Не забывайте про регулярные обновления плагинов и системы.
• Выбирайте только проверенные плагины.

Работа над блогом продолжается — оставайтесь с нами.

• Блог компании Click.ru
• Веб-разработка