Стандартні таблиці бази даних Joomla 6.x та їх призначення

Під час встановлення Joomla система автоматично створює набір стандартних таблиць бази даних, необхідних для роботи ядра CMS. У цих таблицях зберігаються матеріали, категорії, користувачі, меню, модулі, налаштування розширень, права доступу та інші службові дані.

Знання структури бази даних CMS Joomla корисне під час розробки, аудиту та супроводу сайтів. Зокрема, еталонний список стандартних таблиць дозволяє швидко визначити, які таблиці належать ядру системи, а які були створені сторонніми розширеннями. Це може знадобитися після видалення компонентів, під час пошуку застарілих даних, очищення бази даних або аналізу проєкту, який був розроблений іншими спеціалістами.

Нижче наведено повний список таблиць, які створюються після чистої інсталяції Joomla 6.1 без додаткових розширень. Для кожної таблиці наведено короткий опис її призначення та типів даних, які в ній зберігаються. Це допоможе не лише виявляти нестандартні таблиці, а й швидше орієнтуватися у структурі бази даних під час розробки, інтеграції або налагодження сайту.

Повний список стандартних таблиць Joomla 6.x

Таблиці користувачів та прав доступу

У Joomla 6.x підсистема користувачів і керування доступом побудована на розділеній структурі таблиць. Вона відокремлює облікові дані, групи користувачів, рівні доступу та додаткові механізми автентифікації. Такий підхід дозволяє реалізувати складну ACL-модель без зміни ядра та забезпечує масштабованість для проєктів будь-якої складності.

Список основних таблиць користувачів та доступу:

• #__users — основна таблиця облікових записів користувачів (логін, email, пароль, стан акаунта, базові параметри).
• #__usergroups — групи користувачів та їх ієрархія (рольова модель доступу).
• #__user_usergroup_map — зв’язок користувачів із групами (many-to-many структура).
• #__viewlevels — рівні перегляду контенту та прив’язка до груп доступу.
• #__user_profiles — додаткові структуровані поля профілю користувача.
• #__user_notes — службові нотатки адміністратора щодо користувача.
• #__user_keys — токени доступу для сесій та зовнішніх авторизаційних механізмів.
• #__user_mfa — налаштування багатофакторної автентифікації (MFA).
• #__webauthn_credentials — облікові дані WebAuthn (апаратні ключі, біометрія).

У сукупності ці таблиці формують багаторівневу систему доступу Joomla, де права користувача не зберігаються напряму в одному місці, а визначаються комбінацією груп, рівнів перегляду та методів автентифікації. Для розробника важливо розуміти, що саме зв’язки між таблицями (users → usergroups → viewlevels) визначають фактичний доступ до контенту та функціоналу, а не окремі записи в таблиці користувачів.

При розробці, міграції або аудиті бази даних треба враховувати ці залежності, оскільки порушення зв’язків між таблицями може призвести до некоректної роботи ACL або втрати доступу до адміністративної частини сайту.

Таблиці матеріалів та категорій

У Joomla 6.x структура зберігання контенту побудована навколо двох ключових рівнів — самих матеріалів і їх ієрархічної класифікації. Такий підхід дозволяє відокремити вміст від логіки його групування, що важливо для масштабованих сайтів із великою кількістю сторінок та різними сценаріями відображення.

Список основних таблиць матеріалів та категорій:

• #__content — основна таблиця матеріалів, де зберігаються тексти статей, метадані публікації, статуси, автори та параметри відображення.
• #__categories — універсальна таблиця категорій, яка використовується не лише для статей, а й для інших компонентів Joomla.
• #__content_frontpage — зв’язок матеріалів із відображенням на головній сторінці (legacy-механізм або сумісність).
• #__content_rating — зберігання оцінок і рейтингових даних матеріалів.
• #__history — версійність матеріалів, включно з можливістю відновлення попередніх редакцій.
• #__ucm_content — універсальна модель контенту, яка синхронізує матеріали між різними компонентами.
• #__ucm_base — базові зв’язки UCM, що забезпечують узагальнену роботу з контентними сутностями.

