Сделать нормальную систему плагинов

[kerch.fm 1]

Здравствуйте. Когда вы сможете реализовать нормальную систему плагинов - через хуки, чтобы не пришлось привязываться к написанному вами коду? Потому что сейчас каждое обновление это рулетка - слетит/ не слетит плагин. Сейчас есть несколько вариантов при обновлении сайта:

1. Накатить обновление сначала на тестовом сервере, там все поправить. Однако не у всех есть свободное железо и соответствующие навыки. К тому же на тестовом сервере лицензия слетает. А если сайт реально огромный, на сотни терабайт, то прям тяжко это все организовать. Риски - высокая квалификация админа, плюс дополнительное время и ресурсы на разворачивание на тесте.
2. Перевести DLE в сервисный режим, накатить обнову и править на продакшене. Все время пока будут делаться исправления - сайт будет простаивать. Не факт что все плагины удастся легко исправить. Риски вывода сайта из работы на неопределенное время.
3. Вариант который я сам использую. Перед обновлением скачиваю архив, локально его изучаю и по каждому плагину прохожусь вручную, пытаясь выполнить те действия которые есть в плагине. Если надо, создаю обновленную версию плагина для новой версии DLE и после обновления на продакшене включаю эти плагины, отключая их старые копии. Риски - велика вероятность ошибок (можно что то не заметить) и огромный объем работы впустую, если плагинов скажем несколько десятков.

Все эти проблемы решаются легко путем вызова плагина через хуки в определенных местах, как это сделано например в Wordpress.

 

