Wp content

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

На сегодняшний день WordPress среди систем управления контентом популярнее всего. Его доля составляет 60,4% от общего числа сайтов, использующих CMS-движки. Из них, согласно статистике, 67,3% сайтов базируется на последней версии данного программного обеспечения. Между тем за двенадцать лет существования веб-движка в нем было обнаружено 242 уязвимости различного рода (без учета уязвимостей, найденных в сторонних плагинах и темах). А статистика сторонних дополнений выглядит еще печальней.
к, компания Revisium провела анализ 2350 русифицированных шаблонов для WordPress, взятых из различных источников. В результате они выяснили, что более половины (54%) оказались зараженными веб-шеллами, бэкдорами, blackhat seo («спам») ссылками, а также содержали скрипты с критическими уязвимостями. Поэтому устраивайся поудобней, сейчас мы будем разбираться, как провести аудит сайта на WordPress и устранить найденные недостатки. Использовать будем версию 4.1 (русифицированную).

Первым этапом любого теста обычно бывает сбор информации о цели. И тут очень часто помогает неправильная настройка индексирования сайта, которая позволяет неавторизованным пользователям просматривать содержимое отдельных разделов сайта и, например, получить информацию об установленных плагинах и темах, а также доступ к конфиденциальным данным или резервным копиям баз данных. Чтобы проверить, какие директории видны снаружи, проще всего воспользоваться Гуглом. Достаточно выполнить запрос Google Dorks типа site:example.com intitle:"index of" inurl:/wp-content/. В операторе inurl: можно указать следующие директории:

/wp-content/  /wp-content/languages/plugins  /wp-content/languages/themes  /wp-content/plugins/  /wp-content/themes/  /wp-content/uploads/

Если сможешь просмотреть /wp-content/plugins/, следующий шаг по сбору информации об установленных плагинах и их версиях значительно упрощается. Естественно, запретить индексирование можно с помощью файла robots.txt
. Так как по умолчанию он не включен в установочный пакет WordPress, его необходимо создать самому и закинуть в корневую директорию сайта. Мануалов по созданию и работе с файлом robots.txt довольно много, поэтому оставлю эту тему для самоподготовки. Приведу лишь один из возможных вариантов:

User-Agent: *  Disallow: /cgi-bin  Disallow: /wp-login.php  Disallow: /wp-admin/  Disallow: /wp-includes/  Disallow: /wp-content/  Disallow: /wp-content/plugins/  Disallow: /wp-content/themes/  Disallow: /?author=*  Allow: /

Если в файлах, хранящихся в папке uploads, имеются сведения конфиденциального характера, добавляем к этому списку строчку: Disallow: /wp-content/uploads/.
С другой стороны, в файле robots.txt не рекомендуется размещать ссылки на директории, которые были созданы специально для хранения чувствительной информации. Иначе этим самым ты облегчишь злоумышленнику задачу, так как это первое место, куда обычно все заглядывают в поисках «интересненького».

Еще один важный шаг — идентификация версии CMS. Иначе как подобрать подходящий сплоит? Существует три быстрых способа для определения используемой на сайте версии WordPress:

  1. Найти в исходном коде страницы. Она указана в метатеге generator:
    
    

    или же в тегах <link>:

    
     

  2. Найти в файле readme.html (рис. 1), который входит в состав установочного пакета и находится в корне сайта. Файл может иметь и другие названия типа readme-ja.html.
  3. Найти в файле ru_RU.po (рис. 2), который входит в состав установочного пакета и расположен по адресу /wp-content/languages/:
    "Project-Id-Version: WordPress 4.1.1n"
Рис. 1. Версия WordPress в файле readme.html
Рис. 1. Версия WordPress в файле readme.html
Рис. 2. Подсматриваем версию WordPress в файле ru_RU.po
Рис. 2. Подсматриваем версию WordPress в файле ru_RU.po

Один из вариантов защиты в данном случае — ограничить доступ к файлам readme.html
и ru_RU.po с помощью .htaccess.

