Участники сообщества WordPress, не согласные с грядущей кардинальной переработкой интерфейса, основали (https://github.com/ClassicPress/ClassicPress) форк, который будет развиваться под именем ClassicPress (https://www.classicpress.net/). Причиной создания форка стало решение по переводу будущего выпуска WordPress 5.0 по умолчанию на новый визуальный интерфейс редактирования Gutenberg (https://wordpress.org/gutenberg/), позволяющем создавать страницы в режиме drag&drop. Поддержка классического интерфейса редактирования контента будет удалена из WordPress 5.0, но останется доступной в виде внешнего плагина (https://wordpress.org/plugins/classic-editor/).
Создатели ClassicPress придерживаются мнения, что следует сохранить привычный уклад и нельзя вносить изменения только ради самих изменений, если функциональность работает и устраивает пользователей. Если какая-то возможность присутствует уже достаточно давно, то не значит, что она сломана и требует замены, а вероятно говорит о том, что это оптимальное решение. Разработчики ClassicPress также уверены, что все значительные решения нужно принимать коллегиально, учитывая мнение сообщества не только разработчиков, но и web-маcтеров, строящих сайты на базе предлагаемой платформы.
Gutenberg ориентирован прежде всего на начинающих пользователей, давая возможность создавать страницы даже неквалифицированному персоналу. Основные претензии к переходу на Gutenberg сводятся к наличию обилия нерешённых проблем (https://github.com/WordPress/gutenberg/issues?q=is%3Aop...), полному изменению методов работы с интерфейсом, несовместимости с большинством сторонних тем оформления и снижению эффективности при работе специалистов (в Gutenberg работа превращается в "бесконечные клики мышью"). Более того, изменение интерфейса редактирования приведёт к значительным затратам для потребителей - по приблизительной оценке (https://medium.com/@scott.bowler83/wordpress-gutenberg-...), переобучение персонала, отвечающего за обновление сайтов, адаптация тем оформления и сопутствующие расходы обойдутся компаниям суммарно в 529 млн долларов.
Первый выпуск ClassicPress ответвился от ветки 4.9, будет полностью аналогичен WordPress 4.9 и сохранит полную совместимость со всеми сайтами на базе WordPress. ClassicPress 1.0 планируют поддерживать в течение как минимум двух лет, выпуская обновления с исправлением уязвимостей и ошибок.
В дальнейшем пути ClassicPress и WordPress разойдутся и ClassicPress будет развиваться без использования редактора Gutenberg и без привязки к библиотеке React.js. Начиная со второго выпуска в ClassicPress планируется начать расширять функциональность с принятием решений о добавлении тех или иных изменений на основе голосования представителей сообщества.Классический интерфейс, предлагаемый в ClassicPress:
Новый интерфейс Gutenberg, который появится в WordPress 5.0:
URL: https://medium.com/@scott.bowler83/wordpress-gutenberg-...
Новость: https://www.opennet.ru/opennews/art.shtml?num=49241
Идея хорошая. Но вопрос - а разве установка классического редактора будет недоступна в новой версии?
Поставил для тестирования 5.0 alpha - классический редактор можно задействовать.
Можно и ничего страшного не произойдёт.
И я о том же :-) .
Где скачать эту альфу версию WordPress? В этом Gutenberg'е имеется возможность вставки HTML?
P.S. Отвечаю сам себе.Скачать здесь: https://wordpress.org/nightly-builds/wordpress-latest.zip
Возможность вставки HTML-кода имеется, выглядит новый редактор довольно убого: небольшая рамка, которую требуется заполнять текстом. Если вставляешь туда огромное количество текста, всё расползается к чертям.
Форк пригодится в первую очередь тем, кому нужно будет долго саппортить сайт с минимальными изменениями, при этом не отказываясь от обновлений безопасности. Других задач у него особо и нет (история с расщеплением MODX тому свидетельство). Основное стадо делающее сайты с нуля будет пользоваться новой версие WP с Гутенбергом.
Г-ди, да сколько же можно уже ориентироваться на начинающих пользователей?! Напечатать текст и вставить картинку — это теперь так сложно?!
Уже лет 10 идёт эта дурацкая тенденция на "упрощение". Уже кажется, что проще некуда — но нет, очередная обезьянка не может 2 простых действия связать в своей трёхнейронной коробке приёма пищи. И ради неё кастрируют и делают убогими вполне привычные и понятные алгоритмы работы. Да сколько можно уже, чёрт возьми?Извините.
>Уже лет 10 идёт эта дурацкая тенденция на "упрощение".Эта тенденция пошла из-за усложнения сайтов. Если 20 лет назад достаточно было накидать сайт в "блокноте", то сейчас, из-за, обилия свистоперделок даже простенький лендинг пожирает в 20 раз больше системных ресурсов и содержит на порядок больше кода.
речь не о свистоперделках - их тебе вропресс полный рот напихает сам, как и раньше.
Речь о банальном писании текста, может быть - с картинкой, посреди этих перделок и пищалок располагаемом.
Тут не в коде дело, а формах ввода контента, которые, на мой взгляд, становятся только менее гибкими и куда менее понятными. Вместо того, чтобы заставлять людей хоть чему-то учиться, разработчики делают "упрощения", которые как раз и увеличивают количество кода, а вместе с тем и количество ошибок и дыр.
Поэтому мне симпатичен похапэ + маленько JS для пользы, эффекты в CSS.
(в чистом виде PHP, без JS все четко и адаптивно на 95%). обожаю свой сайт (для себя можно и под ключ наваять с удовольствием).
Причем этот "простой" (скорее примитивный) интерфейс будет жрать в 10 раз больше ресурсов, чем старый, с кучей видимых формочек.
А вот это беда, прожорливость "пока" актуального старого интерфейса вполне сносная, даже на некро Core Duo и бульдозерах он вполне юзабелен. Гутенберг ещё не щупал, да и желания нет. Новые сайты я буду явно не на WP делать.
Что касается веб-морд, то яркий пример. Старый интерфейс Search console от Гугла - проста, понятна, летает на любом ПК. Новая бета-версия - тормозное лагалово, менее чем с на машине со свежим "гиперпнём" лучше не запускать. Интерфейсу Гугл Аналитики и i3 не всегда хватает (особенно в Лисе).
Как и зачем все это - загадка. Вроде бы они даже свой Ангуляр не используют для своих же сайтов, делают свои какие-то скрипты, дико тормозящие.
Мои сайты на Ангуляре похожей сложности работают гораздо быстрее, без всяких изысков оптимизации.Впрочем, все это меркнет на фоне услуг моск. области. Примитивная форма с отзывчивостью в 5 минут это уметь надо.
Логичным ответом было бы два интерфейса: "начинающих пользователей" и мощный (полнофункциональный, продвинутый, аццкий, как хотите). Но нет, нынче так не умеют.
Дело даже не в неумении. Кто-то да умеет, ведь делали же прошлые версии. Просто недомаркетологи воют, что сложность интерфейсов отпугнет новых пользователей, и заставляют идти на поводу у своих дилетантских представлений о том, как должен выглядеть профессиональный интерфейс.
Проще говоря, это все равно что я полезу к производителям автомобилей и заявлю, что в машине должны быть только руль и педаль газа, а все остальное слишком сложно для необученных новичков.
Вставить картинку БЫСТРО - это очень хорошая возможность. Как и БЫСТРО сделать хорошую раскладку.
> Г-ди, да сколько же можно уже ориентироваться на начинающих пользователей?!Это растущий рынок и деньги.
Вам лично может не нравиться новый мир и попытки под него подстроиться, но миру на вас наплевать. Адаптируйся или сдохни. Вот авторы ClassicPress решили сдохнуть. Помянем.
Алсо, это коммент для минусования рефлексирующими технократами, которые тоже сдохнут.
Вот и мой 14-летний племянник то же самое говорит, но он это перерастет, а ты уже нет.
зачем нужен вордпресс и компания,написанные: 1) на пыхе, 2) с соблюдением всех традиций написания на пыхе (со всякими там умопомрачительными инъекциями, exec-ами эт цетера эт цетера),
когда есть генерация статического сайта с маркдаунов?
вероятно, затем, что "статические сайты" не нужны.
чем сайт на WP будет отличаться от статики, которая перегенерируется при каждом изменении контента?
Вопрос только в удобной админке.
>чем сайт на WP будет отличаться от статики, которая перегенерируется при каждом изменении контента?WP так тоже внезапно умеет.
>Вопрос только в удобной админке.
например, тем, что ты будешь часами (для сайта с худо-бедно приличным наполнением) "перегерерировать" после каждого мелкого изменения (юзер запостил коммент - перегенерируем ВСЕ, потому что у нас в тыще мест может даже сам коммент не показываться, но показываться где-нибудь в боковой колонке навигации "статья такая-то, комменатриев 210...опа, 211" - перегенерируем ВСЕ где это число может вылезти прямо или косвенно)
Или вон по каждому нажатию плюсика на опеннете - перегенерируем весь опеннет, ага. И нет, это вполне содержательная инфа, показывающая реакцию (или ее полное отсутствие) пользователей на контент.В общем, играли мы в эти игры в 99м году, netscape server был такое г-но, что поставить на нем content-processor было невозможно никак, пришлось именно генерить при каждом изменении контента.
А чтобы оно хоть иногда отдыхало от перегенережа всего - повесить этот процесс на большую-красную-кнопку.А админка была удобная, такая же точно как на нормальных динамических сайтах - просто результат ее работы видно не было. Что-то как-то этот клиент быстро потом сбежал на нормальный апач.
> 2k18
> велосипедить комменты
> соответственно, велосипедить авторизацию
> соответственно, велосипедить регистрациюмань, в 2k18 нет необходимости в серверной логике для того, чтобы появились полноценные комменты, и прикинь!: в 2k18 добавление коммента не нуждается даже в том, чтобы изменялся отдаваемый с сервака хэ-тэ-мэ-эль: таким образом, статику нужно регенерить исключительно при изменении самой статьи, и не обязательно даже всю: пара страниц всего: сама статья и какой-нибудь заглавный индекс статей.
> велосипедить комменты
> соответственно, велосипедить авторизацию
> соответственно, велосипедить регистрациюа, надо отдать это все на откуп гуглю (дискусу, еще кому, пофиг), а потом удивляться, почему вменяемые люди обходят твою поделку десятой дорогой.
И да, у гугля-то все это не статикой генерится. Но ты продолжай рассказывать, что динамические сайты не нужны. Только у меня для тебя хреновая новость: следующий на очереди в ненужно - ты и твой "статический сайт". Со словами "нет необходимости" в тебе и твоих поделках - у гугля и это тоже есть, готовое. Авторизацию с регистрацией ты ему уже слил, вместе с данными о своих пользователях? Комменты (то есть уже и часть контента) тоже кому-то слил? Ну и с чем остался, с ненужно-статьями, то есть самым простым для слития. Даже гуглосайты не понадобятся, хватит блога.
Вы в крайности то не впадайте. Контент может спокойно быть статикой, а комменты забираем с облачной СУБД. Я так делал, мне понравилось жить без бэкенда. Нынешние js-фреймворки годятся не только для SPA.
Да там весь Вордпресс надо переписывать с нуля. Качество кода - просто отстой. Глобальные переменные, лапша, хуки - ужас. ООП паттерны? Нет, не слышали.
А зачем? Вы как пользователь интересуетесь, или как контрибьютор, или как кто?
> или как кто?Как нытик, видимо.
И то и другое. Приоходится допиливать функционал и вносить изменения.
Как потребитель скажу - потребителям пофиг на самом деле. Главное, чтобы статьи публиковались.
Как разработчик я вас прекрасно понимаю.Но миром рулит капитал, бабосы и все такое. Так что надо захлопнуть профессиональное хлебало и радоваться тому, что есть.
А если можешь лучше - ради бога, делай лучше!
Ровно до тех пор пока разработчики не смогут быстро править старые баги и пилить новые фичи из за плохого дизайна и кода.
Пора бы в 2к18 понимать, что качество кодовой базы важное свойство непосредственнно влияющее на распространённость, функциональность и безопасность продукта и на эти самые бабосы.
Тоже недавно думал над этим. По сути можно попробовать взять API Вордпресса и переписать его на Symfony, например. Весь фронт оставить как он есть, но изменить только бэкэнд-апи. Не знаю, насколько это реально, потому что идея вроде как на поверхности, но почему-то никто не реализовывает. Возможно, что мы чего-то не знаем.
Не, на Symphony не надо. Лучше на Node.JS/Express
> Лучше на Node.JS/ExpressЛовите хипстера! Поставьте ловушку со смузи, если не поймаете.
да какое смузи, Express уже удел старперов. Сейчас время SSR и серверов на next.js или golang
Ну голый WP дает задерджку 10-20мс не больше на дешевом шаред хостинге.
Ну а то что темы говно или там плагинов поноставят ... так тут вопрос к разработчикам тем и плагинов. Хотя да 20мс на ровном месте ...Просто часто с плагинами и прочей гадостью выходит 150-200мс.
Про задержки на стороне клиента на получения всех ресурсов перед отрисовккой и время на рендеринг я умолчу.под 200 ресурсов под 20-30 хостов .
Ну а некоторые умудряются залить не сжатое фото, несжатое я имею ввиду 8мб jpg :)А так сайты на WP в гугл спид 100/100 и в webpagetest тоже все ОК.
Вопрос в том что всем наплевать на качество и скорость. (в студиях тоже наплевать , ооочень часто)а домохозяйка даже и знать не знает зачем отдавать 304
Эта проблема отчасти решается генерацией из всей динамической каши статического HTML для отдачи юзеру. В 2018-ом для этого уже и извилинами шевелить не нужно, есть вполне годные приложения типа Super Cache, HyperCache, Comet Cache.
> Ну а некоторые умудряются залить не сжатое фото, несжатое я имею ввиду 8мб jpg :)что значит "некоторые"? И почему только 8? (разглядывая фоточки-для-сайта, размером по 5 мег и 24mp каждая, какчество - ну так, если 800x600 сделать, то почти неблевотное - ну так это 2013й год, сейчас такие фотики и немодно уже давно)
впрочем, откройте гитхаб и посмотрите, сколько занимает дурацкая картинка (картинка, а не фото!) и какого она размера...
> Вопрос в том что всем наплевать на качество и скорость. (в студиях тоже наплевать , ооочень
> часто)потому что скорость нынче определяется числом открываемых https-соединений и rtt до них, ну и во вторую-третью очередь количествами наворотов в css/js, а вовсе не фоточкой.
Активно пользуюсь гитхабом, но как-то в консольку не заглядывал.
Открыл гитхаб по Вашему посылу и... эээ, ЭЭЭЭ! - https://i.imgur.com/Fl8nJIo.png
Логотип гугла для отображаемого размера 53х53 используется 2800х2800 весом 638Кб - это просто позор какой-то, братцы!
SVG не осилили, печаль (тогда бы она весила 688 bytes).
А зачем вообще существуют CMS в таком виде?
Для многого достаточно такого include, чтобы соединить например одно и то же меню слева с другим содержимым.
Поверх - такие контейнеры чтобы объединить соединить общий шаблон сайта с "документами" и позволить безгеморно их добавлять.
Ну и поверх - визуальный редактор на js который знает про инклуды и по этому редактирует шаблон из которого всё генерируется, а не то что сгенерировалось.Плюсы: Никаких форм - мы редактируем единую страницу, вставляем что угодно куда угодно, набираем текст сразу со всеми стилями, всё выглядит сразу так, как и будет на сайте.
В чём вообще плюсы отдельного интерфейса для набирания статьи? Ну хоть один?Такое есть? Сгодится для дипломной работы, выглядит простой штукой, более простой чем обычные cms.
Вообще тут конфликт интересов. Если человек способен поднять хостинг и развернуть на нем WordPress самостоятельно, то ему новый редактор ни к чему.Если он не может самостоятельно WP развернуть, то ему что старый, что новый...
Людям не способным "развернуть WP"(это может любая школота со средним айкью) надо в дворники идти....какие редакторы.
потому что человек, рисующий шаблоны сайтов и человек, добавляющий на сайт статьи - обычно два совершенно разных человека. И второму вообще не надо знать, ни про "инклуды", ни про то, как на этом сайте оно вообще должно в конце-концов выглядеть, он занимается текстом и картинками в нем.> В чём вообще плюсы отдельного интерфейса для набирания статьи? Ну хоть один?
например в том, что одна и та же статья может в разных частях сайта/в зависимости от того, что ее окружает, выглядеть разно. И заботиться об этом должна cms, а не автор статьи вручную.
А завтра дизайн вообще весь переделают - но контент не должен никуда деться и не должен начать показываться криво.
В следующей версии оставят кнонку меню , совместят строку заголовка и строку текста а всё остально перенесут в расширения магазина.
GNOME WAY
ну сделали бы этот деабильный гутенберг выбором при установке, но нет, давайте сделаем как мозилла, посчитаем всех своих юзеров за идиотов.
Изменения ради изменений - новый девиз всего IT. Теперь не обязательно, чтобы новая версия работала быстрее или лучше, не нужно закрывать дыры или улучшать эргономичность. Нет, сегодня этот подход не работает. Новая версия программы просто должна быть _не похожа_ на предыдущую. Теперь это основной критерий новизны.
> Изменения ради изменений - новый девиз всего IT. Теперь не обязательно, чтобы
> новая версия работала быстрее или лучше, не нужно закрывать дыры или
> улучшать эргономичность.Вылезайте из криокамеры:
https://www.doxdesk.com/img/updates/20101101-xara/skins.png
Ну или вспомним winamp, неро и много-много другого софта еще начала двухтысячных, примерно с таким вот "нескучным" интерфейсом:
http://drummer-rolf.com/gallery/software-nero-startsmart-ful...
в котором эргономичностью не сильно-то и "пахнет".
Ненене, софт из нулевых - отдельная тема. Там важным критерием "крутости" программы было наличие переливающихся кнопок всех форм и размеров. Если разработчик менял курсор на анимированное нечто, он автоматически начинал считать себя Архитектором из Матрицы. Это было время вырвиглазного, разномастного - и как раз оттого неудобного - софта. Программы были неудобны из-за кривых интерфейсов.
Сейчас неудобство пользования растет из попыток сменить сам принцип работы программы на заведомо нелогичный или чересчур примитивный (яркий пример - нововведения в гноме, хотя кто-то и не согласится).
Теперь дыр будет в два раза больше.
Новый редактор нужный, но для лендингов. Не для статей.
Взять и сделать свой "Вордпресс" на котором можно будет делать сайты такие же легкие как в 2005 но при этом будут иметь "все нужное" по современным меркам.
Возможно такое?
Надо настроить вордпресс, выключив ненужное, в т.ч. в шаблонах делать по-своему и юзать пэхп 7х
Для легкости есть другие CMS. Лучше под ключ для небольших сайтов
Встроить ckeditor из js, остальное на чистом пыхпе
Не знал, оказывается в новой 5 версии cke работает на npm... зараза.
выбирайте http://cmslist.ru/find_cms/
А что мешает откатиться к версии 2005 года и бекпортировать фиксы CVE за 10 лет (это и есть "все нужное")? Их много, но это явно проще, чем свое писать.
то что известные вам cve - далеко не все, что за это время было исправлено.
Что-то из исправленного так никогда и никем не было найдено, оставшись в той версии 2005го года, но это хрен с ним, эффект неуловимого джо вас спасет. Хуже когда найдено было, и тихо закрыто разработчиками, без лишнего шума.Ну и бэкпортировать фикс на код десятилетней давности (и не сломать) может оказаться сложнее, чем его переписать (в узкоспециализированный под конкретную задачу, не пытаясь повторить весь комбайн)
отдельный вопрос, где вы будете брать мильен плагинов, совместимых с той древней версией (и их тоже исправлять)
> А что мешает откатиться к версии 2005 года и бекпортировать фиксы CVE за 10 лет?Бессмысленность этой идеи.