P.S. не туда написал ((
Целился в раздел "Пожелания для новых версий DataLife Engine"

Изменено 19 марта пользователем kerch.fm

[celsoft 6 092]

11 минут назад, kerch.fm сказал:

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

Никогда !!!! Потому что эта система не имеет преимуществ и имеет колосальные недостатки по производительности.

12 минут назад, kerch.fm сказал:

1. Накатить обновление сначала на тестовом сервере, там все поправить. Однако не у всех есть свободное железо и соответствующие навыки. К тому же на тестовом сервере лицензия слетает. А если сайт реально огромный, на сотни терабайт, то прям тяжко это все организовать. Риски - высокая квалификация админа, плюс дополнительное время и ресурсы на разворачивание на тесте.
2. Перевести DLE в сервисный режим, накатить обнову и править на продакшене. Все время пока будут делаться исправления - сайт будет простаивать. Не факт что все плагины удастся легко исправить. Риски вывода сайта из работы на неопределенное время.
3. Вариант который я сам использую. Перед обновлением скачиваю архив, локально его изучаю и по каждому плагину прохожусь вручную, пытаясь выполнить те действия которые есть в плагине. Если надо, создаю обновленную версию плагина для новой версии DLE и после обновления на продакшене включаю эти плагины, отключая их старые копии. Риски - велика вероятность ошибок (можно что то не заметить) и огромный объем работы впустую, если плагинов скажем несколько десятков.

Даже если делать через хуки, ни одно из этих действий не отменяется, если вы не в курсе. Если по вашему мнению, при обновлении даже если будет на хуках тестировать не нужно? То вы заблуждаетесь, нужно. И вероятность несовместимости выполняемых действий точно такая же что текущая система плагинов, что через хуки. Плюс очень много других недостатков у системы хук, поэтому система плагинов в DLE специально была разработана такой какой она есть, а не на хуках.

[kerch.fm 1]

1 минуту назад, celsoft сказал:

Никогда !!!! Потому что эта система не имеет преимуществ и имеет колосальные недостатки по производительности.

В принципе я не удивлен. Уже 6 лет прошло с момента выхода системы плагинов, а ваше мнение так и не поменялось )
Виртуальная файловая система которая была внедрена для поддержки нынешней систем плагинов также имеет влияние на производительность. Не думаю что проверка на зарегистрированные плагины в местах вызова хуков будут иметь сильное влияние. Хотя конечно все зависит от архитектуры вашего ПО и тут вам безусловно виднее. Просто вот именно такой подход с патчингом кода "на лету" я не встречал в других распространенных CMS.

 

7 минут назад, celsoft сказал:

Даже если делать через хуки, ни одно из этих действий не отменяется, если вы не в курсе. Если по вашему мнению, при обновлении даже если будет на хуках тестировать не нужно? То вы заблуждаетесь, нужно. И вероятность несовместимости выполняемых действий точно такая же что текущая система плагинов, что через хуки. Плюс очень много других недостатков у системы хук, поэтому система плагинов в DLE специально была разработана такой какой она есть, а не на хуках.

Вот тут я с вами не согласен. Хук имеет строго определенное API - перечень передаваемых аргументов и возвращаемых значений, и если внешний контракт плагина с хуком не нарушен, то ничего сломаться не должно. На этом стоит вся система плагинов, и именно в этом её сильное преимущество перед тем что вы предлагаете.

[celsoft 6 092]

1 час назад, kerch.fm сказал:

Хук имеет строго определенное API - перечень передаваемых аргументов и возвращаемых значений

Хук это не API, это место вызова с передачей аргументов. И если продукт развивается, добавляются новые возможности, оптмизируется структура данных, то изменения тоже неизбежны. 

1 час назад, kerch.fm сказал:

и если внешний контракт плагина с хуком не нарушен, то ничего сломаться не должно.

Если структура БД изменилась, то ваш код который работает со старой структурой конечно же не сломается. Вы в это искренне верите? Вопрос риторический.

Ломается все одинаково и в Wordpress плагины отваливаются на ура при обновлении. Так что тестировать предварительно нужно всегда обязательно и везде перед обновлением, независимо от CMS. Поэтому все ваши перечисленные пункты никоим образом не отменяются.

1 час назад, kerch.fm сказал:

Виртуальная файловая система которая была внедрена для поддержки нынешней систем плагинов также имеет влияние на производительность.

Удивлю вас, но нет, не влияет. Так она уж устроена, чтобы никакого влияния было вообще. Внедренный сторонний код, да может повлиять безусловно, но то как работает эта система не влияет соврешенно никак, с точки зрения выполнения PHP интерпретатором это монолитный линейный код, без сложных проверок, регистрации, расхода памяти на хранение и прочее, как в хуках. С точки зрения производительности эта лучшая система, превзойти которую не может ни один другой алгоритм. Да у нее есть свои недостатки, это большая чем у других систем зависимость от исходного кода, но при грамотном планировании плагина и грамотном определении точки входа, этот недостаток легко нивелировать при разработке плагина. Например официальный сайт содержит очень обьемный плагин чтобы реализовать нужные только нам функции, задействует более 10 файлов и еще ни разу не модифицировался при обновлении на новые версии, при этом мы никогда на него не ориентировались при разработке новых версий DLE. Просто у него грамотные точки входа, которые врядли когда изменятся в принципе в DLE, потому что врядли когда возникнет необходимость в этом. Что важнее быстродействие системы каждый день, или 2 потраченных дня в году на проверку совместимости при обновлении? Для вас может быть важнее не тратить время на проверку, хотя придется все равно, но для нас абсолютный приоритет производительность и максимально возможный низкий расход ресурсов сервера. Поэтому хуков не будет никогда.

1 час назад, kerch.fm сказал:

Не думаю что проверка на зарегистрированные плагины в местах вызова хуков будут иметь сильное влияние.

Регистрация событий происходит при каждом выполнении CMS и при каждом просмотре страницы, а не один раз и на всю жизнь когда вы его поставили. Зарегиструйте тысячи обьектов, похраните их, попроверяйте и повызывайте, проведите тесты, и только потом делаете выводы. Чтобы ваш код выполнился через хук, его нужно зарегистрировать в системе, пройтись по всем плагинам, зарегистрировать их в памяти, и только потом выполнять в нужных местах и событиях. И все это при каждом выполнении, т.е. просмотре страницы. Смотрите например обратную связь, а CMS еще и пройдет по плагинам регистрации пользователя на сайте и т.д. разместит в памяти код, и зарегиструет события и для этого ненужного точно на данной странице плагина, потому что пока его код не выполнен, неизвестно что он там делает, а его выполнение как раз и регистрирует события и хуки где его вызывать, потому что события нужно зарегистрировать в системе. Пример прожорливость приведенных выше других CMS, таких как Wordpress, 1С и других. Приведите все CMS в одни равные возможности добавив в них плагины, проверьте производительность и расхода памяти. Тогда и выводы вам стоит делать. А так это лишь ваши предположения, ни на чем не основанные. И я точно знаю что не соответствующие действительности.

[kerch.fm 1]

1 час назад, celsoft сказал:

Хук это не API, это место вызова с передачей аргументов. И если продукт развивается, добавляются новые возможности, оптмизируется структура данных, то изменения тоже неизбежны.

Хук предоставляет возможность CMS взаимодействовать с плагинами (внешними программами). А значит такое взаимодействие попадает под определение API - "программный интерфейс, то есть описание способов взаимодействия одной компьютерной программы с другими". Но терминология тут конечно вторична, и спорить об этом нет смысла.

 

1 час назад, celsoft сказал:

Если структура БД изменилась, то ваш код который работает со старой структурой конечно же не сломается. Вы в это искренне верите? Вопрос риторический.

Ломается все одинаково и в Wordpress плагины отваливаются на ура при обновлении. Так что тестировать предварительно нужно всегда обязательно и везде перед обновлением, независимо от CMS. Поэтому все ваши перечисленные пункты никоим образом не отменяются.

При правильном спроектированном API, работа плагинов не будет зависеть от внутренней структуры БД. Если вы планируете какие то изменения, которые поломают обратную совместимость - помечаете аргументы или сами хуки как deprecated и постепенно выводите их из кода. Ведь все уже давно придумано, надо просто взять удачную реализацию API за основу. А вот то, что сейчас у вас реализовано - это не плагины, это хаки. И вот как раз эти хаки крайне жестко связаны с кодом и структурой БД.

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

 

1 час назад, celsoft сказал:

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

Да не вопрос. Никогда так никогда. Ваша система, вы решаете. Просто я отметил, что для использования плагинов нужно привлекать PHP разработчиков (как минимум для написания плагина и потом для обновления системы). А с этим у клиентов часто большие проблемы. Поэтому как бы ни была хороша ваша система, но обслуживать даже несколько сайтов на DLE с разными "плагинами" - занятие утомительное для обычного вебмастера. Не говоря уже о том, чтобы как то серьезно модифицировать функциональность скрипта. Поэтому на десятках других сайтов я использовал иные CMS, потому как отдать заказчику сайт на котором потом надо каждый раз для обновления проверять все плагины, править стили и шаблоны - ну так себе идея. А уж если заказчик захочет что нибудь нестандартное реализовать, то вообще "туши свет".

 

2 часа назад, celsoft сказал:

Регистрация событий происходит при каждом выполнении CMS и при каждом просмотре страницы, а не один раз и на всю жизнь когда вы его поставили. Зарегиструйте тысячи обьектов, похраните их, попроверяйте и повызывайте, проведите тесты, и только потом делаете выводы. Чтобы ваш код выполнился через хук, его нужно зарегистрировать в системе, пройтись по всем плагинам, зарегистрировать их в памяти, и только потом выполнять в нужных местах и событиях. И все это при каждом выполнении, т.е. просмотре страницы. Смотрите например обратную связь, а CMS еще и пройдет по плагинам регистрации пользователя на сайте и т.д. разместит в памяти код, и зарегиструет события и для этого ненужного точно на данной странице плагина, потому что пока его код не выполнен, неизвестно что он там делает, а его выполнение как раз и регистрирует события и хуки где его вызывать, потому что события нужно зарегистрировать в системе. Пример прожорливость приведенных выше других CMS, таких как Wordpress, 1С и других.

Не спорю что это много работы. И хотя по скорости и прожорливости у меня нет под рукой данных, но например правильно настроенный Wordpress с кучей плагинов у меня выдавал примерно такие же показатели как и сайт на DLE (на одном и том же физическом сервере) в Lighthouse. Но в Wordpress гораздо больше настроек и возможности кастомизации + визуальный билдер Oxygen. Что для клиента явилось достаточным аргументом в пользу выбора первого - он просто дешевле в обслуживании и быстрее в запуске.

 

2 часа назад, celsoft сказал:

Приведите все CMS в одни равные возможности добавив в них плагины, проверьте производительность и расхода памяти. Тогда и выводы вам стоит делать. А так это лишь ваши предположения, ни на чем не основанные. И я точно знаю что не соответствующие действительности.

Да, возможно я и не прав. Но и вы также никаких цифр не предоставляете, а просто утверждаете что другие CMS хуже потому что то вроде "хуки тормозят систему, а виртуальная файловая система нет". По правилам полемики тот кто что либо утверждает, берет на себя бремя доказывания.

[MSK 289]

3 часа назад, kerch.fm сказал:

Просто вот именно такой подход с патчингом кода "на лету" я не встречал в других распространенных CMS.

А что вы вкладываете в понятие "на лету"?

20 минут назад, kerch.fm сказал:

По правилам полемики тот кто что либо утверждает, берет на себя бремя доказывания.

Это относится ко всем сторонам полемики ;)

