Нюансы коммерческой разработки на WordPress. Полезные советы для разработчиков на WordPress. Этапы разработки WordPress

Новости 13.03.2019
Новости

Сейчас все кому не лень создают сайты. Один из самых популярных движков — это WordPress. Программист под данный движок должен не только знать php, но и знать саму структуру движка, уметь верстать и знать jquery(JavaScript)
Так уж сложилось, что мне довольно часто приходится искать разработчика под Вордпресс для своего сайта. Я сталиквался с несколькими разработчиками. Кое-кто делает свою работу очень плохо. А кого-то я могу посоветовать.
Ну а теперь я расскажу о основных принципах, как выбрать специалиста по WordPress.

Студия это не всегда хорошо.

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

Инди-Программист WordPress

Под инди я имею ввиду разработчика, который работает сам на себя. Стоит сразу поговорить с человеком, чтобы выяснить уровень его знания Вордпресс. Когда я искал человека, наткнулся на Колесникова Сергея . Состоялся вот такой диалог:

Kolesnikov Sergey: Здравствуйте
Дмитрий Евгеньевич: Вопрос
Kolesnikov Sergey: слушаю
Дмитрий Евгеньевич: Насколько хорошо знаете вордпресс?
Kolesnikov Sergey: не мне судить наверное))
Kolesnikov Sergey: что вас интересует?
Дмитрий Евгеньевич: Ну допустим чем пост отличается от станицы кроме типа записи в бд
Kolesnikov Sergey: мне сейчас некогда экзамены сдавать)) если чтото конкретное я вас слушаю
Дмитрий Евгеньевич: Секунду
мне нужно такой плагин
Дмитрий Евгеньевич: оцените цену в рублях и сроки
Дмитрий Евгеньевич: раз уж конкретно
Kolesnikov Sergey: ок, отпишусь

Как видите, девелопер отказался пройти тест, ну и естественно мне не написал. С таким я связываться точно не буду. Мало того, что он скорее всего не знает вопрдпресс, т.к. не смог сходу ответить на простой вопрос, так он еще и не держит обещания. Ну естественно, он не отписался. Такой специалист либо кинет вас, бросив проект посреди срока, либо сделает все настолько криво, что вы замучаетесь исправлять ошибки.

Нужно искать правильного специалиста по WordPress