Теперь давай соберем информацию об установленных плагинах и темах независимо от того, активированы они или нет. Прежде всего такую информацию можно выудить из исходного кода HTML-страницы, например по JavaScript-ссылкам, из комментариев и ресурсов типа CSS, которые подгружаются на страницу. Это самый простой способ получения информации об установленных компонентах. Например, строчки ниже указывают на используемую тему twentyeleven:

<script src="http://example.com/wp-content/themes/twentyeleven/js/html5.js" type="text/javascript"></script>

Далее, HTTP-заголовки, такие как X-Powered-By, могут указывать на наличие плагина (например, на плагин W3 Total Cache).

Так как информация о плагинах не всегда отображается в исходном коде HTML-страницы, то обнаружить установленные компоненты можно с помощью утилиты WPScan (см. врезку). Только не забывай, что перебор путей плагинов зафиксируется в логах веб-сервера.
Получив данные об установленных компонентах, уже можно приступать к поиску уязвимостей своими силами либо найти общедоступные эксплойты на ресурсах типа rapid7 или exploit-db.

По умолчанию в WordPress каждому пользователю присваивается уникальный идентификатор, представленный в виде числа: example.com/?author=1
. Перебирая числа, ты и определишь имена пользователей сайта. Учетная запись администратора admin, которая создается в процессе установки WordPress, идет под номером 1, поэтому в качестве защитной меры рекомендуется ее удалить.

Рис. 3. Ошибки при аутентификации пользователя
Рис. 3. Ошибки при аутентификации пользователя

Зная имя пользователя, можно попробовать подобрать пароль к панели администрирования. Форма авторизации WordPress на странице wp-login.php весьма информативна (рис. 3), особенно для злоумышленника: при вводе неправильных данных появляются подсказки о неверном имени пользователя или пароле для конкретного пользователя. Разработчикам известно о данной особенности, но ее решили оставить, так как подобные сообщения удобны для пользователей, которые могли забыть свой логин и/или пароль. Проблему подбора пароля можно решить, используя стойкий пароль, состоящий из двенадцати и более символов и включающий буквы верхнего и нижнего регистра, числа и спецсимволы. Или же, например, при помощи плагина Login LockDown.

xakep.ru

Что делать, если у вас выводится полный текст поста, а вы хотите выводить анонсы со ссылкой «Далее»?

Всё, что нам потребуется сделать, это:

  • Непосредственно перед циклом определить глобальную переменную $more.
  • Затем, уже непосредственно перед функцией the_content() присвоить ей значение 0 (отображать анонсы) или 1 (отображать целиком весь пост):

Пример:

Читайте также описание функции the_title().

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

Как вывести содержимое конкретного поста, зная его ID?

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

Другой способ — функция get_post().

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

Если фильтр the_content в данном случае вам нужен, тогда наш пример изменится следующим образом:

Фильтры

the_content_more_link — позволяет изменить кнопку «Далее»

Как же так, ведь текст кнопки «Далее» можно указать в первом параметре функции the_content()
? Дело в том, что там вы можете указать только текст ссылки, а фильтр the_content_more_link позволяет полностью изменить её HTML код.

В качестве примера добавим к ссылке «Далее» HTML-атрибут target="_blank".

the_content — изменяем содержимое поста перед выводом

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

misha.blog

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

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

Папки

  • 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
  • xmlrpc.txt (об этом тоже ниже)

