Владимир Петрозаводский Если полистать сайт developer.wordpress.org то можно найти пост который называется Best Practice (лучшие практики).
В этом посте меня заинтересовал последний пункт там говорится что вместо того чтобы начинать создание каждого нового плагина с нуля можно воспользоваться заранее сделанными заготовкам и приведен их список.
Если коротко то речь пойдет о том что в php начиная с версии 5.4.0 и как то сей факт на мой взгляд незаслуженно забыли, хотя во многих случаях пользоваться им достаточно удобно , и для мелких задач это самый правильный путь для тестовых проектов и прочих экспериментов.
Шорткоды WordPress прекрасны ими удобно расширять функционал страниц и постов, но есть как минимум один сомнительный момент, заключается он в том что для некоторых шорткодов хотелось бы подключить js и css файлы. Здесь и начинаются вопросы, например как подключить эти файлы только на страницах где это необходимо.
Мне не хотелось бы видеть эти файлы на тех страницах контент которых не содержит шорткода, но о том как это сделать правильно информации толком найти не удалось поэтому будем экспериментировать.
Проблема появилась когда писал код на машине с плохим интернетом, весь мой сайт отдавался с локального веб сервера, но запросы к gravatar.com подобного вида:
Сейчас модно в web разработки использовать автоматическую сборку проектов, и это хорошо, хорошо потому что удобно и сильно ускоряет весь процесс.
Сейчас самым лучшим и популярным на мой взгляд инструментом для сборки я является Gulp, именно поэтому сегодня я расскажу именно про Gulp, про GruntJS я бы тоже мог рассказать так как использовал и его, но Grunt сейчас уже сильно отстал от Gulp по всем параметрам поэтому не буду его поминать боле.
Почти официально объявлено о долгожданном слиянии включении событии WP REST API включат в ядро WordPress.
Я видел много информации о WP-Cli в интернете но, все посты были похожи друг на друга в них перечисляется несколько самых очевидных команд и зачем это вообще нужно. Но не слова на русском я не нашел о конфигурации утилиты как быть в том случае если на моем сайте несколько сайтов и т.д.
В продолжение моей прошлой статьи о сборке плагинов gulp-ом решил сделать продолжение и написать о моем опыте автоматизации создания шаблонов для WordPress.
Встала задача создания мультисайтовой инсталяции wordpress на локальном сервере Winginx и так как я в качестве локального сервера по Windows давно уже использую только Winginx (он очень хорош http://winginx.com/ru/) то немного изучить его конфиг, он имеет свои особенности :
По умолчанию WordPress умеет перемещать загруженные файлы в подкаталоги с разбивкой по годам:
В интернете можно найти странное объяснение что веб шелл это такая страшная штука может пароли перебирать, украсть конфиденциальные данные и обязательно где то в этом предложении фигурирует приставка «вредоносный «.
В случае если над блогом работают несколько редакторов, у пользователей есть возможность писать гостевые посты либо в подобных похожих ситуациях, бывает случаются оказии когда статьи планируется на неадекватно далекое будущее. Например бы я запланировал/отложил до лучших времен это пост, скажем на 2056 год то то как минимум он бы потерял актуальность, а возможно до его публикации дожили бы не все мои знакомые. Но даже если не брать в расчет такие маргинальные сценарии то есть и другие минусы, каждый раз когда я создаю пост на несколько лет вперед и после этого добавляю скажем миниатюру поста то в каталоге загрузок WordPress создается новый каталог совпадающий с годом указанным в посте и в него уже загружается изображение миниатюры и после того как гипотетический, абстрактный я в вакууме сменит год на более подходящий и опубликует запись то в url миниатюры (при дефолтных настройках WordPress ) все равно останется 2056 год от рождества христова, что не устраивает моего внутреннего перфекционистка. А если подобных постов становится много то буквально все становится хуже: выпадающие списке фильтров в админке становятся хуже, труднее прикинуть количество медиафайлов загруженных за определенный промежуток времени, директория загрузок на сервере смотрится не красиво…
Всем известно что некоторые глобальные параметры WP-CLI можно задать в его конфигурационном файле
wp-cli.yml и что среди них нет хоста базы данных, ее имени и других параметров которые задаются в wp-config.php.
Давным-давно я уже писал о том как добавить в админку WordPress произвольное поле с возможностью загрузки файлов, но код из той статьи все это время меня смущал. Дело в том что прошлый раз я описал не лучшую реализацию загрузчика да и код мягко говоря грязноват, поэтому я решил написать тоже самое но более красиво и удобно поэтому я изучил вопрос глубже и выяснилось вот что: в админке на странице редактирования поста в javascript определен глобальный объект wp который содержит все что нужно для реализации данной функциональности.
Содержимое объекта с комментариями можно посмотреть в файле wp-includes/js/media-editor.js.
Недавно сделал маленький плагин который, умеет делать только одну вещь — он не дает напечатать анонс длинней заданного в настройках количества символов.