[kerch.fm 1]

@celsoft Вообще изначально вашу CMS я выбрал в далеком 2012 году из за простоты работы с изображениями в статьях + поддержка мультикатегорий. Автоматическое раскладывание картинок по подпапкам + показ только тех картинок, которые загружены к новости стали киллерфичей на тот момент для журналистов (которым вечно надо как можно быстрее выложить статью и ничего не перепутать). Ну и конечно производительность скрипта была на высоте, недосягаемой тогда другим CMS. 

Но время идет, и все уже не так однозначно, хотя еще раз скажу без скрытого подкола - мне очень нравится что вы достаточно оперативно внедряете новые фичи, и следите за прогрессом. Однако жесткая централизация всего в одном ядре делает нас зависимым от обновлений раз в полгода.

Со стороны кажется что если бы у вас была нормальная система плагинов + маркет с плагинами который бы люди сами наполняли и могли продавать, Колесо Сансары вращалось бы немного быстрее релизные циклы бы сократились, вывод новых фич ускорился, а ваш кошелек стал бы толще) Хотя возможно мне это просто кажется))

4 минуты назад, MSK сказал:

А что вы вкладываете в понятие "на лету"?

В комментарии все есть, прочтите внимательно

4 минуты назад, MSK сказал:

Это относится ко всем сторонам полемики ;)