Это типичный набор для WordPress 4.0.

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

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

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

 location ~* ^/(.htaccess|xmlrpc.php)$ {  return 404; } 

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

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

 location ~* ^/wp-admin/(.*(?<!(.php)))$ {  auth_basic "protected by password";  auth_basic_user_file users/somefile;  root /path/to/site/root;  #еще параметры } 

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


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

 location ~* (/wp-admin/|/wp-cron.php|/wp-config.php|/wp-config-sample.php|/wp-mail.php|/wp-settings.php|/wp-signup.php|/wp-trackback.php|/wp-activate.php|/wp-links-opml.php|/wp-load.php|/wp-comments-post.php|/wp-blog-header.php|/wp-login.php|/wp-includes/.*?.php|/wp-content/.*?.php) {  auth_basic "protected by password";  auth_basic_user_file users/somefile;  root /path/to/site/root;  #еще параметры } 

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

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

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

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

nginx накладывает ряд ограничений:

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

Что же делать?

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

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

 location ~* (/wp-postpass.php) {  if ($args ~ "^action=postpass$") {  set $wppostpass 1;  }  if ($wppostpass ~ 0) {  return 403;  }  #еще параметры } 

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

Для работы такой схемы нам нужен ngx_http_substitutions_filter_module . В конфиге следует прописать

 subs_filter 'https://example.com/wp-login.php?action=postpass' 'https://example.com/wp-postpass.php?action=postpass' gi; 

Тогда 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.

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

Wp content

Без 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.jpgbig_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/

Соответственно для них мы и сделаем новые правила в location и будем использовать nginx c ngx_http_substitutions_filter_module.
Ставить этот модуль не обязательно, можно обойтись одними лишь rewrite’ами, но сам по себе он полезный и через него можно улучшить тот или иной вывод с backend’а.

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

 	subs_filter_types text/html; 	subs_filter_types text/xml; 

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

Затем:

 subs_filter 'https://example.com/wp-content/uploads/' 'https://static.example.com/uploads/' gi; subs_filter 'https://example.com/wp-content/themes/' 'https://static.example.com/themes/' gi; subs_filter 'https://example.com/wp-content/plugins/' 'https://static.example.com/plugins/' gi; subs_filter 'https://example.com/wp-includes/js/' 'https://static.example.com/js/' gi; subs_filter 'https://example.com/wp-includes/css/' 'https://static.example.com/css/' gi; subs_filter 'https://example.com/wp-includes/certificates/' 'https://static.example.com/certificates/' gi; subs_filter 'https://example.com/wp-includes/fonts/' 'https://static.example.com/fonts/' gi; subs_filter 'https://example.com/wp-includes/images/' 'https://static.example.com/images/' gi; 

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

 location ~* ^/wp-content/themes/(.*(?<!(.php)))$ { 	rewrite ^/wp-content/(.*)$ https://static.example.com/$1 permanent; }  location ~* ^/wp-content/plugins/(.*(?<!(.php)))$ { 	rewrite ^/wp-content/(.*)$ https://static.example.com/$1 permanent; }  location ~* ^/wp-content/uploads/(.*(?<!(.php)))$ { 	rewrite ^/wp-content/(.*)$ https://static.example.com/$1 permanent; }  location ~* ^/wp-includes/js/(.*(?<!(.php)))$ { 	rewrite ^/wp-includes/(.*)$ https://static.example.com/$1 permanent; }  location ~* ^/wp-includes/css/(.*(?<!(.php)))$ { 	rewrite ^/wp-includes/(.*)$ https://static.example.com/$1 permanent; } location ~* ^/wp-includes/certificates/(.*(?<!(.php)))$ { 	rewrite ^/wp-includes/(.*)$ https://static.example.com/$1 permanent; } location ~* ^/wp-includes/fonts/(.*(?<!(.php)))$ { 	rewrite ^/wp-includes/(.*)$ https://static.example.com/$1 permanent; } location ~* ^/wp-includes/images/(.*(?<!(.php)))$ { 	rewrite ^/wp-includes/(.*)$ https://static.example.com/$1 permanent; } 

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

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

Затем остается лишь сделать аккаунт на cloudflare (или любом) другой cdn провайдере, который вы собираетесь использовать, прописать их DNS у себя и включить кеширование домена static.example.com, без кеширование example.com, где работает wordpress.

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

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

 allow 127.0.0.1; allow IPv4 сервера; allow IPv6 сервера; allow IP/подсеть серверов CDN; ... allow IP/подсеть серверов CDN; deny all; 

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

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

 root /path/to/site/dummy; 

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

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

 location =/ { 	default_type text/html; 	return 200 "c'est static, c'est simple :P"; } 

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

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

 location ~* ^/uploads/.*(?<!(.php))$ { 	root /path/to/site/root/wp-content; 	autoindex off; 	index index.html; }  location ~* ^/themes/.*(?<!(.php))$ { 	root /path/to/site/root/wp-content; 	autoindex off; 	index index.html; }  location ~* ^/plugins/.*(?<!(.php))$ { 	root /path/to/site/root/wp-content; 	autoindex off; 	index index.html; }  location ~* ^/js/.*(?<!(.php))$ { 	root /path/to/site/root/wp-includes; 	autoindex off; 	index index.html; }  location ~* ^/css/.*(?<!(.php))$ { 	root /path/to/site/root/wp-includes; 	autoindex off; 	index index.html; }  location ~* ^/certificates/.*(?<!(.php))$ { 	root /path/to/site/root/wp-includes; 	autoindex off; 	index index.html; }  location ~* ^/fonts/.*(?<!(.php))$ { 	root /path/to/site/root/wp-includes; 	autoindex off; 	index index.html; }  location ~* ^/images/.*(?<!(.php))$ { 	root /path/to/site/root/wp-includes; 	autoindex off; 	index index.html; } 

При запросе static.example.com/images/pic.png сервер отдаст файл из директории /wp-includes/images/ файл pic.png, но при запросе static.example.com/images/pic.php location прощелкает и в итоге пользователю отдадут файл из dummy/images/pic.php, которого нет и как итог ошибка 404.

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

 limit_rate_after 16m; limit_rate 2m; 

После 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.

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

Тут сразу два случая:

  1. При загрузке медиафайлов они получают ссылку вида example.com/?attachment_id=XX, где XX это id странички для этого медиафайла. Соотвественно перебирая 1, 2, 3… пользователь может выкачать весь контент, причем и ту его часть, которая ему не предназначается;
  2. php так и пестрит болячками. Наверное, тут не столько архитектура языка, сколько скилы программистов и настройки среды, в которое сие творение вертится. Но раз поставили wordpress, то будем готовится к будущим багам.

Для этого пропишем в server {} нашего конфига для nginx код:

 if ($args ~* "(attachment_id|eval|duplicate|base64|substring|preg_replace|create_function)") { 	return 403; } 

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

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

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

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

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

 subs_filter '<a href='https://static.example.com/uploads/(.*?)'>' '<a href='https://static.example.com/uploads/$1' target='_blank'>' gi; subs_filter '<a href="https://static.example.com/uploads/(.*?)">' '<a href="https://static.example.com/uploads/$1" target="_blank">' gi; 

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

Задача: повсюду xmlrpc.php ссылки… надо убрать.

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

 subs_filter 'https://example.com/xmlrpc.php' 'https://example.com/xmlrpc.txt' gi; 

Ну а в xmlrpc.txt можно засунуть пасхалочку.

habr.com

Если вы когда-нибудь работали с WordPress, то наверняка знаете, что такие компоненты как изображения, таблицы стилей, шаблоны и плагины по умолчанию хранятся в папке wp-content. Но известно ли вам, что на самом деле название этой папки можно изменять, и все равно CMS будет работать?

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

Сегодня мы хотим рассказать вам о том, как это реализовать.

Создайте новую папку

В данном примере мы будем переименовывать wp-content в assets. Учтите, что после переименовывания этой папки, любой активный плагин или шаблон будут деактивированы, и даже не будут представлены в консоли, так как WordPress будет пытаться обнаружить их в папке, выставленной по умолчанию, — wp-content.

Изменение конфигурации

Нам нужно внести несколько изменений в wp-config.php, но прежде мы рекомендуем вам создать резервную копию этого файла. Просто на случай, если что-то пойдет не так, — тогда у вас будет возможность восстановить все на исходную позицию.

Для начала, добавьте следующую строку перед require_once(ABSPATH . ‘wp-settings.php’); (обычно она находится в самом низу файла), посредством чего вы сообщите WordPress о том, что значение wp-content изменено на assets.

define ('WP_CONTENT_FOLDERNAME', 'assets');

Затем, ниже добавьте следующую строку, тем самым предоставив WordPress путь до новой папки.

define ('WP_CONTENT_DIR', ABSPATH . WP_CONTENT_FOLDERNAME) ;

После того, как вы добавите вышеприведенную строку, WordPress сможет обнаружить и представить список установленных шаблонов и плагинов.

Но, как вы могли видеть на скриншоте шаблона (смотрите ниже), ссылки пока еще остаются битыми.

Чтобы исправить это, вам нужно добавить эту строку, которая укажет направление до новой папки:

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/');
define('WP_CONTENT_URL', WP_SITEURL . WP_CONTENT_FOLDERNAME);

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

Следует учесть!

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

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

www.coolwebmasters.com

Как добавить свою функцию в файл functions.php?

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

В целях обучения не будем использовать какой-то громоздкий код, а возьмем классический пример “Привет, Мир!”

Вот код функции, которая выводит надпись “Привет, Мир!”:

Теперь мы вставим эту функцию в файл functions.php. Открываем файл functions.php в любимом редакторе кода. Еще раз напомню местоположение файла:

/wp-content/themes/название_шаблона/functions.php

Кстати, возможен такой вариант, что этого файла нет в вашей теме (т.е. в вашей теме вообще не использовались собственные функции). В этом случае просто создайте файл с названием functions.php в папке вашего шаблона /wp-content/themes/название_шаблона/.

Теперь, если ваш файл functions.php пустой, то просто скопируйте и вставьте в него следующий код:

<?php и ?> – открывающий и закрывающий теги языка программирования php, которые указывают, что между ними находится код, написанный на этом языке php.

Если же файл functions.php уже был у вас и там присутствует некоторый код, то вам нужно перейти в самый конец файла (Ctrl+End) и вставить код нашей функции перед закрывающим тегом ?>

Вот посмотрите на скриншоте я оставил фрагмент предыдущего кода, который был в function.php, а ниже – вставленный код нашей функции hello_world().

Добавление функции в functions.php

Сохраняем изменения (Ctrl+S) и теперь мы можем вызывать функцию в нужном нам месте.

Для вызова разместите в нужном месте (например, в футере footer.php) следующий код:

Понятно, что “Привет, Мир!” можно и так написать – без использования функции. В данном случае я её использовал для простоты и удобства восприятия. Теперь, по аналогии, вы сможете размещать код любой функции, примеров которых уже много на просторах Интернета и скоро будет достаточно и на моем блоге.

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

На сегодня – все. Если есть вопросы – спрашивайте.

wordpress-life.ru

На моем сайте уже есть статья, о том — как скрыть версию WordPress, так что эту статью тоже можно отнести к этой тематике.

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

Для этого открываем файл конфигураций — wp-config.php и начинаем искать в нем такую строку:

  require_once(ABSPATH . 'wp-settings.php');  

И перед ней добавляем новую конфигурацию.

  /*меняем название папки wp-content*/  define ( 'WP_CONTENT_FOLDERNAME', 'НОВОЕ ИМЯ ПАПКИ' );  define ( 'WP_CONTENT_DIR', ABSPATH . WP_CONTENT_FOLDERNAME );  define ( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/' );  define ( 'WP_CONTENT_URL', WP_SITEURL . WP_CONTENT_FOLDERNAME );  

Во второй строке указываем новое имя папки НОВОЕ ИМЯ ПАПКИ, после чего нужно таким же именем переименовать папку wp-content.

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


wp-content/themes/tema/images/img.jpg

то теперь, оно будет таким.


новое_имя_папки/themes/tema/images/img.jpg

Такая же ситуация и с плагинами. 95% разработчиков плагинов, делают их так, что проблем не должно быть, но все-же иногда бывает и такое, что плагин не работает. Если имеете навыки, то можно поискать в коде плагина и исправить путь или же использовать его аналог, а от старого отказаться.

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

На этом все, спасибо за внимание. 🙂

gnatkovsky.com.ua

WordPress известен вебмастерам, блоггерам и владельцев веб-ресурсов, как интуитивно понятная платформа на PHP. Но, наверное, в общих чертах многим хотелось бы понимать принцип работы движка WP-сайта и разобраться как работает WordPress.

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

Инфографика: как работает WordPress

Источник: wpbeginner.com

1. Обращение к wp-config.php для загрузки конфигурации

Процесс загрузки начинается с запуска wp-config.php (конфигурационного файла с глобальными переменными и подключением к БД).

2. Загрузка дефолтных констант

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

3. Загружается advanced-cache.php

Файл используется плагинами кэширования.

4. Подгружается wp-content/db.php (если он существует)

Файл необходимый для оптимизации работы BD. Он может повысить производительность сайта за счет уменьшения числа запросов к базе данных.

5. Подключение к серверу баз данных MySQL

CMS произведет выбор БД на сервере MySQL, либо вы увидите ошибку: «Error establishing database connection».

6. Запуск object-cache.php, либо wp-includes/cache.php

WordPress будет искать файл object-cache.php и при отсутствии такового, запустит по умолчанию wp-includes/cache.php.

7. Загрузка файла wp-content/sunrise.php

При наличии сети сайтов, запустится режим Multisite (после обнаружения вордпрессом sunrise.php в папке wp-contetnt).

8. Загрузка локализации

После обращения к библиотеке /l10n.php из wp-includes, вордпресс выполнит локализацию веб-сайта.

9. Запуск мультисайтовых плагинов

В случае мультисайтовой сети, WP запустит Multisite-плагины.

10. Событие «muplugins_loaded»

Срабатывает только для активных сетевых мультисайт-плагинов.

11. Запуск активированных плагинов

Запускаются все активные плагины, указанные в поле active_plugins таблицы wp_options.

12. Загрузка pluggable.php

Активированные вордпресс плагины могут переопределять функции pluggable.php, но если это не так, то платформа обратится к файлу pluggable.php.

13. Срабатывает событие plugins_loaded

Разработчики могут вставлять «plugins_loaded» в код различных хуков и запускать собственные функции после загрузки всех активированных плагинов.

14. Применение правил Rewrite для ЧПУ

Выполняются Rewrite Rules – правила переопределения ссылок в SEO-дружественные и понятные человеку URL (ЧПУ).

15. Инициализируются объекты $wp_query, $wp_rewrite, $wp

На этом этапе WP задействует:

  • $wp_query: Глобальная переменная класса WP_Query сообщает, что контент запрошен в типичном для WP-движка формате
  • $wp_rewrite: Глобальная переменная класса WP_Rewrite. Содержит функции и правила Rewrite Rules, подсказывающие вордпрессу, какой URL соответствует запрашиваемому контенту
  • $wp: Глобальная переменная класса WP. Ее функции автоматически разбирают пользовательские запросы и загружают главную очередь (main query)

16. Запускается функция «setup_theme»

Загружая тему оформления, CMS выполняет предварительные действия.

17. Запуск functions.php дочерней темы

Файл functions.php работает как плагин и его назначение – придавать WP-теме отличительные особенности. Файл запустится, только если активна дочерняя тема, в противном случае загрузится functions.php активной темы.

18. Запуск functions.php родительской темы

Если используется дочерняя тема, на этом шаге WP запустит файл functions родительской темы.

19. Выполненяется «after_setup_theme»

Выполнение функции последует сразу за загрузкой основного шаблона (темы) и ее файла functions.php.

20. Загрузка объекта текущего пользователя User Object

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

21. Выполненяется функция «init»

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

22. Выполненяется функция «widget_init»

Разработчикам widget_init позволяет регистрировать виджеты и выполнять нужный для их функционирования код.

23. Выполнение wp()

Из файла wp-includes/functions.php вызывается функция wp(). Задаются переменные $wp, $wp_query, $wp_the_query и сразу следует вызов $wp->main.

24. Парсинг запроса

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

25. Выполнение запроса

Когда вордпресс не находит соответствующий пользовательскому запросу контент, условный тег is_404 сгенерит страницу ошибки 404. Если контент найден, то продолжится запуск других запросов:

  • WP_Query->get_posts()
  • Функции DO_ACTION_REF_ARRAY ‘pre_get_posts’ для объекта WP_Query
  • apply_filters (фильтр для очистки запросов и пр. завершающих проверок)
  • К извлекаемым из БД постам применяются фильтры posts_results и the_posts

Теперь, когда все запросы выполнены, вордпресс выведет загруженные записи (посты).

26. Запуск функции template_redirect

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

27. Загрузка Feed-шаблона

Для RSS feed запроса, вордпресс загрузит соответствующий шаблон RSS-ленты.

28. Загрузка основной темы (шаблона)

WP приступит к поиску файла темы. Обычно, процесс загрузки шаблона начинается с файла содержащего основной цикл вордпресса.

29. Запуск функции «shutdown»

Закончив исполнять PHP-код WordPress запустит «shutdown». Работа WP-движка выполнена.

В ответ на запрос пользователя, веб-серверу хостинга будет передан сгенерированный вордпрессом HTML код со стилями CSS / скриптами JS, далее последует рендеринг страницы браузером.

Работа WordPress заняла лишь миллисекунды!

seo-design.net

Структура директорий WordPress

Файловая структура WordPress очень проста. У вас есть папка public_html, где находятся как правило три ключевые папки, а так же множество других важных файлов, включая wp-config.php и .htaccess

Чтоб получить доступ к файлам и папкам, вы можете использовать файловый менеджер cPanel от вашего хостинг-сервиса или любой обычный FTP-клиент.

Для этого обзора мы будем использовать самый популярный ftp-клиент — FileZilla. Вот как должна выглядеть папка public_html внутри:

папка public_html

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

# BEGIN WordPress  &lt;IfModule mod_rewrite.c&gt;  RewriteEngine On  RewriteBase /  RewriteRule ^index.php$ - [L]  RewriteCond %{REQUEST_FILENAME} !-f  RewriteCond %{REQUEST_FILENAME} !-d  RewriteRule . /index.php [L]  &lt;/IfModule&gt;  # END WordPress

Затем, есть файл index.php, который по умолчанию представляет вашу домашнюю страницу, если, конечно, он не замещен страницами типа front-page.php или home.php:

index.php

Еще один необходимый файл в этой директории – это wp-config.php. Данный  файл позволяет задать базовую конфигурацию WordPress, включая настройки для базы данных MySQL, секретные ключи, и информацию о префиксе базы данных. Вот как должны выглядеть настройки вашей базы данных:

// ** MySQL settings - You can get this info from your web host ** //  /** The name of the database for WordPress */  define('DB_NAME', 'notarealname');  /** MySQL database username */  define('DB_USER', 'notarealuser');  /** MySQL database password */  define('DB_PASSWORD', 'notarealpassword');  /** MySQL hostname */  define('DB_HOST', 'localhost');

Другие примечательные файлы в этой директории – это wp-activate.php, и wp-signup.php, которые все вместе отвечают за регистрацию, авторизацию и процесс подтверждения пользовательской регистрации. Файл wp-comments-post.php отвечает за функцию комментирования и предотвращение дупликации контента, в то время как wp-settings.php отвечает за установку некоторых WordPress-переменных.

Папка wp-admin

Папка wp-admin

Как понятно из названия папки, здесь лежит инструментарий админа. Например, admin.php (сердце данной папки) позволяет вам связать инсталляцию с базой данных, отображает панель управления WordPress и предлагает прочие ключевые функции, такие как, например, проверка того, является ли данный пользователь администратором. Если пользователь является админом, то включается использование файла wp-load.php, который в свою очередь загружает файл  wp-config.php:

/**     * In WordPress Administration Screens  *  * @since 2.3.2  */  if ( ! defined( 'WP_ADMIN' ) ) {  define( 'WP_ADMIN', true );  }     if ( ! defined('WP_NETWORK_ADMIN') )  define('WP_NETWORK_ADMIN', false);  if ( ! defined('WP_USER_ADMIN') )  define('WP_USER_ADMIN', false);  if ( ! WP_NETWORK_ADMIN &amp;&amp; ! WP_USER_ADMIN ) {  define('WP_BLOG_ADMIN', true);  }     if ( isset($_GET['import']) &amp;&amp; !defined('WP_LOAD_IMPORTERS') )  define('WP_LOAD_IMPORTERS', true);  require_once(dirname(dirname(__FILE__)) . '/wp-load.php');

Если вы обратите внимание на названия данных файлов, то  поймете, что большинство из них говорят пользователю о выполняемых ими функциях, которые вам знакомы по админке WordPress. Например, profile.php выводит экран администрирования пользовательского профиля,  theme-install.php контролирует панель установки тем, а plugin-install.php делает тоже самое для  панели установки плагинов.

Что касается других важных папок внутри wp-admin, то  images заполнены картинками, которые используются в административной панели WordPress, css и js – это «дома» для CSS-кода и JavaScript-скриптов, а network включает PHP-файлы, необходимые для работы мультисайтовости WordPress

Папка wp-content

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

Папка wp-content

Папка Plugins

Папка Plugins

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

папка популярного плагина Akismet

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

Папка Themes

Папка Themes

Так же, как и в случае с плагинами, каждая тема имеет собственные подпапки. Если мы откроем папку с любой темой, то увидим там множество PHP-файлов, которые все вместе создают внешний вид и структуру вашей темы. Возьмем знаменитую тему Divi от Elegant Themes в качестве примера, в главной папке которой мы найдем файлы 404.php, a functions.php, a sidebar.php, и style.css, среди остальных. Divi также имеет отдельные папки для css, картинок и js темы, что весьма стандартно для большинства качественных тем. Но, как бы то ни было, некоторые другие папки достаточно уникальны, к примеру, epanel и et-pagebuilder:

Divi также имеет отдельные папки для css, картинок и js темы

Папка wp-includes

Папка wp-includes

Еще одна папка – это wp-includes, и она довольно большая. wp-includes содержит все те файлы, которые не вошли в описанные ранее папки. Условно говоря, именно благодаря этой папке сайт работает как часы.

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

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

/**  * Convert given date string into a different format.  *  * $format should be either a PHP date format string, e.g. 'U' for a Unix  * timestamp, or 'G' for a Unix timestamp assuming that $date is GMT.  *  * If $translate is true then the given date and format string will  * be passed to date_i18n() for translation.  *  * @since 0.71  *  * @param string $format Format of the date to return.  * @param string $date Date string to convert.  * @param bool $translate Whether the return date should be translated. Default true.  * @return string|int|bool Formatted date string or Unix timestamp. False if $date is empty.  */     function mysql2date( $format, $date, $translate = true ) {  if ( empty( $date ) )  return false;     if ( 'G' == $format )  return strtotime( $date . ' +0000' );     $i = strtotime( $date );  if ( 'U' == $format )  return $i;     if ( $translate )  return date_i18n( $format, $i );  else  return date( $format, $i );  }

Другие ключевые файлы – это cache.php (управляет процессом добавления и удаления данных из кеша, а также за отвечает за его закрытие или перезапуск), links.php (функциональность, которая отвечает за ссылки WordPress) и version.php (отвечает за версию WordPress).

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

 

wpnice.ru


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Adblock
detector