Ця структура показує, що Joomla не обмежується просто зберіганням текстів у таблиці матеріалів, а використовує додаткові механізми для історії змін, універсальної сумісності та розширюваної класифікації.

У підсумку, робота з матеріалами та категоріями в Joomla вимагає розуміння не лише #__content, а й супутніх таблиць, які впливають на відображення, версіонування та інтеграцію контенту в різні частини системи. Це особливо важливо під час міграцій, оптимізації або розробки кастомних компонентів, які взаємодіють зі стандартною моделлю контенту.

Таблиці меню та модулів

Таблиці меню та модулів є одними з ключових елементів архітектури Joomla, оскільки саме вони визначають структуру навігації сайту та логіку відображення значної частини контенту. На відміну від багатьох інших CMS, у Joomla пункти меню не лише формують навігацію, а й часто визначають маршрутизацію URL, набір параметрів сторінки, шаблон відображення та активний контекст компонента.

• #__menu — основна таблиця пунктів меню. Містить тип пункту меню, URL, параметри компонента, ієрархію вкладеності, SEO-псевдоніми (alias), стан публікації та службові параметри маршрутизації.
• #__menu_types — зберігає інформацію про всі створені меню на сайті. Кожен запис відповідає окремому меню, наприклад «Головне меню» або «Меню користувача».
• #__modules — містить конфігурацію всіх модулів сайту, включаючи їх тип, позицію в шаблоні, параметри, порядок сортування, статус публікації та правила доступу.
• #__modules_menu — реалізує зв'язок між модулями та пунктами меню. Саме ця таблиця визначає, на яких сторінках повинен відображатися конкретний модуль.

Для розробників особливо важливо розуміти, що некоректні зміни в таблицях #__menu або #__modules_menu можуть призвести до порушення маршрутизації, появи помилок 404 або неправильного відображення модулів на сторінках сайту. Під час міграції, імпорту даних або розробки власних розширень рекомендується працювати з меню та модулями через API Joomla, оскільки система використовує додаткові внутрішні механізми кешування та побудови маршрутів, які не завжди очевидні при прямому редагуванні бази даних.

Таблиці тегів і зв'язків контенту

Таблиці тегів і міжоб'єктних зв'язків забезпечують додатковий рівень класифікації контенту в Joomla. На відміну від категорій, де використовується сувора ієрархічна структура, теги дозволяють реалізувати гнучку систему зв'язків між матеріалами, контактами, новинними стрічками та іншими сутностями. Це особливо важливо для великих проєктів, де один елемент контенту може належати одночасно до декількох тематичних груп.

• #__tags — основна таблиця тегів. Містить назву тега, псевдонім (alias), опис, вкладеність, метадані та службові параметри.
• #__contentitem_tag_map — проміжна таблиця, яка реалізує зв'язок «багато до багатьох» між тегами та різними типами контенту. Саме вона визначає, які теги призначені конкретному об'єкту.
• #__associations — таблиця мовних асоціацій, яка використовується для зв'язування еквівалентних об'єктів різними мовами в багатомовних сайтах.

Для розробників важливо враховувати, що Joomla використовує універсальний механізм прив'язки тегів, тому таблиця #__contentitem_tag_map може містити посилання на записи з різних компонентів, а не лише зі статей. Під час імпорту даних, створення власних компонентів або реалізації багатомовності необхідно коректно працювати з цими зв'язками, інакше система може втратити навігаційні залежності, фільтрацію за тегами або мовні асоціації між об'єктами.

Таблиці власних полів

Таблиці власних полів дозволяють розширювати стандартну модель даних Joomla без внесення змін до структури бази даних ядра. Завдяки механізму Custom Fields розробник може додавати додаткові атрибути до матеріалів, контактів, користувачів та інших об'єктів, зберігаючи сумісність із майбутніми оновленнями CMS. Це особливо корисно під час створення каталогів, довідників, корпоративних порталів та інших проєктів із нестандартною структурою даних.

