ГлавнаяНовостиНачалась разработка WordPress 4.2

Началась разработка WordPress 4.2

Обновление: WordPress 4.2 вышел 23 апреля 2015. Подробности в нашем новом обзоре →

Несколько дней назад прошла еженедельная встреча разработчиков ядра WordPress, где официально начался цикл разработки версии 4.2. Предварительная дата выхода новой версии — 8 апреля.

Релиз-лидом новой версии стал разработчик из компании 10up Дрю Джейнс. Он уже долгое время принимает активное участие в развитии WordPress, а на протяжении последних нескольких релизов, он сформировал команду, которая продокументировала каждый фильтр и событие в коде ядра WordPress.

Что войдет в версию 4.2

Среди проектов претендующих войти в состав WordPress 4.2 были названы Press This, Theme Switcher и Shiny Updates. Напоминаем, что начиная с версии 3.8 большая часть нового функционала WordPress разрабатывается в виде отдельного проекта на протяжении нескольких релиз-циклов ядра.

Первые наброски на новый Press This в WordPress 4.2

Первые наброски на новый Press This в WordPress 4.2

Press This — это букмарклет для браузера, который позволяет опубликовать статью на сайт WordPress из любой точки Интернета. Данный букмарклет уже давно является частью ядра WordPress, но в новой версии разработчики надеются существенно упростить, ускорить и улучшить интерфейс.

Theme Switcher — дополнение к конфигуратору тем WordPress, которое позволяет просматривать установленные темы не покидая сам конфигуратор.

Обновление плагинов в WordPress 4.2

Обновление плагинов в WordPress 4.2

Shiny Updates — упростит пользовательский интерфейс при установке и обновлении плагинов WordPress. Выбранные обновления будут выполняться фоном, примерно так же, как приложения для мобильных устройств в App Store или Google Play.

Кроме данных изменений в баг-трекере WordPress уже более 260 задач, которые помечены для новой версии. Предварительная дата релиза WordPress 4.2 — 8 апреля, а первая бета-версия появится на свет уже в конце февраля.

Что бы вы хотели увидеть в WordPress 4.2?

Константин Ковшенин

Сооснователь журнала WP Magazine и первой конференции WordCamp в России. Разработчик в компании Automattic, принимает активное участие в развитии ядра WordPress. Любимый язык программирования: Python.

Подписаться на рассылку

