• Создание HANA-приложения с использованием среды разработки Eclipse
    0
    Уберите WordPress из хабов.
  • Недостатки Wordpress — техническая сторона
    0
    Мы обычно не комментируем к таким записям. Если вам нужны фишечки и няшечки вроде MVC, MVP, ORM и прочие аббревиатуры, методологии и стили жизни, то вряд ли вам подойдет WordPress.
  • Deploy4Me — сервис, который развернул себя сам
    0
    Спасибо! Да, я понимаю, но если вы позволяете пользователям выбрать старую версию, то пусть она лучше будет не уязвимой. То, что у вас есть 4.0.1 это здорово, многие хостинг-провайдеры до сих пор что-то вроде 3.5 ставят через древний Softaculous.
  • Deploy4Me — сервис, который развернул себя сам
    +2
    Ну да, только я думал, что за $29 у меня будет, цитирую: «Production ready» и «Pre-configured security», а не то, что мне еще нужно будет что-то до-устанавливать и обновлять.

    > Хм… А Вы часто читаете _в панелях_управления_, кто производитель софта?

    Когда речь о софте, который разрабатываю — да.
  • Deploy4Me — сервис, который развернул себя сам
    +4
    Классный сервис! На странице WordPress у вас в поле Manufacturer указана коммерческая компания Automattic, а должен быть некоммерческий фонд WordPress Foundation. А среди доступных версий у вас 3.9.1 которая является уязвимой. 3.9.2 вышла в августе, и 3.9.3 вместе с 4.0.1 в ноябре.
  • WordPress для параноиков, часть 1
    +4
    Базовая версия 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 это тоже глупость, особенно когда вы попытаетесь воспользоваться внешними инструментами для работы с сайтом, включая официальные мобильные приложения.
  • WordPress для параноиков, часть 1
    +3
    Если вы закрываете wp-admin базовой аутентификацией то у вас перестанет работать AJAX, т.к. весь AJAX (включая анонимный) в WordPress работает через файл wp-admin/admin-ajax.php, есть также некоторые вещи, которые работают через wp-admin/admin-post.php.
  • 84% сайтов на WordPress могут быть взломаны: что дальше?
    0
    Если быть точнее, то не около 30%, а 47%. И да, более 50% сайтов остаются потенциально уязвимыми. Из них большая часть скрываются за добросовестными хостинг-провайдерами, которые фильтруют уязвимость на уровне веб-сервера, так что на практике цифра гораздо меньше 84%, которая у вас указано в заголовке.
  • 84% сайтов на WordPress могут быть взломаны: что дальше?
    0
    Обновление 3.9.3 итак содержит фикс для этой уязвимости, 0day отписал же выше, что критическое обновление вышло для всех веток, начиная с 3.7.
  • Релиз WordPress 4.0 Benny
    0
    TinyMCE 4.1.3.
  • Релиз WordPress 4.0 Benny
    0
    Все правильно, глобальные перменные и прочий багаж вызван хорошей обратной совместимостью, что очень сложно сказать про многие другие 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-ти лет :)
  • Релиз WordPress 4.0 Benny
    +1
    Почему-то все источники делают видео-превью встраивания oEmbed, а вот новое поведение скролла в редакторе отображают картинкой. Но его ведь просто невозможно понять с помощью картинки, а «фича» на мой взгляд одна из самых лучших в 4.0. Вот короткий видео-ролик прокрутки:



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



    В общем обновляйтесь друзья!
  • Проекты на WordPress: советы по оптимизации
    0
    > Если будете оверселить ресурсы, то всё будет жутко тормозить и лагать, т.е. клиенты такого размера как вы описываете, просто свалят.

    Здесь речь идет не о шаред-хостинге :) WordPress.com это сервис на основе WordPress мультисайт, который развернут на более тысячи серверов в 6 дата-центрах на 3-х континентах. БД шардится на более 600 серверов MySQL, на каждый из которых приходится в среднем по ~ 400 запросов в секунду. Можете представить какой у нас объем.

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

    Тем не менее, возьмите типичный американский университет, где студентам и преподавателям предоставляется возможность создать сайт и вести свой блог. Такого объема как у WordPress.com у них в сети никогда не будет, но поверьте, 100 ГБ они быстро наберут, особенно если добавить элементы соц. сети, например с помощью BuddyPress.

    В общем я не говорю, что нужно использовать MyISAM. Все знают, что у InnoDB будущее куда светлее, чем даже у MariaDB. Но тот факт, что InnoDB потребляет в несколько раз больше места на диске, лучше все-таки держать в голове.
  • Проекты на WordPress: советы по оптимизации
    0
    > Я бы, честно, пошел в сторону уменьшения размера БД

    Вот мы и пошли в сторону MyISAM :)

    > поставил бы рейд из SAS-дисков или даже SATA в несколько Тб. Всё равно ведь используются реплики.

    Так репликам ж тоже с дисков читать надо.

    > не увидел там причины того, что базы под WP должны занимать 100G+. :((

    Суть в том, что в режиме мультисайт вы можете поднять неограниченное количество сайтов под одной установкой ядра и БД WordPress. Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит.

    Иными словами — сеть блогов любого университета, не говоря уже о крупных проектах как edublogs.org, happytables.com и т.д.
  • Проекты на WordPress: советы по оптимизации
    0
    > Когда идет SELECT, блокируется вся таблица на запись и на обновление.
    > Когда идет запись, ставится блокировка на чтение всей таблицы

    Вы правы, только это происходит не всегда, см. 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. Запишите видео доклада, я бы послушал.

    Обязательно.
  • Проекты на WordPress: советы по оптимизации
    +1
    Спасибо за ответ!

    > БД редко бывают размеров больше 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) — это объем, потому я и затронул эту тему в моем предыдущем комментарии.
  • Доступна для скачивания WordPress 4.0 Beta 1
    +1
    В отношении WordPress, 4.0 не является более «мажорной», чем 3.9 или 3.8. В WordPress мажорные версии это х.х а минорные (пойнт-релизы) х.х.х.
  • Проекты на WordPress: советы по оптимизации
    +13
    Вы забыли упомянуть, что InnoDB потребляет раза в 4 больше пространства на жестком диске, и при большом объеме данных (раз уж речь идет о крупных и высоко-нагруженных проектах), это не всегда может быть оправдано.

    Связка 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 под нагрузкой: масштабирование и отказоустойчивость :)
  • Ускоряем Wordpress
    0
    Memcached + Nananananannnana Batcache!

    А для всего что вы описали есть простой модуль mod_pagespeed для Apache, или ngx_pagespeed для nginx :)
  • Синхронизация файлов между серверами в кластере
    0
    Ок :)
  • Синхронизация файлов между серверами в кластере
    0
    Дата-центры разделены, правда (пока) не в Азии и не в Европе, но сути это не меняет. К тому же есть ноды Anycast которые выполняют функцию CDN на трех континентах.
  • Синхронизация файлов между серверами в кластере
    0
    WordPress.com хостится в 3-х разных дата-центрах, и распределенные файловые системы вполне подходят :)
  • Синхронизация файлов между серверами в кластере
    0
    Зачем хранить и синхронизировать загруженные файлы на серверах приложения? Ведь WordPress прекрасно работает с сетевыми и распределенными хранилищами файлов, вроде NFS, MogileFS и пр. :)
  • Comment from a drafted post.
  • Comment from a drafted post.
  • WordPress 3.7 будет обновляться автоматически
    +2
    Обновления из админки в WordPress появились ещё несколько лет назад в версии 2.7, включая ядро, темы и плагины. Запись и проверка файлов происходит благодаря классу WP_Filesystem, который может работать с прямым доступом к файловой системе (например через suphp), через FTP или FTPS, а так же через SSH. По последним двум — вам решать от чьего имени произойдёт обновление.
  • Так может выглядеть редактор в новой версии WordPress
    0
    К сожалению в настоящее время да, только с Twenty Eleven.
  • Так может выглядеть редактор в новой версии WordPress
    0
    +1. Ещё интереснее contenteditable в HTML5: html5demos.com/contenteditable
  • Так может выглядеть редактор в новой версии WordPress
    0
    > Социальные кнопки и все остальное лишнее у вас же не встраивается непосредственно в сам текст

    Так это не от вас зависит, а от плагинов, которыми вы пользуетесь, например Jetpack Sharedaddy, который при выводе the_content просто добавляет блок в конце. Многие другие плагины работают подобным образом. Похожая ситуация возникает с шорткодами — если у вас есть шорткод для отображения блока голосования посреди вашего контента, как отреагирует на него ваш редактор? Вам ведь тогда придётся выводить «необработанный» контент в чистом виде, а поверх него этот же контент только уже с обработкой, чтобы при изменении в редакторе появлялся именно оригинал.
  • Так может выглядеть редактор в новой версии WordPress
    0
    Спасибо за ссылку!
  • Так может выглядеть редактор в новой версии WordPress
    0
    Теги и категории обычно устанавливаются после написания записи перед сохранением или публикацией, так что смысл держать их внизу рядом с кнопкой «Сохранить» думаю смысл есть. Вот с медиатекой конечно согласен — она стала слишком далеко от содержимого и от блока форматирования.
  • Так может выглядеть редактор в новой версии WordPress
    0
    Возможно вы имеете дело с вредоносными плагинами или бесплатно скаченной «премиум» темой? А может быть у вас пароль очень слабый и легко подбирается? А может в вашем FTP клиенте сидит червь? Нельзя винить во всём движок :) см. Основы безопасности WordPress.
  • Так может выглядеть редактор в новой версии WordPress
    0
    Нужно чтобы был установлен и активен ещё плагин MP6, затем после активации WordPress Front-end Editor (в моём случае версия 0.3). Активируйте тему Twenty Eleven, зайдите на главную где у вас список записей откройте любую запись и нажмите «редактировать» — у вас откроется новый редактор.
  • Так может выглядеть редактор в новой версии WordPress
    0
    Интересно, а как быть, когда в этот же блок с контентом, плагин добавляет социальные кнопки, или схожие записи, или биографию автора. Многие ведь подобные плагины именно к фильтру the_content подключаются. Получается ваше решение включит (или попытается включить) все эти дополнительные данные в редактор? Не сталкивались с этим?
  • Так может выглядеть редактор в новой версии WordPress
    0
    Tarya, интересно! А где-нибудь можно посмотреть подробнее ваше решение — плагин или может быть просто наброски кода остались?
  • Так может выглядеть редактор в новой версии WordPress
    0
    Именно это и является самой сложной задачей в реализации подобного редактора :)
  • Так может выглядеть редактор в новой версии WordPress
    0
    Про Битрикс, к сожалению, ничего сказать не могу, но как я и упомянул, сама идея не является новшеством. Плагин Front-end Editor для WordPress появился ещё в 2009 году, а первый раз я что-то подобное увидел наверное в Macromedia Contribute миллион лет назад.
  • Так может выглядеть редактор в новой версии WordPress
    0
    С доп. полями и метабоксами согласен — сложно их будет как-то внедрить в новый интерфейс.
  • Так может выглядеть редактор в новой версии WordPress
    0
    У меня нет ответа на ваш вопрос, настолько глубоко в TinyMCE 4.0 я не копал :(
  • Рабочая бизнес-модель успешного портала маленького города, созданного на CMS WordPress
    +1
    > Так получилось, что мой портал стоит не на одном WordPress, а сразу на двух.

    Вам будет интересен WordPress в режиме Multisite.

    > Вся графика заливается не через интерфейс WordPress, а через FTP. Причём название файлов соответствует URL страницы.

    Почему вы не использовали стандартную медиатеку WordPress?

    И как вам уже упомянули, вы работаете с очень старой версией WordPress. Вам следует немедленно обновить движок до версии 3.5.2, а через пару недель уже и 3.6 :) wpmag.ru/2013/stoit-li-obnovlyat-wordpress/