esc_js вешать не надо, достаточно отключить нефильтрованный HTML как я писал ниже. По умолчанию это не сделано, поскольку редакторы в своих статьях часто используют js код для баннеров, соц. кнопок, новостных рассылок, форм, опросов и для многого другого.
+1. Глупо обвинять WordPress если человек сам не прав. Нужно понимать, что именно редактор это основная роль в WordPress, а роль администратора должна использоваться только для административных задач — работа с плагинами, темами и т.д. А редактор должен иметь права на вставку всяких js, иначе как же AdSense, баннерные сети, твиттер виджеты, подписки на рассылки и всё остальное?
Опять же, при желании можно одной строчкой отключить нефильтрованный HTML, чего я советую всем, кто сталкивается с многопользовательскими блогами и сайтами, и с работой с людьми, которым они не доверяют.
Уязвимость тут не в WordPress, а здесь: «Администраторы блогов выдают права редакторов своим PR-службам…» — они бы им ещё сразу SSH давали. А если и давать права администратора или редактора посторонним лицам, то нужно просто отключить нефильтрованный HTML для всех, как это сделано на WordPress.com и во многих других сетях:
> Вся графика заливается не через интерфейс WordPress, а через FTP. Причём название файлов соответствует URL страницы.
Почему вы не использовали стандартную медиатеку WordPress?
И как вам уже упомянули, вы работаете с очень старой версией WordPress. Вам следует немедленно обновить движок до версии 3.5.2, а через пару недель уже и 3.6 :) wpmag.ru/2013/stoit-li-obnovlyat-wordpress/
Все сторонние разработки (патчи) данные open source проекту MySQL (включая документацию) были вынуждены не только соблюдать лицензию GPL, но и полностью передать авторские права на разработку проекту (copyright assignment). Купив MySQL Oracle полностью приобрели авторские права на *весь* исходный код целиком, имено поэтому они и имеют право изменить лицензию в любой момент. Как единственный правообладатель исходного кода, такой поступок не является нарушением лицензии GPL.
Переучивать не нужно будет — всё осталось на своих местах. Изменился лишь внешний вид элементов — форма, цвет, шрифт, иконка и т.д. Сперва может показаться не привычно, но я пользуюсь уже несколько месяцев и вздрагиваю когда вижу старую серую админ-панель :)
Раньше через mfunc можно было это делать, как в W3 Total Cache, так и в WP Super Cache. После того, как обнаружили уязвимость в обоих плагинах, авторы убрали эту «фичу» (где-то 1-2 месяца назад) и пока не вернули.
Ядро обновляется 2-3 раза в год, а maintenance/security релизы ещё чаще. Темы и плагины зависят от разработчиков той или иной темы или плагина, иногда раз в год (а то и реже), иногда каждую неделю. А разработчики ядра так же работают над авто-обновлением, которое не только позволит автоматически обновлять ядро для всех пользователей WordPress, но и чаще выпускать обновления к ядру. А когда это дойдёт до тем и плагинов, то вашей постоянной работой будет сидеть и сжимать скрипты каждый день :)
Первое правило разработчиков WordPress — никогда не изменяйте файлы ядра. Никогда.
+1. Обожаю WP Super Cache за то что он позволяет вообще миновать исполнение .php файлов, но к сожалению при таком подходе он не хранит никаких мета-данных о закэшированых страниц (кроме тех, что у файловой системы) и выборочно убрать несколько страниц из кэша не так уж и просто (но возможно).
Подобное кэширование в файлы перестаёт быть эффективным при переходе с одного веб-сервера на два и более. В таком случае страницы должны быть общие, доступны всем в любое время. Для этого советую глянуть плагин Batcache, который позволяет использовать внешний объектный кэш (например Memcached, APC, Redis) для хранения страниц. Он очень простой и безумно гибкий, а так же используется для кэширования страниц в сети WordPress.com.
Ни в коем случае не заменяйте файлы ядра WordPress, включая изображения, CSS и JS (включая файлы темы и плагинов). Если вам нужно сжимать или минимизировать подобные файлы, делайте это с помощью плагина (тот же W3 Total Cache), на уровне веб-сервера (например mod_pagespeed, ngx_pagespeed) или ещё лучше на стороннем CDN.
На данный момент Automattic Inc. / WordPress.com ведёт переписку с Роскомнадзором. Скоро всё встанет на свои места, а пока для доступа к вашим сайтам можно пользоваться 4 из 6 IP адресов которые ещё не заблокированы.
Если одним словом — то ужас :) особенно там, где вы подключаетесь к базе данных WordPress, подключаете файлы wp-config.php и pluggable.php, и ajax запрос на файл. Больно смотреть на ваш код.
Настройки пользователя нужно сохранять и получать используя get_user_meta(), текущего пользователя можно получить с помощью get_current_user_id(), картинки уменьшать и обрезать можно с помощью add_image_size(), вывести миниатюру можно одной функцией the_post_thumbnail(), скрипты и стили нужно подключать с помощью wp_enqueue_script() и wp_enqueue_style(), а ajax совершенно по другому работать должен — через admin-ajax.php. И это только начало.
Опять же, при желании можно одной строчкой отключить нефильтрованный HTML, чего я советую всем, кто сталкивается с многопользовательскими блогами и сайтами, и с работой с людьми, которым они не доверяют.
Вам будет интересен WordPress в режиме Multisite.
> Вся графика заливается не через интерфейс WordPress, а через FTP. Причём название файлов соответствует URL страницы.
Почему вы не использовали стандартную медиатеку WordPress?
И как вам уже упомянули, вы работаете с очень старой версией WordPress. Вам следует немедленно обновить движок до версии 3.5.2, а через пару недель уже и 3.6 :) wpmag.ru/2013/stoit-li-obnovlyat-wordpress/
Все сторонние разработки (патчи) данные open source проекту MySQL (включая документацию) были вынуждены не только соблюдать лицензию GPL, но и полностью передать авторские права на разработку проекту (copyright assignment). Купив MySQL Oracle полностью приобрели авторские права на *весь* исходный код целиком, имено поэтому они и имеют право изменить лицензию в любой момент. Как единственный правообладатель исходного кода, такой поступок не является нарушением лицензии GPL.
Раньше через mfunc можно было это делать, как в W3 Total Cache, так и в WP Super Cache. После того, как обнаружили уязвимость в обоих плагинах, авторы убрали эту «фичу» (где-то 1-2 месяца назад) и пока не вернули.
Первое правило разработчиков WordPress — никогда не изменяйте файлы ядра. Никогда.
Подобное кэширование в файлы перестаёт быть эффективным при переходе с одного веб-сервера на два и более. В таком случае страницы должны быть общие, доступны всем в любое время. Для этого советую глянуть плагин Batcache, который позволяет использовать внешний объектный кэш (например Memcached, APC, Redis) для хранения страниц. Он очень простой и безумно гибкий, а так же используется для кэширования страниц в сети WordPress.com.
Ни в коем случае не заменяйте файлы ядра WordPress, включая изображения, CSS и JS (включая файлы темы и плагинов). Если вам нужно сжимать или минимизировать подобные файлы, делайте это с помощью плагина (тот же W3 Total Cache), на уровне веб-сервера (например mod_pagespeed, ngx_pagespeed) или ещё лучше на стороннем CDN.
Настройки пользователя нужно сохранять и получать используя get_user_meta(), текущего пользователя можно получить с помощью get_current_user_id(), картинки уменьшать и обрезать можно с помощью add_image_size(), вывести миниатюру можно одной функцией the_post_thumbnail(), скрипты и стили нужно подключать с помощью wp_enqueue_script() и wp_enqueue_style(), а ajax совершенно по другому работать должен — через admin-ajax.php. И это только начало.
Прошу вас, не учите людей пока сами не научились.