Wp activate php что за файл

Обновлено: 06.07.2024

Это серия статей об особенностях установки и работы WordPress на Nginx.

Задача:

Имеется сайт, который, при 300 хостов в сутки, пожирает 6Гб оперативной памяти и средняя нагрузка 0.5, с учетом того, что сервер Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz 1600.000 Mhz X 4

В ближайшее время планируется увеличение посещаемости, а значит, что требуется оптимизация!

Что имеем:

VDS (Виртуализация: OpenVZ, Процессор: 1 ядро, Память: 512 Мб, Диск: 30 Гб)
Желание оптимизации и ускорения сайта, а так же уменьшение затрат
Повышение защиты сервера
ПО:
- ОС Debian
- Nginx
- Mysql

Решение:

Сначала разберемся из чего же состоит WordPress, какие файлы и папки имеет.

На момент написания статьи актуальной версией был WordPress 4.1.1

Когда мы распаковываем архив, то видим следующую картину:

Папки

wp-admin
wp-content
wp-includes

Файлы php

wp-activate.php
wp-blog-header.php
wp-comments-post.php
wp-config.php
wp-config-sample.php
wp-cron.php
wp-links-opml.php
wp-load.php
wp-login.php
wp-mail.php
wp-postpass.php
wp-settings.php
wp-signup.php
wp-trackback.php
xmlrpc.php

Давайте разберемся за что отвечает каждый из файлов.

/wp-activate.php — страница активации

/wp-login.php — авторизация пользователей

/wp-login.php?action=register — регистрация пользователей

/wp-login.php?action=lostpassword — сброс пароля пользователя

/wp-blog-header.php — В этом файле распарсивается и распознается запрос . Выбираются записи из базы по необходимости и формируется необходимая страница к выводу на основе активной темы. В том числе в этом файле подключается файл с настройками wordpress wp-config.php .

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

Итак, если вы счастливый владелец nginx, знатный параноик и за каким-то чертом решили поставить wordpress, то… Первое, что пришло в голову — это «надо ограничить сему творению свободу!».

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

Папки

Файлы php

wp-activate.php
wp-blog-header.php
wp-comments-post.php
wp-config.php
wp-config-sample.php
wp-cron.php
wp-links-opml.php
wp-load.php
wp-login.php
wp-mail.php
wp-postpass.php (об этом ниже)
wp-settings.php
wp-signup.php
wp-trackback.php
xmlrpc.php
xmlrpc.txt (об этом тоже ниже)

Что же нам нужно? Нам нужно ограничить доступ к php файлам и админке, вынести статику, закрыть xmlrpc.

Ограничиваем доступ в админку и к php файлам

В моем варианте wordpress я не сохраняю комментарии пользователей и не использую xmlrpc. Как безопасно дать доступ на комментарии, как и ряд других насущных вопросов по nginx и wordpress будет расмотрен во второй части этой статьи, которая, естественно, будет создана при наличии оных. Так как тут нет apache, то файл .htaccess бесполезен.
Следовательно, закрываем указанные выше свистоперделки:

После этого при запросах xmlrpc.php и .htaccess у нас будет 404 ошибка. Хотя можно выдать и 403 и 200 «trololo», но это уже дело вкуса.

Далее ограничиваем доступ к оставшимся. Под ограничением я имею в виду запрос авторизации, а именно auth_basic.

*данный код заставит nginx запрашивать авторизацию при запросе статики из /wp-admin/, статику выдает nginx.

Далее ограничиваем доступ к файлам:

Запись вида /wp-includes/.*?\.php включает в себя все php файлы в wp-includes и ниже.

Готово, доступ мы закрыли. Теперь будем выборочно включать нужные нам элементы для паблик версии, а это дальше по тексту.

Включаем защищенные записи в нашем защищенном Wordpress

Так как мы закрыли wp-login.php авторизацией, то, написав защищенный пост и скинув ссылку и пароль (от поста) нужному пользователю, пользователь… испугается неведанного окна. Так как пароль передается файлу wp-login.php как post запрос с GET параметрами ?action=postpass.