Совершенно другое представление о себе производит Степасюк Андрей (http://stepasyuk.org.ua/)
Цена разработки в час от 15 долларов в принципе очень адекватная цена. При общении, сразу видно что человек знает вордпресс, т.к. задает правильные вопросы после прочтения ТЗ. Не нужно тестировать человека на знание движка. Работа по предоплате у данного специалиста одна из гарантий кидка и того, что специалист закончит ваш проект.
Ключевое условие выбора кандидата — интерес к вашему проекту, наличие вопросов перед началом проекта и по ходу работ. Если вопросов нет — повод задуматься, идет ли работа..

Бывают и провалы

У меня тоже были провалы. Человек брался за работу и не выполнял ее в срок. Поэтому, перед тем, как дать человеку работу, нужно протестировать разработчика и понять его уровень. Для этого можно задать простые вопросы

  1. Чем пост отличается от страницы
  2. Может ли человек верстать и как хорошо знает JS
  3. В какой таблице хранятся посты
  4. Что такое доп.поля и как их задавать

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

  1. Что самое сложное в ТЗ и почему?
  2. Какой самый сложный проект вы делали? Попросите пример и уточните, что сложного
  3. Разрабатывали ли вы плагины

Обычно опыт разработки плагина для программиста под WordPress дает хороший опыт. Предоплату за работу можно делать в размере 10-30 процентов, с условием, что если проект затянется, то предоплата возвращается без каких-либо обязательств.

Мой черный список разработчиков под WordPress

Здесь я приведу контакты, кто не доделал работу до конца или сделал ее плохо.
Первая конторка, о которой я писал — BVB Logic. Сделали работу криво и очень плохо.
Второй человек: Skype: spider13_ — вместо заявленных 1 недели делал мой проект 3 недели. В итоге я отказался от долгостроя. Постоянно возникали вопросы по реализации. Такое ощущение, что человек плохо знает сам движок, хотя за работу взялся и вроде как что-то делал. На вторую неделю ничего не предоставил. Потом перестал отвечать на сообщение в скайпе. Сотрудничество пришлось завершить.

P.S. Кстати на нашем сайте все еще открыта .

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

Этапы разработки WordPress

Разработка каждой новой версии WordPress делится на пять основных этапов:

  • Планирование
  • Дизайн и разработка
  • Бета тестирование
  • Релиз кандидаты
  • Релиз

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

Всего на один релиз уходит примерно 4 месяца: 2 на дизайн и разработку, 1 месяц на бета тестирование и 1 месяц на релиз кандидаты. После *выхода* новой версии начинается цикл её поддержки с помощью технических релизов, как например версии 3.5.1 и 3.5.2, которые не содержат в себе нового функционала, но устраняют ошибки и уязвимости предыдущих версий.

Параллельно с работой над техническим релизом начинается планирование уже следующей основной версии.

Кто разрабатывает WordPress

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

Кроме этих людей, в развитии проекта участвуют более двухсот дизайнеров и разработчиков со всего мира: кто-то в рамках своей основной работы, а кто-то в качестве хобби. Этот список растёт с каждым релизом.

Существует немалое количество компаний, чей бизнес каким-либо образом связан с WordPress, эти компании выделяют одного или нескольких сотрудников для работы над WordPress. Самые яркие примеры — это хостинг провайдеры Bluehost и DreamHost, разработчики тем WooThemes и The Theme Foundry, ну и конечно же компания Automattic.

Subversion

Сам исходный код WordPress хранится в системе управления версиями под названием Subversion. Это открытый репозиторий , куда может заглянуть каждый. Он имеет следующую структуру:

  • /tags — в это директорию помещаются все релизы: как основные, так и технические
  • /branches — это ветки, которые всегда содержат последние изменения в определённой основной версии. Например, если это ветка 3.5, то она будет содержать все изменения в 3.5.1, 3.5.2 и т.д.
  • /trunk — содержит новую версию, которая находится в разработке, и ещё пока не выпущена. На сегодняшний день это версия 3.6

Для доступа к репозиторию, вам потребуется Subversion клиент, например Versions для OS X, или TortoiseSVN для Windows.

Trac

Для управления проектом WordPress используется система Trac , которая чем-то напоминает обычный форум.

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

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

Тестирование

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

Общение

Всё общение между участниками проекта происходит в основном в трёх местах. Это IRC чаты, сеть блогов «make» и система управление проектом Trac, о которой мы уже говорили.

Каждую среду, разработчики WordPress проводят встречу в чате. Это канал #wordpress-dev на IRC сервере Freenode . Любой желающий может присоединиться и поучаствовать в дискуссии, предложить свои варианты решения проблемы, или просто узнать о том, как и куда движется разработка.

Кроме чатов, есть так же сеть блогов под названием make/* , например make/core для разработчиков, make/ui для дизайнеров и т.д. На этих блогах ведётся всё планирование. Разработчики делятся идеями, делают наброски (скриншоты), публикуют анонсы и другую информацию.

Как мы можем помочь

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

К примеру, если вы занимаетесь дизайном, вы можете подписаться на блог make/ui , который посвящён созданию пользовательских интерфейсов, участвовать в обсуждении и делиться своими идеями. Еженедельные чаты этой группы проходят в IRC канале #wordpress-ui.

Кроме дизайна есть группа переводчиков. Если вы владеете английским языком, вы можете участвовать в переводе документации, тем, плагинов и самого WordPress. В таком случае вам стоит посетить блог make/polyglots и познакомиться с системой translate.wordpress.org .

Если вам нравится помогать людям, вы можете отвечать на вопросы в форумах поддержки на WordPress.org и в IRC канале #wordpress. Загляните в группы make/support — посвящена поддержке, и make/docs посвящена документации.

Для разработчиков тем и плагинов для WordPress есть группы make/themes и make/plugins . Здесь обсуждают репозитории тем и плагинов на WordPress.org, правила попадания в директории и прочее.

Для разработчиков приложений для мобильных устройств существует группа make/mobile . На сегодняшний день, для WordPress уже разработаны мобильные приложения на платформы iOS, Android, Windows Mobile и другие. Так же как и само ядро WordPress, разработка мобильных приложений ведётся публично.

Для организаторов мероприятий, связанных с WordPress есть группа make/events . Здесь участвуют организаторы неформальных встреч, митапов, конференций WordCamp, обсуждают идеи и делятся опытом.

Ну и наконец разработчики. Для разработчиков существует группа make/core . Это основная группа, где можно узнать куда движется WordPress, и когда выйдет новая версия.

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

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

По большей части информация будет «технического плана», касательно CMS Worpdress, «по верхушкам». Я рассказываю лишь про наш путь, для кого использование технологий, путей, приемов etc. вопрос религии - просьба воздержаться от холиваров. Приступим.

Для начала небольшое отступления. В общей своей массе, у нас именно, проекты делятся на несколько типов по принципу разработки:

  • HTML шаблон с themeforest -> сборка на CMS;
  • Дизайн -> верстка -> сборка на CMS;
  • Разработка индивидуальных решений.

Сразу оговорюсь, что рассматривать в этой статье я буду только первых два пункта, ибо обобщить третий мне представляется довольно сложной задачей, т.к. любимые/самые лучшие/все остальные плохие технологии у каждого свои и в небольших городах бывает сложно найти разработчика хорошего уровня на RoR/Flask и иже с ними. И пробегусь по ним обзорно. Если возникнет интерес к этой теме - почему бы и не быть развернутой статье-туториалу «Как собрать сайт на WP за 4-8 часов, которым клиент будет доволен».

Почему Wordpress?

Низкие бюджеты и желание привносить в мир меньше энтропии обосновало выбор. Более подробно:

  • Удобство админ-панели для клиентов. Я серьезно, после введения этой CMS все обучение заказчиков свелось к тому, что мы высылаем пароль администратора. Воспоминания о записи видео “Как создать новость”, “Как поменять телефон на сайте” перестали мне сниться.
  • Скорость сборки сайта. Около 4-8 часов на проект это здорово. Конкурентное преимущество.
  • Кривая обучения разработчиков для сборки проектов. Пока мой рекорд - 1.5 недели обучения с нуля (то есть аббревиатура HTML кажется заклинанием, вызывающим Сатану) до полноценной сборки сайта за срок, который меня устраивает.
  • Красивые графики для клиентов с рейтингом CMS:)
  • Freeware, нет необходимости приобретать лицензии.

И да, я не буду стучаться в вашу дверь с брошюрой в руках и говорить “Не хотите ли вы поговорить о WP?”. Просто мы используем эту CMS и об этом и есть заметка. Фактически здесь монолог в печатном формате, который я произношу всем новым веб-мастерам, приходящим к нам.

Какие нюансы следует учитывать при верстке проекта?

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

Шаблон должен легко разделяться на “шапку сайта”, собственно контент и “подвал”. Если необходимо скрывать некоторые элементы шапки/подвала - WP предоставляет довольно много замечательных функций-условий. (is front page(), is_404() etc.). Если необходимо изменять внешний вид - CSS умеет, body_class() имеется.

Когда верстаются различные меню, которые будут управляться через Внешний вид -> меню сайта, необходимо придерживаться следующей структуры:

Из нюансов здесь важно то, что подменю должны иметь css класс sub-menu . Это избавит вас от необходимости писать кастомный волкер при сборке сайта, для функции wp_nav_menu($args) ;.

Буду как капитан очевидность, но все динамические позиции в верстке должны быть либо отдельным элементов (если телефон, то, к примеру + 7 XXX XXX etc. без извращений), для дальнейшей замены плейсхолдера, либо быть похожи на следующую логическую структуру:

Верстка до списка
Верстка элемента списка

Верстка элемента списка
Верстка после списка

Обязательно создать отдельное правило в CSS для контента, который клиенты вставляют через wysiwyg в админ-панели. Что-то вроде этого (пусть это будет LESS):

User-content{ ... a{ &:hover{ ... }; &:active{ ... }; &:focus{ ... }; } p{ ... } table{ thead { ... th { ... } } tbody { tr{ ... td{ ... } } } } h1, h2, h3, h4, h5, h6, h7{ … } h1{ ... } ... h7{ ... } ul{ ... li{ ... } } img{ … } }

В дальнейшем убережет от звонков вида “Почему я вставила картинку и у меня все поехало!”

Если у вас есть на сайте галереи изображений (по три в ряд, по шесть в ряд etc.), то необходимо привести верстку этих галерей в верстку, которую генерирует WP шорткодом gallery. Или переопределить этот шорткод и сделать верстку просто придерживаясь правила “Верстка до списка, Верстка элемента списка, Верстка после списка”, если функционал WP по части количества колонок и прочего избыточен.

Верстка постраничной навигации, генерируемая WP, принимает примерно следующий вид:

Верстка «хлебных крошек» тривиальна. Либо ul li список, либо , разделенный " >> " и иже с ними.

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

Получили набор html/css/js файлов, что дальше?

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

  • Самая свежая версия WP.
  • Не дефлотный пароль на администраторе;).
  • Билдер новых типов постов с кастомными полями из админ панели. Мы используем Magic fields 2 . Используется для создания элементов вида Список элементов -> Отдельная страница элемента. Шаблоны вида archive-$type.php и single-$type.php , или вывод, используя WP_Query.
  • Билдер новых полей для таксономии, использую Tax-Meta-Class
  • Кастомизатор для экранов редактирования. Использую Advanced СustomFields . Незаменим для следующего кейса. Имеется шаблон контактов, к примеру tpl-contacts.php , с прописанным внутри Template Name: Шаблон страницы контактов . И необходимо, чтобы при выборе этого шаблона в админ-панели, на странице редактирования контактов, появлялись дополнительные поля, такие как координаты карты, привязанная форма обратной связи etc. И тут он нам и помогает.
  • Билдер форм перезвона, обратной связи, заказа, etc. Contact Form 7
  • Билдер глобальных настроек сайта. Используется для телефонов в шапке, соц.сетей и прочей информации такого типа. Theme Options .
  • Functions.php с функциями, покрывающими практически весь оставшийся функционал:
    • Поддержка меню темой. register_nav_menus();
    • Поддержка миниатюр у постов. add_theme_support ("post-thumbnails");
    • Ресайз изображений, с поддержкой из меньшего->большее и кешированием. resize_image($attach_id = null, $img_url = null, $width, $height, $crop = false)
    • Генератор хлебных крошек. the_breadcrumb() .
    • wp_corenavi($wp_query)
    • Кастомный волкер для wp_nav_menu() для расширения. class My_Walker extends Walker Nav Menu { оригинальный код WP }
    • Задел для изменения шорткода галереи. remove_shortcode("gallery", "gallery_shortcode");add_shortcode("gallery", "my_gallery_shortcode");function my_gallery_shortcode($attr) {}
    • Генератор постраничной навигации. wp_corenavi($wp_query)
  • Файлик со сниппетами, для напоминания.

И вся сборка проекта сводится к следующему:

  • Создание virtual host на компьютере
  • git clone ...
  • Импорт бд, ввод трех SQL команд, для того, чтобы сказать WP, какой у нас сейчас текущий URL (gist)
  • Копирования сниппетов со второго монитора и наполнение верстки смыслом.
  • Деплой на сервер и чашка кофе

Примерное содержание файлика со сниппетами:
ID)); $image = vt_resize(null, $url, 220, 220, true); if (!$image["url"]) $image["url"] = "http://placehold.it/220x220&text=NO IMAGE"; ?>


По данному алгоритму собрал за последний год уже более сотни сайтов, в среднем по времени уходит от 1 до 3 рабочих дней, в зависимости от сложности дизайна и различных моушен-эффектов. Сама сборка занимает около 4-8 часов. Возможно это и не результат, но сравнивать мне пока не с чем, буду благодарен диалогу.

Только зарегистрированные пользователи могут участвовать в опросе.

Из этой статьи вы узнаете, как создать сайт на WordPress. С помощью пошагового руководства сделаете качественный и функциональный ресурс, пригодный для привлечения и конвертации трафика.

Почему WordPress – что это такое и 5 причин его использовать для сайта или блога

WordPress - это самая популярная система управления контентом (CMS). По данным Web Technology Surveys , на этом движке по состоянию на ноябрь 2018 года работает 32,3 % от общего числа существующих сайтов, а также 59,5 % сайтов, использующих CMS. В 2015 году WordPress использовали только 24 % ресурсов на CMS. Ниже перечислены основные причины популярности WordPress.

Бесплатный «движок» CMS WordPress распространяется по открытому лицензионному соглашению (GNU GPL). Вы можете свободно использовать этот продукт в любых целях, включая коммерческие. Практически неограниченные возможности С помощью WordPress можно создать интернет-магазин, личный блог, корпоративный сайт, информационный портал, отраслевой ресурс, галерею мультимедиа. Гибкая настройка внешнего вида и функциональности Владельцам сайтов на WordPress доступны платные и бесплатные шаблоны, с помощью которых можно кастомизировать внешний вид. А с помощью плагинов можно решать технические задачи, обеспечивать необходимую функциональность сайта. Простота администрирования Чтобы работать с WordPress, не нужны специальные знания. Принципы работы с движком понятны на интуитивном уровне. Возможность создать сайт и опубликовать первый контент в течение 5 минут Конечно, придется потратить гораздо больше времени, чтобы превратить шаблонный продукт во что-то новое и интересное. Но на первую публикацию потратите не больше 5 минут.

Ну что, решили сделать сайт на WordPress? Тогда переходите к пошаговому руководству.

Шаг № 1: как выбрать хостинг и зарегистрировать домен

Если у вас некоммерческий проект, выбирайте бесплатный хостинг. Например, делиться с миром фотографиями котиков или вести дневник молодого бодибилдера можно на платформе WordPress. Адрес сайта будет выглядеть так: primer.wordpress.com. Если реализуете коммерческий проект, например, создаете тематический блог, корпоративный сайт или планируете зарабатывать с помощью ресурса любым способом, выбирайте платный хостинг.

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

Выбор доменной зоны не влияет на технические характеристики ресурса или позиции в поисковой выдаче. Однако теоретически этот параметр может влиять на доверие аудитории. При прочих равных пользователи охотнее верят сайтам с адресом vasya-pupkin.ru или vasya-pupkin.com, чем ресурсам типа vasya-pupkin.wordpress.com или vasya-pupkin.blogspot.com. Поэтому для коммерческих проектов старайтесь выбирать домены верхнего уровня, например, .com, .info, .org, .net, .ru, .ua, .by и т.п. Обратите внимание на появившиеся недавно домены первого уровня, например, .club, .guru, .ninja, .expert и другие.

Шаг № 2: как установить WordPress своими руками

После покупки хостинга и регистрации доменного имени установите WordPress. Обратите внимание, некоторые хостинг-провайдеры предлагают тарифные планы с предустановленной CMS. Если вы выбрали один из них, сразу переходите к третьему шагу руководства. Если вы приобрели хостинг без установленного движка, следуйте инструкциям:

Перейдите на сайт WordPress и скачайте дистрибутив.


Распакуйте архив.



Как русифицировать тему WordPress

Русифицировать тему удобно с помощью бесплатной программы Poedit . Скачайте и установите ее на компьютер. Затем скачайте на компьютер языковые файлы выбранного шаблона. Для этого потребуется доступ к FTP. Его можно получить с помощью FTP-клиента, например, FileZilla, а также с помощью плагинов, например, File Manager . Если вы установили данный плагин, действуйте по описанному ниже алгоритму.

В консоли выберите меню FileManager – Configuration. Настройте конфигурации, как указано на иллюстрации.


В меню FileManager – FileManager выберите папку wp-content – themes.


Выберите папку темы, которую хотите русифицировать. В ней откройте папку languages.


Скачайте на компьютер файлы en.mo и en.po. Если таких файлов нет, скачайте на компьютер файл с расширением.pot.


Откройте программу Poedit и выберите опцию «Создать новый перевод».


Откройте файл перевода и укажите код языка.


Приступайте к переводу. В поле «Исходный текст» программа отображает текст на английском языке. В поле «Перевод» нужно добавить текст на русском.


Сохраните перевод. Программа загрузит на жесткий диск вашего ПК два файла: ru_Ru.mo и ru_RU.po. С помощью функции Upload files загрузите файлы в папку languges вашего шаблона.


Вы русифицировали шаблон.

Вместо программы для ПК Poedit можно использовать плагин Loco Translate . После установки и активации надстройки интерфейс для перевода шаблонов появляется прямо в админке сайта.


Шаг № 5: решаем практические задачи с помощью плагинов для WordPress

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

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

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

  • Обеспечить безопасность сайта.
  • Бороться со спамом.
  • Оптимизировать ресурс к требованиям поисковых систем.
  • Повысить функциональность и улучшить юзабилити.

Как с помощью плагинов обеспечить безопасность сайта на WordPress

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

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

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

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


Нажмите кнопку «Установить». После установки активируйте плагин. Теперь настройте параметры резервного копирования. Выберите меню «Инструменты – WP DB BackUp». Нажмите Create New Database BackUp. Вы создали резервную копию по требованию.


Настройте регулярное создание резервных копий по расписанию. Перейдите на вкладку Sheduler, включите автоматическое создание резервных копий, выберите частоту создания архивов.


На вкладке Destination включите автоматическое сохранение архива на Google Drive или отправку на электронную почту.


Чтобы защитить сайт от несанкционированного доступа, воспользуйтесь плагином Loginizer Security . Надстройка надежно защищает сайт от взлома методом перебора или брутфорсинга.


Как бороться со спамом на сайте WordPress

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

Защититься от спама можно с помощью плагинов, например, Akismet или Antispam Bee . После установки Antispam Bee плагин работает в фоновом режиме. Обычно подходят дефолтные настройки, но если нужно что-то поменять, перейдите в меню админки «Настройки – Antispam Bee».


Как обеспечить SEO сайта на WordPress

WordPress – SEO-дружественная CMS по умолчанию. Но есть задачи, без которых сайт нельзя считать полностью соответствующим требованиям поисковых систем. Вот они:

  • Создание и обновление карты сайта.
  • Канонизация URL.
  • Оптимизация title страниц.
  • Автоматическая генерация мета-данных страниц.
  • Блокирование индексации дублированного контента.
  • Создание микроразметки страниц .

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

  • Google XML Sitemaps.
  • Simple WP Sitemap.
  • Google Sitemap.

Google XML Sitemap . Для настройки плагина перейдите в меню «Настройки – XML-Sitemap».


Начинающим вебмастерам лучше оставить настройки по умолчанию. После активации плагин создал карту сайта, добавил ее адрес в файл robots.txt и приготовился уведомлять поисковые системы об обновлениях ресурса.


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


Для технической оптимизации ресурса воспользуйтесь одним из следующих плагинов:

  • All in One SEO Pack.
  • WordPress SEO by Yoast.
  • Platinum SEO Pack.

Установите и активируйте выбранный плагин, например, All in One SEO Pack . Используйте настройки по умолчанию, если вы только знакомитесь с WordPress. Если считаете себя продвинутым веб-мастером, можете изменить некоторые настройки SEO-модуля. Для этого выберите меню All in One SEO в консоли движка.


Обратите внимание на перечисленные ниже настройки.

В разделе «Основные настройки» уберите флажок напротив пункта Use Schema.org Markup. Размечать страницу лучше с помощью отдельного плагина.


Если в качестве главной используете страницу записей, в разделе «Настройки главной страницы» укажите title, description и keywords. Если в качестве главной используется статическая страница, установите флажок в поле «Включить».


В разделе «Настройки для вебмастера» укажите код верификации ресурса в кабинете для вебмастеров Google. Для этого добавьте в «Инструменты для вебмастеров» новый ресурс, выберите альтернативные методы верификации. Скопируйте часть кода HTML, указанную на иллюстрации.


Вставьте ее в поле «Инструменты вебмастера Google» на странице настройки плагина.


Сохраните параметры плагина. В кабинете для вебмастеров нажмите кнопку «Подтвердить».

Для разметки страниц воспользуйтесь одним из следующих плагинов:

Связка WPSSO и WPSSO JSON Первый плагин базовый, а второй представляет собой расширение . С помощью базового решения на сайт можно добавить разметку Open Graph. С помощью второго с помощью JSON-LD реализуется разметка Schema.org. WP SEO Structured Data Schema С помощью данного плагина на сайт можно добавить несколько типов разметки Schema.org, включая Article, BlogPosting и Review. Разметка реализуется с помощью JSON-LD. Плагин Schema App С помощью этой программы на сайт можно добавить разные типы разметки Schema.org. Она реализуется через JSON-LD. Бесплатная версия поддерживает базовые типы разметки. Также разметку можно реализовать с помощью онлайн-генератора Schema.org JSON-LD Generator .

Установите и активируйте плагины WPSSO и WPSSO JSON. В консоли на странице настроек плагинов в разделе Essential Settings укажите информацию о сайте, а также сведения для разметки Open Graph. Не меняйте другие настройки.


Перейдите в раздел Schema Markup. В полях Organization Logo Image URL и Organization Banner URL укажите URL логотипа и баннера сайта. Эти изображения могут использоваться на странице поисковой выдачи.


С помощью выпадающего меню выберите базовый тип разметки для страницы записей блога, статической главной страницы. Вам нужны следующие типы: Blog и Website соответственно.

Выберите тип разметки для страниц публикаций, статических страниц и страниц медиафайлов. Для страниц записей подходят типы разметки Article и BlogPosting. Выбор зависит от формата публикаций в блоге.

Тип разметки BlogPosting – производное Article. Кроме BlogPosting, к частностям Article относится тип разметки News Article или «Новость». То есть BlogPosting содержит все семантические данные разметки Article.

Используйте тип BlogPosting, если публикуете небольшие заметки, личные наблюдения и впечатления. Используйте тип Article, если публикуете обзоры, аналитические статьи, руководства. Вот пример: для публикаций в блоге «Текстерры» подходит тип разметки Article, а для дневника Екатерины Безымянной в ЖЖ подходит тип BlogPosting. Для статических страниц и страниц медиафайлов укажите тип разметки WebPage.


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


Что делать, если вы публикуете материалы разного типа: лонгриды, небольшие заметки и новости? В этом случае для каждой публикации лучше выбрать подходящую разметку. Вместо надстройки WPSSO JSON воспользуйтесь плагином WP SEO Structured Data Schema.

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


Недостаток плагина – необходимость размечать каждую публикацию вручную. А к преимуществам можно отнести поддержку дополнительных типов разметки, например, Review, Product и Aggregate Ratings. Бесплатная версия WPSSO JSON не поддерживает эти типы.

Как повысить функциональность и юзабилити ресурса

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

В этой серии статей мы планируем рассмотреть основополагающие моменты, которые следует учитывать при разработке плагина или темы WordPress .

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

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

В этой статье мы рассмотрим следующие темы:

  • Стандарты кодирования WordPress ;
  • Как избежать конфликта названий функций;
  • Код комментариев;
  • Советы по безопасности.

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

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

Я постараюсь, чтобы статьи этой серии были легкими для понимания. Я буду включать в статьи некоторые примеры правильно составленного кода и примеры ошибок. Не все описанное здесь является обязательным при создании плагина, но если вы начинаете работу с WordPress , почему бы не сделать это правильно?

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

Стандарты кодирования WordPress

Честно говоря, это один из моих самых серьезных недостатков. Если вы разрабатываете инструменты для WordPress , вы должны просто следовать Стандартам кодирования WordPress . Это помогает повысить читаемость кода и избежать распространенных ошибок.

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

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

В Руководстве WordPress стандарты делятся по четырем основным используемым языкам:

  1. Стандарты кодирования CSS
  2. Стандарты кодирования НTML
  3. Стандарты кодирования JavaScript
  4. Стандарты кодирования PHP

Примеры

Ниже я покажу вам несколько простых примеров PHP — кода, чтобы вы получили общее представление, о чем идет речь.

Ошибки:

if(condition) action0($var); if(condition) { action1(); } elseif(condition2) { action2a(); action2b(); }

Примеры правильного кодирования:

if (condition) { action0($var); } if (condition) { action1(); } elseif (condition2) { action2a(); action2b(); }

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

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

Вот то, что я имею в виду:

>
" class="feature-link" title=""> ";} ?> "; foreach($categories as $tag) { $tag_link = get_category_link($tag->term_id); $titleColor = categorys_title_color($tag->term_id, "category", false); echo "".$tag->name.""; } echo ""; } }?>

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

Как избежать конфликтов имен функций

Конфликты имен происходят, когда функция имеет то же имя, что и функция, которая уже была определена ранее. Например, если у вас в теме есть функция get_the_post_terms() , и вы установите плагин, который содержит функцию с тем же именем, вы получите что-то вроде:

Fatal error: Cannot redeclare get_the_post_terms() (previously declared in....

К сожалению, это происходит гораздо чаще, чем следовало бы. Но таких конфликтов легко избежать.

Для этого у нас есть следующие варианты:

1. Префиксы функций

Например, если ваш плагин называется «WordPress Cool Plugin» , вы можете использовать префикс wcc_ для всех его функций.

Таким образом, в приведенном выше примере название нашей функции будет выглядеть, как wcc_get_the_post_terms() .

2. Заключите функции в класс

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

class Wcc_Mailer { static function send($post_ID) { $friends = "[email protected]"; mail($friends,"New post!", "Check my new post in " . get_permalink($post_ID)); return $post_ID; } } add_action("publish_post", array("Wcc_Mailer", "send"));

Как видите, в этом примере я просто использовал префикс для имени класса, но моя функция называется «send» . Это имя метода защищено от изменений через глобальную область имен, сам метод не может вызываться непосредственно. Чтобы вызвать его, мне нужно будет сделать следующее:

Wcc_Mailer::send($post_id);

Код комментариев

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

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

Лично я использую для комментирования функций синтаксис PHPDoc , с применением Sublime + Docblockr это делается очень просто.

Давайте посмотрим, как ребята из WordPress комментируют функцию wp_mail() , расположенную в файле wp-includes/pluggable.php :

/** * Отправляет почтовые сообщения, аналогичные почте PHP * * Возвращаемое значение true не значит автоматически, что пользователь получил * письмо. Это только значит, что использованный метод выполнил * запрос без ошибок. * * Использование обращений "wp_mail_from" и "wp_mail_from_name" позволяет * задавать адрес отправителя в следующем формате "Name ", * если заданы оба обращения. Если использовано только обращение "wp_mail_from", * в адресе отправителя будет указывать только электронная почта. * * Тип контента по умолчанию - "text/plain", что не позволяет использование HTML. * Однако вы можете задать тип контента электронных сообщений, использовав * фильтр "wp_mail_content_type". * * Кодировка по умолчанию соответствует кодировке применяемой в блоге. Другая * кодировка может быть установлена через фильтр "wp_mail_charset". * * @since 1.2.1 * * @uses PHPMailer * * @param string|array $to Массив или разделенный запятыми список e-mail адресов для рассылки писем. * @param string $subject Тема письма * @param string $message Текст сообщения * @param string|array $headers Опционально. Дополнительный заголовок. * @param string|array $attachments Опционально. Прикрепленные файлы. * @return bool Всегда, когда содержимое письма было отправлено успешно. */ function wp_mail($to, $subject, $message, $headers = "", $attachments = array()) { [....] // Отправлено! try { return $phpmailer->Send(); } catch (phpmailerException $e) { return false; } }

Как видите, они описывают то, что делает эта функция, какие параметры ей необходимы и что она возвращает.
Довольно информативно, не правда ли?

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

В CSS я использую комментарии, чтобы разделить код на разные разделы.

Например:

/********************* ОБЩИЕ СТИЛИ *********************/ body { font-family: Arial; color: #333; } /****************************************************************** СТИЛИ H1, H2, H3, H4, H5 ******************************************************************/ h1, .h1 { font-size: 2.5em; line-height: 1em; font-family: $vag-bold; } /********************* СТИЛИ МЕНЮ НАВИГАЦИИ *********************/ nav { color:red } [...]

К безопасности нужно относиться очень серьезно! Если ваш плагин или тема становятся популярными, поверьте мне, вы не захотите, чтобы по вашей вине были взломаны тысячи сайтов.

Если вы думаете, что я преувеличиваю, посмотрите на исследования Сheckmarx , проведенные ими в 2013 году среди 50 лучших плагинов WordPress .

Теперь давайте рассмотрим некоторые советы по безопасности разработки для WordPress :

XSS-уязвимости

Для предотвращения XSS мы должны сделать две вещи. Проверять безопасность входящих данных и проверять безопасность исходящих данных .

Существует несколько методов для проверки безопасности в зависимости от данных и контекста, в котором они используются. Общее правило: вы не должны доверять любым вводящим данным, и не должны доверять любым данным, которые выводятся.

Для ввода данных можно использовать, например, sanitize_text_field() , которая проверяет недопустимый текст UTF-8 , конвертирует в объект одиночные символы <, убирает все теги, удаляет разрывы строк, отступы и лишние пробелы, а также убирает октеты. В зависимости от контекста, существуют разные функции, которые помогут вам обезопасить данные.

То же самое происходит, когда вы выводите данные. Взгляните на следующий пример того, как выводится ссылка:

">

  • esc_url отвергает неверные URL-адреса, устраняет недопустимые символы и удаляет опасные символы;
  • esc_html кодирует & «‘при выводе HTML.

Опять же, в зависимости от данных, которые вы имеете, существуют различные функции, которые могут вам помочь. Для JavaScript вы можете использовать esc_js .

Кроме проверки самих данных, не забудьте проверить и дату.

Предотвращение прямого доступа к файлам

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

Чтобы предотвратить это, вы можете разместить в верхней части вашего скрипта очень простой код:

// Выход, если предоставлен прямой доступ if (! defined("ABSPATH")) exit;

Это в целом помешает выполнить скрипт, если доступ к нему получен не через WordPress .

Удалите все предупреждения и уведомления

Злоумышленники могут воспользоваться не только ошибками PHP — извещения и предупреждения также включают в себя много ценной для них информации. Каждый плагин должен быть закодирован с использованием режима DEBUG .

Это также помешает злоумышленникам вычислить устаревшие функции в вашем плагине. Чтобы включить режим DEBUG просто найдите эту строку в файле wp-config.php и установите значение TRUE :

define(WP_DEBUG, true);

Используйте значения Nonce

Nonce -значения — это сокращение от numbers used once (однократно использованные числа) , они используются для защиты от ложных запросов между сайтами, или CSRF .

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

В зависимости от того, где вам нужно применить значение Nonce , вы можете создавать его по-разному.

Для ссылок используйте wp_nonce_url() :

$complete_url = wp_nonce_url($bare_url, "trash-post", "my_nonce");

Для форм — wp_nonce_field() :

wp_nonce_field("trash-post", "my_nonce");

В других местах — wp_create_nonce() :

wp_localize_script("my-script", "my-var-name", array("nonce" => wp_create_nonce("trash-post", "my_nonce"));

Если вы посмотрите на приведенный выше пример, то увидите, как я использую wp_localize_script (о которой речь пойдет в следующей статье ), чтобы включить nonce в блок кода JavaScript . Я делаю это, потому что позже планирую использовать JQuery для выполнения запроса AJAX , и вы тоже всегда должны включать nonce в вызовы AJAX .

После этого в скрипте, просто для проверки nonce, используйте следующий код:

if(! wp_verify_nonce("trash_post" , "my_nonce")) { die("Busted!"); }

Используйте функции и библиотеки WordPress

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



Рекомендуем почитать

Наверх