• #__fields — містить опис усіх створених полів, включаючи їх тип, назву, контекст використання, параметри відображення та правила валідації.
• #__fields_groups — зберігає групи полів, які використовуються для логічного об'єднання та впорядкування полів у адміністративному інтерфейсі.
• #__fields_values — містить фактичні значення полів, прив'язані до конкретних об'єктів. Саме ця таблиця зазвичай містить найбільшу кількість записів.
• #__fields_categories — визначає зв'язок між полями та категоріями, дозволяючи обмежувати відображення полів лише для певних категорій контенту.

Під час розробки слід враховувати, що значення власних полів не зберігаються безпосередньо в таблицях компонентів, наприклад у #__content. Тому при написанні SQL-запитів, створенні імпорту/експорту або реалізації власних API необхідно додатково обробляти таблицю #__fields_values. Для високонавантажених проєктів також варто звертати увагу на продуктивність запитів, оскільки велика кількість користувацьких полів може суттєво збільшити кількість JOIN-операцій під час вибірки даних.

Таблиці пошуку Smart Search

Технологія Smart Search у Joomla використовує окремий набір таблиць для побудови повнотекстового індексу та швидкого пошуку по сайту. На відміну від стандартного пошуку, Smart Search не виконує запити безпосередньо до таблиць контенту під час кожного звернення користувача. Замість цього система попередньо індексує дані, формує пошукові токени та зберігає їх у спеціалізованих таблицях. Саме завдяки цьому забезпечується висока швидкість пошуку, підтримка фільтрації та ранжування результатів.

• #__finder_links — основна таблиця індексованого контенту, яка містить інформацію про всі проіндексовані об'єкти незалежно від їх типу.
• #__finder_terms — зберігає окремі пошукові терміни, виділені під час індексації контенту.
• #__finder_tokens — містить токени, що використовуються механізмом пошуку для побудови індексу.
• #__finder_tokens_aggregate — зберігає агреговані токени, необхідні для оптимізації пошукових операцій.
• #__finder_links_terms — реалізує зв'язок між індексованими об'єктами та пошуковими термінами.
• #__finder_taxonomy — містить таксономічну структуру, яка використовується для категоризації індексованих даних.
• #__finder_taxonomy_map — забезпечує зв'язок між елементами індексу та таксономією.
• #__finder_types — визначає типи контенту, які беруть участь в індексації.
• #__finder_filters — зберігає інформацію про фільтри, що застосовуються під час пошуку.
• #__finder_logging — використовується для журналювання пошукових запитів користувачів.
• #__finder_terms_common — містить список часто вживаних слів, які можуть виключатися з процесу індексації.

Розробникам слід враховувати, що таблиці Smart Search можуть дуже швидко збільшуватися в розмірі на сайтах із великою кількістю контенту. Після масового імпорту матеріалів, зміни структури даних або розробки власних компонентів зазвичай необхідно виконувати повторну індексацію через компонент Smart Search. Крім того, при створенні власних розширень для підтримки повнотекстового пошуку необхідно реалізовувати відповідні індексувальні плагіни, інакше контент розширення не буде доступний у результатах пошуку.

Таблиці журналів та системних подій

Журнали дій та системні події відіграють важливу роль у моніторингу роботи Joomla, аудиті безпеки та аналізі змін, виконаних користувачами. На відміну від стандартних лог-файлів вебсервера, ці таблиці зберігають інформацію про події безпосередньо на рівні CMS. Завдяки цьому адміністратор або розробник може визначити, хто, коли і які зміни вніс у систему, а також відстежувати активність розширень, що підтримують механізм журналювання.

• #__action_logs — основна таблиця журналу дій, у якій зберігаються записи про події, виконані користувачами або системою.
• #__action_log_config — містить налаштування журналювання для окремих типів подій і компонентів.
• #__action_logs_users — використовується для зв'язування записів журналу з конкретними користувачами системи.
• #__action_logs_extensions — зберігає інформацію про розширення, які беруть участь у механізмі журналювання або генерують записи в журналі.

