Foren / National / Russian / Тех. поддержка / Взаимо исключение расширений

webitproff
#1 3. Juni 2023, 13:41

Уважаемые участники команды Cotonti и разработчики!

Большая просьба, прошу помочь с практическим решением такого вопроса.

пример с названием плагинов гипотетический.

 

   1. В админке находится три редактора разметки

       а) CKEditor - не установлен

       б) MarkItUp! - установлен

       в) TinyMCE - приостановлен

 

   2. Требуется установка "CKEditor" - но владелец сайта в этом тупо болван как и я в хирургии,

   и не понимает, что это может и вызовет конфликты, а также недоразумения,

   почему "CKEditor" установили, а на сайте по прежнему в редакторировании текста в статьях задействован "MarkItUp!"...

   Собственно и вопрос:

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

Например мы зашли на страницу деталей плагина "CKEditor"

https://cotontiproject.com/admin/extensions?a=details&pl=ckeditor

и потому как, у нас MarkItUp! - установлен, - мы получаем уорнинг:

"Для установки CKEditor, - следует удалить такие расширения:

  • MarkItUp!
  • TinyMCE

а затем в конфигурации плагина HTML Parser, назначить "CKEditor" для использования в системе по умолчанию "

 

 

аккаунт удален - не срослось с разработчиками
ушел на другой движок
Dayver
#2 3. Juni 2023, 15:25

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

Допустим есть сайт и в нём для модуля Page на котором реализованы статьи на сайте устанавливается парсер html который даст огромные возможности в оформлении статей а значит для него устаналиваем визуальный редактор - предположим CKEditor а вот на форуме или комментариях такие обширные возможности в оформлении давать не стоит потому логичнее иметь парсер BBCode и под него MarkItUp. Тогда лочино что в системе будет два парсера и два виз редактора и если бы в системе была взаимоисключающа блокировка то такой сценарий не было бы возможности реализовать. Потому то стема и базируется не на факте установлености парсера\виз.редактора как плагина а на факте выбора для каждого модуля в его настройках своего парсера из доступных установленых в системе или в конфиге движка парсера по умолчанию.

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

Да и вообще следует помнить что Cotonti не чистая CMS а и CMF что подразумевает под собой гибкость и возможность реализовать разные типы сайты с разными функциональными возможностями.

 

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

  • Нужно вводить сопутствующий функционал который позволит задавать расширениям что то подобие категорий. Не те категории которые есть сейчас указание которых просто добавляет в список расширений разбивку на группы, а "функциональные категории" указание которых позволит проводить проверку типа "для категории расширения-пылесосы разрешать только одно расширение"
  • И собстенно если будет такая "категоризация\типизация" а так же будет выбор "Разрешать для такой-то категории множественные расширения или нет?!" то это тогда и нужно еще делать возможность совершать такую конфигурацию из админки, а не только из блока [BEGIN_COT_EXT][END_COT_EXT] файла plugin.setup.php что б было гибко и удобно

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

Pavlo Tkachenko aka Dayver
webitproff
#3 3. Juni 2023, 15:40
#46840 Dayver:

Если смотреть на вопрос конкретно в разрезе визуальных редакторов и парсеров то тут изначально вопрос поставлен узконаправлено. Система позволяет ....

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

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

Тем более, чтоб добавить заявку к ветке, я не совсем представляю,

как мне правильно и грамотно, техническим языком её сформулировать,

чтобы она была легко реконструирована

и наполненна логическим смыслом в сознании разработчика.

аккаунт удален - не срослось с разработчиками
ушел на другой движок

Dieser Beitrag wurde von webitproff (am 3. Juni 2023, 15:45, vor 9 Monate) bearbeitet