Подписаться → Подпишитесь на бесплатную рассылку журнала WP Magazine и получайте новости, события, подборки тем и плагинов, уроки, советы и многое другое в мире WordPress!

  • Evgeniy

    Вот этой штуковины однозначно не хватает

    https://wordpress.org/plugins/black-studio-tinymce-widget/

    • Согласен. Визуальный редактор текстового виджета – давняя потребность. Никого не устраивает простой текст.

  • Катастрофически не хватает одной, но очень важной и глобальной фичи — нормальной поддержки мультиязычности на уровне ядра. Если сделать блог или простой сайт на нескольких языках еще можно с помощью WPML, Polylang или через Multisite, то со сложными проектами — *опа. В идеях на wordpress.org туча предложений, идей, голосов за эту фичу. Я сам упоминаю об этом везде где только можно, и таких разрабов много. Результат — нулевой :)

    • Интересное предложение. А что именно вы бы хотели увидеть «на уровне ядра» чего не реализовано в виде плагинов типа WPML, Multilingual Press и т.д.?

      • Константин, мне только сейчас пришло уведомление на почту об этом ответе :)
        Чего не хватает на уровне ядра, если малой кровью — из общения и совместных попыток решить проблему с автором плагина Polylang — так это возможности иметь одинаковые slugs. Polylang создает скрытую таксономию для языков, и в целом более-менее хорошо справляется с поддержкой мультиязычки для простых сайтов, особенно блогов. Но вот с более сложными проблема. Урл у одинаковых страниц (не только pages, но и постов, архивных и тд) на разных языках по определению будет уникальным, так как содержит фрагмент с кодом языка (например, ru и en), поэтому slug можно бы смело сделать одинаковым, и часто это необходимо. Но WordPress этого не позволяет. Банальный пример — кастомная таксономия «страны» или «города». Есть страны, которые на разных языках по разному пишутся, слаги будут разные. А есть и такие, которые будут одинаковы, например, Конго, Беларусь, Канада и так далее — они в английском написании и в транслите (с рус, укр, бел) будут писаться одинаково, на многих языках с латиницей тоже. В результате возникают слаги с индексом «-2» и подобный мусор. Это только поверхностный взгляд на одну из проблем, а вообще по сути этот вопрос я с удовольствием готов обсуждать, автор Polylang тоже рад будет подключаться — у него там целый список пожеланий и почти готовое видение, как можно это все реализовать.

    • Yevgeniy Vlassyuk

      Соглашусь, было бы хорошо, чтобы эта функция была сразу «вшита».

      Подскажите, с WPML, Polylang и т.п., как быть с названием сайта, которое в «Настройки» -> «Общие», там где Название сайта и краткой описание? Ведь там плагин не позволяет разные задать. Как лучше реализуется этот момент?

      • Ivan Panfilov

        что мешает в коде прописать это дело. проверить версию сайта — можно.
        я вообще хранил разные блоки html в постах вместо виджетов и выводил их содержимое.
        а посты и рубрики нормальон фильтруются через polylang

    • Ivan Panfilov

      multisite или несколько копий сайта — реально и для сложных проектов.
      другое дело что wp для сложных проектов лучше не использовать.

    • Не думаю что нужна мультиязычность в рамках одного сайта. Потому что помимо просто слов на другом языке очень многое тоже необходимо изменять, поэтому легче, если у сайта один язык. Например, очень часто используются картинки с подписями на них. И в случае, когда на 1 сайте 10 языков, как вы будете менять текст на картинках? Как будут поддерживаться комментарии на разных языках? Как будут учитываться какие-то дополнительные региональные особенности (например, рекламный баннер, который нужен только на английском языке, а ну русском совсем другой)? И еще миллион проблем на самом деле всплывает.

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

  • Oleg

    В этой версии, в ядро будет вшит rest json api?

    • В этой версии нет, но один из ведущих программистов WordPress Эндрю Нейсин упомянул, что REST API запланирован на версию 4.3 или 4.4 позже в этом году.

      • Дамир

        Здравствуйте, а что это и зачем он нужен?
        спасибо

        • Это API для упрощенной работы с данными в WordPress через JavaScript и сторонние инструменты. Он позволит строить более динамичные интерфейсы внутри WordPress, а также сторонние приложения и сервисы, которые будут взаимодействовать с WordPress сайтами.

  • Я хотел бы увидеть и думаю многие согласятся, не в 4.2 версии к примеру, а позже какую то людскую систему комментирования постов. Та которая щас уже морально устарела то есть это самый базовый функционал + без ajax она еще и грузит сервер больше(так как после каждого запроса обновляется весь сайт). Знаю есть куча плагинов и даже сервисов типа Disqus но не всегда это подходит так скажем. Вот я не знаю можно ли в само ядро заложить какой то API новый для комментариев? Как мне кажется это не очень сложная задача и не потребует много времени но упростит думаю жизнь всем обывателям не посвящённым в php и js. Было бы больше у меня опыта сам бы попробовал что то такое реализовать на уровне плагина.

    • Да, задача «вроде» несложная. Тут сложнее будет стандартизировать это, чем просто код написать для одиночного случая. Вроде были какие-то плагины для этого.

    • Не понимаю, как AJAX-овость комментариев может повлиять на нагрузку сервера. Обновить страницу целиком чаще всего гораздо быстрее, чем выполнить AJAX запрос, поскольку многие системы кэширования выдадут страницу из кэша при полном обновлении, а при AJAX запросе будут генерировать ее «с нуля».

      Ну а если вам все же хочется обновлять комментарии с помощью AJAX, то для этого есть множество плагинов.

      • Роман Якушев

        aiax загрузит ТОЛЬКО комментарии зачем грузить всю страницу?. Пока полная страница будет отдавать кеш, или даже начнёт выгружать шапку сайта с главным меню — ajax уже выдаст 1-2 новых комментария.

        • Ну так это значит, что на сервер будет наоборот больше нагрузки, т.к. кроме страницы из кэша ему необходимо еще и комментарии выдать отдельным AJAX запросом :)

          • Роман Якушев

            Вы совсем не понимаете логики ajax? Давайте попытаюсь обьяснить на пальцах. клиент грузит всю страницу.это долго, даже если это кеш. Только если это не кеш браузера. Но даже тут ajax быстрее. После отправляет свой комментарий. комментарий принимает сервер и в ответ что бы показать ему что его комментарий добавился можно не обновлять всю страницу — как делается обычными средствами к примеру php, а отправить всего лишь одну короткую строку на ajax. вот вам и выигрыш в скорости. сравните по отправке — длина символов всей страницы или длина одной строки или даже бита — если не учитывать заголовки.

          • Очевидно мы не совсем поняли друг друга :) Вы говорите про отправку комментариев через AJAX. Я говорю про отображение комментариев через AJAX, но вы правы, если сравнивать POST запрос + редирект и POST запрос через AJAX, то для пользователя AJAX конечно будет быстрее.

            Правда если говорить именно о нагрузке на сервер, то разницы ощутимой нет. Обычный POST запрос, и AJAX запрос будут одинаково медленно загружать все окружение WordPress, тему и все плагины, чтобы записать комментарий.

          • Роман Якушев

            давайте про отображение) Пользователю что бы увидеть новые комментарии необходимо перезагрузить всю страницу. Или же ajax подгрузит ему сам новые, как только они появятся. При этом ajax загрузит только новые комментарии, без всей страницы. Снова меньше информации. Правда что бы комментарии грузились совсем моментально — необходим long polling — постоянное соединение с сервером. Что правда увеличивает нагрузку. И в плане количества данных, и в плане количества соединений. Веб не умеет «так» подгружать сайт. Правда умеет node.js — на который кстати и собираются перепиливать wordpress. И чувствую что как раз для этого =) Но там гляди и WebSockets нагрянет. Так вообще не будет проблем с двухстороннем обменом информации

          • Только в теории. Это сработает только если можно будет все AJAX ответы грамотно закэшировать так же как и обычные HTTP запросы, и к сожалению многие популярные плагины для кэширования этого не делают. А если о polling говорить то подгружать все плагины и тему каждый раз когда нужно проверить есть ли новые комментарии – совсем не снижает нагрузку.

            Правда умеет node.js — на который кстати и собираются перепиливать wordpress.

            Это вы с чего решили? :)

          • Роман Якушев

            а зачем кешировать комментарии? если они появляются допустим каждую секунду?
            про ноду читал где то =)

  • Kosss

    Хочется уже нормально чтобы допилили мультисайт и домэйн мэппинг. Чтобы все это дело без стронних плагинов и работало простите из коробки (ну максимум чекбокс поставить). А то упрощают сейчас то, что особо и не нужно никому, зато сделать просто. Про мультиязычность правильно говорят — когда функционал на уровне ядра — это стандарт и все ему следуют. Хочется поддержку nginx из коробки (я про правильные урлы, которые в случае нджинкса нужно наколдовать). Хочется системного, а добавляют перделки-свистелки опять, которые ни для чего не предназначены только тормозить.

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

      Тормозить — в WordPress очень много функционала. Это нормально, что каждый использует какой-то свой набор штук и он разный. Если заботиться о производительности и переживать по поводу каждого лишнего вызова функции, то тогда надо делать отдельную CMS под конкретный сайт, в которой все будет вшито в коде без возможности что-то глобально менять через веб-страницу.

      • Kosss

        Как это к ядру подключается не принципиально. Тут главное, что когда это стандарт — это стандарт и остальные используют стандартное API или что там есть. Я совершенно несогласен, кстати что мультиязычность или мультисайтинг должны быть костылями-плагинами. Это довольно глобальные штуки которые не совсем понятно как в ядре-то реализовать правильно (про мультисайтинг понятно — примеров вагон, про мультиязычность нет — т/к нет универсального правильно решения по локализации), не говоря вообще про внешние плагины.

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

        А по поводу функционала — вордпресс тянет с собой из светлого прошлого вагоны каких-то идиотских пунктов настроек и прочего никому ненужного скарба. Вот чем пилить юзерскрипт публикации (который судя по скриншоту будет копипастить контент в блог, который потом получит по мозгам и от гугла и от яндекса), лучше бы в настройках порядок навели тоже. Пингбэки/трекбеки сейчас только спаммеры юзают, зачем миллион вариантов отображения урлов, если правильный с точки зрения ПС только один (еще один можно оставить для легаси). и так можно по всем пунктам пройтись — оно сейчас в 2015 году надо? нет? нафиг! А действительно необходимые настройки по тому же SEO и поведению сайта во внешних плагинах, многие о них и не знают вовсе. Что еще? Профиль. Трудно сделать профиль на фронтпейдже? Вордпресс давно не только блог — нефиг кого угодно в админку пускать. Нормальная регистрация внимание! с защитой от спаммеров. Это насущные вещи почти для всех, кто не только научился статьи писать в стиле «поел, поспал, пос…», но и видит свой сайт в перспективе зарабатывающим деньги.

        • внутри админки домены видны как поддомены, а на фронтэнде они редиректятся на домеры второго уровня.

          Это вы о реализации с помощью плагина WordPress MU Domain Mapping. Еще раз говорю, в ядре есть полная поддержка разных доменов без сторонних плагинов, вы можете почитать об этом в статье которую я указал выше.

          • Kosss

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

          • не кнопкой же press this заниматься, за которую все поисковые машины будут лупить сайт по голове пока она дурная не отвалится.

            Уже несколько лет на WordPress.com, Tumblr и в других сетях существуют функции типа «reblog» и никто никого не «лупит» по этому поводу, поэтому думаю зря вы переживаете.

          • Kosss

            Я переживаю, т/к в курсе что такое SEO и как ПС относятся к копипасту. Яндекс забанит, Гугл загонит в сопли. И наверно не нужно сравнивать один из крупнейших сервисов блогов (траст +100500) с блогом васи пупкина с посещаемостью 10 одноклассников в неделю и трастом ПС -1 К тому же у блогплатформ есть свои источники генерации траффика, не только ПС.

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

    • Мапить домены можно и без плагинов, см. Как использовать разные домены в WordPress Multisite.

      Хочется поддержку nginx из коробки

      У nginx (слава богу) нет поддержки файла .htaccess или подобного, поэтому для ЧПУ в любом случае нужна соответствующая конфигурация в nginx.conf, а если дать WordPress право изменять эту конфигурацию, то это будет серьезной уязвимостью в системе. Кстати, хостинг провайдеры работающие на nginx итак поддерживают WordPress из коробки и никакой дополнительной конфигурации не требуется, включая работу с разными доменами.

      • Kosss

        Но счет мэппинга без плагинов. Помнится этот трюк был нерекомендуем разработчиками WP, еще года полтора-два назад и правильным путем назывались только плагины с редиректом. Я пробовал тогда этот трюк, но работал он нестабильно и некорректно. Если с тех времен починили — я буду очень рад ибо WordPress MU Domain Mapping черезвычайно не нравится — костыль на ровном месте.

        На счет нжинкса — ну вы же разработчики, придумайте простой путь :) Пускай по шагам что сделать надо (в нескольких вариантах, для разных ситуаций), но все равно правильный путь для конечного юзера. а то сейчас разыскиваешь правильную конфигурацию в инете, прописываешь, а все равно какой-нибудь плагин не работает (у меня сейчас xml карта сайта из yast seo не работает и как ее пилить знать не знаю ибо не админ совсем). А то, что задумчивый апач больше не жилец это уже ясно.

        • Если конечному пользователю давать доступ править nginx.conf, то хорошим это ничем не закончится, а грамотный системный администратор легко справится с подобной задачей. По этой же причине WordPress не дает рекомендации по размеру буфера в InnoDB, по количеству «воркеров» php-fpm, по выделяемой памяти сервера Memcached и т.д.

          Именно поэтому мы советуем пользователям выбирать хороших хостинг-провайдеров, а не тех, у кого «все включено и безлимитно» за 5 копеек в год.

          • Kosss

            Я вообще не говорю про шаред хостинги. Нет больше такого понятия (по крайней мере в моей жизни). Нормальные сайты это не 100 человек/день, чтобы вордпресс мог работать на шареде. А все остальное, что мне делать на VPS — это уже сугубо моя ответственность или админа которому я плачу. Если можно сделать так, чтобы делать все самостоятельно, то лучше так, чем иначе.

          • VPS для пользователей порой еще хуже чем хороший shared хостинг, потому что переходя на VPS (или еще хуже если берут выделенный сервер), пользователи полностью отказываются от какой-либо технической поддержки со стороны провайдера, кроме как «помочь перезагрузить сервер».

            Администрировать серверы дело не простое, этим должны заниматься профессионалы, а не владельцы сайтов. Именно поэтому в последнее время стали популярны специализированные хостинг-площадки, которые берут на себя все (включая работу с nginx.conf), а пользователям остается лишь наполнять сайт контентом.

          • Kosss

            По тому, что я интересуюсь мультисайтом, понятно что я не из таких. Или ВПС или дедик или инстансы в облаках. Но уж никак не шаред. Я говорю именно про себя а не про 100500 личных блогов про «поел, поспал и тд» Им все и так нормально, а 10 одноклассников будут заходить даже если сайт из выдачи выкинут. Я про профессиональное применение только. Работа у меня такая, понимаете ли :)

          • Понимаем :)