Для розробників ці таблиці можуть бути особливо корисними під час розслідування інцидентів безпеки, пошуку причин неочікуваних змін контенту або налагодження власних розширень. Водночас слід враховувати, що на активних сайтах таблиця #__action_logs може швидко збільшуватися в розмірі, тому в рамках технічного обслуговування доцільно контролювати період зберігання записів та регулярно виконувати очищення застарілих даних відповідно до політики аудиту проєкту.

Таблиці контактів

Компонент контактів у Joomla (com_contact) використовує окрему таблицю #__contact_details, яка призначена для зберігання структурованої контактної інформації. На відміну від звичайних матеріалів, контакти є окремим типом сутностей із власним набором полів, параметрів відображення та механізмів інтеграції.

У таблиці #__contact_details зберігаються ім'я контактної особи, посада, адреса, телефони, email, вебсайт, географічні координати, службові примітки, параметри публікації та SEO-дані. Крім того, контакт може бути пов'язаний із конкретним користувачем Joomla через поле user_id, що дозволяє автоматично синхронізувати частину інформації або використовувати контакт як профіль співробітника.

Для розробників важливо враховувати, що компонент контактів підтримує власні параметри відображення, які зберігаються у форматі JSON безпосередньо в записі таблиці. Саме тому під час імпорту або міграції контактів недостатньо перенести лише базові поля — необхідно також коректно обробляти параметри (params) та метадані (metadata), інакше частина налаштувань може бути втрачена.

На практиці таблиця #__contact_details часто використовується не тільки для стандартної сторінки контактів, але й як джерело даних для каталогів співробітників, корпоративних довідників, інтеграції з CRM-системами та створення кастомних API. Тому при розробці власних розширень доцільно використовувати стандартні моделі та API Joomla, а не працювати з таблицею напряму, що забезпечить сумісність із майбутніми оновленнями CMS.

Таблиці банерів

Банерна система Joomla (com_banners) призначена для керування рекламними кампаніями, обліку статистики показів і взаємодії з рекламодавцями. Незважаючи на те, що багато сучасних сайтів використовують сторонні рекламні платформи, вбудований компонент банерів залишається корисним інструментом для корпоративних порталів, інформаційних ресурсів та проєктів із власною системою розміщення реклами.

• #__banners — основна таблиця компонента, у якій зберігаються банери, їхні параметри публікації, посилання, ліміти показів, терміни дії та службові налаштування.
• #__banner_clients — містить інформацію про рекламодавців або організації, яким належать банери. Один клієнт може бути пов'язаний із кількома рекламними кампаніями.
• #__banner_tracks — використовується для накопичення статистики переглядів і кліків. Саме ця таблиця дозволяє аналізувати ефективність рекламних кампаній та формувати звіти.

Для розробників важливо враховувати, що таблиця #__banner_tracks може дуже швидко збільшуватися в розмірі на сайтах із високою відвідуваністю. Тому під час технічного обслуговування доцільно контролювати обсяг накопиченої статистики та за необхідності виконувати архівацію або очищення застарілих записів. Крім того, при інтеграції з зовнішніми рекламними сервісами рекомендується використовувати події та API Joomla, а не змінювати дані безпосередньо в базі, щоб зберегти сумісність із майбутніми оновленнями CMS.

Таблиці новинних стрічок

Компонент новинних стрічок (com_newsfeeds) призначений для інтеграції зовнішніх RSS та Atom каналів із сайтом на Joomla. Незважаючи на те, що сучасні вебпроєкти часто використовують API сторонніх сервісів, механізм News Feeds залишається корисним інструментом для агрегаторів новин, корпоративних порталів та тематичних ресурсів, які автоматично публікують інформацію із зовнішніх джерел.

• #__newsfeeds — основна таблиця компонента, яка містить адреси RSS або Atom каналів, назви стрічок, їх псевдоніми (alias), параметри кешування, налаштування публікації, категорії, метадані та інші службові параметри.

