Снова о блокировке компонентов
В одном из прежних постов рассказывал что в Joostina мы добавили возможность блокировки компонентов. для этого в таблице было создано новое поле access, которе в дальнейшем предполагалось использовать так же для разграничения доступа к компоненту по группам.
Но всё же пришлось отказаться от использования нового поля... Расскажу почему.
При установке расширений совершаются запросы в базу, записываются новые данные в компоненте, его подпункты меню и т.д. Всё хорошо если запросы выполняются только ядром. Но иногда сами компоненты делают прямые SQL запросы в таблицу компонентов
Например компонент файлового архива jDownloads (1.4.2 RC), файл install.jdownloads.php:
INSERT INTO jos_components VALUES (NULL, 'jDownloads', 'option=com_jdownloads', 0, 0, 'option=com_jdownloads', 'jDownloads', 'com_jdownloads', 0, '../administrator/components/com_jdownloads/images/m_jdownloads.gif', 0, '').
Запрос выполняется без явного указания столбцов для записей, и MySQL записывает данные в порядке расположения.
Тут последний элемент записи - '', он отвечает за данные вносимые в столбец params, являющийся последним в прежних версиях Joostina, и предпоследним в 1.3.0 версии.
Но у нас же новое поле - access, про которое jDownloads ничего не знает. И получается что это поле не получает значения для записи. Тут и возникает ошибка, MySQL сообщает что не все данные получены, и запрос НЕ выполняется. В следствии чего запись в базе не появляется и компонент и не считается установленным.
Вот такое неинтересное кино...
В качестве решения проблемы выбрали неиспользуемый столбец menuid той же таблицы, и немного изменили условие. Теперь если menuid=0, что по умолчанию, то компонент доступен. Если menuid=1 - то доступ к компоненту блокируется.
Занавес.
Но всё же пришлось отказаться от использования нового поля... Расскажу почему.
При установке расширений совершаются запросы в базу, записываются новые данные в компоненте, его подпункты меню и т.д. Всё хорошо если запросы выполняются только ядром. Но иногда сами компоненты делают прямые SQL запросы в таблицу компонентов
Например компонент файлового архива jDownloads (1.4.2 RC), файл install.jdownloads.php:
INSERT INTO jos_components VALUES (NULL, 'jDownloads', 'option=com_jdownloads', 0, 0, 'option=com_jdownloads', 'jDownloads', 'com_jdownloads', 0, '../administrator/components/com_jdownloads/images/m_jdownloads.gif', 0, '').
Запрос выполняется без явного указания столбцов для записей, и MySQL записывает данные в порядке расположения.
Тут последний элемент записи - '', он отвечает за данные вносимые в столбец params, являющийся последним в прежних версиях Joostina, и предпоследним в 1.3.0 версии.
Но у нас же новое поле - access, про которое jDownloads ничего не знает. И получается что это поле не получает значения для записи. Тут и возникает ошибка, MySQL сообщает что не все данные получены, и запрос НЕ выполняется. В следствии чего запись в базе не появляется и компонент и не считается установленным.
Вот такое неинтересное кино...
В качестве решения проблемы выбрали неиспользуемый столбец menuid той же таблицы, и немного изменили условие. Теперь если menuid=0, что по умолчанию, то компонент доступен. Если menuid=1 - то доступ к компоненту блокируется.
Занавес.
« Встречаемся в реале! | Joostina SERVER » |
---|
Категории
- Joostina 1.2.0 ( 1 )
- Joostina 1.3.0 ( 20 )
- Фишки ( 1 )
- Расширения ( 3 )
- Советы ( 13 )
- Процесс ( 3 )
- Обо всём ( 9 )
- Форум для Joostina ( 2 )
- Разработка YaForms ( 3 )
- Книга «Реактивные веб-сайты» ( 3 )
Комментарии
- Chongbuire → Вариант переезда с Joostina 1.2.0 на 1.3.0
- Davidlic → Вариант переезда с Joostina 1.2.0 на 1.3.0
- Josephamind → Вариант переезда с Joostina 1.2.0 на 1.3.0
- Williamrof → Вариант переезда с Joostina 1.2.0 на 1.3.0
- FrankNap → Вариант переезда с Joostina 1.2.0 на 1.3.0
- Howardslina → Вариант переезда с Joostina 1.2.0 на 1.3.0
- AlbertAsymn → Вариант переезда с Joostina 1.2.0 на 1.3.0