Redirect 301 (Moved Permanently) — это код состояния HTTP, который означает, что страница или запрошенный ресурс был окончательно перемещён на новый адрес (URL). В основном Redirect 301 используется для перенаправления пользователей с одной страницы на другую.
Браузер в случае такого ответа перенаправляется на эту страницу, а поисковые системы обновляют свои ссылки на ресурс (говоря языком SEO, вес страницы переносится на новый URL-адрес).
Ранее я рассматривал простые примеры постоянного (окончательного) перенаправления на уровне Apache и Nginx, а в этой публикации рассмотрим пример, как это можно осуществить при помощи родных функций из ядра WordPress.
Не будем ходить вокруг да около, а сразу рассмотрим реальный пример перенаправления со старой страницы с адресом /old-page/ на новую, на адрес /new-page/ :
Для удобства можно назвать сниппет «Перенаправления 301» и при необходимости добавлять сюда новые.
После активации сниппета WordPress будет перенаправлять нас на новый адрес. В этом можно убедиться при просмотре заголовков из ответа сервера:
Комментарий к коду
Нашу безымянную функцию требуется вызывать до отправки, так сказать, в браузер HTML. Для этого вполне подходит хук ‘template_redirect’
Событие удобно использовать для перенаправления, когда WordPress обработал основной запрос и установил все объекты ($wp_query, $post, условные теги), но вывод контента на экран еще не произошёл.
https://wp-kama.ru/hook/template_redirect
Функция is_page() помогает проверить текущую страницу согласно условию и выполнить код только исключительно на ней. В примере я использую проверку по слагу (slug) — эта та часть URL, которая идентифицирует данную страницу.
Но так же в функцию is_page() можно передавать и «айдишник». Возможно вам будет полезно прочесть: Как узнать ID страницы?
Если стоит задача осуществить перенаправление внутри сайта, то можно ради разнообразия, рассмотреть ещё и вот такой вариант:
Перед нами решение той же задачи, но немного другим путём. Мы указали ID-страниц для условия и получения постоянной ссылки с помощью функции get_permalink()
exit; или die(); необходимо указывать для того, чтобы после перенаправления ничего лишнего не выполнилось.
Задача: Запретить поисковым системам индексировать страницы нашего сайта.
Такая задача может быть актуальной, если вы разрабатываете сайт для служебных целей, например, как информационную систему внутри компании и совершенно не видите смысла делать доступной для поиска информацию на её страницах.
Так же включение данной функции полезно при разработке сайта. Если она происходит, как часто бывает, сразу онлайн — из интернета. В этом случае тоже полезно задействовать эту функцию «Попросить поисковые системы не индексировать сайт«, для того что бы случайно в поисковые базы не попали страницы с текстом-рыбой или прочим демонстративным контентом.
Как включить запрет на индексацию?
Переходим в раздел главного меню Настройки > Чтение и включаем вот эту функцию:
Что произойдёт? На все страницы вашего сайта будет добавлен мета-тег с атрибутом content, со значениями: noindex, nofollow
Что это значит? Это предписание для поисковых роботов, сигнал о том, чтобы не индексировать информацию на этой странице и не следовать по ссылкам, указанных на ней.
Важно понимать, что блокировка индексирования при помощи правила noindex не является гарантированной и существует ряд нюансов, которые могут принести разный результат, порой даже неожиданный.
noindex — Не показывать страницу, медиаконтент или ресурс в результатах поиска. Если не добавить это правило, страница, медиаконтент или ресурс будет проиндексирован и сможет показываться в результатах поиска.
nofollow — Не выполнять переход по ссылкам на странице и не связывать отношения их (ссылок) с ней (с текущей страницей).
Внимание! Запуская сайт в Production-среду обязательно проверяйте эту настройку. Если вы хотите чтобы вас находили в интернете она должна быть отключена!
Что такое панель администратора WordPress? Это приватная часть сайта для управления его содержимым. То есть, наш сайт под управлением CMS WordPress состоит из двух частей: публичной и приватной.
Публичная часть
Публичная часть сайта доступна всем в сети интернет. Любой может перейти на неё, например, из поисковой системы Google или Яндекс и увидеть её содержимое.
Но информации изменить на страницах, будучи обычным посетителем, мы не можем. Для того чтобы изменить информацию на страницах или создать новые нам необходимо зайти в панель управления — это является уже приватной частью сайта.
Приватная часть
Приватная часть сайта — она же «админка», она же панель управления WP, она же консоль, она же WP Admin Dashboard (англ.) и можно встретить ещё ряд названий, нужна для того чтобы управлять содержимым сайта: менять информацию на нём, создавать страницы, новые разделы и т.п. Но вход в неё доступен не всем. Вход доступен по имени пользователя и паролю.
Как зайти в панель управления?
Очень просто. После адреса сайта допишите /wp-admin
Произойдёт перенаправление и откроется страница с формой для входа
Если внимательно приглядеться, то можно заметить, что перенаправление произошло на файл wp-login.php, следовательно второй вариант входа в «админку» можно осуществить просто дописав вместо /wp-admin вариант /wp-login.php
Мы окажемся на том же экране, где нам необходимо пройти авторизацию (зайти в админку с правами нашей учётной записи) при помощи Имени пользователя (login) и Пароля (password)
Если вы не помните пароль, то его можно восстановить. На рисунке выше отмечена ссылка для восстановления.
При успешном входе вы увидите приватную часть сайта — панель управления WordPress:
В этой публикации мы рассмотрим настройку отправки почты с сайта сделанного на CMS WordPress через почтовый сервис от Google для того чтобы письма не попадали в СПАМ.
В первой статье по настройке плагина WP Mail SMTP мы рассмотрели возможность настройки через SMTP хостинг-провайдера, а эта публикация будет посвящена SMTP от Google.
Напомню, что плагин WP Mail SMTP включает в себя множество различных вариантов настройки SMTP:
SendLayer
SMTP.com
Brevo (formerly Sendinblue) SMTP
Mailgun SMTP
SendGrid SMTP
Postmark SMTP
SparkPost SMTP
Gmail SMTP (Gmail, Google Workspace, G Suite)
Microsoft SMTP (Outlook.com и Office 365) [Pro платная версия]
Amazon SES SMTP [Pro платная версия]
Zoho Mail SMTP [Pro платная версия]
Все прочие SMTP
Бесплатная версия плагина позволяет нам настроить отправку почтовых сообщений через Gmail SMTP. Я ожидаю, что плагин у вас уже установлен и мы сразу обращаемся к экрану настроек с выбором сервиса-посредника:
Почтовая программа Gmail хорошо подходит для сайтов, которые отправляют небольшое количество писем. API Gmail имеет ограничения скорости и ряд дополнительных ограничений, которые могут привести к проблемам во время отправки.
Если вы планируете отправлять большое количество писем или обнаружите, что ваш веб-сервер не совместим с ограничениями API Gmail, мы рекомендуем рассмотреть другой вариант почтовой программы.
Примечание от разработчиков
После выбора провайдера (в нашем случае это Google/Gmail) ниже будут доступны его настройки, с которыми мы сейчас начнём работу
Принятая весть для обладателей PRO-версии, включение функции One-Click Setup обеспечивает быстрый и простой способ подключения к Google, не требующий создания собственного приложения.
Но так как мы рассматриваем вариант подключения в бесплатной версии впереди нас ожидает тернистый путь 🙂
Первое условие — у вас должен быть аккаунт на Google, так как дальнейшая наша работа будет связана с ним. Если у вас нет аккаунта на Google, то воспользуйтесь этой справкой чтобы его создать: Как создать аккаунт?
Настройки подключения. Шаг за шагом
В разделе настроек Основные укажите вашу почту на сервисе Gmail через которую будет осуществляться пересылка сообщений
После этого переходим к разделу с внесением данных:
ID клиента
Секретный код клиента
Чтобы их получить вам потребуется использовать свою учетную запись Google для создания веб-приложения.
Создание веб-приложения в вашей учетной записи Google
Примечание. Прежде чем продолжить, обязательно выйдите из всех других учетных записей Google, кроме учетной записи, которую вы будете использовать для настройки SMTP.
В новой вкладке или окне, которое вы открыли, войдите в свою учетную запись Google и откройте Google Cloud Console .
Если вы впервые используете Google Cloud Console, вы можете увидеть всплывающее окно с просьбой выбрать страну и согласиться с Условиями обслуживания.
Сделайте это, а затем нажмите «Agree and Continue» , чтобы перейти к следующему шагу.
Далее необходимо создать Новый проект
Поле этого дадим название нашему проекту
После создания проекта, убедитесь что выбран именно он и перейдите в подраздел Библиотеки (Library) раздела APIs & Services
Далее нам нужно включить API, для этого введите в строке поиска «Gmail API»
Выбираем Gmail API и включаем его:
После включения API Gmail вы должны быть перенаправлены на страницу обзора API Gmail. Здесь нажмите кнопку Create credentials.
На следующей странице нам нужно пройти последовательно несколько этапов заполнения данных. Первым — в раскрывающемся списке выберите «Gmail API» и выберите опцию User Data, после этого нажимаем Next
Затем Google запросит некоторую базовую информацию о вашем приложении. Мы заполним лишь обязательные поля (помечены звёздочкой). Первая часть для публичных данных о приложении, а последний E-mail (кантатная информация разработчика) предназначен для Google, чтобы уведомлять вас об изменениях в вашем проекте.
Следующий раздел №3 необязателен для заполнения, поэтому кликаем «Сохранить и Продолжить«
В разделе №4 OAuth Client ID выбираем Веб-приложение (Web Application)
А также задаём Имя — это имя используется только для идентификации клиента в консоли и не будет отображаться конечным пользователям.
Затем пропустите раздел Authorized JavaScript origins и переходим к важному моменту — это подраздел Authorized redirect URIs. Здесь нам нужно добавить URI перенаправления.
Но где его взять? Для этого нужно вернуться на ваш сайт к странице настроек плагина, там он указан:
У всех он одинаковый, поэтому можете просто скопировать его отсюда:
https://connect.wpmailsmtp.com/google/
Вставьте эту ссылку и создайте перенаправление
После успешного добавления вы автоматически переместитесь к заключительному этапу №5, на котором у вас будет отображаться ваш клиентский ID
Нам доступна загрузка информации для аутентификации приложения в формате JSON, но мы, как обычный пользователь, просто скопируем Clien ID и добавим его в настройки плагина на сайте
Не забудьте сохранить изменения. Теперь давайте получим Секретный код клиента.
Зайдите в раздел «OAuth consent screen» и в подразделе «Статус публикации» обратите внимание на текущий статус — это Test. Опубликуйте ваше приложение кликнув Publish App
Подтверждаем…
После публикации в «Продакшн»,вы можете заметить изменение в статусе.
Отлично! Далее, перейдите в раздел Credentials. Там вы обнаружите ваше приложение для аутентификации на серверах Google. Нажмите на карандашик чтобы перейти к редактированию
Именно там и находится Client secret. Хотя, стоит заметить, что на этапе создания Client ID, когда нам был ещё доступен файл для скачивания с данными в формате JSON, то там уже присутствовал наш Client ID. Но это просто для информации.
Что ж, копируем и вносим в настройки плагина наш Client ID
Становится активной примечательная кнопочка Разрешить плагину отсылать почту использую ваш google аккаунт.
Притомились? Но финал близок. Теперь всё готово и нам нужно осуществить Авторизацию.
Нажимаем… Откроется экран входа в Google. Продолжайте и войдите в учетную запись, с которой вы настраиваете SMTP.
После выбора аккаунта вы можете увидеть вот такое предупреждение. Не переживайте. Просто переходите по ссылке к Дополнительным настройкам
И нажимаем на ссылку перехода
Перед нами ещё один экран. Здесь после одобрения произойдет обратное перенаправление
После некоторой магии, в которой произойдет обмен токенами и приложения пройдут аутентификации, вы должны увидеть вот такое сообщение об успешной авторизации.
А кнопочка превратится вот в такую:
Поздравляю! Вы сделали это!
Теперь смело переходим к тестированию отправки сообщений и отправим вначале через Инструмент данного плагина
А вот и письмо в ящике после успешного теста
Проверим с боевой формы сайта
Письмо на месте)
Сделаем проверку через сервис Mail Tester. Неплохо)
Правда наш «айпишник» значится в 2-х базах чёрных списков. Но это уже совершенно другая история…
В этой статье рассмотрим, пожалуй, самый простой плагин для страничного кеширования сайта на WordPress — Surge.
Плагин настолько простой, что даже не имеет настроек и работает «из коробки», то есть сразу же после установки и активации. Файлы кэша сохраняются на диске и автоматически удаляются при обновлении сайта — вот и весь принцип работы.
Если не вдаваться в подробности, то данный плагин позволит ускорить ваш сайт и снять нагрузку с сервера. Вот яркое заявление от разработчиков:
В различных нагрузочных тестах Surge показал, что легко обрабатывает 1000–2500 запросов в секунду при 100 одновременных операциях на небольшом одноядерном сервере всего с 1 ГБ ОЗУ. Это более чем в 70 раз быстрее, чем стандартная установка WordPress.
https://wpmag.ru/2021/surge-caching-wordpress/
Как установить плагин?
Установить плагин Surge можно через панель администрирования WordPress в разделе Плагины > Добавить новый.
После активации плагин сразу приступит выполнять свои обязанности. В директории wp-content вашего сайта будет создан файл-вкрапление и директория для хранения кэша
Ну а сами файлы кэша выглядят вот так
Как проверить что кэширование работает?
Можно открыть страницу сайта в режиме инкогнито, пару раз обновить, чтоб страница точно попала в кэш и с помощью инструментов для разработчиков посмотреть заголовки ответа сервера:
Значение hit директивы X-Cache говорит о том, что ответ пришёл из кэша, а это значит что всё хорошо и наше кеширование работает 🙂
Если вы используете WP-CLI, то установить и активировать Surge можно так:
Посетители вашего сайта отправляют вам электронные письма через контактные формы, а они попадают в папку СПАМ, или не приходят вовсе. Знакомая картина?
Эта проблема присутствует на многих сайтах под управлением WordPress, потому что по умолчанию WordPress использует для отправки электронных писем почтовую функцию PHP и многие сервера не настроены должным образом и не соответствуют требованиям безопасности, которые достигаются настройкой SPF, DKIM и DMARC записями.
Первое с чего стоит начать — это с тестирования.
Протестируйте Ваши письма на СПАМ
Переходим на страницу этого сервиса. Вам будет сгенерирован случайным образом адрес электронной почты, на который вам необходимо отправить тестовое сообщение, чтобы затем сделать диагностику и выявить причины попадания сообщений в СПАМ.
После копирования E-mail страницу не закрывайте! Мы к ней ещё вернёмся.
Плагин Contact Form 7
Если вы используете на сайте для создания контактных форм плагин Contact Form 7, то необходимо этот email указать в числе получателей (если получателей несколько, то их нужно разделять запятыми).
Теперь необходимо со страницы вашего сайта, с контактной формы отправить сообщение
Затем нам нужно вернуться на сайт на котором сгенерирован наш E-mail и перейти к отчёту проверки
Перед нами откроется окно с результатами, где в принципе, всё подробно расписано, за что вам снизили баллы и т.п.
В частности мы видим, что у нас не настроены нужные и важные записи, которые подтверждают достоверность отправителя и как следствие системы защиты почтовых сервисов могут отправлять ваши письма в СПАМ.
DKIM — это метод проверки подлинности сообщений электронной почты и в отчёте мы видим его отсутствие. Также отсутствует и DMARC, который защищает получателя от спуфинга (англ. spoofing — подмена). Поэтому не стоит удивляться, что отправленное письмо прилетело в СПАМ 🙂
Что делать дальше? Как исправить ситуацию?
Можно настраивать эти записи DNS вручную или при помощи поддержки «хостера» (места где размещается ваш сайт), как правило служба поддержки оказывает подобные услуги и помогает настраивать эти вещи.
Решать поставленную задачу мы будем за счёт плагина и надежно настроим отправку сообщений, для того чтобы они больше не попадали в папку СПАМ получателей.
Встречайте, плагин WP Mail SMTP
Необходимо установить плагин на ваш сайт. Если вы не знаете, как это сделать, то воспользуйтесь этой инструкцией.
После установки и активации перед вами откроется окно помощника установки. Предлагаю просто вернуться в Панель управления
Далее, мы окажемся на странице настроек плагина. Кстати, он создаёт целый раздел в Главном меню панели управления
В первую очередь нас интересует раздел на этой странице, который называется Почтовая программа. Тут нам нужно будет выбрать провайдера (сервис-посредник, через который будет осуществляться отправка Email-сообщений)
Из примера мы видим, что по умолчанию у нас стоит PHP, который нам нужно поменять на один из доступных сервисов. Отмечу, что часть из них доступны только в платной версии.
Мы воспользуемся универсальным методом Прочие SMTP. Это подойдёт для большинства пользователей, но стоит учесть некоторые нюансы, которые конечно же будут.
У вашего хостинг-провайдера должна быть возможность создания почтовых ящиков. Точно могу сказать, что на хостинге от компании TimeWeb эта возможность присутствует. И у хостинг-провайдера Beget на виртуальном хостинге эта возможность есть.
В нашем примере будет рассмотрен хостинг-компания Beget.
Создание почтового ящика
Принцип создания почтовых ящиков, плюс/минус одинаковый. В качестве примера будем создавать почтовый ящик у хостинг-провайдера Beget. Создаём мы его только с одной целью — чтобы он выступал в качестве посредника-отправителя.
На главной странице Панели управления хостингом переходим в раздел Почта
Выбираем нужный домен (тот на котором ваш сайт, для которого мы и настраиваем SMTP) и затем создаём новый почтовый ящик. Я создал его с именем «hello», следовательно моя почта отправителя будет «hello@codeispoetry.ru»
Подробнее, о создании почты на домене можно прочесть тут.
После того, как почта наша готова к работе, нам необходимо узнать данные для SMTP. Эти данные можно запросить у службы поддержки или найти самостоятельно в документации. Я это уже сделал за вас и публикую данные для настройки почтовых клиентов на серверах Beget.
Настройка подключения на серверах Beget
Для настройки работы почты через сервера Beget нужно использовать следующие реквизиты подключения:
Сервер исходящей почты
SMTP-сервер — smtp.beget.com
Порты
SMTP — 25 или 2525 SMTP защищенный SSL — 465
Ограничения на использование почты
На хостинге установлены следующие ограничения на отправку почтовых сообщений:
через PHP-функцию mail(), он же sendmail, можно отсылать не более 30 писем в минуту;
через SMTP-сервер не более 30 писем в минуту и не более 1500 писем в час;
число получателей одного письма — не более 300;
максимальный размер почтового сообщения для SMTP — 75Мб, для mail() — 70Мб;
рассылка должна быть валидной: не содержать вредоносных файлов и ссылок на них, в письме должна содержаться ссылка на отказ от получения данной рассылки.
Теперь подытожим, давайте зафиксируем данные которые нам понадобятся для реализации подключения:
Адрес почтового ящика (который мы создали ранее)
Пароль от этого почтового ящика (задаётся при создании, но можно всего его изменить)
Адрес SMTP-сервера (у каждого провайдера свой, в нашем примере он smtp.beget.com)
Порт 465
Теперь внесём эти данные в настройки нашего подключения SMTP на нашем сайте:
Будьте предельно внимательны. Обратите внимание, что включено, а что выключено в моих настройках, какой указан порт и т.д.
Примечание. Для опытных пользователей рекомендуется данные для подключения указывать через конфигурационный файл WordPress — wp-config.php Это позволит защитить настройки сделав невозможным их редактирование через панель управления. Подробнее…
После этого, нам необходимо перейти в раздел Инструменты и протестировать отправку нашего сообщения:
Если вы всё сделали верно, то непременно письмо будет отправлено успешно:
Но всё равно достоверность его страдает и наше письмо снова залетает в СПАМ, по крайней мере на mai.ru. Это из за того, что у нас отсутствует DKIM
DKIM (DomainKeys Identified Mail) — технология проверки электронной почты, с помощью которой можно вычислить поддельные письма. DKIM добавляет в письмо цифровую подпись. Благодаря ей почтовые провайдеры (Mail.ru, Gmail) могут проверить, что сообщение отправлено именно с указанного домена.
Да, нам никак не избежать дополнительных настроек чтобы добиться качественного отправления. Но есть приятный момент. Когда мы задействуем для отправки сторонние сервера, как в нашем случае с Beget, за нас внесение записи берёт на себя служба поддержки хостинга, по крайней мере на Beget это так. Вот цитата из документации по настройке почтовых клиентов.
Для завершения настройки нам нужно обратиться в поддержку. Текст обращения может быть примерно следующим:
Здравствуйте. Создали почту на домене [ВАШ ДОМЕН] Используем для отправки SMTP Beget. Письма попадают в СПАМ. Просим внести запись DKIM. Спасибо.
Очень приятно, что поддержка Beget в лице Ирины Станиславовны не заставила себя ждать с ответом.
Думаю можно не проверять запись, доверяя работе квалифицированных сотрудников службы поддержки Beget, но если вам интересно убедиться, то тут же из консоли это возможно сделать:
Теперь, если мы повторим отправку сообщения, то можем увидеть наше письмо в разделе Входящие. Для фильтров большинства сервисов наличие записи DKIM вполне достаточно в качестве аргумента 🙂
Но завершающим действием, я предлагаю сделать добавление записи DMARK. Да, её необходимо будет добавить самостоятельно. Для этого переходим в раздел DNS
В этом разделе необходимо выбрать нужный домен и создать для него подзону:
И указываем подзону _dmarc
После этого выберем созданный поддомен и внесём запись TXT со следующим содержимым:
Может не так очевидно, но сообщение говорит о том, что запись присутствует. Всё хорошо.
Попробуйте сделать повторный тест на сервисе Mail Tester. Напишите, помогло ли вам это решение?
Напоследок, рекомендую проверить следующие настройки плагина:
Адрес отправителя — тут должна быть указана ваша почта, ящик которой вы создали.
Принудительно использовать адрес отправителя — ВКЛ (включено)
Лишним не будет указать и имя отправителя на что то более уникальное, чем, как в моём примере — Demo Site.
Послесловие.
Да, безусловно путь не простой по настройке протокола для передачи E-mail сообщений, но его необходимо раз сделать и забыть, чем постоянно мучаться и подвергать себя рискам, которые особенно могут вылезти на сайте электронной коммерции.
Следующая статья тоже техническая, но она позволяет настроить отправку писем через ваш аккаунт на Gmail. В моей практике этот метод настройки был надежным и служил верой и правдой долгие годы на сайтах заказчиков.
Плагины в WordPress — это специальный, добавочный код в виде файлов, который дополняет WordPress новыми функциями или меняет текущие.
Например, чтобы дополнить наш сайт функциями интернет-магазина, нам необходимо установить плагин WooCommerce. А для того чтобы превратить наш сайт в онлайн-платформу для образования, нам нужно задействовать плагин Sensei LMS — онлайн-курсы, контрольные вопросы и обучение.
Так как же установить плагин в наш сайт под управлением WordPress? Рассмотрим три основные способа. И начнём с самого популярного и простого способа.
Установка через панель управления из официального репозитория (хранилища) WordPress
В WordPress есть механизм (встроенный установщик) по поиску и добавлению плагинов прямо из панели управления сайтом. Единственное, вам необходимо обладать правами для этого, а это значит выполнять эти операции нужно под записью администратора — с наивысшими привилегиями.
Заходим в панель управления сайтом и следуем в раздел Плагины
В этом разделе мы можем увидеть все плагины которые уже установлены на наш сайт, но часть из них может быть включена (активирована), а часть выключена (деактивирована).
Чтобы добавить новый плагин нажмите в верхней части страницы Добавить плагин. (эта же функция есть в подменю раздела). Перед нами откроется страница встроенного установщика, где нам необходимо ввести ключевое слово для поиска.
Обращу внимание, что поиск осуществляется по официальному хранилищу, каталогу плагинов WordPress, доступному по этой ссылке. На сегодняшний день заявлено примерно 60 000 плагинов. Внушительная цифра, не правда-ли?
Например, мы желаем установить на сайт плагин для создания контактных форм. Тогда в нашем случае, пожалуй удачным запросом может являться сочетание этих слов.
Перед вами будет огромный выбор плагинов. Как правило, первые из них это то что вам нужно (при условии, что вы ввели однозначно понятный запрос). Например, если я хотел бы реализовать на сайте интернет-магазин, то вероятнее всего так и написал бы:
В этом случае плагин WooCommerce является лучшим решением для электронной коммерции на WordPress.
На что стоит обратить внимание?
Предположим мы нашли нужное нам решение. Но прежде чем устанавливать и активировать плагин, взгляните на информацию о нём. она доступна в его карточке.
Это количество и качество оценок. И в примере выше вопросов не остаётся. Миллионы пользователей используют решение и 13 тысяч отзывов, которые наполняют все пять звёзд.
Обновление. Хорошо когда у плагина стоит дата его обновления в течении до 6-12 месяцев. Если плагин обновлялся последний раз лет 5 назад, то стоит задуматься. В этом случае могут быть проблемы с совместимостью. Хотя встречаются иногда плагины, которые не обновлялись лет 5, но работают безупречно. Но это редкость.
Совместимость. Хороший знак если плагин совместим с вашей версией установки WordPress. Хотя могут многие плагины быть несовместимы, но при этом работать без ошибок.
В любом случае обратите внимание на эту информацию. Категорически не рекомендую устанавливать плагины у которых много отзывов с низкой оценкой. В этом случае стоит подобрать другое решение или посоветоваться с опытными разработчиками, например, на форуме поддержке на предмет использования плагина. Так же не рекомендую использовать плагины, которые не обновлялись 5 и более лет.
Установка и активация плагина
Ну и если всё «ok», то нам ничего не мешает установить плагин в наш сайт. Для этого нужно просто нажать кнопочку «Установить«
Процесс установки может занять некоторое время, как правило в среднем до минуты, в зависимости от размера загружаемого файла плагина и скорости соединения.
Установка — это значит загрузка файлов плагина в директорию нашего сайта, то есть в специальной папке, отведенной для плагинов, на вашем сайте появится загружаемый новый плагин:
После окончания загрузки кнопочка станет синенькой 🙂 и будет уже называться «Активировать«. Для чтобы файлы плагина заработали на нашем сайте его нужно активировать
После активации плагина его код вступит в силу, а это значит, что в панели управления, в главном меню, может появиться какой то специальный раздел…
Теперь рассмотрим способ, который позволяет осуществлять установку плагина из загружаемого файла.
Установка при помощи загрузки файла
Этот способ подразумевает, что у вас есть установочный файл плагина, обычно это zip-архив. Но откуда может появиться у вас этот файл zip-архива? Вероятнее всего вы его «скачали» из интернета или купили плагин на каком-нибудь маркетплейсе, типа CodeCanyon, где после покупки вам достанется установочный файл плагина. Естественно, этих платных решений вы не найдёте в бесплатном репозитории плагинов WordPress, который мы рассматривали в первом способе.
И следовательно, в этом случае установка у нас будет немного иной.
Перейдите в раздел «Плагины» > «Добавить новый» .
Нажмите кнопку «Загрузить плагин» в верхней части экрана.
Далее, необходимо указать путь к файлу установки или методом перетягивания перетянуть файл плагина в эту область окна
Рассмотрим реальный кейс (случай). Мною была приобретена платная версия плагина ACF. После оплаты мне стали доступны в личном кабинете лицензионный ключ и актуальная версия плагина. Которую мне нужно загрузить на свой компьютер, а потом установить на свой сайт под управлением WordPress.
Теперь вернёмся к этапу загрузки файла и загрузим его в WordPress
Выбираем нужный установочный файл плагина и переходим непосредственно к установке, кликнув на «Установить»
Архив загрузится в директорию нашего сайта и разархивируется в папку plugins. Если всё пройдёт успешно, то переменно вы должны увидеть вот такую картинку, на которой нам доступна кнопочка для активации плагина
Ну и в заключении, хотелось бы сказать, о продвинутых способах установки и в тоже время можно их назвать редкими способами, так как рассмотренных выше более чем достаточно.
Но бывают случаи, например, когда ваш сервер не настроен на автоматическую загрузку файлов или могут быть выставлены неправильные права файлов и права пользователя на сервере. То тогда, да… тогда остаётся только пробовать что то из ниже предложенного:
через соединение FTP, SFTP
с помощью менеджера пакетов PHP — Composer
при помощи командной строки и специального инструмента WP-CLI
Рассмотрим изящный способ через WP-CLI — это интерфейс командной строки для WordPress.
На многих хостинг-площадках он уже доступен для работы, к примеру виртуальный хостинг Beget. Минимальный тарифный план и открыв консоль, мы можем взаимодействовать с нашими сайтами через командную оболочку.
Открываем терминал, включаем соединение по SSH и вводим команду:
wp
Если инструмент WP-CLI установлен у вашего хостинг-провайдера, то в консоли должно появиться примерно следующее:
Как устанавливать плагины через WP-CLI
Принцип достаточно простой.
Нужно перейти в директорию того сайта с которым предстоит работа, в который мы планируем установку плагина. Это может выглядеть так:
cd my-site
cd public_html/
wp plugin list
И мне вывалится информация по текущим плагинам данного сайта. Важно! Находится нужно в директории сайта с которым работаете.
+--------------------+----------+-----------+---------+
| name | status | update | version |
+--------------------+----------+-----------+---------+
| akismet | active | available | 5.3 |
| jetpack | active | available | 12.9.3 |
| jetpack-boost | active | available | 2.2.1 |
| nginx-cache | inactive | none | 1.0.5 |
| redis-cache | inactive | none | 2.5.0 |
| wp-mail-smtp | inactive | available | 3.11.0 |
| wp-super-cache | active | none | 1.11.0 |
| advanced-cache.php | dropin | none | |
+--------------------+----------+-----------+---------+
А теперь самый главный принцип. У каждого плагина есть уникальное название в URL
Выше, перед нами плагин для для создания Форума — bbPress. Указав его имя в УРЛ мы можем осуществить установку из командной оболочки:
wp plugin install bbpress --activate
В примере мы устанавливаем и сразу активируем плагин bbPress.
Задача: Узнать идентификатор страницы в WordPress.
Что такое идентификаторы Страниц и Записей в WordPress? Это их числовые уникальные номера, которые не могут быть идентичными.
То есть, если создать две одинаковые страницы, например, страница «О нас» и точно с таким же заголовком вторую страницу «О нас», и наполнить их одинаковой информацией, то что мы получим?
Для пользователя это будут визуально абсолютно одинаковые страницы, а для CMS WordPress — разные. При создании каждой из страниц будет присвоена уникальная цифра, которая и называется — «айдишником» (идентификатором этой страницы), именно по ней WP и различает их.
Можно рассмотреть пример из жизни. Рождаются два близнеца, да таких, что мать родная не различит. Им выдаются разные свидетельства, паспорта. Что в итоге? Близнецы на вид одинаковые, а паспорта разные — для того чтобы отличать их друг от друга в системе Жизнь. Так и со страницами. Не может быть одинаковых номеров.
Решение:
Способ №1
Если вы находитесь в панели управления WordPress с привилегиями, позволяющими видеть, редактировать контент сайта, то в разделе Страницы нужно навести на нужную вам страницу курсор мышки и не отводя его, посмотреть в нижнюю часть, там должна отобразиться ссылка, в которой и будет содержаться идентификатор страницы.
В данном примере id=54
Это справедливо и для Записей, по сути это те же самые страницы. Переходим в раздел всех Записей и наводим курсор на нужную:
В этом примере ID страницы равен 1.
Способ №2
Выяснить идентификатор страницы (или Записи) можно в режиме её редактирования. То есть, переходим в режим редактирования (это когда открыт визуальный редактор этой страницы) и обращаем внимание на ссылку в верхней части:
Видим, что id-53
Способ №3 (с публичной части сайта)
В принципе, рассмотренных вариантов из панели управления достаточно, чтобы быстро идентифицировать страницу. Но как быть, если вы находитесь на сайте, как пользователь, а не как администратор?
В этом случае будет чуть-чуть сложнее. В рассматриваемом примере я использую браузер Google Chrome. Нам нужно находиться именно на той странице, «айди» которой мы желаем выяснить.
Я перехожу на страницу Контакты и нажимаю правой клавишей мышки в любой её области. Затем, нужно открыть Просмотр кода страницы (в разных браузерах может по-разному это называться), или воспользоваться комбинацией горячих клавиш Ctrl+U
В исходном коде попытаться найти какие то упоминания об id. Как правило, это упоминание должно с очень большой долей вероятности находится в теге <body>
Эта заметка относится к разряду технической. То есть уже требует небольшого погружения в код .
Дано: Сайт под управлением CMS WordPress.
Задача: Проверить на уровне сервера (на стороне back-end) данные приходящие извне, на корректный номер телефона.
Решение: Если у вас установлен плагин для электронной коммерции WooCommerce, то обращу внимание на то, что в нём уже существует специальный метод (функция) который позволяет осуществить проверку на корректный номере телефона, то есть исключить обработку данных, если в них содержаться какие то иные символы, например, буквы.
Давайте взглянет на класс WC_Validation. В нём мы увидим нужные нам методы для решения поставленной задачи:
is_phone() — Проверяет номер телефона с помощью регулярного выражения.
format_phone() — Позволяет отформатировать переданный номер телефона.
Давайте взглянем на этот метод из ядра плагина WooCommerce:
/**
* Validates a phone number using a regular expression.
*
* @param string $phone Phone number to validate.
* @return bool
*/
public static function is_phone( $phone ) {
if ( 0 < strlen( trim( preg_replace( '/[\s\#0-9_\-\+\/\(\)\.]/', '', $phone ) ) ) ) {
return false;
}
return true;
}
Очевидно, что метод реализует грамотную проверку на адекватный номер телефона.
Функция strlen() возвращает длину строки и тут же мы её проверяем , чтобы она не была меньше нуля. А функция trim() ещё раньше отрабатывает и её назначение — удалить пробелы из начала и конца строки. И в серединке мы видим функцию preg_replace(), которая осуществляет поиск и замену по регулярному выражению. Первый аргумент — это паттерн. Второй аргумент — это то, что функция получает, то есть наш номер телефона извне. Возвращает функция булев тип: true|false.
Применение:
В принципе, для того чтобы воспользоваться функцией можно просто вызвать её, передав ей данные на валидацию. Но я предлагаю другой подход. Мы её вынесем отдельно, как функцию-хелпер, но только с проверкой на объявление одноимённой функции (можно конечно просто переименовать произвольно и не заморачиваться, но я учёл, что может быть активирован плагин Woo и тогда выполнение вызова функции, будет уже на стороне Woo).
/**
* Validates a phone number using a regular expression.
*
* @param string $phone Phone number to validate.
* @return bool
*/
if (!function_exists('is_phone')) {
function is_phone( $phone ) {
if ( 0 < strlen( trim( preg_replace( '/[\s\#0-9_\-\+\/\(\)\.]/', '', $phone ) ) ) ) {
return false;
}
return true;
}
}
Я специально подготовил данные с разными вариантами: слитно со знаком «плюс», с чёрточками и с пробелом (последний пример). Люди по разному могут указать номер телефона. Все примеры валидны.
А теперь давайте рассмотрим не валидный пример, в котором специально вместо нуля передал заглавную «O», а в двух следующих специальные символы, которые не учтены в паттерне регулярного выражения. В итоге получили false
Форматирование номера телефона
Вторая функция format_phone(), которая идёт «прицепом» к первой, является обёрткой функции wc_format_phone_number()
Обратите внимание, что внутри после проверки на пустую строку идёт проверка и привязка к ранее рассмотренной функции. Согласно коду — это метод класса WC_Validation и он должен быть не false. Тогда то и происходит магия при помощи регулярного выражения и другого паттерна. Задумка хорошая, но по большому счёту для нашего континента бесполезная 🙂
При желании можно конечно «допилить» это дело, например, оформить в отдельную функцию-хелпер или же дополнить код первой функции и получить полное решение валидации номера телефона с последующим форматированием при возврате функцией. Хорошей отправной точкой тут может послужить нативная функция PHP sscanf() — которая разбирает строку в соответствии с заданным форматом. Вот пример со страницы описания данной функции.
Естественно, что для начинающих пользователей это может показаться сложным решением, поэтому я предлагаю написать простенькую «функцию-прицеп» к нашей первой функции-валидатору, которая будет возвращать отформатированную строку.
Код не идеальный. Это просто импровизация для того чтобы показать, как просто на стороне «бэкэнд», на PHP можно сделать форматирование возвращаемой строки с номером телефона.
Здесь для демонстрации возможностей PHP для каких-то проверок/условий задействовал функцию iconv_strlen() — возвращает количество символов в строке, а не количество байт (как, например strlen()).
Если отталкиваться от этого кода, то тут нужно учесть, что первая наша функция разрешает символы «+» и «-» , а следовательно их подсчёт тоже будет учитываться и нас подстерегает неожиданность при форматировании 🙂 Поэтому, в этом случае имеет смысл передавать только цифры, а всё лишнее — вычищать. Следовательно, наше выражение может иметь в первой функции следующий вид:
preg_replace("/[^0-9]/","", $phone ........
Но тут опять много нюансов, например человек может начать запись с «8-ки», а может с «7-ки» 🙂 А в Казахстане формат встречается зачастую +7 (7xx) xxx-xx-xx
Поэтому можно сохранять в базу значение до форматирования, а потом ещё и после и в случае каких-то непонятных ситуаций исследовать эти значения.
В общем, если подытожить, то на мой взгляд первой функции вполне достаточно. Главную задачу она выполняет — чистка пробелов и прочих лишних символов, которые никак не ассоциируются с записью телефонного номера.
Но, если вы всё-таки намерены делать форматирование, то я предлагаю реализовать его на стороне клиента и для этого можно задействовать изящное решение под WooCommerce, при помощи которого мы можем задать нужную маску для ввода номера телефона пользователем перед тем, как он будет передаваться функции-валидатору.
Прежде всего стоит осознать, какую угрозу для вашего SEO (поисковая оптимизация сайта) несут неработающие (битые) ссылки внутри вашего веб-сайта.
Распознать такую ссылку очень легко. Как правило, переход по ней приводит на страницу со статусом ошибки 404.
При взаимодействии пользователей с вашим сайтом, это влечёт для них негативный опыт и как следствие понижение в выдачи поисковых систем страниц вашего сайта. Ведь зачем показывать Яндекс и Google URL с вашего веб-сайта на первых позициях, если пользователи не смогут получить нужную им информацию. Согласны?
Отсюда, индекс качества таких URL понижается и они попросту теряются. Вероятность, что кто то попадёт на такие страницы (со статусом 404) из поисковой выдачи очень мала.
Как обнаружить неработающие ссылки?
Для этих целей существуют различные инструменты: Google Search Console, Screaming Frog, Яндекс Вебмастер и другие. В Яндекс Вебмастере относительно недавно, появился новый инструмент для проверки ссылок с ошибками.
С помощью «Вебмастера» вы можете определить неработающие ссылки:
внутренние — это ссылки, ссылающиеся между страницами вашего сайта;
внешние — это ссылки, ведущие на ваш сайт со страниц других ресурсов;
исходящие — это ссылки, которые ведут со страниц вашего сайта на другие ресурсы.
Выглядит это так:
Внутренняя ссылка — это ссылка, которая расположена на странице вашего сайта и ведет на другую страницу этого же сайта.
Неработающие внутренние ссылки могут отрицательно влиять на удобство сайта, если они мешают навигации посетителей по страницам сайта.
Ссылка считается неработающей, если на запрос робот получил HTTP-статус отличный от 2XX или 3XX.
Неработающие ссылки могут быть исключены из индекса. Информация об этом доступна в разделе «Статистика обхода».
Сведения о работоспособности ссылки обновляются в сервисе после переиндексации роботом.
Плагин для проверки битых ссылок Broken Link Checker (автор: WPMU DEV)
Если по каким то причинам вы не желаете использовать отличный сервис Яндекс Вебмастер или схожие, то можно воспользоваться решением в виде плагина для CMS WordPress.
После установки плагина, работу с ним начать можно сразу из меню Проверка ссылок:
Перед нами дилемма: или начать работу в «облаке», либо «по старинке» за счет вычислительных мощностей вашего сервера и интерпретатора PHP 🙂
Первый метод требует создание аккаунта на сервисе разработчиков, поэтому я предпочёл выбрать второй вариант — Локальный.
Стоит отметить, что плагин работает сразу «из коробки», то есть уже начинает анализировать ваш контент на предмет битых ссылок. В данном примере видно, что сразу найдено 9-ть неправильных ссылок и 741 URL в очереди на проверке. Неплохое начало)
Тут же мне посыпались уведомления (на E-mail администратора), о том что были найдены битые ссылки. В скриншоте выше видно, что уведомлениями мы можем управлять и при необходимости отключить их или изменить получателя. А вот и скриншот письма:
Вобщем, при локальном методе работы, наш плагин содержит две вкладки: Обнаруженные ссылки и раздел настроек:
Давайте прежде разберёмся, что делать с неработающими ссылками, а потом немного рассмотрим настройки плагина.
Как исправить битые ссылки?
Всё зависит от назначения ссылки. Ситуации бывают разные. Рассмотрим один интересный кейс (случай):
Ссылка на сайте долгое время вела на каталог в формате PDF (кстати, такие файлы тоже индексируются и могут быть доступны для поиска пользователям в Google, Яндекс или других поисковых машинах).
Вот баннер, который располагается на главной странице сайта.
Клик по баннеру перенаправляет пользователя на каталог в виде файла формата PDF
Этой ссылкой, на этот файл много делились в социальных сетях, многие из дилеров или дизайнеров интерьеров оставляли на него закладку в своём браузере, чтобы быстрее возвращаться к нему при работе с клиентами, в момент предложения интерьерных решений, например.
И вот в один прекрасный день, кто-то по ошибке, а может и нарочно удаляет с сервера этот файл. Что произойдёт? Все кто будет переходить по этому УРЛ будут непременно видеть:
Знакомая картина?
Поэтому, конечно же необходимо проверять свой сайт на предмет неработающих ссылок, наверняка этот аудит принесет не мало удивлений вам 🙂 По крайней мере можно вовремя исправить неприятность, такую которую мы сейчас рассматриваем в этом примере.
Итак, как исправить эту неработающую ссылку? Естественно загрузить новый файл с точно таким же названием, либо сделать перенаправление на другой файл или страницу. Тем самым мы не потеряем потенциальных клиентов, которые перейдут по этой ссылке, понимаете?
Другой случай. Была удалена неактуальная статья с сайта. А на эту статью ссылались другие страницы сайта, условно говоря, была перелинковка. Что делать в этом случае? Естественно исправлением будет — удаление ссылок на эту страницу, так как новую создавать не планируется, в силу неактуальности информации.
Поэтому, тут всё индивидуально. Смотря какая ситуация будет у вас. В основном это следующие решения:
Настройка переадресации (301) на похожие страницы сайта
Исправление ссылки на новую (действующую)
Удаление неисправных ссылок
Настройки плагина
В разделе настроек хотел бы отметить следующие возможности:
Настройка уведомлений об обнаружении битых ссылок на вашем сайте
Периодичность проверок (по умолчанию 72 часа). Если контент на вашем сайте редко меняется, то можно значительно увеличить этот интервал.
Можно указать тип контента по которому осуществлять поиск. В частности, если у вас интернет-магазин, то возможно будет разумным включить поиск по типу контента — Товары.
Показать виджет панели инструментов для… И по умолчанию стоит настройка «Редактор и выше». Возможно, стоит ограничиться только ролью Администратора
«Поковыряйтесь» обязательно в настройках, вполне возможно некоторые из них вас приятно удивят.
Если не вдаваться в долгие разъяснения, о системе кеширования в WordPress, а попытаться объяснить просто и кратко, то своё пояснение я начал бы с того, что есть некий механизм, который способен снять нагрузку с сервера (место где работает сайт) и тем самым ускорить ваш веб-сайт под управлением WordPress.
Механизм этот называется — кеширование. Принцип работы достаточно простой. Кеширование позволяет использовать готовые сформированные данные, а не генерировать их при каждом повторном обращении к страницам сайта.
Кэш страниц (Page cache)
Чтобы понять суть этого вида кэширования, давайте рассмотрим простой пример. Возьмём этот сайт. Предположим Вася попадает на эту страницу. На сервере (на back-end) происходит много скрытых, невидимых глазу посетителя процессов: обработка запроса, формирования заголовков ответа, выборка данных из базы данных, выполнение логики и вычислительных операций PHP и прочее. В итоге формируется страница, которая должна вернуться в браузер Васи в виде HTML для отрисовки. Сервер получил нагрузку выполняя эту подготовку. Через минуту эту же страницу посещает Петя. Что происходит? Снова происходят те же самые процессы: выборка и обработка данных для формирования страницы, чтобы отправить Пете в браузер. А через пару минут эту страницу посещает девочка Катя. Ну вы догадались что произойдёт, да? 🙂
А представьте, что одновременно эту страницу будут посещать в течении нескольких минут ещё пользователей 100-200 и это нормальная ситуация, даже для свежеиспечённых сайтов. Такую нагрузку может вызвать реклама или рассылка, которая приведёт на эту страницу большое количество посетителей.
Мы можем снять нагрузку с сервера путём страничного кеширования. Проиграем снова эту ситуацию, но уже с реализацией страничного кеширования.
Включен полный страничный кэш
На эту страницу заходит Петя. Происходит та же самая магия: подготовка и обработка данных. Страница сформирована и готова байтами лететь в браузер Пети. Сервер, как обычно отправляет страницу, но за одним исключением. Мы сохраняем копию этой сформированной страницы — это и есть кэш.
Далее заходить на эту страницу сайта Вася. Догадались что будет происходить? Да! Сервер отдаст готовый вариант этой страницы и не будет заново её формировать.
Теперь на время жизни этого кэша всем посетителям сайта будет отдаваться сформированный результат и как следствие — это выигрыш в скорости работы сайта, повышение его производительности за счёт короткого отклика (так как страница уже сформирована) и снятие вычислительной нагрузки.
WordPress не наделён этим механизмом «из коробки» (то есть после установки и первого запуска). Реализовать такое кеширование помогут плагины, такие как:
WP Super Cache
W3 Total Cache
WP Rocket (платный)
Объектный кэш в WordPress
Но в этой статье мы будем говорить об объектном кэшировании в WordPress, которое, кстати, так же «из коробки» является непостоянным. Проиграем опять ситуацию. Заходит на страницу сайта Петя, происходит формирование страницы. И объектный кэш это другой уровень кеширования. На уровне страниц пример был рассмотрен выше и если вы были внимательны, то вспомните что при формировании страницы данные берутся из Базы Данных, то есть происходит, если выражаться техническим языком, их SQL запрос. Представим что запрос был сложный и данные запрашивались из БД по разным критериям (параметрам).
Да, в WordPress есть механизм объектного кэширования в рамках сеанса запрошенной страницы. Предположим, функция get_option() вызывается в рамках страницы 10 раз. Если провести аналогию с кэшированием страниц, то после первого вызова она попадёт в объектный кэш и последующие её вызовы будут уже обслуживаться из встроенного объектного кэша WordPress. Вроде всё классно, неправда-ли? Но что произойдёт если на эту страницу зайдет Вася? Функция get_option() снова будет запрашивать данные и в пока Вася находится на странице и не переходит на другие всё будет хорошо и последующие её вызовы будут обслуживаться из кэша.
Вот это и есть непостоянный объектный кэш. Но нам хотелось бы и это уже само напрашивается, чтобы для новых посетителей сайта не происходили одинаковые запросы из БД, а при повторном запросе данные были взяты из памяти, а не заново формировались ( как по аналогии со страницами).
И это реализуемо. Этот механизм называется — постоянный объектный кэш. Единственное, что реализуется он преимущественно за счёт внешних источников хранения, то есть нужно устанавливать на сервер дополнительное программное обеспечение. И сейчас мы рассмотрим один из самых простых примеров реализации постоянного объектного кэша где как раз таки не нужно ничего устанавливать, хотя есть небольшой нюанс.
Может напрашиваться вопрос: можно ли использовать оба кеширования вместе? Да, можно. И даже если ваш сайт постранично жёстко закеширован, всё равно нужно использовать объектный кэш, что бы уменьшить нагрузку с базы данных при работе, например, в админке, при работе в режиме авторизации пользователей, на страницах которые не должны кэшироваться, такие как корзина и страница оформления заказа и наверняка можно найти целый ряд дополнительных случаев оправдывающих постоянный объектный кэш даже в связке с грамотным страничным.
Кейс (реальный случай)
Мы решили организовать на своём сайте постоянный объектный кеш. Виртуальный хостинг не имеет в своём ПО сервис Redis, а следовательно после активации плагина мы не сможем его задействовать, так как наш тарифный план не включает установку дополнительного программного обеспечения.
Docket Кэш — это плагин для реализации постоянного кеша объектов в WordPress, который хранится в виде PHP-кода. Задача плагина предоставить альтернативный вариант для постоянного объектного кэша для тех, кто не может использовать на своих серверах такие сторонние решения, как: Redis или Memcached.
После активации плагина нам становятся доступны его разделы настроек:
Принцип работы плагина отличается от популярных решений, таких как Redis или Memcached, а также Docket Cache не использует механизм сериализации/десериализации объектов PHP для хранения в файлах в виде строк, а сохраняет данные путем преобразования объекта в простой PHP-код, что приводит к более быстрому извлечению данных и повышению производительности при включенном Zend OPcache.
Что такое Zend OPcache?
OPcache — это механизм кэширования, встроенный в PHP, который повышает производительность за счет хранения предварительно скомпилированного байт-кода сценария в общей памяти, тем самым устраняя необходимость PHP загружать и анализировать сценарии при каждом запросе.
Docket Cache преобразует кэш объектов в простой PHP-код. При чтении и записи кеша он будет напрямую использовать OPcache, что приводит к более быстрому извлечению данных и повышению производительности.
У плагина много всяких настроек доступных в разделе Configuration, включите некоторые из них:
В разделе Обзор можно увидеть статистику кеширования — это хороший знак, значит плагин работает 🙂
Есть также отдельный раздел OPcache где мы можем получить техническую информацию, в частности полезно понимать сколько доступно и задействуется памяти для хранения. Ну и сами файлы с кэшем.
Требования
Для использования Docket Cache нужно выполнить минимальные требования:
PHP 7.2.5
WordPress 5.4
Zend OPcache
Естественно все тонкости и настройки рассматривать смысла я не вижу. Главное что бы ваш сервер и его ПО удовлетворял минимальным требованиям и после активации плагина появлялись файлы, статистика кэша. Для начала это уже будет неплохо 🙂
Вот так хранится кэш на сервере. Это директория для хранения.
А вот файлы и их содержимое
Хранятся данные в виде массивов в синтаксисе PHP
Для технических специалистов возможно будет полезна эта ссылка на документация плагина
Подытожим об объектном кешировании
Кэширование объектов — это процесс, который сохраняет результаты запросов к базе данных, чтобы быстро восстановить их в следующий раз, когда они потребуются.
Кэшированный объект будет оперативно обслуживаться из кеша, а не отправлять несколько запросов в базу данных. Это более эффективно и снижает огромную ненужную нагрузку на ваш сервер.
Проще говоря, кэширование объектов позволяет копировать часто используемые объекты и хранить их в более близком месте для более быстрого использования.
За отрисовку кнопки, как элемента HTML, отвечает эта строка:
<button id="go-back">Вернуться назад</button>
Единственное, если быть точными и делать всю реализацию на JavaScript, получается по доброму этот элемент нужно создавать тоже при помощи скрипта. Выглядеть это может примерно так:
А за функционал на стороне клиента вот этот сниппет на JavaScript, который прослушивает событие клика по элементу с идентификатором «go-back» и вызывает на это событие метод back() принадлежащий интерфейсу History, который предписывает браузеру вернуться на одну страницу назад в истории сеанса.
@TODO По доброму ещё можно сделать проверку на существование значения «реффера» и принадлежности к текущему домену.
Мы рассмотрели механизм решения данной задачи на стороне клиента (браузера) при помощи JavaScript. Теперь давайте рассмотрим вариант на стороне сервера, при помощи PHP:
Реализация на PHP
В контексте WordPress, на стороне сервера подобное можно реализовать при помощи функции WP из ядра, которая является обёрткой других функций.
Начинающих пользователей могут смутить открывающие и закрывающие теги PHP, часто в этом допускают синтаксическую ошибку. Ниже привожу пример где я вывел обработку (функцию отчистки) URL из атрибута href, тем самым позволив исключить теги PHP:
// получаем реферальную ссылку
$return_url = wp_get_referer();
// если не false продолжаем ...
if ($return_url) {
// обработка УРЛ (подготовка)
$url = esc_url($return_url);
// вывод
echo"<a class='button' href='{$url}'>Вернуться назад</a>";
}
P.S. тоже «не сахар» вариант 🙂 Будьте внимательнее с кавычками. Чтобы в строке языковой конструкции echo у нас выводилась переменная с нашим УРЛ, необходимо убедиться что сама строка в двойных кавычках, а атрибуты элемента ссылки в одиночных!
Небольшим преимуществом серверного метода можно считать тот факт, что если у клиента будет выключен в браузере JavaScript или возникнут ошибки которые не дадут отработать первому решению (на JS), то наша кнопка всё равно окажется в DOM так как приходит с сервера, а не формируется на стороне клиента.
Если по каким то причинам вы не получаете письма с сайта WordPress на свой электронный ящик, или просто желаете подстраховаться — чтобы не пропустить отправленные важные E-mail оповещения такими плагинами, как WooCommerce, задействуйте плагин WP Mail Logging.
После установки, плагин достаточно только активировать и он незамедлительно приступит к работе и встанет на стражу e-mail транспорта.
Какая информация регистрируется?
Все электронные письма, отправленные с вашего сайта WordPress теперь, после активации плагина, будут протоколироваться.
А вот информация, которая сохраняется:
Тема письма
Содержимое электронной почты (HTML или текст)
Вложения электронной почты
Заголовки электронной почты (кому, от кого, кому ответить, копия, скрытая копия)
Сообщение об ошибке (в случае, если при попытке отправить электронное письмо произошла ошибка)
IP-адрес исходного сервера (нужно включить в настройках)
Дата и время письма
Получатель (адрес электронной почты)
Сейчас мы оформим заказ в магазине WooCommerce и посмотрим что отловит наш плагин для сохранения
Теперь в разделе журнала плагина мы можем наблюдать фиксацию данного события. Оформление заказа вызвало три события отправления электронных писем:
Вот панель для действий над письмами. Мы можем заново вызвать отправку выборочного письма, удалить или же жмакнуть на «глазик» и посмотреть тело письма которое получаем мы, как администратор сайта и какое получает клиент. Иногда это очень полезно 🙂
Письмо менеджерам интернет-магазина:
А вот такое письмо получают клиенты интернет-магазина:
Помимо прямого назначения, плагин также очень удобно использовать непосредственно для настройки, вёрстке электронных писем, например, при разработке сайта на localhost.
Дополнительные настройки
В настройках плагина можно включить
Хост — Отображение IP-адреса хоста, на котором работает WordPress. Это полезно при запуске WP Mail Logging на нескольких серверах одновременно.
Отображение вложений (файлов) — Отображение вложений в таблице журнала.
Учтите, что этот плагин сохраняет только путь к файлу вложений, а не сам файл вложений. Если путь к файлу вложения не существует или файл был удален, он не будет отображаться в журналах.
А после включения хоста, в нижней части превью письма вы можете увидеть «айпишник» с которого было отправление:
Akismet — это служба, которая фильтрует спам в комментариях, обратных ссылках и сообщениях контактной формы на сайтах под управлением WordPress.
Данный плагин это одно из самых надежных решений для защиты от спама для WordPress и WooCommerce.
Akismet проверяет ваши комментарии и отправленные контактные формы по нашей глобальной базе данных спама, чтобы предотвратить публикацию вредоносного контента на вашем сайте. Вы можете просмотреть спам в комментариях, который он улавливает, на экране администратора вашего блога «Комментарии».
Плагин доступен сразу после установки WordPress. Чтобы его задействовать нужно его активировать и пройти регистрацию на официальном сайте, после которой вам будет выдан ключ, который нужно активировать в настройках плагина.
Основные функции Akismet:
Автоматически проверяет все комментарии и блокирует те, что похожи на спам.
Каждый комментарий имеет свою историю статусов, благодаря которой можно легко проверить, какие комментарии были заблокированы или одобрены Akismet, а какие были помечены как спам или не спам модератором.
Адреса ссылок отображаются прямо в теле комментария, чтобы выявить скрытые или вводящие в заблуждение ссылки.
Модераторы могут посмотреть количество одобренных комментариев для каждого пользователя.
Функция сброса, которая блокирует наихудшие спам комментарии, поможет вам сохранить ваше место на диске и ускорить работу сайта.
После активации вам будет предложено получить ключ API Akismet.com, чтобы использовать его. Ключи бесплатны для личных блогов; платные подписки доступны для предприятий и коммерческих сайтов.
Тут нам необходимо выбрать бесплатную подписку (если вы желаете получить продукт бесплатно)
Далее огорчим смайлик, суммой со значением «0» и примем условия для использования сервиса
И наш ключ получен!
Теперь вернемся на наш сайт и задействуем полученный ключ. После его активации служба Akismet активна и готова бороться со спамом. Статистика спама на вашем сайте будет отображаться на специальной странице настроек.
Теперь формы комментариев на сайте защищены сервисом Akismet
В настройках плагина можно отключить вывод этого уведомления. Мы его вывели для проверки.
Если вы используете конструктор форм Contact Form 7 , то рекомендую ознакомиться с информацией, о том, как защитить формы этого плагина при помощи Akismet.
Если Akismet правильно настроен (включая регистрацию, указание API ключа), вы можете использовать служебные слова, для того чтобы убедиться в работе сервиса и в защите ваших форм комментариев и форм обратной связи от спама:
В WordPress существует встроенный механизм самостоятельной регистрации пользователей на сайте, который по умолчанию отключен и на странице форма «входа на сайт» его не обнаружите.
Регистрация на сайте ВКЛ/ВЫКЛ
Как включить регистрацию на сайте в WordPress?
Для этого пройдите в раздел Настройки > Общие и отметьте нужный чекбокс
После этого при входе на сайт, под формой появится одноимённая ссылка Регистрация
Роли пользователей в WordPress
В WordPress заложены несколько видов ролей, которые различаются между собой по назначенным на них возможностям.
То есть — это система управления доступом, которая позволяет определить, какие действия могут выполнять пользователи на вашем сайте WordPress,а какие не могут. Каждая роль имеет свои особенности и ограничения, которые помогают обеспечить безопасность и эффективность при совместной работе на сайте.
Стандартная установка WordPress включает несколько предопределенных ролей:
Администратор (administrator): это основная роль, которая имеет полный доступ ко всем функциям и настройкам сайта. Администратор может управлять другими пользователями, устанавливать и настраивать плагины и темы, редактировать контент и т.д.
Редактор (editor): редакторы могут создавать, редактировать и публиковать контент на сайте. Они также имеют возможность управлять контентом, созданным другими пользователями, но не могут изменять настройки сайта или устанавливать плагины.
Автор (author): авторы могут создавать и редактировать свой собственный контент, но не имеют доступа к контенту других авторов или возможности управлять настройками сайта.
Участник (contributor): участники могут оставлять комментарии на сайте, но не имеют возможности создавать или редактировать контент.
Подписчик (subscriber): подписчики могут только просматривать контент и подписываться на обновления.
После установки WordPress автоматически создается учетная запись администратора.
Как установить роль при регистрации новых пользователей?
Роль по умолчанию для новых пользователей назначается с минимальными возможностями, по сути их даже нет. Эта роль называется — Подписчик и может быть изменена в разделе Настройки > Общие
Внимание! Будьте внимательны при включении Регистрации. Убедитесь какая роль будет присваиваться при регистрации нового пользователя. Неверно указанная роль может обернуться катастрофой на вашем сайте.
Подробнее о возможностях и ролях можно узнать тут или тут.
Чтобы выборочно изменить текст, например, некоторых слов, необходимо выделить нужное их количество и в разделе дополнительных возможностей, доступ к которым мы получаем по клику на эту стрелку (действие на рисунке №2) выбрать Выделение, а затем указать цвет из заготовок или произвольно
В результате получаем:
Чтобы изменить текст всего абзаца, необходимо выделить нужный блок и справа перейти к его настройкам, где аналогично выбрать цвет для всего блока абзаца. Учтите, что окрашенные ранее в другой цвет слова останутся по прежнему красными.
Помимо заготовок цветов, которые могут поставляться с шаблоном оформления, мы можем указать и произвольный цвет при помощи цветового круга или точного значения в шестнадцатеричной системе