Для розробників важливо розуміти, що таблиця #__newsfeeds не зберігає самі новини або імпортований контент. У ній містяться лише параметри підключення та налаштування відображення зовнішньої стрічки. Отримання, обробка та кешування даних виконуються безпосередньо компонентом під час роботи сайту. Тому при створенні власних інтеграцій або механізмів імпорту необхідно враховувати, що зміна записів у таблиці #__newsfeeds впливає лише на конфігурацію джерела, а не на фактичний вміст новин.

Таблиці конфіденційності та безпеки

Починаючи з Joomla 3.9, у CMS були реалізовані механізми захисту персональних даних та дотримання вимог GDPR. У Joomla 6.x ці функції продовжують розвиватися і використовують окремі таблиці бази даних для зберігання інформації про згоду користувачів, запити на обробку персональних даних та параметри сучасних механізмів автентифікації. Для розробників розуміння призначення цих таблиць є важливим під час створення форм, інтеграції із зовнішніми сервісами та проведення аудиту безпеки сайту.

• #__privacy_consents — зберігає інформацію про згоди користувачів на обробку персональних даних, включаючи дату надання згоди та версію політики конфіденційності.
• #__privacy_requests — містить запити користувачів на експорт або видалення персональних даних відповідно до вимог GDPR та інших нормативних актів.
• #__user_mfa — використовується для зберігання налаштувань багатофакторної автентифікації (MFA) користувачів.
• #__webauthn_credentials — містить облікові дані WebAuthn, необхідні для автентифікації за допомогою апаратних ключів безпеки або біометричних пристроїв.
• #__user_keys — зберігає службові токени, які використовуються для різних процесів автентифікації, підтвердження дій та відновлення доступу.

Під час розробки та супроводу сайтів не рекомендується змінювати записи в цих таблицях безпосередньо через SQL-запити, оскільки це може порушити роботу механізмів автентифікації або призвести до втрати юридично значимих даних щодо обробки персональної інформації. Для роботи з такими даними доцільно використовувати стандартні API Joomla та вбудовані інструменти адміністративної панелі.

Таблиці оновлень Joomla

Механізм оновлень у Joomla 6.x побудований таким чином, щоб автоматично отримувати інформацію про нові версії ядра та встановлених розширень із віддалених серверів розробників. Для цього CMS використовує окремий набір службових таблиць, які зберігають джерела оновлень, результати перевірок та метадані, необхідні для безпечного оновлення системи. Розуміння структури цих таблиць особливо важливе під час діагностики проблем з оновленнями, перенесення сайтів або розробки власних розширень.

• #__update_sites — містить список серверів оновлень, з яких Joomla отримує інформацію про доступні нові версії ядра та розширень.
• #__update_sites_extensions — реалізує зв'язок між встановленими розширеннями та відповідними серверами оновлень.
• #__updates — зберігає результати останньої перевірки оновлень, включаючи інформацію про доступні нові версії.
• #__extensions — містить інформацію про всі встановлені розширення, їхній стан, версію, тип та службові параметри.
• #__tuf_metadata — використовується механізмом безпечних оновлень для перевірки цілісності та автентичності пакетів відповідно до концепції The Update Framework (TUF).

Для розробників важливо враховувати, що пошкодження або некоректне редагування цих таблиць може призвести до неможливості отримання оновлень або появи помилкових повідомлень про їх наявність. При створенні власних розширень рекомендується реалізовувати стандартний XML-маніфест оновлень та використовувати штатний механізм Joomla, оскільки це забезпечує автоматичну інтеграцію з системою оновлень і сумісність із майбутніми версіями CMS.

Таблиці планувальника завдань

Таблиці планувальника завдань у Joomla 6.x забезпечують роботу вбудованого механізму автоматизації фонових процесів. За допомогою компонента com_scheduler адміністратор або розробник може налаштовувати періодичне виконання різних операцій, таких як очищення кешу, відправлення повідомлень, запуск власних скриптів або синхронізація даних із зовнішніми сервісами. Використання планувальника дозволяє зменшити кількість ручних операцій та централізувати керування службовими завданнями в межах CMS.