в location от nginx мы не можем описать параметры запроса;
в if выражении нельзя использовать auth_basic;
игра с переменной в конфиге, которое передается 1 в случае удачной авторизации ничего не принесет, так как переменная живет только в текущем запросе.

Решение есть! Создать символическую ссылку на wp-login.php в той же папке. У меня это wp-postpass.php. Символическая ссылка нужна для того, что если мы обновим wordpress, то wp-login.php тоже обновится и обновится файл по ссылке… Вот за что я люблю linux.

Следом в конфиге nginx прописываем:

В таком случае при запросе /wp-postpass.php?action=postpass переменная wppostpass примет значение 1, и location отработает до конца. В случае голого запроса wp-postpass.php или с другими параметрами (как видит тут проверяется от начала ^ до конца$ строки) будет ошибка 403, что означает доступ закрыт.

Тогда nginx автоматом изменит ссылку wp-login.php?action-postpass на wp-postpass.php?action-postpass, и пользователь сможет авторизоватся паролем для просмотра защищенной записи.

Выносим статику на отдельный сервер и подключаем CDN

В нагрузке js, css и мелкие gif'ки роли не играют, так как при наличии памяти nginx хранит их в своем кеше, а при наличии достаточного количества памяти всю статику сайта можно вынести на tmpfs раздел (3.8 Гб чтение-запись и 745к iops'ов к примеру).

Но в случае одного сервера кто-то получит файл раньше, кто-то позже, и если у нас много клиентов, то при раздаче 1000 файлов по 1Мб канал нехило просядет, если не вводить rate.

Вот для этих случаев и придуманы кеширующие CDN провайдеры. Для примера — cloudflare.

Принцип работа замечательно проиллюстрирован на их картинке:

Без CDN все запросы идут на конечный сайт, а с CDN запросы идут на CDN провайдера, который выступает как промежуточное звено. И в этом случае если 1000 пользователей запросят файл размеров 1 Мб, то этот файл будет запрошен CDN провайдером 1 раз для своего кеша, и затем раздан той 1000 пользователей. Варианты DDoS'а в стиле à la google docs, когда запросили big_photo.jpg?ver=1, затем big_photo.jpg?ver=2, и т.д. не сработает, если выбран режим умеренного кеширования (у cloudflare он есть) и кеширование только статики, то при запросе big_photo.jpg, big_photo.jpg?ver=1 или big_photo.jpg?ver=123 с сервера запрашивается big_photo.jpg и затем раздается он и только он, даже если клиент запрашивает файл с аргументами (они просто игнорируются). Это решает проблему ддоса cdn провайдером, который по сути должен и от ддоса защищать.

/wp-content/uploads/
/wp-content/themes/
/wp-content/plugins/
/wp-includes/js/
/wp-includes/css/
/wp-includes/certificates/
/wp-includes/fonts/
/wp-includes/images/

В конфиг добавляем:

Чтобы фильтровать вывод html и xml документов.

Тем самым ссылки в html и xml будут переписаны. Теперь осталось сделать так, чтобы конечный пользователь, зная оригинальную ссылку, не абузил сервер, а был направлен на CDN.

В итоге, при запросе любого php файла ничего не будет. А при запросе статики (все что не php в случае с WP, что логично) пользователь будет перенаправлен на сервер статики.

Настройка профиля nginx для сервера статики будет рассмотрена ниже.

Настройка сервера статики

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

Требуется разрешить доступ локалхосту, доступ самому серверу с внешнего IP (например какой скрипт) и серверам CDN провайдера. Например, подсети CloudFlare можно найти вот по этой ссылке. И, конечно же, закрыть доступ всем остальным. Так как если CDN внезапно решит пустить траффик на прямую… оставить свободный канал.

Так же надо сделать dummy директорию как root для всего сервера статики.

Чтобы запросы, которые пришли на сервер статики на location / или =/ и которые не соответствуют прописанным там location пошли в ту самую dummy директорию. Эта директория прописывается внутри server<>.

Далее location приветствие:

Это текст, который увидит пользователь, запросивший корень. Писать можно что угодно, главное при использовании внутри " экранировать кавычки как \".