А вы адвокат celsoft?

[celsoft 6 092]

42 минуты назад, kerch.fm сказал:

При правильном спроектированном API, работа плагинов не будет зависеть от внутренней структуры БД.

Ваши теории прекрасны, но ни в одной CMS мира не работают на практике.

42 минуты назад, kerch.fm сказал:

Если вы планируете какие то изменения, которые поломают обратную совместимость - помечаете аргументы или сами хуки как deprecated и постепенно выводите их из кода. Ведь все уже давно придумано, надо просто взять удачную реализацию API за основу. А вот то, что сейчас у вас реализовано - это не плагины, это хаки. И вот как раз эти хаки крайне жестко связаны с кодом и структурой БД.

В таком случае в WordPress тоже не хуки, а хаки. Потому как там не работает так как описали вы. В таком случае вы просили моменять хаки на хаки ))

42 минуты назад, kerch.fm сказал:

И хотя по скорости и прожорливости у меня нет под рукой данных, но например правильно настроенный Wordpress с кучей плагинов у меня выдавал примерно такие же показатели как и сайт на DLE (на одном и том же физическом сервере) в Lighthouse. Но в Wordpress гораздо больше настроек и возможности кастомизации + визуальный билдер Oxygen. Что для клиента явилось достаточным аргументом в пользу выбора первого - он просто дешевле в обслуживании и быстрее в запуске.