• #__scheduler_tasks — основна таблиця планувальника, у якій зберігаються всі створені завдання, їх типи, параметри виконання, розклад запуску, статус активності та службові налаштування.
• #__scheduler_logs — таблиця журналів виконання завдань. Містить інформацію про час запуску, результат виконання, повідомлення про помилки та інші діагностичні дані.

Для розробників важливо враховувати, що планувальник Joomla працює через систему завдань (Tasks API), тому при створенні власних автоматизованих процесів рекомендується використовувати стандартні плагіни типу task замість реалізації окремих CRON-скриптів. Такий підхід спрощує супровід проєкту, забезпечує інтеграцію з адміністративною панеллю та дозволяє використовувати вбудовані механізми журналювання й контролю виконання завдань.

Таблиці робочих процесів

Таблиці робочих процесів (Workflow) у Joomla 6.x забезпечують керування життєвим циклом контенту — від створення матеріалу до його остаточної публікації або архівації. Цей механізм особливо корисний для великих редакційних проєктів, де над контентом працюють автори, редактори та модератори з різними рівнями доступу. Завдяки системі робочих процесів можна реалізувати контроль затвердження матеріалів без використання сторонніх розширень.

• #__workflows — містить визначення всіх створених робочих процесів, їх назви, опис, стан публікації та параметри конфігурації.
• #__workflow_stages — зберігає етапи кожного робочого процесу, наприклад «Чернетка», «На перевірці», «Опубліковано» або «Архівовано».
• #__workflow_transitions — визначає дозволені переходи між етапами та правила їх виконання. Саме ця таблиця контролює, які користувачі можуть змінювати стан матеріалу.
• #__workflow_associations — використовується для зв'язування конкретних елементів контенту з відповідними робочими процесами та їх поточними етапами.

Для розробників важливо розуміти, що система Workflow тісно інтегрована з ACL Joomla та механізмом подій ядра. Тому під час розробки власних компонентів або автоматизації публікації контенту необхідно враховувати стан робочого процесу, а не лише значення поля state у таблиці контенту. Ігнорування логіки Workflow може призвести до ситуацій, коли матеріал формально опублікований, але фактично недоступний для подальшого редагування або не відповідає затвердженому редакційному сценарію.

Таблиці структурованих даних Schema.org

Таблиці структурованих даних у Joomla 6.x відповідають за зберігання інформації, яка використовується для формування семантичної розмітки відповідно до стандарту Schema.org. Цей механізм дозволяє передавати пошуковим системам додатковий контекст про вміст сторінок, що може позитивно впливати на відображення сайту в результатах пошуку. Для розробників важливо розуміти, що система структурованих даних інтегрована безпосередньо в ядро Joomla і може використовуватися без встановлення сторонніх SEO-розширень.

• #__schemaorg — містить конфігурацію структурованих даних, прив'язаних до окремих матеріалів або інших об'єктів контенту. У таблиці зберігаються типи схем, налаштовані властивості та службові параметри, необхідні для генерації JSON-LD розмітки.
• #__schemas — використовується для зберігання опису доступних схем та їх структури. Ця таблиця забезпечує роботу механізму побудови та валідації структурованих даних у адміністративній частині Joomla.

Під час розробки власних компонентів або SEO-рішень слід враховувати, що структуровані дані повинні відповідати актуальній специфікації Schema.org і рекомендаціям пошукових систем. Некоректно сформована розмітка може не лише не принести користі, а й призвести до появи попереджень у сервісах для вебмайстрів. Тому при інтеграції з таблицями #__schemaorg та #__schemas рекомендується використовувати стандартні API Joomla, що забезпечує коректну генерацію JSON-LD та сумісність із майбутніми оновленнями CMS.

Інші системні таблиці Joomla

