У меня 3 домена кстати там, только что поигрался с фильтрами в beast mode проблем не увидел. Про Сбермаркет тоже не подтвердилось - только что зашел в лисе и добавил промокод - все ОК
Сбермаркет
Могу только предположить, что вы там "обвешались" аддонами которые и блокируют нормальную работу браузера
Интересная методика, заходим на сайт и ищем тупо по языку... джун, мидл, синьор, тимлид, Wordpress, Symfony - все ЗП в кучу и делим на кол-во результатов. Я подозревал, что типичный HR так и делает.
Т.е. ты предлагаешь мне самому реализовывать управление ролями в админке? Или ставить чужой велосипед?
Ну если не устроит базовый функционал и ты любишь "велосипеды" - то да.
В WP это сделать не так-то просто (и чтоб обновлялось все), если до тебя все формы реализованы с помощью стороннего плагина, так как в WP изначально нет базового инструмента для работы с формами. А он и не нужен, так как это cms для блогов, судя по всему так рассуждают разработчики)
Вот и я о том же - у вас сильно завышенные требования для простого блога.
Не надо полную реализацию. Дайте базовые интерфейсы и функционал для работы с формами. И пусть уже на основе его шлепают свои плагины и конструкторы.
Так ведь имеено базовое API и дано в виде custom fields, а дальше уже сами решайте как будете реализовывать.
WP_Query хрень какая-то. Не умеет даже JOIN, а это базовые вещи.
WP_Query делает JOIN "под капотом" для сущностей WP, если нужно что-то нестандартное - wpdb и пишем сами либо плагины.
Если бы в wp изначально был нормальный API, то не было бы всех этих велосипедов.
У WP отличный API, но если разработчик любит велосипеды то его ведь ничто не остановит, он и на условной Джумле и на Симфони начнет их писать.
stephenharris/WP-Query-Builder это сторонний инструмент. С таким подходом я могу symfony подключить. Что кстати судя по коду некоторый плагинов так же является нормой в wp разработке...
Конечно можете, что замечательно - выбор инструмента за вами.
На одном WP сайте вполне легко могут быть symfony, laravel и yii)
Я не видел, но теоретически - да, все зависит от того кто занимается разработкой, это уже на его совести.
Да, а ещё cicd, и этого хочет рынок! Это современные реалии. Это все непосредственно влияет на качество продукта.
Это хотите вы в вашем малюсеньком мирке, а рынок уже порешал в пользу WP.
WP занимает больше 60% рынка и не имеет нормального инструмента. Это позорище какое-то!
Опять же, если нет желания позорится то нужно выбирать что-то другое... но увы, рынок выбирает "ненормальный" WP и его процент растет.
Ко мне приходит человек, заказывает фичу, и у него с вероятностью 60% будет стоять WP, и нам с этим работать! Это не нормально.
Ну тут сильно зависит от разработчика, мне очень много приходилось и приходится переделывать за такими вот реализаторами фич - как понапишут велосипедов, волосы дыбом.
Если ты столь популярный, то будь добр - сделай соотвествующую инструментуную базу. Это можно сделать плавно не ломая обратную совместимость.
phpbb например спокойно перешел на symfony и там все хорошо. Почему бы WP не делать похожий шаг?
Всем мил не будешь, кого-то устраивает то что есть, а есть те, кому нужен условный симфони, так и делайте на симфони, зачем эти полумеры. WP стал популярен и продолжает быть именно из-за своей user friendly - любой пользователь может его установить и начать комфортно пользоваться улучшая плагинами и даже не привлекая разработчиков до какого-то момента.
Разница в особенностях обработки соединений. Nginx лушче работает как прокси, поэтому мы используем его в этой схеме для обработки статических данных площадки. В то же время Apache занимается интерпретацией PHP.
Вы можете объяснить, в чем преимущество Apache как php интерпретатора (вернее его модуля) перед тем-же php-fpm или Nginx Unit?
Согласен, эта древняя практика Apache + Nginx применяется сейчас либо новичками начитавшимися древних мануалов наподобии этого либо shared хостингами где тот-же новичок постучится в саппорт и начнет жаловаться что у него .htaccess файл "не работает".
Да как захотите, если не устраивает базовый функционал - плагины, которые собственно и используют это API.
Это значит что я могу с помощью одного инструмента гибко делать формы любого типа как в админке, так и на самом сайте. Как динамические, так и статичные.
Ну как я и писал выше - ACF и его аналоги, если хотите мышкой - Gravity Forms.
Сейчас чтоб настроить конструктор форм с нестандартным поведением на Ajax надо "выкрутиться буковой дзю", и так чтоб при обновлении плагина ни чего не отвалилось.
Не совсем понятно про "нестандартное поведение на Ajax", но тут уже скорее дело в разработчике выбравшем неверный инструмент, а скорее всего начавший как вы говорите "писать велосипеды". Популярные плагины (ACF, GravityForms, Toolset, Meta Box) имеют отличную обратную совместимость.
Если бы из коробки был стандартный инструмент, то таких проблем не было бы.
Я же писал выше, из коробки вам дают базовое API. Если его мало - плагины на его основе. Этот подход выгодно отличает WP от той же Jumla - тебе не суют в "коробку" все что нужно и не нужно, а дают выбор, если нужен доп функционал нет какого то единого "православного" инструмента all in one - есть множество аддонов разной степени сложности и функционала. Поэтому эта ваша проблема надумана.
Покажите пожалуйста где в API WP находится QueryBuilder или ORM? Покажите с помощью каких функций (объектной модели ведь нет) можно реализовать CRUD в админке со своей таблицей?
С базовым построением запросов прекрасно справляется и WP_Query, если этого мало - есть альтернатива. Реализации CRUD тоже есть, я знаком с wpDataTables, но есть конечно еще.
Но вообще конечно у вас интересные запросы к CMS (коей WP и является), вам хочется неимоверно гибкий RBAC, ORM, ActiveRecord, QueryBuilder... еще бы полноценный MVC и шаблонизатор, Twig например, URI routing гибкий, ну и как это все тестировать - PHPUnit конечно! Нсли вам нужно все это, то вы наверняка хотите реализовывать сложную бизнес-логику (если нет, вы оч. "странный") и путь вам лежит к полноценным фреймворкам Yii, Laravel ну и конечно Symfony. Наверное потому и WP в разы и популярнее той же Джумлы, т.к. знает свое место и не пытается впихать все что нужно и не нужно, оставаясь user friendly и при этом годной для разработки.
Какие именно? Roles - есть, capabilities - есть, с помощью этого уже можно работать полноценно.
Нет общего инструмента для форм и админки в целом. Везде свои велосипеды.
Что значит "общий" инструмент? Есть custom fields и как вы будете с ними работать уже лично ваш выбор, хотите велосипедов - пишите или возьмите готовые инструменты - тот-же ACF, хотите с множеством настроек - GravityForms - решений навалом.
Полноценный инструмент где есть набор инструментом избавляющих от написания велосипедов.
У меня 3 домена кстати там, только что поигрался с фильтрами в beast mode проблем не увидел. Про Сбермаркет тоже не подтвердилось - только что зашел в лисе и добавил промокод - все ОК
Сбермаркет
Могу только предположить, что вы там "обвешались" аддонами которые и блокируют нормальную работу браузера
Ну "как пример" нужна ссылка
Там редирект на www.nalog.gov.ru но все открылось и работает, про сертификат не понял
Очень похожий график
Ну про "вообще нет" это не правда, мало - да.
Есть uBlock Origin, AdGuard
Интересная методика, заходим на сайт и ищем тупо по языку... джун, мидл, синьор, тимлид, Wordpress, Symfony - все ЗП в кучу и делим на кол-во результатов. Я подозревал, что типичный HR так и делает.
Я сам на винде, восстанавливаю вкладки (когда мне это нужно) через меню FF: History -> Restore previous session
А есть примеры таких сайтов?
А можно подробностей? Сам просто недавно начал использовать VGA->HDMI в 2-х местах и нареканий пока нет.
Нет смысла парсить этот сайт, на порядок быстрее и проще спарсить ресурсы откуда этот сайт напарсил свои результаты - sudrf.ru, сайт минюста и т.п.
Ну если не устроит базовый функционал и ты любишь "велосипеды" - то да.
Вот и я о том же - у вас сильно завышенные требования для простого блога.
Так ведь имеено базовое API и дано в виде custom fields, а дальше уже сами решайте как будете реализовывать.
WP_Query делает JOIN "под капотом" для сущностей WP, если нужно что-то нестандартное - wpdb и пишем сами либо плагины.
У WP отличный API, но если разработчик любит велосипеды то его ведь ничто не остановит, он и на условной Джумле и на Симфони начнет их писать.
Конечно можете, что замечательно - выбор инструмента за вами.
Я не видел, но теоретически - да, все зависит от того кто занимается разработкой, это уже на его совести.
Это хотите вы в вашем малюсеньком мирке, а рынок уже порешал в пользу WP.
Опять же, если нет желания позорится то нужно выбирать что-то другое... но увы, рынок выбирает "ненормальный" WP и его процент растет.
Ну тут сильно зависит от разработчика, мне очень много приходилось и приходится переделывать за такими вот реализаторами фич - как понапишут велосипедов, волосы дыбом.
Всем мил не будешь, кого-то устраивает то что есть, а есть те, кому нужен условный симфони, так и делайте на симфони, зачем эти полумеры. WP стал популярен и продолжает быть именно из-за своей user friendly - любой пользователь может его установить и начать комфортно пользоваться улучшая плагинами и даже не привлекая разработчиков до какого-то момента.
А зачем в этой связке вам Апач?
Вы можете объяснить, в чем преимущество Apache как php интерпретатора (вернее его модуля) перед тем-же php-fpm или Nginx Unit?
Согласен, эта древняя практика Apache + Nginx применяется сейчас либо новичками начитавшимися древних мануалов наподобии этого либо shared хостингами где тот-же новичок постучится в саппорт и начнет жаловаться что у него
.htaccessфайл "не работает".Да как захотите, если не устраивает базовый функционал - плагины, которые собственно и используют это API.
Ну как я и писал выше - ACF и его аналоги, если хотите мышкой - Gravity Forms.
Не совсем понятно про "нестандартное поведение на Ajax", но тут уже скорее дело в разработчике выбравшем неверный инструмент, а скорее всего начавший как вы говорите "писать велосипеды". Популярные плагины (ACF, GravityForms, Toolset, Meta Box) имеют отличную обратную совместимость.
Я же писал выше, из коробки вам дают базовое API. Если его мало - плагины на его основе. Этот подход выгодно отличает WP от той же Jumla - тебе не суют в "коробку" все что нужно и не нужно, а дают выбор, если нужен доп функционал нет какого то единого "православного" инструмента all in one - есть множество аддонов разной степени сложности и функционала. Поэтому эта ваша проблема надумана.
С базовым построением запросов прекрасно справляется и WP_Query, если этого мало - есть альтернатива. Реализации CRUD тоже есть, я знаком с wpDataTables, но есть конечно еще.
Но вообще конечно у вас интересные запросы к CMS (коей WP и является), вам хочется неимоверно гибкий RBAC, ORM, ActiveRecord, QueryBuilder... еще бы полноценный MVC и шаблонизатор, Twig например, URI routing гибкий, ну и как это все тестировать - PHPUnit конечно! Нсли вам нужно все это, то вы наверняка хотите реализовывать сложную бизнес-логику (если нет, вы оч. "странный") и путь вам лежит к полноценным фреймворкам Yii, Laravel ну и конечно Symfony. Наверное потому и WP в разы и популярнее той же Джумлы, т.к. знает свое место и не пытается впихать все что нужно и не нужно, оставаясь user friendly и при этом годной для разработки.
Нормально так... для начала 2000-х
Какие именно? Roles - есть, capabilities - есть, с помощью этого уже можно работать полноценно.
Что значит "общий" инструмент? Есть custom fields и как вы будете с ними работать уже лично ваш выбор, хотите велосипедов - пишите или возьмите готовые инструменты - тот-же ACF, хотите с множеством настроек - GravityForms - решений навалом.
Все есть - выбирайте.
А что вы имеете ввиду под API? И чем "ненормален" он в WP?
И правда, давайте смотреть объективно
Правильно, нужно в каждую семью видеонаблюдение и ежедневный визит соцработника, а то мало ли чему они его там учат