Why you should never use wp-admin named folders in your plugin or theme

Why you should never use wp-admin named folders in your plugin or theme

Working on each plugin I always want to create a simpler and clean folders and files structure which everyone can understand in just one glance. It’s a main goal for all developers — creating simply and reusable code which doing some amazing work inside your products. Isn’t it?

I’ve been going a long way in attempts to create a solid files structure which perfect fits for every product I’m working on. It’s a good idea to write just a simply fancy code in single project. Even better to write a code using certain standards.

Unfortunately now WordPress doesn’t have established recommendations for plugins structure. The themes have a better equipment. Usually the themes shouldn’t have any hardcoded logic. I think that themes should be just a templates which defines a views, not a business logic or something. Or maybe not. Every single product have different purposes and environment. I don’t think that this world have just a one single solution which is right.

Now we have many plugins with absolutely different files structure. And understanding the logic of that plugin is like the conquest of Everest. 🙂

Jetpack plugin files

Jetpack plugin files

In my projects I have come to the conclusion that a folder called wp-admin is the best name for the folder with files which relates to WordPress wp-admin pages (admin screens). But it’s not the best name for this type of folder.

After running a wp core verify-checksums I was surpised with output in console.

wp core verify-checksums
...
Warning: File should not exist: wp-content/plugins/setka-editor/twig-templates/wp-admin/settings/auth/token.html.twig
Warning: File should not exist: wp-content/plugins/setka-editor/twig-templates/wp-admin/settings/common/checkboxes-in-fieldset.html.twig
Warning: File should not exist: wp-content/plugins/setka-editor/twig-templates/wp-admin/settings/common/template.html.twig
Success: WordPress install verifies against checksums.

Ow! It looked not as I expected. In trying to understand and explain this behaviour I’m stuck in WP-CLI source code. And the answer in Core_Command->get_wp_core_files(). So I’ve just renamed my folder from wp-admin to admin.

Also be avoid name your folders as wp-includes or any other WordPress “reserved” names. Other products may confused with this names.

P. S. It seems that I need more to write about plugin structure in next posts.

Advertisements

Санитайзинг по-русски

«Санитайзинг» по-русски

На совместном ужине со спикерами WordCamp Moscow 2016 мы, кажется, обсуждали о том, как называть некоторые вещи по-русски: валидация, верификация… Самым сложным англицизмом оказался санитайзинг. Озвучивались разные варианты, но все как-то не очень подходили и вызывали дополнительные вопросы, потому что не полностью отражали изначальной сути.

Сегодня я случайно полез на php.net за очередной порцией документацией — сайт случайно открылся на русском языке и я увидел санитазийнг! Вернее не «санитайзинг», а «нормализацию значений». Вот оно!

Sanitizing = Нормализация значения

Приглашение на WordCamp

Приглашаю всех на WordCamp в Москве. Так получилось, что я буду выступать там — расскажу про Vagrant, VirtualBox и VVV (ну, и по мелочи затрону: Git, Amazon Web Services).

2016.moscow.wordcamp.org

Посетителям обещают много разных докладов и неформальное общение. А также футболки с логотипом WordPress и покормят! 🙂

Новые инструменты. Symfony Validator

Я хотел написать про кучу нового и интересного с чем удалось познакомиться и какие мысли пришли в голову — но это много. Поэтому разобьем все на несколько постов. Первый (этот) пост посвящен короткому, но знакомству, с Symfony Validator.

На прошлой неделе я разобрался с работой Symfony Validator. Это потрясающая библиотека (дополнение) позволяет проверять любые типы данных на какие-либо соответствия. Если коротко, то проверка чего угодно сводится к паре дополнительных строчек. И не нужно городить очередную реализацию какой-нибудь формы в 101 раз.

Библиотека хороша тем, что работает где угодно, даже в WordPress — для этого ей ничего не нужно. Это большой плюс Symfony — весь фреймворк по сути набор небольших модулей (symfony.com/components), которые умеют работать независимо друг от друга (может скоро и Doctrine захочется прикрутить к WordPress? — пока не было необходимости). Я использую все это для проверки настроек большого плагина (энтерпрайз и все такое).

Ниже приведен простой пример использования Validator, но он полностью рабочий (должен быть, писал в блокнотике по памяти). Конечно, все это подойдет лишь для демонстрационного «стенда». Для нормального применения пришлось написать с десяток новых классов, «задокументировать» все это в интерфейсах и прочее. Но результат того явно стоил.

// Создаем валидатор
$validator = Validation::createValidator();

// Входные данные
$input_data = array(
	// Значение должно быть ссылкой
	'url' => 'http://korobochkin.com/',

	// Список чего-либо
	'post_types' => array( 'post', 'page' )
);
// Создаем правила для проверки массива
$constraints = new Constraints\Collection( array(
	'url' => array(
		// Не должно быть пустым
		new Constraints\NotBlank(),
		// Должно содержать ссылку
		new Constraints\Url()
	),
	'post_types' => new Constraints\Choice( array(
		// Доступные (разрешенные) варианты (опции)
		'choices' => array_values( get_post_types() ),
		// Может быть выбрано сразу несколько
		'multiple' => true,
		// Строгая проверка типов для брони :)
		'strict' => true
	) )
) );

// Проверяем
$errors = $validator->validate( $input_data, $constraints );

if( count( $errors ) === 0 ) {
	// Ошибок нет, переменная $input_data прошла проверку
}
else {
	// Есть ошибки при валидации
}

Формы 3. Знакомство с Backbone

Не так давно я начал писать на Backbone. И, переделав кривущее приложение с нуля по наставлению коллеги (спасибо Егору), мне понравилась эта библиотека. Это то, чего мне не хватало в JavaScript. Системность и структурность, наконец-то.

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

Так вот, формы. Небольшой поиск показал, что есть Backbone Forms. Хорошая штука, которой не хватает в WP Forms. Если авторы ничего не накрутили и можно строить вьюшки по уже существующим в DOM элементам, то это потрясающая находка.

Кэширование языковых файлов в WordPress

Недавно заметил, что WordPress довольно часто тратит много времени на загрузку MO-файлов (файлы переводов). После некоторых поисков нашлось даже готовое решение WordPress MO Cache.

Плагин модифицирует логику загрузки MO-файлов и засовывает их содержимое в объектный кэш. Ну, а дальше понеслось.

Несмотря на наличие wordpress.org версии, плагин лучше подключать как MU Plugin. Иначе все языковые файлы, подключаемые до загрузки этого самого плагина, будут все равно загружаться как и раньше — каждый раз с диска (об этом написано и в FAQ плагина).

Из минусов, стоит отметить, несмотря на все это, вызывается функция is_readable(), что, я подозреваю, все равно делает обращение к файловой системе. Ну, и наличие composer.json в репозитории плагина бы не помешало.

Как поддержка хостинга может добавить уязвимостей вашему сайту

Недавно мне прислали вопрос в духе «форма отправки сообщений с сайта перестала работать, что делать?». Я ответил, что необходимо проверить настройки подключения к SMTP-серверу и попробовать отправить тестовое письмо — после приема сообщения, сайт отправляет его на почтовый ящик через SMTP сервер.

Continue reading

Формы для WordPress. Часть 2

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

Continue reading

Формы для WordPress

Наткнулся на интересный плагин wordpress.org/plugins/cmb2. Программное создание формочек и всяких дополнительный полей для плагинов и тем. Вроде без shitty-кода внутри, но внутреннюю архитектуру с одного взгляда «прочитать» не удалось.

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

Иллюзия обмана от Apple

После вчерашнего обновления до Mac OS 10.11.4 (15E65), выпущенную на свободу сразу после анонса iPhone SE, я немного испугался уже на первый день использования. Мое замечание и восклицание касается Safari и его дизайнеров, которые, похоже, «гудели» вместе с дизайнерами iPhone SE.

Обычный рабочий день, код и дебаг, копаюсь в браузере на локальном сайте (использую VVV, кстати) и тут при клике, вылезает что-то вроде «окошка», которое я быстро «скипаю» ESC-ом, не придавая особого значения. Мало ли что там вылезло.

Screen Shot 2016-03-23 at 23.46.30

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

Screen Shot 2016-03-23 at 23.32.26

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

Screen Shot 2016-03-23 at 23.32.56

System Monitor и прочие штуки не показывают ничего подозрительного в системе, Сафари жив и не повис. И вот тут я неслабо так перепугался, начав вспоминать, каким чудом, я, мог, подцепить, немыслимое.

Спустя минуту паники я написал в консоль window.alert(‘hi’);. И что же я увидел? Да! Именно такое же окошко!

Как можно было нарисовать Алерт на 100% напоминающий обычный кусок веб-страницы?! Apple, ау!

Бонус видео (смотреть со звуком):