WooCommerce

Разрабатываем WordPress сайты на встроенном в php сервере

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

Применяем js/css только на тех страницах где присутствует шорткод WordPress

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

WordPress собираем при помощи Gulp

Сейчас модно в web разработки использовать автоматическую сборку проектов, и это хорошо, хорошо потому что удобно и  сильно ускоряет весь процесс.
Сейчас самым  лучшим и популярным на мой взгляд инструментом для сборки я является Gulp, именно поэтому сегодня я расскажу именно про Gulp, про GruntJS я бы тоже мог рассказать так как использовал и его, но Grunt сейчас уже сильно отстал от Gulp по всем параметрам поэтому не буду его поминать боле.

Конфигурационные файлы WP-CLI

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

Запретить планировать пост больше чем на год в WordPress

В случае если над блогом работают несколько редакторов, у пользователей есть возможность писать гостевые посты либо в подобных похожих ситуациях, бывает случаются оказии когда статьи планируется на неадекватно далекое будущее. Например бы я запланировал/отложил до лучших времен это пост, скажем на 2056 год то то как минимум он бы потерял актуальность, а возможно до его публикации дожили бы не все мои знакомые. Но даже если не брать в расчет такие маргинальные сценарии то есть и другие минусы, каждый раз когда я создаю пост на несколько лет вперед и после этого добавляю скажем миниатюру поста то в каталоге загрузок WordPress создается новый каталог совпадающий с годом указанным в посте и в него уже загружается изображение миниатюры и после того как гипотетический, абстрактный я в вакууме сменит год на более подходящий и опубликует запись то в url миниатюры (при дефолтных настройках WordPress ) все равно останется 2056 год от рождества христова, что не устраивает моего внутреннего перфекционистка. А если подобных постов становится много то буквально все становится хуже: выпадающие списке фильтров в админке становятся хуже, труднее прикинуть количество медиафайлов загруженных за определенный промежуток времени, директория загрузок на сервере смотрится не красиво…