Окрім таблиць, пов'язаних із конкретними компонентами, Joomla 6.x створює низку системних таблиць, які забезпечують базову роботу CMS. Вони відповідають за керування розширеннями, шаблонами, мовами, сесіями користувачів, кешуванням конфігурацій та іншими внутрішніми механізмами. Саме ці таблиці найчастіше використовуються ядром Joomla незалежно від типу сайту, тому їх наявність у базі даних є обов'язковою для коректної роботи системи.

• #__assets — зберігає ієрархію ресурсів та права доступу ACL для всіх об'єктів сайту.
• #__extensions — містить інформацію про всі встановлені компоненти, модулі, плагіни, шаблони та бібліотеки.
• #__languages — використовується для зберігання даних про встановлені мови сайту та адміністративної панелі.
• #__session — містить інформацію про активні сесії користувачів і адміністраторів.
• #__template_styles — зберігає стилі шаблонів та їх параметри конфігурації.
• #__template_overrides — використовується для керування перевизначеннями шаблонів у адміністративній частині.
• #__mail_templates — містить шаблони системних електронних листів, які використовуються Joomla для надсилання повідомлень.
• #__messages — зберігає внутрішні повідомлення між адміністраторами сайту.
• #__messages_cfg — містить персональні налаштування внутрішньої системи повідомлень.
• #__postinstall_messages — використовується для відображення службових повідомлень після встановлення або оновлення Joomla.
• #__overrider — зберігає мовні перевизначення, створені через менеджер мов.
• #__guidedtours — містить інформацію про інтерактивні тури адміністративної панелі.
• #__guidedtour_steps — зберігає окремі кроки інтерактивних турів.

Розробникам слід пам'ятати, що більшість системних таблиць тісно пов'язана з внутрішніми API Joomla. Пряме редагування їх вмісту через SQL можливе лише за повного розуміння архітектури CMS, оскільки помилки можуть призвести до порушення авторизації, некоректної роботи розширень або втрати доступу до адміністративної панелі.

Під час аудиту бази даних саме ці таблиці доцільно використовувати як еталон для виявлення записів і структур, доданих сторонніми розширеннями.

Як визначити таблиці сторонніх розширень

Під час аудиту, оптимізації або перенесення сайту на Joomla розробнику часто потрібно визначити, які таблиці були створені сторонніми розширеннями, а які належать ядру CMS. Це особливо актуально після видалення компонентів, міграції між серверами або очищення бази даних від застарілих даних. Наявність невикористовуваних таблиць не тільки ускладнює супровід проєкту, але й може негативно впливати на резервне копіювання, продуктивність та безпеку сайту.

• Порівняйте список таблиць поточного сайту зі списком таблиць чистої інсталяції Joomla тієї ж версії.
• Перевірте таблицю #__extensions, щоб з'ясувати, які компоненти, модулі та плагіни встановлені в системі.
• Звертайте увагу на префікси в назвах таблиць. Багато розширень використовують власні скорочення, наприклад #__akeeba_*, #__kunena_*, #__hikashop_* або #__jcomments_*.
• Проаналізуйте XML-маніфести встановлених розширень у каталозі /administrator/components/, оскільки вони часто містять опис створюваних таблиць.
• Після видалення розширення перевіряйте, чи не залишилися в базі даних невикористовувані таблиці, оскільки далеко не всі розробники реалізують повне очищення під час деінсталяції.
• Якщо призначення таблиці невідоме, виконайте пошук її назви в коді сайту або у вихідних файлах розширень.
• Перед видаленням будь-якої таблиці обов'язково створіть резервну копію бази даних і переконайтеся, що таблиця не використовується активними розширеннями або власним кодом проєкту.

Слід враховувати, що деякі сторонні розширення інтегруються з ядром Joomla і можуть використовувати як власні таблиці, так і стандартні таблиці CMS. Тому рішення про видалення невідомих таблиць повинно прийматися лише після комплексного аналізу структури сайту. Практика порівняння бази даних із чистою інсталяцією Joomla є одним із найефективніших способів виявлення сторонніх або «осиротілих» таблиць під час технічного аудиту.