Затем следует прописать location'ы на статику:

Еще надо добавить рейты на скорость.

После 16 мегабайт скорость уменьшается до 2 Мб в секунду на поток. Это чтобы CDN при кешировании огромного файла не забил весь канал.

В случае с cloudflare максимальный размер файла (на момент написания этого материала) составляет 512 мегабайт, а поддерживаемые форматы на бесплатном тарифном плане включают: css, js, jpg, jpeg, gif, ico, png, bmp, pict, csv, doc, pdf, pls, ppt, tif, tiff, eps, ejs, swf, midi, mid, ttf, eot, woff, otf, svg, svgz, webp, docx, xlsx, xls, pptx, ps, class, jar.

Фильтрация запросов

Тогда если в аргументах запроса встретятся attachment_id, eval, duplicate, base64, substring, preg_replace, create_function nginx вернет ошибку 403, причем запрос не будет передан на динамику для исполнения потенциальной уязвимости.

Плюшки через subs_filter от nginx

Предназначение этого модуля было рассмотрено здесь.

Задача: wordpress по умолчанию открывает ссылки на медиафайл в текущем окне. А нужно, чтобы в новом.

Решение: добавить небольшой код в когфиг nginx.

После этого к ссылкам на медиафайлы средствами frontend'a будет добавлен target="_blank".

Каждый веб-разработчик регулярно сталкивается с задачей миграции. Сюда входят и развёртывание (deploy) локальной версии на удалённом сервере, и перенос работающего сайта с одного сервера на другой. Некоторые печатные издания для программистов называются «Cookbook» – что буквально значит «книга рецептов». Рецептов множество, какой из них лучший — дело вкуса. В этом материале автор расскажет о том, какую технологию переноса типичного сайта на WordPress он считает оптимальной, и почему.

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

Резервное копирование данных

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

В чём главная цель разработчика при переносе сайта с одного сервера на другой? Ничего не потерять. То есть на новом месте сайт должен быть полностью идентичен тому же сайту на старом.

Перво-наперво, вы должны убедиться в том, что после создания резервной копии сайта на нём не будут производиться какие-либо изменения.

Самый простой путь — обратиться ко всем редакторам сайта с просьбой не вносить изменения в содержимое сайта на время переноса (допустим, на ближайшие полчаса). Если, например, вы ведёте блог на WordPress, то договариваться с кем-либо нет необходимости.

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

Режим обслуживания

Вы могли заметить, что когда WordPress обновляет плагины или ядро системы, посетители сайта видят вместо его содержимого белый фон и поверх большой заголовок «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту.».

Как принудительно перевести в него сайт?

Для этого необходимо в корне сайта создать файл под названием .maintenance и разместить в нём следующий PHP-код:

Результат:

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

Однако, если вы хотите сделать страницу более привлекательной, можете создать в папке wp-content файл maintenance.php , который будет загружаться вместо исходного текста. В нём вы можете сверстать какую угодно картинку для поджидающего окончания работ пользователя.

Также можно порекомендовать специальный плагин, которые можно использовать в тех же целях:

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

Резервная копия базы данных

При помощи плагинов WP-DB-Backup, WP Database Backup и прочих.
При помощи браузерной утилиты phpMyAdmin
При помощи консоли сервера
При помощи панели хостинга

Если у вас есть доступ к консоли сервера, и вы умеете пользоваться терминалом — это заметно ускорит работу.

Прежде всего потому, что создании резервной копии выполняется одной единственной командой:

По-хорошему будет заархивировать дамп базы на ходу:

Текстовые файлы, коим является дамп базы, архивируются наилучшим образом. Размер архива может быть значительно ниже размера дампа базы. Это важно при переносе, т.к. 100Мб перенести куда быстрее, чем 1Гб, например.

Некоторые хостинг-компании предоставляют возможность архивирования данных сайта через панель управления услугами:

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

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

Резервная копия файлов

Файловая система WordPress обычно выглядит следующим образом (без поддиректорий и их содержимого):

В принципе, больше всего нас интересуют папка wp-content и конфигурационный файл wp-config.php .

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

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

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

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

