Wp content uploads что это

WordPress для параноиков, часть 1

Итак, если вы счастливый владелец 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 (об этом тоже ниже)

Что же нам нужно? Нам нужно ограничить доступ к 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, что означает доступ закрыт.

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

Тогда 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 для сервера статики будет рассмотрена ниже.

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

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

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

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

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

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

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

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

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

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

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

После 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, то будем готовится к будущим багам.

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

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

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

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

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

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

Где WordPress хранит изображения на вашем сайте

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

Как WordPress хранит изображения?

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

По-умолчанию, WordPress хранит все ваши изображения и медиазагрузки в папке /wp-content/uploads/ на сервере. Все загрузки организованы в папках год/месяц в зависимости от даты загрузки.

Например, все ваши медиафайлы, загруженные в июле 2016 будут сохранены в:

Эти папки вы сможете увидеть, если подключитесь к своему сайту WordPress с помощью FTP клиента.

WordPress также добавляет информацию о загрузке изображения в базу данных. Информация о загрузках хранится в БД в виде определенного типа записи — вложения (attachment) в таблице posts.

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

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

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

Также, если вы удалите отсылки на ваши изображения и медиафайлы из базы данных, то WordPress перестанет отображать их в Библиотеке медиафайлов. Даже если если ваши картинки останутся лежать на сервере.

Изменяем способ хранения изображений в WordPress

По-умолчанию, WordPress не позволяет вам изменять местоположение для загрузок из административной панели. Единственное изменение, которое вы можете сделать, это отключить сортировку загрузок по месяцу и году, на странице Настройки » Медиафайлы.

Просто снимите галочку рядом с опцией ‘Помещать загруженные мной файлы в папки по месяцу и году’ и сохраните изменения. С этого момента WordPress начнет сохранять ваши файлы просто в папку wp-content/uploads/ .

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

Организация ваших изображений в WordPress

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

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

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

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

По всем вопросам и отзывам просьба писать в комментарии ниже.

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

Папка WordPress wp-content – что в ней хранится и, как она используется CMS

Папка WordPress wp-content, как понятно из её названия, хранит в себе элементы контента. В ней нет всех страниц и записей, которые есть на сайте (они сохраняются в базе данных), но в этой папке присутствует другой контент.

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

languages

Итак, открываем корневую папку сайта и в ней переходим в папку WordPress wp-content. Первый каталог, который в ней есть, это languages. В нём собраны языковые .mo и .po файлы самой WordPress, а также некоторых плагинов (другие плагины хранят языковые файлы в своих собственных папках). Обычно пользователи WordPress не вносят редактирования в эту папку.

plugins

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

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

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

themes

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

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

uploads

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

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