Часто возникает вопрос — как посчитать число скачиваний файла и спрятать реальную ссылку на скачиваемый файл?

Для решения этой задачи надо сделать две вещи: перехватить клик на ссылку и отдать реальный файл пользователю средствами php.

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


В связи с выходом редактора Гутенберг, который получил название блочного редактора в WordPress 5.0, часто возникает вопрос — как программно определить, какой редактор используется в настоящее время для редактирования поста в консоли сайта?

Вариантов тут можеть быть несколько:

  • WordPress 4.9, плагин Гутенберг не активен
  • WordPress 4.9, плагин Гутенберг активен
  • WordPress 5.0, включен блочный редактор по умолчанию
  • WordPress 5.0, активен плагин Classic Editor
  • WordPress 5.0, активен плагин Classic Editor, но в консоли в «Настройки > Написание» выбрана опция «Использовать по умолчанию редактор блоков…»

Все указанные выше варианты могут обработаны следующим кодом:


Вышла новая версия 2.0.0 плагина WOOF by Category. Плагин теперь полностью совместим с WPML.

WOOF по Категориям — это расширение плагина WooCommerce Product Filter (WOOF), которое позволяет установить различные фильтры WOOF в различных категориях. Плагин имеет опции в консоли, чтобы установить соответствие между любой категорией товаров WooCommerce и любым набором фильтров WOOF. Только выбранные фильтры будут отображены на страницах выбранной категорий и ее подкатегорий.

В новой версии плагина настройки сохраняются для каждого языка WPML по отдельности. Это позволяет иметь разный набор пар пар «категория->фильтры» в разных языках, и работать с категориями, переведёнными с помощью WooCommerce Multilingual (этот плагин входит в состав WPML).


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

Так будет выглядеть конечный результат (4 крайние кнопки справа).

Вначале давайте создадим командный файл для переключения xDebug. Предполагается, что мы работаем под Windows 10 с установленной оболочкой Linux Bash. В некой папке, которая находится в PATH Windows, создадим два файла: xdebug.bat и xdebug.sh.


Наша компания получила новый статус: «Сертифицированный WPML контрактор». Это международная оценка качества наших веб-сайтов, выполненных на WordPress с использованием плагина интернационализации — WPML.

Согласно исследованию W3C, WordPress используется на 30% от всех веб-сайтов в сети Интернет. Многие из этих сайтов содержат контент на нескольких языках. Наиболее широко распространённым плагином мультиязычности является WPML, созданный и поддерживаемый OnTheGoSystems.

В январе 2018 года OnTheGoSystems создала клуб контракторов, куда вошли подтверждённые фирмой фрилансеры и компании, активно работающие с WPML. Сейчас в клубе состоят 189 подтверждённых контракторов.

В марте членам клуба было предложено пройти сертификацию. К настоящему моменту, на начало апреля 2018 года, вcего 5 контракторов прошли процесс сертификации, в том числе KAGG Design.


Анализаторы кода такие, как PHP Code Sniffer, и стандарты кодирования такие, как WordPress Coding Standards, позволяют создавать современный, легко обновляемый код, избежать множества ошибок еще на стадии написания кода, и совершенно незаменимы при командной работе над проектом. Эти средства встроены в phpStorm — мощную современную среду разработки под php.

В то же время, у многих разработчиков возникают сложности при установке анализатора кода PHP Code Sniffer и правил оформления кода WordPress Coding Standards для него в PhpStorm под Windows. Сведения об этом разбросаны по многим статьям в Сети.

Ниже мы сведем воедино эти знания и рассмотрим последовательность установки шаг за шагом.


Возможно ли «выжать» из сайта на WordPress высокую производительность? Наш ответ — да! В этой статье мы покажем, как добиться устойчивой работы сайта на WordPress при высоких нагрузках, доходящих до 10,000 соединений в секунду, что равно 800 миллионам посещений в сутки.

Прежде всего, нам нужен собственный виртуальный сервер (VPS). Для тестов использовался VPS, арендованный у DigitalOcean за 20 USD в месяц со следующими параметрами: 2GB памяти, 2 процессора, 40GB дискового пространства на SSD. В качестве операционной системы была выбрана CentOS Linux release 7.3.

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


Наш аккаунт — единственный на русском StackOverflow, кто получил значок wordpress: http://ru.stackoverflow.com/help/badges/226/wordpress


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

  • 47% пользователей ожидают, что веб-страница загрузится в течение 2 секунд;
  • 40% посетителей могут уйти с сайта, который грузится более 3 секунд;
  • 75% посетителей ушли на сайты конкурентов, не дождавшись загрузки страницы;
  • 88% заявили, что вряд ли вернутся на сайт после неудачной попытки его открыть.

Причем требовательность к скорости загрузки сайта растет со временем:

  • в 1999 году треть пользователей уходила, если сайт загружался более 8 секунд;
  • в 2006 та же треть уходила, если сайт загружался более 4 секунд:
  • последние исследования говорят о том, что приемлемое время загрузки сократилось до 2 секунд.

Для интернет-магазина время загрузки является еще более важным фактором. Amazon провел серию тестов, которые установили: каждые 100 мс, на которые увеличивается время загрузки Amazon.com, уменьшают продажи на 1%. Google обнаружил, что замена страницы с 10 результатами поиска, загружающейся за 0,4 секунды, на страницу с 30 результатами, загружающуюся за 0,9 секунды, снизила трафик и доходы от рекламы на 20%.

Мы уделяем первостепенное внимание быстродействию наших сайтов, ставя перед собой задачу обеспечить время загрузки любой страницы создаваемого сайта менее 1 секунды, а страниц с картами — менее 2 секунд. Для достижения этой цели мы используем только виртуальные и выделенные серверы, последние версии nginx, mySQL и php 7 (который вдвое быстрее предшественника), системы кэширования, оптимизацию структуры сайта, минимальное число проверенных плагинов.

Ознакомьтесь с результатами измерения скорости загрузки страниц некоторых созданных нами сайтов и сравните с результатами для вашего сайта, которые можно получить с помощью известного сервиса Pingdom. У вас медленный сайт? Обращайтесь к нам, мы заставим его «летать»!