Используя для переноса архив, вы перемещаете всего 1 файл. Да, он много больше размером, но за счёт того, что требуется всего лишь одно соединение с сервером, перенос совершается быстрее. При текущих скоростях доступа к сети Интернет разница во времени может составлять десятки, сотни раз.

Настоятельно рекомендую для транспортировки большого скопления мелких файлов использовать архив в роли контейнера.

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

Восстановление данных

Итак, архив файлов сайта и дамп базы данных перенесены на новый сервер.

Воссоздание файловой структуры

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

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

Распаковывать архив необходимо там же, где он был создан.

Например, если вы сжимали сайт при помощи консольного архиватора из корня сайта zip -r "full-backup.zip" * , то и распаковывать на новом сервере его необходимо также в корне сайта unzip full-backup.zip .

Обратите внимание, что невидимые файлы, коим является .htaccess не всегда архивируются вместе с остальными. Поэтому, если на вашем новом сайте не работают «красивые адреса», первым делом проверьте, перенесли ли вы .htaccess в корень сайта.

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

Воссоздание базы данных

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

Через веб-интерфейс при помощи утилиты phpMyAdmin
Через панель управления хостингом
Через консоль сервера следующей командой:

Имя базы данных
Имя пользователя
Пароль

Используя эти данные мы должны импортировать наш дамп базы данных.

Опять-таки, сделать это мы можем теми же средствами.

В phpMyAdmin выбираем базу данных, вкладку «Импорт», выбираем файл дампа и отправляем форму запроса.

Если вы работаете через консоль, используйте команду mysql -u[имя_пользователя] -p[пароль] [имя_базы_данных] < [дамп_базы_данных].sql .

В случае, если дамп базы данных был заархивинован: gunzip < [дамп_базы_данных].sql.gz |mysql -u[имя_пользователя] -p[пароль] [имя_базы_данных] .

Не забудьте удалить дамп базы данных с сервера или перенести его в безопасное место, в случае, если он там был.

Настройка файла конфигурации

Теперь необходимо открыть в редакторе файл wp-config.php и установить соответствующие настройки для соединения с новой базой данных:

Не забудьте удалить файл .maintenance из корневой папки сайта.

Остаётся только проверить работоспособность сайта!

Заключение

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

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

Создаем собственную страницу регистрации для мультисайта взамен стандартной wp-signup.php .

В обычной установке WordPress страницу регистрации (авторизации, сброса пароля) выводит файл wp-login.php .

/wp-login.php — авторизация
/wp-login.php?action=register — регистрация
/wp-login.php?action=lostpassword — сброс пароля

Для мультисайта в wp-login.php есть отдельные условия. Так, при переходе по ссылке /wp-login.php?action=register на мультисайте, WordPress сделает редирект на страницу /wp-signup.php . Во многих темах страница выглядит не очень привлекательно, поэтому мы сделаем свою собственную.

Файл wp-signup.php в теме Селена. Как и во многих других темах выглядит не очень опрятно.

Основной сайт сети

По умолчанию, WordPress открывает страницу регистрации ( wp-signup.php ) на основном домене (сайте) сети. Тем не менее, можно сделать отдельную страницу регистрации для каждого сайта сети, даже если у них разные темы. Мы будем рассматривать случай, когда на всех сайтах сети есть своя собственная страница регистрации, но используется одинаковая тема и сайты различаются лишь языком. Если используются разные темы, потребуется написать больше кода.

functions.php?

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

Лирическое отступление

Стоит отметить, что MU-плагины загружаются раньше обычных плагинов и до полной загрузки ядра WordPress, поэтому вызов некоторых функций может привести к фатальным ошибкам в PHP. Подобная «ранняя» загрузка имеет и свои плюсы. Скажем внутри любой темы нельзя цепляться к некоторым экшенам, которые срабатывают еще до загрузки файла functions.php из темы. Примером этого могут служить экшены из плагина Jetpack вида jetpack_module_loaded_related-posts ( related-posts — название модуля) с помощью которых возможно отслеживать активность модулей в Jetpack. К этому экшену невозможно «прицепиться» из файла темы, потому что экшен уже сработал до загрузки темы — плагины загружаются раньше тем. Взглянуть на общую картинку порядка загрузки WordPress можно на странице Action Reference в кодексе.

