Тема: Как создать таблицу в базе данных Joomla? Таблицы базы данных joomla
Список таблиц базы данных Joomla 3 (сразу после установки)
CMS Joomla работает на движке, написанном на языке программирования PHP. Данные, которые требуются для работы сайта и админки Joomla хранятся в базе данных (обычно это MySQL). В этой статье представлен список таблиц базы данных сайта только что установленной Joomla (версии 3.8.4). Дистрибутив взят на официальном сайте, никаких дополнительных компонентов, языков, шаблонов не устанавливалось. Это база данных Joomla без дополнительных расширений.
Для того, чтобы посмотреть список таблиц базы данных Joomla проще всего воспользоваться программой phpMyAdmin (она обычно установлена на всех серверах хостингов. Как это сделать, подробно описано в → этой статье. Итак, собственно сам список таблиц:
Список таблиц базы данных Joomla 3 (сразу после установки)
- assets
- associations
- banners
- banner_clients
- banner_tracks
- categories
- contact_details
- content
- contentitem_tag_map
- content_frontpage
- content_rating
- content_types
- core_log_searches
- extensions
- fields
- fields_categories
- fields_groups
- fields_values
- finder_filters
- finder_links
- finder_links_terms0
- finder_links_terms1
- finder_links_terms2
- finder_links_terms3
- finder_links_terms4
- finder_links_terms5
- finder_links_terms6
- finder_links_terms7
- finder_links_terms8
- finder_links_terms9
- finder_links_termsa
- finder_links_termsb
- finder_links_termsc
- finder_links_termsd
- finder_links_termse
- finder_links_termsf
- finder_taxonomy
- finder_taxonomy_map
- finder_terms
- finder_terms_common
- finder_tokens
- finder_tokens_aggregate
- finder_types
- languages
- menu
- menu_types
- messages
- messages_cfg
- modules
- modules_menu
- newsfeeds
- overrider
- postinstall_messages
- redirect_links
- schemas
- session
- tags
- template_styles
- ucm_base
- ucm_content
- ucm_history
- updates
- update_sites
- update_sites_extensions
- usergroups
- users
- user_keys
- user_notes
- user_profiles
- user_usergroup_map
- utf8_conversion
- viewlevels
Всего 72 таблицы.
Заберите ссылку на статью к себе, чтобы потом легко её найти ;)
Выберите, то, чем пользуетесь чаще всего:
Спасибо за внимание, оставайтесь на связи! Ниже ссылка на форум и обсуждение ; )
Discuss this article
INFO: You are posting the message as a 'Guest'
mb4.ru
Разработка компонента для Joomla 2.5 (com_djminiprice): Урок 1. Проектируем структуру таблицы базы данных
Разработка компонента для Joomla 2.5 (com_djminiprice): Урок 1. Проектируем структуру таблицы базы данных
Во введении мы уже разобрались с тем, чем мы будем заниматься. Также мы выделили необходимые нам свойства. На этом уроке мы создадим структуру таблицы базы данных, которая будет необходима для работы нашего компонента.
Сразу следует оговориться, что, при проектировании нужно уделить достаточное внимание, чтобы предусмотреть различные возможности, но и зацикливаться на проектировании не стоит. В любом случае, первый вариант практически всегда вы процессе работы подвергается изменению, но чем меньше будет изменений, тем нам же лучше. Перед нами стоит достаточно простая задача, поэтому мы обойдемся одной таблицей, в которой будут храниться данные компонента.
Давайте разберемся с типами полей, к свойствам товара я добавил еще поле id – уникальный идентификатор записи, он же будет первичным ключом, checked_out и checked_out_time для реализации групповых операций с товарами:
- идентификатор записи: id – int (11);
- наименование товара: name – varchar (255);
- состояние товара (опубликован/не опубликован): state – tinyint;
- код товара (артикул): sku – varchar(50);
- цена товара: price – varchar(50);
- категория товара (категории будем использовать стандартные): catid – int(11);
- порядок товара (для возможности сортировки): ordering – int(11);
- checked_out – int(11);
- checked_out_time – datetime;
- описание товара: description – text;
- изображение товара: image – varchar(255).
В общем-то, все просто. К тому же при именовании полей таблицы и указании их типов я ориентировался на стандартные поля таблиц CMS Joomla.
А вот sql код для создания таблицы, для удобства и простоты для его создания и использовал phpmyadmin.
CREATE TABLE IF NOT EXISTS `jos_djminiprice_product` ( `id` int(11) UNSIGNED NOT NULL AUTO_INCREMENT, `name` VARCHAR(255) NOT NULL , `state` TINYINT(1) NOT NULL DEFAULT '1', `sku` VARCHAR(255) NOT NULL , `price` VARCHAR(255) NOT NULL , `catid` INT(11) NOT NULL , `ordering` INT(11) NOT NULL , `checked_out` INT(11) NOT NULL , `checked_out_time` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00', `description` TEXT NOT NULL , `image` VARCHAR(255) NOT NULL , PRIMARY KEY (`id`) ) DEFAULT COLLATE=utf8_general_ci;www.dev-joomla.ru
Таблицы InnoDB при разработке расширений Joomla
Начиная с версии 3.0 Joomla стала для базы данных MySQL использовать по умолчанию таблицы типа InnoDB. Движок InnoDB считается более продвинутым по сравнению с MyISAM, он поддерживает транзакции с различными уровнями изоляции и внешние ключи, позволяя контролировать целостность данных на уровне СУБД. Что же дает использование этого типа таблиц для Joomla?
Особенности таблиц InnoDB
Основные отличиями таблиц InnoDB от MyISAM:
- блокировки чтения/записи на уровне строк, а не целых таблиц;
- поддержка целостности данных через внешние ключи;
- поддержка транзакций;
- обработка каскадных удалений и обновлений при использовании внешнего ключа.
Если не вдаваться в подробности, то можно сказать что сильные стороны InnoDB проявляются на больших объемах данных с большим количеством одновременных запросов. Точнее падение скорости обработки запросов InnoDB при значительном росте объема данных будет намного меньше чем у таблиц MyISAM. Транзакции и внешние ключи, можно сказать, являются со стороны CMS дополнением к собственным системам контроля. Они требуют дополнительных затрат на разработку и незначительно снижают скорость запросов, но зато гарантируют целостность и соответствие данных.
Надо заметить, что движок MyISAM не зря долгое время использовался Joomla как основной и считается движком по умолчанию для MySQL. При последовательных запросах, на небольших таблицах, движок MyISAM дает выигрыш в скорости выборки данных. Еще одним преимуществом движка MyISAM является полнотекстовой поиск. То есть для многих, если не большинства, сайтов Joomla движок MyISAM будет заведомо лучшим выбором.
Как же используются возможности InnoDB в расширениях Joomla и как их можно использовать при разработке собственных расширений?
InnoDB в расширениях Joomla
Joomla 3 хоть и переведена на InnoDB, но в схеме базы данных даже версии 3.4.3 внешние ключи не используются ни в системных таблицах, ни в таблицах встроенных расширений.
Использование транзакций в коде системы встречается только единожды — в классе FOFTableNested, который в расширениях Joomla не используется.
Видимо, неполное использование возможностей движка объясняется тем, что до этого просто не дошли руки, ведь использование и внешних ключей и транзакций требует значителной переработки основ CMS и всех стандартных расширений.
Особенность фреймворка Joomla
В версии Joomla 3 большинство встроенных компонентов используют паттерн работы с данными «список элементов таблицы / форма редактирования элемента таблицы / действие (создать/изменить) над элементом», в котором используются расширяющие Legacy классы: контроллера JControllerLegacy + модели JModelLegacy + представления JViewLegacy.
Одной из основных особенностей этого паттерна является обработка за один HTTP запрос данных в одной таблице БД.
Это хорошо отлаженный и удобный для программирования паттерн. Работа с ним описана в цикле статей Создание компонента для Joomla 2.5.
Посмотрим, какие проблемы могут возникать при использовании внешних ключей и почему в Joomla не используются транзакции.
Внешние ключи в таблицах InnoDB в расширениях Joomla
Внешние ключи предоставляют встроенные в СУБД механизмы контроля целостности данных.
Если для поля одной таблицы создан внешний ключ ссылающийся на поле второй таблицы, то внешний ключ гарантирует, что для каждой записи в первой таблице есть соответствующая запись во второй таблице. Это "строгий" внешний ключ. "Нестрогий" внешний ключ допускает что поле внешнего ключа может не иметь связи.
Строгий внешний ключ
Предположим в разрабатываемом компоненте необходимо хранить две сущности, одна из которых (Сhild) зависит от другой. При этом каждый Сhild обязательно должен быть связан с Parent.
Aтрибут NOT NULL поля child.parent_id требует обязательного указания существующего parent_id для каждого элемента Child.
При попытке создать элемент Child с несуществующим или пустым parent_id MySQL вернет ошибку.
Работа с такой схемой БД полностью прозрачна для программиста Joomla. Единственное о чем следует побеспокоится — обработка ошибок, возникающих при записи данных, но об этом позже.
Нестрогий внешний ключ
Если предположить, что Child не обязательно должен быть связан с Parent, то схема немного изменится.
Эта схема предполагает что каждый элемент Сhild в поле parent_id записан либо NULL, либо parent.id существующего элемента Parent.
СУБД не даст сделать запись child.parent_id если такого parent.id не существует, но если child.parent_id = NULL, то такая запись вполне может существовать.
Простая и понятная схема хранения данных, но в модели Joomla и в PHP программировании в целом, она вызывает некоторые сложности.
Пример
Есть страница с HTML-формой редактирования элемента Child. Сохраняя элемент мы отправляем POST запрос c task=child.save или task=child.apply. Эта задача будет обработана методом save() контролера MycompControllerChild extends JControllerForm.
Метод MycompControllerChild::save() получает данные из запроса, проверяет и очищает их, и передает методу save() класса MycompModelChild extends JModelAdmin.
Метод MycompModelChild::save() формирует объект JTable и сохраняет его через JTable::store().
Проблемы начинаются, когда требуется сохранить NULL в поле child.parent_id.
Первая проблема - HTML форма не может передать значение NULL. Из формы можно передать 0 или '' (пустая строка) или любой другой набор символов, который программно можно будет транслировать в NULL. Для примера примем, что когда HTML форма передает параметр jform[parent_id] = 0, то его требуется записать в поле child.parent_id как значение NULL. В данном случае такое соглашение допустимо, т.к. число 0 в поле child.parent_id не может быть записано ни при каких условиях, и значение 0 будет пропускаться фильтром типа INT, который логично использовать для этого поля.
Вторая проблема - при выполнении запроса на сохранение элемента в стеке вызовов методов модели JModelAdmin имеется несколько мест блокирующих передачу на запись в БД значений NULL. Поэтому, чтобы записать parent_id = NULL, необходимо переопределить несколько методов в классе MycompModelChild extends JModelAdmin.
/** * образец переопределения методов записи элемента */ class MycompModelChild extends JModelAdmin { ... /** * Переопределяет метод с возможностью записи значения NULL. * Можно скопировать весь код родительского метода JModelAdmin::save(), заменив единственную строку. */ public function save($data) { ... // заменить вхождение // $table->store() // на // $table->store(TRUE) ... } ... /** * Метод позволяет изменить объект JTable непосредственно перед вызовом JTable::store() * Соглашение: если поле parent_id – пустое, записать в него NULL */ protected function prepareTable($table) { if (empty($table->parent_id)) { $table->parent_id = NULL; } } ... }Пояснения к коду.
Метод save() в классе JModelAdmin вызывает метод JTable::store(), который, при вызове без параметров, при создании запроса игнорирует все поля со значением NULL.
Вызов метода JTable::store(true)с параметром TRUE, указывает на необходимость вставлять в поля значение NULL.
Надо учитывать, что NULL будет вставляться только в SQL запросы UPDATE. В запросах INSERT поля со значением NULL все равно будут отфильтрованы. Поэтому важно задать в схеме БД значение по умолчанию для этого поля:
`parent_id` INT NULL DEFAULT NULLМетод prepareTable() вызывается перед вызовом JTable::store(), и позволяет работать напрямую с объектом JTable, изменяя значения его свойств.
В переопределенном методе любое empty-значение (0, '', FALSE) в свойстве parent_id будет заменено на NULL.
Общий вариант этого метода. Например, по соглашению внутри схемы БД использовать наименование включающее подстроку "_id", например, "item_id" для всех полей, имеющих внешние ключи. Тогда это будет универсальный метод для любого класса дочернего JModelAdmin.
/** * Метод позволяет изменить объект JTable непосредственно перед вызовом JTable::store() * Соглашение: если имя поля содержит вхождение _id и пустое значение, записать в него NULL */ protected function prepareTable($table) { // перебираем все поля таблицы foreach ($table->getProperties() as $key => $value) { // т.к. имя таблицы всегда на латинице можно использовать strpos($key, '_id', 1) // если в имени поля встречается подстрока _id, а значение у поля пустое, то поле = NULL if (\Joomla\String\String::strpos($key, '_id', 1) !== FALSE && empty($value)) { $table->$key = NULL; } } }Обработка ошибок целостности данных
При попытке записать в таблицу Сhild строку с parent_id, которому нет соответствия в таблице Parent, MySQL возвращает ошибку с кодом 1452 и сообщением:
Cannot add or update a child row: a foreign key constraint fails `child`, CONSTRAINT `fk_child_parent1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`))При попытке удалить строку из таблицы Parent, на которую ссылается хотя бы одна строка Child, MySQL вернет ошибку 1451:
Cannot delete or update a parent row: a foreign key constraint failsОшибка поднимается по стеку вызовов JTable::store() -> JModelAdmin::save() -> JControllerForm::save().
Обработчик ошибок в контроллере JControllerLegacy обработает подобные ошибки, выводя стандартное сообщение типа error о невозможности сохранить элемент.
При необходимости ошибку можно перехватить обработать специальным образом. Что делать с этой ошибкой и где ее перехватывать — надо решать исходя из логики приложения.
В каких случаях могут возникать ошибки целостности данных?
При работе системы в "штатном однопользовательском" режиме, когда изменения данных производит только один пользователь модель Joomla успешно отфильтровывает ошибочные данные и обрабатывает ошибки.
Проблемы могут возникать когда одновременно два пользователя изменяют данные. Например, первый пользователь редактирует элемент Child, он открыл форму редактирования элемента, в которой сформирован список существующих parent.id, пользователь выбирает некий id. Второй пользователь удаляет этот элемент Parent. Первый пользователь нажимает кнопку сохранить и на запись отправляется элемент Child с несуществующим parent_id.
Фильтр Joomla посчитает такую запись валидной, т.к. значение будет соответствовать заданному типу и при отсутствии контроля целостности данных со стороны СУБД, такая запись будет успешно сохранена. Для реализации защиты от таких коллизий без использования внешних ключей необходимо добавить проверку на существование элемента. В случае установленного внешнего ключа СУБД вернет ошибку.
Транзакции в запросах к БД Joomla
Редактирование элемента из формы
При редактировании элемента в форме предполагается, что форма передает данные одного редактируемого элемента, задача на запись (&task=child.save) обрабатывается в контролере MycompControllerChild::save(), данные запроса передаются в модель MycompModelChild::save(), которая в свою очередь сохраняет их в таблицу JTable::store(). В результатом должна быть одна измененная строка в единственной таблице БД.
Поскольку записывается единственная строка в одной таблице, то транзакция не имеет смысла.
Разработчики Joomla заложили возможность добавить в этот паттерн обработку дополнительных данных через метод контроллера postSaveHook($model).
Например, в одной HTML форме можно изменить и данные элемента Parent и связанного с ним Child и отправить их одним запросом.
Метод postSaveHook($model) получает управление только в случае успешного завершения вызова $model->save().
Переопределив метод в контроллере MycompControllerParent::postSaveHook($model), можно получить доступ к модели MycompModelParent и получить значение id сохраненного элемента Parent, после этого вызвать модель MycompControllerChild и сохранить данные элемента Child.
Поскольку в одном HTTP запросе будут сохраняться данных двух связанных таблиц, логично было бы обернуть запросы в транзакцию. Но реализовать транзакцию достаточно сложно, т.к. запросы вызываются из разных моделей и согласовать закрытие транзакции с учетом всех возможных вариантов ошибок будет проблемой.
Одним из вариантов решения этой проблемы является перенос логики из postSaveHook в метод save() Parent модели. Это даст возможность откатить транзакцию, если возникла проблема при сохранении Child.
Получение данных из потока или файла
Отдельной задачей в работе сайтов стоит обработка потоковых данных или парсинг файлов. Под подобную задачу приходится писать отдельную модель или использовать библиотеку. Хорошим примером подобных задач является разбор данных CommerceML или подобных форматов обмена между учетными системами и сайтом. При парсинге CommerceML, данные требуется писать связанные данные в несколько таблиц БД.
Запросы на запись в таблицы в таких случаях не только можно, но и желательно обернуть в транзакцию. Транзакции могут быть реализованы на уровне логических блоков файла данных или на весь файл/поток целиком.
Работа с транзакциями через класс JDatabaseDriver описана в статье JDatabaseDriver - использование транзакций.
Подводим итоги
- InnoDB мощный механизм имеющий широкие возможности для улучшения производительности и надежности крупных и нагруженных сайтов.
- На текущем этапе CMS Joomla и встроенные компоненты не использует возможности не только InnoDB, но и других транзакционных баз данных.
- При разработке расширений можно и нужно использовать возможности предоставляемые InnoDB для увеличения надежности работы с данными.
- Разрабатывая публичные расширения необходимо учесть возможность установки на таблицы типа MyISAM и эмулировать работу систем целостности данных и транзакций на программном уровне.
cmscafe.ru
Как создать таблицу в базе данных Joomla?
Люди, такая беда (я - мятый чайник, не удивляйтесь)! Сделал с грехом пополам новый сайт на джумле, на хостинге создал базу данных, требуется в этой базе создать таблицу. При попытке импорта выдает следующееSQL-запрос:-- phpMyAdmin SQL Dump-- version 2.6.1-- http://www.phpmyadmin.net-- -- Хост: rjifhbr_krin-- Время создания: Дек 15 2009 г., 23:23-- Версия сервера: 5.0.45-- Версия PHP: 5.2.4-- -- БД: `site`-- -- ---------------------------------------------------------- -- Структура таблицы `bak_banner`-- CREATE TABLE `bak_banner` (`bid` int( 11 ) NOT NULL AUTO_INCREMENT ,`cid` int( 11 ) NOT NULL default '0',`type` varchar( 30 ) NOT NULL default 'banner',`name` varchar( 255 ) NOT NULL default '',`alias` varchar( 255 ) NOT NULL default '',`imptotal` int( 11 ) NOT NULL default '0',`impmade` int( 11 ) NOT NULL default '0',`clicks` int( 11 ) NOT NULL default '0',`imageurl` varchar( 100 ) NOT NULL default '',`clickurl` varchar( 200 ) NOT NULL default '',`date` datetime default NULL ,`showBanner` tinyint( 1 ) NOT NULL default '0',`checked_out` tinyint( 1 ) NOT NULL default '0',`checked_out_time` datetime NOT NULL default '0000-00-00 00:00:00',`editor` varchar( 50 ) default NULL ,`custombannercode` text,`catid` int( 10 ) unsigned NOT NULL default '0',`description` text NOT NULL ,`sticky` tinyint( 1 ) unsigned NOT NULL default '0',`ordering` int( 11 ) NOT NULL default '0',`publish_up` datetime NOT NULL default '0000-00-00 00:00:00',`publish_down` datetime NOT NULL default '0000-00-00 00:00:00',`tags` text NOT NULL ,`params` text NOT NULL ,PRIMARY KEY ( `bid` ) ,KEY `viewbanner` ( `showBanner` ) ,KEY `idx_banner_catid` ( `catid` )) ENGINE = MYISAM AUTO_INCREMENT =9DEFAULT CHARSET = utf8 AUTO_INCREMENT =9;
Ответ MySQL: Документация#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '
CREATE TABLE `bak_banner` (`bid` int(11) NOT NULL auto_increment,`ci' at line 1
Как мне эту чертову таблицу создать? Что куда писать, и тыкать?
www.html.by
| #assets / JTableAsset | Это новая таблица, введенная для системы списков контроля доступа (ACL) в версии 1.6. Она содержит строки для каждого компонента, также для каждого элемента с полномочиями ACL. К их числу относятся строка Root Asset (Корневой ресурс) для глобальных прав доступа, строка для каждой категории компонентов, а также строка для каждой статьи. В столбце rules (правила) хранятся групповые права доступа в формате JSON. |
| #associations / нет | Используется для собственного многоязычного средства в Joomla, чтобы дать возможность связать отдельный пункт меню с соответствующим пунктом меню на другом языке мира |
| #banners / нет | Содержит строки для каждого баннера, определенного на веб-сайте |
| #banner_clients / нет | Содержит строки для каждого клиента баннера, определенного на веб-сайте |
| #banner_tracks / нет | Содержит строки для каждого канала отслеживания баннеров, определенного на веб-сайте |
| #categories / JTableCategory | Содержит строки для каждой категории, определенной на веб-сайте, включая статью, баннер, ленту новостей и вебссылку |
| #contact_details / нет | Содержит строки для каждой контактной информации, определенной на веб-сайте |
| #content / JTableContent | Содержит строки для каждой статьи, определенной на вебсайте |
| #content_rating / нет | Содержит строки для каждой статьи, оцененной на вебсайте |
| #core_log_searches / нет | Содержит строки для каждого фильтра поиска, установленного по команде Smart Search (Manage Search Filters) в переводе - Интеллектуальный поиск (Управлять фильтрами поиска) |
| #extensions / JTableExtension | Содержит строки для каждого расширения, установленного на веб-сайте, включая компоненты, библиотеки, модули, шаблоны, подключаемые модули, языки и файлы |
| #finder_filters / FinderTableFilter | Содержит строки для каждого элемента содержимого, индексированного средствами интеллектуального поиска |
| #finder_links / FinderTableLink #finder_links_terms (0-f) | Сопоставляет критерии поиска со ссылками, учитывая весовой коэффициент. (Следует иметь в виду, что 15 таблиц, по существу, составляют единую логическую таблицу, но разделены на отдельные таблицы ради ускорения их индексирования.) |
| #finder_taxonomy / FinderTableMap #finder_taxonomy_map / нет#finder_terms / нет#finder_terms_common / нет#finder_tokens / нет#finder_tokens_aggregate / нет#finder_types / нет | Содержит строки для каждого поискового элемента, индексированного по всем элементам содержимого Содержит строки для каждого общеупотребительного в языке слова (не подлежит индексированию). Временные таблицы, используемые в процессе индексирования |
| #languages / JTableLanguage | Содержит строки для каждого языка мира, установленного на веб-сайте |
| #menu / JTableMenu | Содержит строки для каждого пункта меню, определенного в пользовательской и административной частях веб-сайта |
| #menu_types / JTableMenuType | Содержит строки для каждого меню, определенного в пользовательской части веб-сайта |
| #messages / нет | Содержит строки для каждого частного сообщения, отправляемого на веб-сайте |
| #messages_cfg / нет | Содержит строки для каждого пользователя административной части, настраивающего веб-сайт по команде Components => Messaging => My Settings (Компоненты => Обмен сообщениями => Мои настройки) |
| #modules / JTableModule | модуль, относящийся к пользовательской части, а значение 1 — модуль, относящийся к административной части вебсайта |
| #modules_menu / нет | Это таблица соответствий, в которой показано назначение модулей для отдельных пунктов меню. Назначение модулей для отдельных пунктов меню указывается в столбце menuid следующим образом: значение 0 обозначает, что модуль назначен для всех пунктов меню; положительное значение—для данного конкретного пункта меню; отрицательное значение — для всех пунктов меню, кроме данного пункта |
| #news feeds / нет | Содержит строки для каждой ленты новостей, созданной на веб-сайте |
| #redirect_links / нет | Содержит строки для каждой переадресации, организованной на веб-сайте |
| #schemas / нет | Содержит строки для каждого расширения, внесшего изменения в базу данных во время установки, наряду с последней установленной версией расширения |
| #session / JTableSession | Содержит строки для каждого активного сеанса работы с веб-сайтом |
| #template_styles / нет | Содержит строки для каждого стиля шаблона, определенного на веб-сайте |
| #updates / JTableUpdate | Содержит строки для каждого доступного для установки пакета |
| #update_categories / нет | Эта таблица служит для разделения обновлений на отдельные категории. Она сопровождается в Joomla автоматически |
| #update_sites / нет | Содержит список сайтов обновления, выбираемый из XML- файла для каждого расширения |
| #update_sites_extensions / нет | Это таблица соответствий, связывающая расширения # с обновлениями # и содержащая строки для каждого сочетания расширения и сайта обновления, где это расширение может быть обновлено |
| #usergroups / JTableUsergroup | Содержит строки для каждой группы пользователей, определенной на веб-сайте |
| #users / JTableUser | Содержит строки для каждого пользователя, определенного на веб-сайте |
| #user_profiles / нет | Содержит строки для каждой группы, членом которой является данный пользователь |
| #viewlevels / JTableViewlevel | Содержит строки для каждого уровня представления, определенного на веб-сайте |
| #weblinks / нет | Содержит строки для каждой веб-ссылки, определенной на веб-сайте |
www.web-forsite.ru