Надо иметь такие данные, а не предполагать. Показатели чего? Расхода памяти? Даже близко не будет. Клиента устроило что?  Время отклика? Это на новом сайте его устроило, а устроит его то сколько ему придется выкладывать когда будет тысяча посетителей, а сто тысяч? Сколько будет обслуживание уже этого? Это он просчитал? Далеко не дешевле выйдет. И тут уже каждый решает сам по какому пути ему идти, один идет по одному пути, другой по другому. А потом часто бывает что и пути меняются на ту или иную сторону. Многр людей идет в Wordpess, а потом поняв что плохой путь, приходят в DLE, есть кто и наоборот идет в DLE а потом в Wordpress. DLE не Wordpess, а Wordpess даже близко не DLE. Это разные вещи для разных путей. И не нужно пытаться из одного слепить другое.

42 минуты назад, kerch.fm сказал:

По правилам полемики тот кто что либо утверждает, берет на себя бремя доказывания.

Что тут доказывать я вам в предыдущем сообщении описал пример. В системе хуков все !!!!! плагины загружаются, что бы они не делали, для чего не предназначены, все выполняются, не действия, а их код загружается в память и  компилируется интерпретатором, потом функцией регистрации хуков участки кода назначаются событиям и если событие происходит, то вызывается код из нужного плагина. Т.е. плагин например модификаци добавления публикации, будет запущен и выполнен например на странице формы обратной связи. И по другому никак.А система виртуальной файловой системы выполняет запуск уже модифицированного системой плагинов файла вместо оригинального, и все!!! никакой лишней работы.

3 часа назад, kerch.fm сказал:

Просто вот именно такой подход с патчингом кода "на лету" я не встречал в других распространенных CMS.

Нет никакого "на лету" в DLE. DLE "готовит" код один раз, когда вы ставите плагин, потом он использует "готовый" поэтому он в сотни раз быстрее хуков и прочего. Что быстрее? Сделать готовый один раз и всегда использовать готовое как DLE, или готовить и выполнять код каждый раз при загрузке любой страницы как это делает Wordpress?  Вот и вся разница.

42 минуты назад, kerch.fm сказал:

Но в Wordpress гораздо больше настроек и возможности кастомизации + визуальный билдер Oxygen.

Утверждение не соответствующее действительности ))) В Wordpress намного меньше настроек и возможностей катомизации из коробки. Для него много сторонних плагинов но это не относится уже к возможностям CMS, сообщество просто больше в разы. Но потому что это мировое сообщество, а не российская плюс модель распространение, т.е. опять таки другой путь.

42 минуты назад, kerch.fm сказал:

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

Придумано вами и не соответствует действительности, потому что на любой CMS если ее поддерживать при обновлении нужно все тщательно тестировать и проверять. А в стилях и шаблонах при обновлении новые возможности возмуться из воздуха по вашему? И на другой CMS их править не нужно? Так и в DLE шаблоны править не нужно если не нужны новые возможности, старые будут рабоать и на старых в таком случае.

42 минуты назад, kerch.fm сказал:

А уж если заказчик захочет что нибудь нестандартное реализовать, то вообще "туши свет".

Конечно зачем вам работать, лучше найти бесплатное в тысячах плагинах, и пофиг на качество, поддержку и уязвимости и отдать. Проект же сделан парой кликов, продано, все свободны. Прекрасный подход. Но не мой. Я отвечаю за то что делаю и за что беру деньги. Опять таки у вас свой путь, у меня свой. Писать код одинаково по сложности что на WordPress что на DLE, все едино, PHP он и в африке PHP. А вот взять готовое из базы плагинов других авторов не имеет никакого отношения к программированию. И когда человек говорит что писать на DLE сложно проще на wordpress это означает что он вообще ничего писать и делать не хочет, а хочет с клиента взять деньги только за то что он нажмет кнопку 'поставить плагин'.

[kerch.fm 1]

Спасибо за подробные разъяснения и извините что отнял ваше время. Вопрос закрыт.