В статье сплошная вода, кроме упоминания JIT. Я считаю что JIT для обычных сайтов не даст существенного прироста из-за того что там скорость выполнения php кода не является узким местом.
Для runtime приложений даст, но для этих задач есть более подходящие стеки.
ИМХО тенденция идёт к тому что разработчики php начнут переходить на другие стеки. PHP будет оставаться в нише MVP, сайтов, панелей и админок. И это не плохо. Он действительно там лучший. Считаю что разработчикам языка php необходимо сосредоточиться именно на этих сферах и усилить позиции языка как наилучшее решение.
Т.е. ты предлагаешь мне самому реализовывать управление ролями в админке? Или ставить чужой велосипед?
Ну как я и писал выше - ACF и его аналоги, если хотите мышкой - Gravity Forms.
А если сторонняя студия или какой-то программистзаложил другой плагин и надо на его базе реализовать не типичное поведение?
Не совсем понятно про "нестандартное поведение на Ajax", но тут уже скорее дело в разработчике выбравшем неверный инструмент, а скорее всего начавший как вы говорите "писать велосипеды".
Есть форма которая перед тем как сказать пользователю что все хорошо и сейчас ты перейдёшь на форму с банковскими реквизитами, делает валидацию на backend и получает ссылку оплаты по API через REST API, получаем её делая обычный Ajax запрос. Ajax, так как все ассинхронные запросы в js изначально основаны XMLHttpRequest, это потом появился Fetch API, а у WP нет своей библиотеки и все пихают свои jquery (как я понял для wp это нормально, что на одной странице может быть три разных jquery, от шаблона и каких-то плагинов). Я же использовал ванильный js и XMLHttpRequest чтоб не отвалились старые браузеры.
Формы все разные и делают их пользователи мышью с помощью конструктора в админке.
У меня таких сайтов было 3 штуки, с двумя разными плагинами форм.
В WP это сделать не так-то просто (и чтоб обновлялось все), если до тебя все формы реализованы с помощью стороннего плагина, так как в WP изначально нет базового инструмента для работы с формами. А он и не нужен, так как это cms для блогов, судя по всему так рассуждают разработчики)
Я же писал выше, из коробки вам дают базовое API. Если его мало - плагины на его основе. Этот подход выгодно отличает WP от той же Jumla - тебе не суют в "коробку" все что нужно и не нужно, а дают выбор, если нужен доп функционал нет какого то единого "православного" инструмента all in one - есть множество аддонов разной степени сложности и функционала. Поэтому эта ваша проблема надумана.
Не надо полную реализацию. Дайте базовые интерфейсы и функционал для работы с формами. И пусть уже на основе его шлепают свои плагины и конструкторы.
С базовым построением запросов прекрасно справляется и WP_Query, если этого мало - есть альтернатива. Реализации CRUD тоже есть, я знаком с wpDataTables, но есть конечно еще.
WP_Query хрень какая-то. Не умеет даже JOIN, а это базовые вещи. Если бы в wp изначально был нормальный API, то не было бы всех этих велосипедов.
stephenharris/WP-Query-Builder это сторонний инструмент. С таким подходом я могу symfony подключить. Что кстати судя по коду некоторый плагинов так же является нормой в wp разработке... В итоге один плагин - один фреймворк. На одном WP сайте вполне легко могут быть symfony, laravel и yii)
Но вообще конечно у вас интересные запросы к CMS (коей WP и является), вам хочется неимоверно гибкий RBAC, ORM, ActiveRecord, QueryBuilder... еще бы полноценный MVC и шаблонизатор, Twig например, URI routing гибкий, ну и как это все тестировать - PHPUnit конечно!
Да, а ещё cicd, и этого хочет рынок! Это современные реалии. Это все непосредственно влияет на качество продукта.
WP занимает больше 60% рынка и не имеет нормального инструмента. Это позорище какое-то!
Ко мне приходит человек, заказывает фичу, и у него с вероятностью 60% будет стоять WP, и нам с этим работать! Это не нормально.
Если ты столь популярный, то будь добр - сделай соотвествующую инструментуную базу. Это можно сделать плавно не ломая обратную совместимость. Ведь они находят где-то ресурсы чтоб перелопатать полностью всю админку.
phpbb например спокойно перешел на symfony и там все хорошо. Почему бы WP не делать похожий шаг?
Roles - есть, capabilities - есть, с помощью этого уже можно работать полноценно.
В админке как это выглядит?
Что значит "общий" инструмент?
Это значит что я могу с помощью одного инструмента гибко делать формы любого типа как в админке, так и на самом сайте. Как динамические, так и статичные.
Сейчас чтоб настроить конструктор форм с нестандартным поведением на Ajax надо "выкрутиться буковой дзю", и так чтоб при обновлении плагина ни чего не отвалилось.
Если бы из коробки был стандартный инструмент, то таких проблем не было бы.
Покажите пожалуйста где в API WP находится QueryBuilder или ORM? Покажите с помощью каких функций (объектной модели ведь нет) можно реализовать CRUD в админке со своей таблицей?
Депутаты просто говорят скатертью дорога, им тут спецы не особо то и нужны, трубы то проложены уже)
Не всё так просто. Посмотрите на пример Венисуэлы, где за управление нефтянкой встали силовики. В итоге это обернулось большими потерями из-за аварий. Даже для обслуживания простой трубы требуются люди с мозгами.
Помимо труб есть ещё куча заводов и атомная энергетика, где мы ещё пока находимся на лидирующих позициях.
А я как разработчик выберу джумлу из-за нормального API.
У меня есть опыт написания достаточно сложных плагинов для обеих CMS. В случае с WP приходится либо подключать сторонний фреймворк, либо писать велосипеды.
В Joomla под капотом полноценный фреймворк, хоть и устаревший.
как из-за демографической ямы в 1990-е годы, так и из-за пандемии коронавируса
Слышал про существенную часть молодых специалистов которые уехали из страны по политическим причинам. При том что это именно специалисты, а не молодежь в китайских адибасах с семками в падиках.
И острая ситуация с недостатоском таких людей может аукнуться нам закрытием границ в виде косвенных причин.
Это связано с сырым API. В мобильной лисе доступны расширения для которых реализован 100% рабочий API.
Делают поддержку в первую очередь для самых популярных расширений.
Я пользуюсь мобильной лисой давно и буквально вижу на глазах как пополняется список плагинов.
Онлайн читалка у PocketBook не пашет. Саппорт отправляет пользоваться хромым.
Пожалуй на этом дискуссию можно закончить)
Спасибо!
В статье сплошная вода, кроме упоминания JIT. Я считаю что JIT для обычных сайтов не даст существенного прироста из-за того что там скорость выполнения php кода не является узким местом.
Для runtime приложений даст, но для этих задач есть более подходящие стеки.
ИМХО тенденция идёт к тому что разработчики php начнут переходить на другие стеки. PHP будет оставаться в нише MVP, сайтов, панелей и админок. И это не плохо. Он действительно там лучший. Считаю что разработчикам языка php необходимо сосредоточиться именно на этих сферах и усилить позиции языка как наилучшее решение.
Так исправьте заголовок. Как парсить википедию.
Если вы реально попробуете парсить какой нибудь сайт объявлений, то для вас будет очень много интересных открытий.
Мы начинаем платить налоги как только родились. Как минимум в виде НДС на товары. Так или иначе потом отдаём долг родителям.
Т.е. ты предлагаешь мне самому реализовывать управление ролями в админке? Или ставить чужой велосипед?
А если сторонняя студия или какой-то программистзаложил другой плагин и надо на его базе реализовать не типичное поведение?
Есть форма которая перед тем как сказать пользователю что все хорошо и сейчас ты перейдёшь на форму с банковскими реквизитами, делает валидацию на backend и получает ссылку оплаты по API через REST API, получаем её делая обычный Ajax запрос. Ajax, так как все ассинхронные запросы в js изначально основаны XMLHttpRequest, это потом появился Fetch API, а у WP нет своей библиотеки и все пихают свои jquery (как я понял для wp это нормально, что на одной странице может быть три разных jquery, от шаблона и каких-то плагинов). Я же использовал ванильный js и XMLHttpRequest чтоб не отвалились старые браузеры.
Формы все разные и делают их пользователи мышью с помощью конструктора в админке.
У меня таких сайтов было 3 штуки, с двумя разными плагинами форм.
В WP это сделать не так-то просто (и чтоб обновлялось все), если до тебя все формы реализованы с помощью стороннего плагина, так как в WP изначально нет базового инструмента для работы с формами. А он и не нужен, так как это cms для блогов, судя по всему так рассуждают разработчики)
Не надо полную реализацию. Дайте базовые интерфейсы и функционал для работы с формами. И пусть уже на основе его шлепают свои плагины и конструкторы.
WP_Query хрень какая-то. Не умеет даже JOIN, а это базовые вещи.
Если бы в wp изначально был нормальный API, то не было бы всех этих велосипедов.
stephenharris/WP-Query-Builder это сторонний инструмент. С таким подходом я могу symfony подключить. Что кстати судя по коду некоторый плагинов так же является нормой в wp разработке... В итоге один плагин - один фреймворк. На одном WP сайте вполне легко могут быть symfony, laravel и yii)
Да, а ещё cicd, и этого хочет рынок! Это современные реалии. Это все непосредственно влияет на качество продукта.
WP занимает больше 60% рынка и не имеет нормального инструмента. Это позорище какое-то!
Ко мне приходит человек, заказывает фичу, и у него с вероятностью 60% будет стоять WP, и нам с этим работать! Это не нормально.
Если ты столь популярный, то будь добр - сделай соотвествующую инструментуную базу. Это можно сделать плавно не ломая обратную совместимость. Ведь они находят где-то ресурсы чтоб перелопатать полностью всю админку.
phpbb например спокойно перешел на symfony и там все хорошо. Почему бы WP не делать похожий шаг?
Возможно многие предпочитают быстренько скачивать фильм на вечер, а 4К качают ценители или заранее.
В админке как это выглядит?
Это значит что я могу с помощью одного инструмента гибко делать формы любого типа как в админке, так и на самом сайте. Как динамические, так и статичные.
Сейчас чтоб настроить конструктор форм с нестандартным поведением на Ajax надо "выкрутиться буковой дзю", и так чтоб при обновлении плагина ни чего не отвалилось.
Если бы из коробки был стандартный инструмент, то таких проблем не было бы.
Покажите пожалуйста где в API WP находится QueryBuilder или ORM? Покажите с помощью каких функций (объектной модели ведь нет) можно реализовать CRUD в админке со своей таблицей?
Ну например с RBAC в WP проблемы.
Нет общего инструмента для форм и админки в целом. Везде свои велосипеды.
Даже с базой работать трудно. Нет ORM и ActiveRecord, что критично для построения CRUD приложений.
А ещё наследие CMS как исключителньо движка для блогов - всё есть post.
Полноценный инструмент где есть набор инструментов избавляющих от написания велосипедов.
Телевизоры с хорошей картинкой становятся более доступными, следовательно спрос на фильмы и сериалы в хорошем качестве должен увеличиться.
Но это я так, продолжаю дискуссию)
Даже сырьевая экономика конкурирует на глобальном рынке. Чтоб быть конкурентноспособным необходимо использовать современные технологии.
Тот же самый Новатек требует достаточно много квалифицированных специалистов. Как я понимаю они даже построили НТЦ в Тюмени.
Даже на обычном карьере требуются люди заниющиеся автоматизацией.
Для обычных шахт так же требуются химики.
Обычные нефтевышки обслуживают инженеры.
Не всё так просто. Посмотрите на пример Венисуэлы, где за управление нефтянкой встали силовики. В итоге это обернулось большими потерями из-за аварий. Даже для обслуживания простой трубы требуются люди с мозгами.
Помимо труб есть ещё куча заводов и атомная энергетика, где мы ещё пока находимся на лидирующих позициях.
А я как разработчик выберу джумлу из-за нормального API.
У меня есть опыт написания достаточно сложных плагинов для обеих CMS. В случае с WP приходится либо подключать сторонний фреймворк, либо писать велосипеды.
В Joomla под капотом полноценный фреймворк, хоть и устаревший.
Нет смысла. За своих детей уже заплатили родители в виде налогов и здоровья. Посмотрите какие нищебродские пенсии в стране!
Удерживать специалистов надо созданием привлекательных условий.
Соглашусь. С качественной картинкой на стрименговых сервисах пока ещё есть проблема.
Однако с увеличением пропускной способности и количеством CDN, появлением новых кодеков, проблема начнет решаться.
Я говорю именно про специалистов.
Не так давно была инициатива депутатов обязывающую закончивших ВУЗы отрабатывать сколько-то лет по специальности на территории РФ.
А вы joomla какой версии рассматривали?
И смотрели ли вы cms на базе фреймворков?
Например на базе очень популярного в России Yii: luya.io и craftcms.com?
Слышал про существенную часть молодых специалистов которые уехали из страны по политическим причинам. При том что это именно специалисты, а не молодежь в китайских адибасах с семками в падиках.
И острая ситуация с недостатоском таких людей может аукнуться нам закрытием границ в виде косвенных причин.
DRM бесмысленнен в эпоху стрименговых сервисов. Сейчас гораздо удобнее и быстрее отдать 100 рублей за прокат фильма, чем запариваться с пиратством.