Порядок в файлах

MU-плагины могут содержать любое количество файлов и любую стуктуру, которая покажется вам логичной. Я придерживаюсь примерно такой иерархии:

В файле load.php подключаются все необходимые «плагины» для нашей сети:

Внутри папки selena-network хранятся папки плагинов, в каждой есть свой plugin.php , которые мы и подключаем в load.php . Это дает гибкость и возможность быстро отключать и включать некоторые вещи.

Адрес страницы регистрации

Чтобы указать адрес страницы регистрации, используется фильтр wp_signup_location . Его можно найти внутри файла wp-login.php и именно он отвечает за редирект на wp-signup.php .

Добавим свою функцию в mu-plugins/selena-network/signup/plugin.php , которая будет отдавать адрес страницы регистрации на текущем сайте:

selena_network — префикс, который я использую в именах всех функций внутри MU-плагинов на своем сайте для избежания коллизий, его следует заменить на свой собственный уникальный префикс. Приоритет добавления фильтра 99, потому что некоторые плагины, например bbPress и BuddyPress могут перезаписать этот адрес на свой собственный (MU-плагины загружаются раньше, чем обычные плагины, см. выше). Обратите внимание, что используется home_url() , вместо network_site_url() , чтобы оставить посетителя на том же домене. В качестве адреса можно использовать любой URL.

Создание страницы

Внутри нового шаблона необходимо выполнить вызов функции selena_network_signup_main() , которая будет выводить форму регистрации.

Стоит заметить, что весь процесс с шаблонами не обязателен и вместо этого можно создать свой шорткод, который будет также вызывать функцию selena_network_signup_main() .

wp-signup.php и wp-activate.php

Теперь займемся созданием функции, которая будет выводить форму регистрации. Для этого скопируем файлы wp-signup.php и wp-activate.php из корня WordPress в mu-plugings/selena-network/signup/ (и не забываем их подключить внутри mu-plugins/selena-network/signup/plugin.php ). Дальнейшие манипуляции с файлами крайне сложно и долго описывать, поэтому прийдется сделать их самостоятельно. Я лишь опишу что именно надо сделать и опубликую исходные файлы своего проекта:

В начале файла удалить все require , вызов функций и прочий код вне функций.
Переименовать все функции, добавив к именам уникальные префиксы.
Нижнюю часть кода wp-signup.php обернуть в функцию selena_network_signup_main и в ее самом начале написать global $active_signup; .
Заменить верстку на свою собственную в нужных местах.

Внутри wp-activate.php необходимо сделать примерно тоже самое:

Удалить весь код вне функций, обернуть верстку в отдельную функцию.
Изменить верстку в местах, где это необходимо.

Файл wp-activate.php отвечает за страницу активации аккаунта. Как и со страницей регистрации для нее необходимо создать отдельный шаблон, внутри которого вызывать функцию из файла wp-activate.php .

Отправляем письма активации

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

Заключение

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

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

Бонус. Защита от спамеров

Даже самые маленькие сайты на WordPress часто подвергаются налету спам-регистраций. Можно писать бесконечные условия для фильтрации ботов, зачастую больше похожие на попытку создать искусственный интеллект 🙂 В случае мультисайта мне очень помог обычный редирект в Apache, с помощью которого при открытии /wp-signup.php и /wp-acitvate.php я попросил выдавать 404 (я не эксперт по настройке Apache, поэтому мои правила могут быть не очень правильными).

P. S. Я стараюсь максимально детально описывать некоторые сторонние вещи, потому что когда начинал я, порой некому было подсказать и объяснить многие вещи. Также я считаю, что подобные небольшие наводки на другие материалы кого-нибудь подтолкнут к изучению чего-то нового и расширению своей области знаний. В записях RewriteRule используются регулярные выражения, они совсем не сложные, например, символ ^ означает начало строки.

Читайте также: