Global WordPress Translation Day in Moscow

In past weekend I had the opportunity to join Global WordPress Translation Day in Moscow, Russia. It was a great weekend with associates and also an occasion to see the attendees, who have also visited WordCamp Moscow 2016, again.

I’m very happy that Setka (where I’m currently working) allows organizers to use our big and lovely editorial office in downtown for WordPress meetups. It’s pretty unusual to see our office empty 🙂

And I’m also exited to see my co-workers and friends at this weekend days (Hi Katya, Petya and Roma). And discuss some product stuff after WordPress meeting.

During this meeting we tried to translate Maker theme and Members plugin. Setka was so friendly and ordered for us some pizza 🍕.

Dmitriy had a chat session with John in realtime to show us to the world 🌎. You can find us from 12:37 (and me at background :).

Глобальный день перевода WordPress в Москве

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.

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

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

2016.moscow.wordcamp.org

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

Формы 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-инициализации полей (инпутов). Посмотрим, имеет ли смысл все это внедрять.

Интересное при работе с wp_remote_get()

Отправляя запрос на внешний сервер через wp_remote_get(), как правило, на принимающей стороне хочется узнать кто делает запрос и откуда.

Какого-нибудь $_SERVER['HTTP_REFERER'] конечно же нету. Но не стоит спешить передавать адрес сайта в качестве URL-аргумента при запросе.

Сам WordPress по умолчанию кое-что передает в заголовках и в результате на принимающей стороне есть $_SERVER['HTTP_USER_AGENT'] — внутри адрес сайта, который делает запрос. В качестве бонуса в этой переменной также можно найти и версию WordPress, которая используется на сайте, делающим запрос.