Мы обычно не комментируем к таким записям. Если вам нужны фишечки и няшечки вроде MVC, MVP, ORM и прочие аббревиатуры, методологии и стили жизни, то вряд ли вам подойдет WordPress.
Спасибо! Да, я понимаю, но если вы позволяете пользователям выбрать старую версию, то пусть она лучше будет не уязвимой. То, что у вас есть 4.0.1 это здорово, многие хостинг-провайдеры до сих пор что-то вроде 3.5 ставят через древний Softaculous.
Ну да, только я думал, что за $29 у меня будет, цитирую: «Production ready» и «Pre-configured security», а не то, что мне еще нужно будет что-то до-устанавливать и обновлять.
> Хм… А Вы часто читаете _в панелях_управления_, кто производитель софта?
Классный сервис! На странице WordPress у вас в поле Manufacturer указана коммерческая компания Automattic, а должен быть некоммерческий фонд WordPress Foundation. А среди доступных версий у вас 3.9.1 которая является уязвимой. 3.9.2 вышла в августе, и 3.9.3 вместе с 4.0.1 в ноябре.
Базовая версия WordPress не использует AJAX на лицевой странице сайта, тем более анонимный. А вот многие темы и плагины используют, это события wp_ajax_* и wp_ajax_nopriv_* (для анонимных запросов). Если вы собираетесь читать и редактировать код плагинов и ядра, пытаться где-то изменить admin-ajax.php на другой файл, то желаю вам удачи, особенно с обновлениями.
Наиболее правильным решением будет открыть доступ к admin-ajax.php и admin-post.php (был еще какой-то файл связанный с TinyMCE на лице, вроде wp-mce-help.php).
Вообще если честно, то блокировка админки WordPress базовой аутентификацией это глупость. Куда надежнее использовать двух факторную аутентификацию, fail2ban или подобные утилиты, HTTPS и конечно же надежные пароли.
Также стоит отметить, что блокировка/удаление/переименование xmlrpc.php это тоже глупость, особенно когда вы попытаетесь воспользоваться внешними инструментами для работы с сайтом, включая официальные мобильные приложения.
Если вы закрываете wp-admin базовой аутентификацией то у вас перестанет работать AJAX, т.к. весь AJAX (включая анонимный) в WordPress работает через файл wp-admin/admin-ajax.php, есть также некоторые вещи, которые работают через wp-admin/admin-post.php.
Если быть точнее, то не около 30%, а 47%. И да, более 50% сайтов остаются потенциально уязвимыми. Из них большая часть скрываются за добросовестными хостинг-провайдерами, которые фильтруют уязвимость на уровне веб-сервера, так что на практике цифра гораздо меньше 84%, которая у вас указано в заголовке.
Все правильно, глобальные перменные и прочий багаж вызван хорошей обратной совместимостью, что очень сложно сказать про многие другие CMS, которые принято переписывать с каждым крупным релизом, а WordPress уже 11 лет. Тем не менее в ядре иногда наблюдаются приятные изменения существующего кода, делая его чище, красивее, функциональнее и быстрее, при этом не ломая обратную совместимость. Хорошие примеры класс WP_Theme, класс WP_Post и некоторые другие.
Тем не менее, у человека пришедшего из мира ООП, MVC, ORM и прочих модных аббревиатур, все равно возникает некий ужас при работе с WordPress: функции, фильтры, события,… но поймите — это одна из причин того, что с WordPress легко справиться даже начинающего разработчику без особых знаний PHP. Как-то раз Мэтт Мулленвег спросил на конференции разработчиков сколько из присутствующих научились программированию на PHP благодаря WordPress. Руки подняли больше половины зала.
Система Ghost — хороший пример, который доказал что именно эта простота является неотъемлемой частью WordPress. Это некий упрощенный аналог WordPress, написанный на Node.js, и теперь он славится лишь своей 45-минутной установкой, а WordPress в это время занимает более 60% доли рынка CMS и активно растет.
Но в легкости WordPress скрывается и его сложность — да, наклепать сайтик за выходные сможет каждый с помощью WordPress, но вот внутреннее строение, архитектуру, и огромное количество нюансов знают немногие. Начиная от элементарных, как например работа с внешними ресурсами с помощью класса WP_Http и функций wp_remote_*(), заканчивая чем-нибудь супер-специфическим, как например аргумент split_the_query в запросах с помощью WP_Query.
А когда с этим всем начинаешь глубоко разбираться, становится интереснее, и с каждым днем понимаешь, что WordPress знаешь все меньше и меньше.
Ну конечно каждому свое. Например мой любимый язык Python, а с WordPress работаю уже более 6-ти лет :)
Почему-то все источники делают видео-превью встраивания oEmbed, а вот новое поведение скролла в редакторе отображают картинкой. Но его ведь просто невозможно понять с помощью картинки, а «фича» на мой взгляд одна из самых лучших в 4.0. Вот короткий видео-ролик прокрутки:
Очень удобно для работы с длинными статьями. Ну и официальный видео-релиз 4.0 для тех, кто еще не нашел:
> Если будете оверселить ресурсы, то всё будет жутко тормозить и лагать, т.е. клиенты такого размера как вы описываете, просто свалят.
Здесь речь идет не о шаред-хостинге :) WordPress.com это сервис на основе WordPress мультисайт, который развернут на более тысячи серверов в 6 дата-центрах на 3-х континентах. БД шардится на более 600 серверов MySQL, на каждый из которых приходится в среднем по ~ 400 запросов в секунду. Можете представить какой у нас объем.
Это конечно самый крупный публичный проект на WordPress, поэтому его можно назвать крайним случаем, и здесь вполне оправдан выбор MyISAM, несмотря на то, что InnoDB был бы эффективнее.
Тем не менее, возьмите типичный американский университет, где студентам и преподавателям предоставляется возможность создать сайт и вести свой блог. Такого объема как у WordPress.com у них в сети никогда не будет, но поверьте, 100 ГБ они быстро наберут, особенно если добавить элементы соц. сети, например с помощью BuddyPress.
В общем я не говорю, что нужно использовать MyISAM. Все знают, что у InnoDB будущее куда светлее, чем даже у MariaDB. Но тот факт, что InnoDB потребляет в несколько раз больше места на диске, лучше все-таки держать в голове.
> Я бы, честно, пошел в сторону уменьшения размера БД
Вот мы и пошли в сторону MyISAM :)
> поставил бы рейд из SAS-дисков или даже SATA в несколько Тб. Всё равно ведь используются реплики.
Так репликам ж тоже с дисков читать надо.
> не увидел там причины того, что базы под WP должны занимать 100G+. :((
Суть в том, что в режиме мультисайт вы можете поднять неограниченное количество сайтов под одной установкой ядра и БД WordPress. Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит.
Иными словами — сеть блогов любого университета, не говоря уже о крупных проектах как edublogs.org, happytables.com и т.д.
Но дело даже не в этом. Когда слейв читает с мастера, он группирует запросы на изменение таблиц последовательно, поэтому на реплике они выполняются гораздо быстрее, чем на мастере. При этом на крайний случай всегда есть --low-priority-updates или возможность приостановить слейв на время. Опять же, самое худшее, что мы можем получить из этой ситуации это лаг.
> Всё таки я не понимаю, что может занимать такие размеры (100G+) в БД. Медиафайлы же хранятся не в базе.
> БД редко бывают размеров больше 100G (в InnoDB), чтобы это стало существенно. Тем более в блогах.
О блогах это вы зря :) Именно в блогах и СМИ авторы публикуют по 200 записей в день, причем по 40 редакций и десяток внедренных объектов oEmbed в каждой, а уж если вы поддерживаете, скажем сеть сайтов в режиме multisite, то «отдельной дисковой подсистемой» можно и не обойтись, и прирост объема в 4 раза может хорошо сказаться на стоимости поддержки, именно поэтому WordPress.com до сих пор крутится на MyISAM.
> Использовать же на таких объемах MyISAM без гарантий консистентности и с блокировками на полные таблицы как-то странно.
Это совершенно не странно, во-первых потому, что несмотря на наличие транзакций и откатов в InnoDB, ядро WordPress ими не пользуется, ровно так же как и внешними ключами, которые вообще практически весь смысл теряют, как только мы переходим на шардинг данных.
Во-вторых, блокировка таблиц влияет только на запись, а для большинства крупных и высоко-посещаемых проектов на WordPress соотношение чтения к записи слишком велико, чтобы об этом даже думать, потому и сложно например встретить репликацию master-master с WordPress, несмотря на то, что такая репликация хорошо поддерживается тем же XtraDB Cluster.
> Но здесь стоит упомянуть, что у MyISAM нет нормального механизма резервного копирования. Хотя это можно попробовать обойти через снапшоты — надо лочить всю базу на запись
Если говорить о резервном копировании при таком объеме данных, то скорее это делается все на реплике на отдельном сервере, поэтому тип блокировки и наличие транзакций никакого влияния не окажет.
Во время резервной копии реплику можно вывести из продакшн, тогда на работоспособность сайта это никак не повлияет, или же просто остановить репликацию на время копирования, тогда будет небольшой лаг, что для большинства проектов совершенно не критично и не заметно.
Плюс, как вы сами отметили в статье, MyISAM позволяет скопировать базу данных на уровне файловой системы, что гораздо быстрее, чем любой mysqldump.
И все же, InnoDB это круто :) и главная причина по которой WordPress.com до сих пор работает на MyISAM (и частично на MariaDB) — это объем, потому я и затронул эту тему в моем предыдущем комментарии.
Вы забыли упомянуть, что InnoDB потребляет раза в 4 больше пространства на жестком диске, и при большом объеме данных (раз уж речь идет о крупных и высоко-нагруженных проектах), это не всегда может быть оправдано.
Связка Apache + nginx используется в основном только тогда, когда клиентам хостинга необходимо предоставить доступ к файлу .htaccess, во всех остальных случаях nginx + php-fpm уже давно стал стандартом для WordPress.
> В новых версиях Wordpress появилась возможность выбора префикса при установке.
Это делается далеко не из соображений безопасности, а только потому, что так работать удобнее если директория с ядром WordPress подтягивается и обновляется с помощью системы контроля версий, например Subversion или Git. Получается, что в самой директории ничего никогда не меняется, а меняется лишь wp-config.php и wp-content, которые оба могут находится за пределами директории ядра.
> Ключи используются для хэширования паролей
Ключи не используются для хэширования паролей, иначе при смене ключа у вас бы ни один старый пароль не подошел. Ключи используются для генерации куки аутентификации, и «одноразовых» чисел (nonce) в WordPress. Менять эти ключи можно когда угодно, при смене всех вошедших пользователей лишь «выбросит» из админки и им придется войти повторно. Более того, это хороший метод защиты, когда у вас например украли куки браузера.
> Удалите информацию о версии Wordpress
Как уже кто-то отметил в комментариях — это глупость. Версию ядра WordPress можно легко узнать из версий внешних библиотек, например jQuery, TinyMCE. Лучше не прятать версию а вовремя обновляться и использовать надежный пароль, возможно 2-уровневую аутентификацию. А наличие тега rel=generator помогает лишь сбору статистики.
Ботам, которые брутфорсят пароли от WordPress, или ищут уязвимости в темах использующие старый TimThumb совершенно не важно какая у вас версия ядра. Им даже не важно стоит ли у вас WordPress :) Есть ответ по 80-му порту — будут бомбить.
> Ограничьте доступ к папкам wp-content и wp-includes.
Может быть wp-content, но не wp-includes, там есть некоторые .php файлы, к которым необходим прямой доступ, например wp-includes/js/tinymce/wp-mce-help.php. Не исключено, что в новых версиях появятся и другие.
> Ограничьте доступ к папке wp-admin.
Тоже не совсем просто. В этой директории есть некоторые файлы, которые исполняются с фронтенда без необходимости авторизации пользователей в WordPress, например любые темы или плагины, которые используют AJAX в WordPress проходят через wp-admin/admin-ajax.php.
> Хм… А Вы часто читаете _в панелях_управления_, кто производитель софта?
Когда речь о софте, который разрабатываю — да.
Наиболее правильным решением будет открыть доступ к admin-ajax.php и admin-post.php (был еще какой-то файл связанный с TinyMCE на лице, вроде wp-mce-help.php).
Вообще если честно, то блокировка админки WordPress базовой аутентификацией это глупость. Куда надежнее использовать двух факторную аутентификацию, fail2ban или подобные утилиты, HTTPS и конечно же надежные пароли.
Также стоит отметить, что блокировка/удаление/переименование xmlrpc.php это тоже глупость, особенно когда вы попытаетесь воспользоваться внешними инструментами для работы с сайтом, включая официальные мобильные приложения.
Тем не менее, у человека пришедшего из мира ООП, MVC, ORM и прочих модных аббревиатур, все равно возникает некий ужас при работе с WordPress: функции, фильтры, события,… но поймите — это одна из причин того, что с WordPress легко справиться даже начинающего разработчику без особых знаний PHP. Как-то раз Мэтт Мулленвег спросил на конференции разработчиков сколько из присутствующих научились программированию на PHP благодаря WordPress. Руки подняли больше половины зала.
Система Ghost — хороший пример, который доказал что именно эта простота является неотъемлемой частью WordPress. Это некий упрощенный аналог WordPress, написанный на Node.js, и теперь он славится лишь своей 45-минутной установкой, а WordPress в это время занимает более 60% доли рынка CMS и активно растет.
Но в легкости WordPress скрывается и его сложность — да, наклепать сайтик за выходные сможет каждый с помощью WordPress, но вот внутреннее строение, архитектуру, и огромное количество нюансов знают немногие. Начиная от элементарных, как например работа с внешними ресурсами с помощью класса WP_Http и функций wp_remote_*(), заканчивая чем-нибудь супер-специфическим, как например аргумент split_the_query в запросах с помощью WP_Query.
А когда с этим всем начинаешь глубоко разбираться, становится интереснее, и с каждым днем понимаешь, что WordPress знаешь все меньше и меньше.
Ну конечно каждому свое. Например мой любимый язык Python, а с WordPress работаю уже более 6-ти лет :)
Очень удобно для работы с длинными статьями. Ну и официальный видео-релиз 4.0 для тех, кто еще не нашел:
В общем обновляйтесь друзья!
Здесь речь идет не о шаред-хостинге :) WordPress.com это сервис на основе WordPress мультисайт, который развернут на более тысячи серверов в 6 дата-центрах на 3-х континентах. БД шардится на более 600 серверов MySQL, на каждый из которых приходится в среднем по ~ 400 запросов в секунду. Можете представить какой у нас объем.
Это конечно самый крупный публичный проект на WordPress, поэтому его можно назвать крайним случаем, и здесь вполне оправдан выбор MyISAM, несмотря на то, что InnoDB был бы эффективнее.
Тем не менее, возьмите типичный американский университет, где студентам и преподавателям предоставляется возможность создать сайт и вести свой блог. Такого объема как у WordPress.com у них в сети никогда не будет, но поверьте, 100 ГБ они быстро наберут, особенно если добавить элементы соц. сети, например с помощью BuddyPress.
В общем я не говорю, что нужно использовать MyISAM. Все знают, что у InnoDB будущее куда светлее, чем даже у MariaDB. Но тот факт, что InnoDB потребляет в несколько раз больше места на диске, лучше все-таки держать в голове.
Вот мы и пошли в сторону MyISAM :)
> поставил бы рейд из SAS-дисков или даже SATA в несколько Тб. Всё равно ведь используются реплики.
Так репликам ж тоже с дисков читать надо.
> не увидел там причины того, что базы под WP должны занимать 100G+. :((
Суть в том, что в режиме мультисайт вы можете поднять неограниченное количество сайтов под одной установкой ядра и БД WordPress. Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит.
Иными словами — сеть блогов любого университета, не говоря уже о крупных проектах как edublogs.org, happytables.com и т.д.
> Когда идет запись, ставится блокировка на чтение всей таблицы
Вы правы, только это происходит не всегда, см. dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html
Но дело даже не в этом. Когда слейв читает с мастера, он группирует запросы на изменение таблиц последовательно, поэтому на реплике они выполняются гораздо быстрее, чем на мастере. При этом на крайний случай всегда есть --low-priority-updates или возможность приостановить слейв на время. Опять же, самое худшее, что мы можем получить из этой ситуации это лаг.
> Всё таки я не понимаю, что может занимать такие размеры (100G+) в БД. Медиафайлы же хранятся не в базе.
Мультисайт: wpmag.ru/2014/wordpress-multisite/
> Если вы так бекапитесь, что у вас почти 100% будут недописанные данные.
Мы так не бэкапимся :) тем не менее: STOP SLAVE; FLUSH TABLES;
> P.S: вы скинули ссылку на конференцию, где вы будуте рассказывать про масштабирование WordPress. Запишите видео доклада, я бы послушал.
Обязательно.
> БД редко бывают размеров больше 100G (в InnoDB), чтобы это стало существенно. Тем более в блогах.
О блогах это вы зря :) Именно в блогах и СМИ авторы публикуют по 200 записей в день, причем по 40 редакций и десяток внедренных объектов oEmbed в каждой, а уж если вы поддерживаете, скажем сеть сайтов в режиме multisite, то «отдельной дисковой подсистемой» можно и не обойтись, и прирост объема в 4 раза может хорошо сказаться на стоимости поддержки, именно поэтому WordPress.com до сих пор крутится на MyISAM.
> Использовать же на таких объемах MyISAM без гарантий консистентности и с блокировками на полные таблицы как-то странно.
Это совершенно не странно, во-первых потому, что несмотря на наличие транзакций и откатов в InnoDB, ядро WordPress ими не пользуется, ровно так же как и внешними ключами, которые вообще практически весь смысл теряют, как только мы переходим на шардинг данных.
Во-вторых, блокировка таблиц влияет только на запись, а для большинства крупных и высоко-посещаемых проектов на WordPress соотношение чтения к записи слишком велико, чтобы об этом даже думать, потому и сложно например встретить репликацию master-master с WordPress, несмотря на то, что такая репликация хорошо поддерживается тем же XtraDB Cluster.
> Но здесь стоит упомянуть, что у MyISAM нет нормального механизма резервного копирования. Хотя это можно попробовать обойти через снапшоты — надо лочить всю базу на запись
Если говорить о резервном копировании при таком объеме данных, то скорее это делается все на реплике на отдельном сервере, поэтому тип блокировки и наличие транзакций никакого влияния не окажет.
Во время резервной копии реплику можно вывести из продакшн, тогда на работоспособность сайта это никак не повлияет, или же просто остановить репликацию на время копирования, тогда будет небольшой лаг, что для большинства проектов совершенно не критично и не заметно.
Плюс, как вы сами отметили в статье, MyISAM позволяет скопировать базу данных на уровне файловой системы, что гораздо быстрее, чем любой mysqldump.
И все же, InnoDB это круто :) и главная причина по которой WordPress.com до сих пор работает на MyISAM (и частично на MariaDB) — это объем, потому я и затронул эту тему в моем предыдущем комментарии.
Связка Apache + nginx используется в основном только тогда, когда клиентам хостинга необходимо предоставить доступ к файлу .htaccess, во всех остальных случаях nginx + php-fpm уже давно стал стандартом для WordPress.
> В новых версиях Wordpress появилась возможность выбора префикса при установке.
Ну да, в новых… Лет так 11 назад ;) core.trac.wordpress.org/changeset/664/
> Переместите файл wp-config.php.
Это делается далеко не из соображений безопасности, а только потому, что так работать удобнее если директория с ядром WordPress подтягивается и обновляется с помощью системы контроля версий, например Subversion или Git. Получается, что в самой директории ничего никогда не меняется, а меняется лишь wp-config.php и wp-content, которые оба могут находится за пределами директории ядра.
> Ключи используются для хэширования паролей
Ключи не используются для хэширования паролей, иначе при смене ключа у вас бы ни один старый пароль не подошел. Ключи используются для генерации куки аутентификации, и «одноразовых» чисел (nonce) в WordPress. Менять эти ключи можно когда угодно, при смене всех вошедших пользователей лишь «выбросит» из админки и им придется войти повторно. Более того, это хороший метод защиты, когда у вас например украли куки браузера.
> Удалите информацию о версии Wordpress
Как уже кто-то отметил в комментариях — это глупость. Версию ядра WordPress можно легко узнать из версий внешних библиотек, например jQuery, TinyMCE. Лучше не прятать версию а вовремя обновляться и использовать надежный пароль, возможно 2-уровневую аутентификацию. А наличие тега rel=generator помогает лишь сбору статистики.
Ботам, которые брутфорсят пароли от WordPress, или ищут уязвимости в темах использующие старый TimThumb совершенно не важно какая у вас версия ядра. Им даже не важно стоит ли у вас WordPress :) Есть ответ по 80-му порту — будут бомбить.
> Ограничьте доступ к папкам wp-content и wp-includes.
Может быть wp-content, но не wp-includes, там есть некоторые .php файлы, к которым необходим прямой доступ, например wp-includes/js/tinymce/wp-mce-help.php. Не исключено, что в новых версиях появятся и другие.
> Ограничьте доступ к папке wp-admin.
Тоже не совсем просто. В этой директории есть некоторые файлы, которые исполняются с фронтенда без необходимости авторизации пользователей в WordPress, например любые темы или плагины, которые используют AJAX в WordPress проходят через wp-admin/admin-ajax.php.
P.S. Если кому-то интересна тема высокой посещаемости и WordPress, крайне рекомендую: WordPress под нагрузкой: масштабирование и отказоустойчивость :)
А для всего что вы описали есть простой модуль mod_pagespeed для Apache, или ngx_pagespeed для nginx :)