On this page

# Topics

Config in Joomla

07 June 2026

Every Joomla site has one screen that quietly controls almost everything: System → Global Configuration. It decides your site name, your SEF URLs, your cache, your mail server, your default permissions, and dozens of other settings. The component behind that screen is called com_config.

Most people open Global Configuration once during setup, change a few options, and never think about it again. But com_config is more interesting than it looks. It is not one form but two jobs: it manages the global settings of the whole site, and it also renders the Options screen that every other component uses for its own settings.

The small component that owns your site's settings - both the global ones and the per-component ones.

This article explains how com_config really works. It covers the basics for owners and editors, the tabs and daily setup for administrators, and the technical details for developers: where settings are stored, how they are read in code, and why Permissions and Text Filters behave differently from the rest.

1. The Basics

1.1 What is com_config?

A Joomla component is a small application that runs inside Joomla. Most components are about something: com_content is about articles, com_users is about users, com_menus is about menus. com_config is about settings.

It has two clearly separated jobs:

Global Configuration - the site-wide settings you reach from System → Global Configuration.
Component Options - the per-component settings you reach by clicking the Options button in the top-right toolbar of any component (for example, Articles → Options).

Both screens are drawn by the same component. That is the single most useful thing to know about com_config: the Options button you see all over the backend is not part of each component. It is com_config doing the work for them.

1.2 Why It Matters

Global Configuration is the control room of a Joomla site. A wrong value here does not break one article or one menu - it changes the behaviour of the whole site:

Turn on Offline and every visitor sees a maintenance page.
Switch Search Engine Friendly URLs and every link on the site changes shape.
Change the cache and the site can become much faster, or start serving stale content.
Edit the Permissions tab and you change what every user group is allowed to do.

Because the stakes are high, it pays to understand where each setting lives and what reads it.

1.3 Where to Find It

There is one main entry point in the backend menu:

System -> Setup -> Global Configuration

And there is the Options button, repeated in the toolbar of nearly every component. Both lead into com_config; only the data they edit is different.

2. Where com_config Lives

2.1 Two Halves: Backend and Frontend

Like several core components, com_config has both an administrator half and a site (frontend) half:

public_html/administrator/components/com_config/   (the backend forms)
public_html/components/com_config/                 (frontend editing)

The backend half is the one most people mean when they say "Global Configuration". The frontend half is smaller and is covered later in section 10.

2.2 The Backend Folder Structure

Inside the administrator component you find a clean, modern Joomla 6 layout:

administrator/components/com_config/
+-- forms/
|     application.xml      (the Global Configuration form)
+-- services/              (DI container wiring)
+-- src/
|   +-- Controller/        (Application + Component controllers)
|   +-- Model/
|   |     ApplicationModel.php   (saves Global Configuration)
|   |     ComponentModel.php     (saves component Options)
|   +-- View/
|   +-- Field/             (special fields: Filters, ConfigComponents)
+-- tmpl/                  (view templates)
+-- config.xml            (com_config's own options)
+-- access.xml            (com_config's own permissions)

Notice forms/application.xml. That single file defines every field on the Global Configuration screen. The tabs you see are the <fieldset> groups inside it.

2.3 The URLs

The two screens map to two views:

Global Configuration:
/administrator/index.php?option=com_config&view=application

Component Options (example: com_content):
/administrator/index.php?option=com_config&view=component&component=com_content

The second URL is exactly what the Options button links to. The component= parameter tells com_config whose settings to load.

3. The Global Configuration Tabs

Global Configuration groups its settings into tabs. Here is what each tab controls in Joomla 6.

3.1 Site

Site Name - the name used in page titles, emails, and the offline page.
Site Offline + Offline Message and Offline Image - the maintenance mode.
Default Editor, Default Access Level, Default List Limit, and Default Feed Limit.
SEO Settings - Search Engine Friendly URLs, URL Rewriting, Adds Suffix to URL, Unicode Aliases, and "Include Site Name in Page Titles".
Cookie Settings and the global Metadata Settings (default meta description, robots, author info).

3.2 System

Debug Settings - Debug System and Debug Language.
Cache Settings - caching off / conservative / progressive, cache handler, and cache time.
Session Settings - session handler, session lifetime, and shared sessions.
Web Services Settings - the CORS options for the REST API.

3.3 Server

Server Settings - path to the temp folder, GZIP page compression, Error Reporting, and Force HTTPS.
Location Settings - the site default time zone.
Database Settings - host, user, name, table prefix, and SSL options (mostly read-only after install).
Mail Settings - mailer (PHP mail / Sendmail / SMTP), from address and name, and SMTP host and credentials.
Proxy Settings - optional outbound proxy for the server.

3.4 Permissions

This tab sets the default permissions for every user group, for the whole site. It is the top of the ACL inheritance chain. Anything you set here is inherited by every category, component, and item unless something more specific overrides it. Section 9 explains where these values are stored.

3.5 Text Filters

This tab controls which HTML each user group may save. Options run from No Filtering (for Super Users) to a Default Blacklist, a custom Whitelist, or No HTML at all. It is your main defence against an editor pasting dangerous markup.

4. configuration.php: The Global Settings File

4.1 One File in the Site Root

Global Configuration values are not stored in the database. They live in a single PHP file in the root of your Joomla site:

public_html/configuration.php

The file defines one class, historically named JConfig:

<?php
class JConfig
{
    public $sitename = 'My Joomla Site';
    public $editor = 'tinymce';
    public $sef = '1';
    public $sef_rewrite = '1';
    public $caching = '0';
    public $cache_handler = 'file';
    public $cachetime = '15';
    public $offline = '0';
    public $dbtype = 'mysqli';
    public $host = 'localhost';
    public $db = 'joomla';
    public $dbprefix = 'abcde_';
    public $mailer = 'smtp';
    public $secret = 'a-long-random-string';
    public $tmp_path = '/path/to/tmp';
    public $log_path = '/path/to/administrator/logs';
    // ...many more...
}

Every property maps to one field name in forms/application.xml. When Joomla boots, it includes this file and reads the settings from it.

4.2 The secret Value

One important property is $secret. Joomla generates it at install time and never shows it in the form. It is used to sign tokens and protect against CSRF. Treat it like a password: never commit it to a public repository, and if it leaks, change it.

4.3 How the File Is Written

When you click Save on Global Configuration, the model ApplicationModel does not edit the file line by line. It builds the full set of values in a Registry object and exports it back as a PHP class:

$configuration = $config->toString('PHP', [
    'class'      => 'JConfig',
    'closingtag' => false,
]);

// then writes it to JPATH_CONFIGURATION . '/configuration.php'

This is why hand-editing configuration.php is safe only when the site is otherwise idle: the next Save from the backend rewrites the whole file from the form values.

5. Component Options: The Same Form, a Different Source

5.1 The Options Button

Open Articles, Contacts, or any other component and look at the top-right toolbar. The Options button opens a settings screen that looks just like Global Configuration. It is the same com_config component, this time in view=component.

5.2 Where the Fields Come From

For Global Configuration, the fields come from com_config's own forms/application.xml. For component Options, the fields come from the target component's own config.xml. For example:

administrator/components/com_content/config.xml

That file defines the option fields you see for Articles: default layout, whether to show the author, the link behaviour, integration settings, and so on. com_config simply loads that XML and renders it.

5.3 Where Component Options Are Stored

Unlike Global Configuration, component options are stored in the database. They live as a single JSON string in the params column of the #__extensions table:

SELECT name, params
  FROM jos_extensions
 WHERE element = 'com_content' AND type = 'component';

The params value looks like compact JSON:

{"show_title":"1","link_titles":"1","show_intro":"1","info_block_position":"0", ...}

So there are two storage locations, depending on which screen you used:

Screen	Stored in	Format
Global Configuration	`configuration.php`	PHP class `JConfig`
Component Options	`#__extensions.params`	JSON string

6. The Configuration Hierarchy: Which Value Wins

6.1 The Same Setting in Several Places

Many settings exist at more than one level. Take "Show Author" in com_content: there is a component-wide default in Articles → Options, but a category can override it, a menu item can override that, and a single article can override everything below it. Joomla lets the broad default sit at the top and lets more specific levels replace it. com_config edits the top two levels - Global Configuration and Component Options - but it helps to see the whole chain.

6.2 The Order of Precedence

From the most general level to the most specific:

Global Configuration        (broadest default)
  -> Component Options       (com_x Options: the whole component)
    -> Category settings     (options on a category)
      -> Menu Item settings  (Options tab of a menu item)
        -> Item settings      (the individual article, contact, ...)

The rule is simple: the most specific value that is not set to "Use Global" wins. Most option fields default to Use Global, which means "do not override here - fall back to the level above". Only when you pick an explicit Yes or No does that level take over.

6.3 Why a Setting Seems to Be Ignored

This chain is the usual reason a setting "does not work". You change "Show Author" in Articles → Options, yet one article still hides the author - because a menu item or that article sets it explicitly, and a more specific value always beats the component default.

The fix is to find the most specific level that overrides the value and either change it there or switch it back to Use Global. When in doubt, work from the bottom up: check the item, then its menu item, then its category, then the component, and finally Global Configuration.

7. Under the Hood: How a Setting Is Read

Saving a setting is only half the story. Developers need to read these values in their own code. Joomla offers a clean way for each kind.

7.1 Reading a Global Setting

Global Configuration values are available from the application object:

use Joomla\CMS\Factory;

$app      = Factory::getApplication();
$siteName = $app->get('sitename');
$cache    = $app->get('caching');
$tmpPath  = $app->get('tmp_path', '/tmp');   // second argument is a default

The application loads JConfig once at boot and exposes every property through get(). You never include configuration.php yourself.

7.2 Reading a Component Option

For component options, use ComponentHelper:

use Joomla\CMS\Component\ComponentHelper;

$params    = ComponentHelper::getParams('com_content');
$showTitle = $params->get('show_title', 1);
$layout    = $params->get('layout', 'default');

The returned object is a Joomla\Registry\Registry, the same class used throughout Joomla for key/value settings. The second argument is again a fallback default.

7.3 The Two APIs Side by Side

You want	Use
A global setting (site name, cache, mail)	`Factory::getApplication()->get('key')`
A component option (Articles, Contacts, ...)	`ComponentHelper::getParams('com_x')->get('key')`

Knowing which one to use comes straight from knowing where the value is stored, which is exactly what section 5 explained.

8. How com_config Saves Your Settings

8.1 Two Models, Two Destinations

The component has two models that handle saving:

ApplicationModel - saves Global Configuration to configuration.php.
ComponentModel - saves component Options to #__extensions.params.

Both validate the submitted data against the relevant form (the XML file) before they write anything. A value that fails validation is rejected, which is why a malformed entry can bounce you back to the form with an error.

8.2 A Safety Detail Worth Knowing

When ApplicationModel rewrites configuration.php, it removes the temporary super-user creation value and protects password fields so they are not blanked by an empty form submission. It also checks that the configuration file is writable. If the file is read-only (a common hardening step on production servers), Save fails with a clear message instead of silently losing your changes.

8.3 Three Possible Destinations

Putting it together, a single click of Save can write to three different places, depending on the tab:

Most fields        -> configuration.php   (JConfig class)
Permissions tab    -> #__assets row 1     (rules column, JSON)
Text Filters tab   -> com_config params   (#__extensions, JSON)

Those last two are special cases, and they surprise even experienced administrators. Section 9 explains them.

9. Permissions and Text Filters: The Special Cases

9.1 Permissions Go to the Root Asset

The Permissions tab does not write to configuration.php. Joomla's access control list (ACL) is stored in the #__assets table, and the global defaults live in the single root asset, the row with id = 1 and name root.1:

SELECT id, name, rules
  FROM jos_assets
 WHERE id = 1;

The rules column holds JSON like this:

{"core.login.site":{"6":1},"core.admin":{"8":1},"core.manage":{"7":1}, ...}

Each key is a permission, and each inner object maps a user group id to allow (1), deny (0), or inherit. Every other asset in Joomla inherits from this root, which is why the Global Configuration Permissions tab sits at the very top of the ACL chain.

One permission on this screen is special: core.admin. It is the "Super User" right, and it also decides who may open Global Configuration at all. Only members of a group with core.admin can reach com_config in the backend, which is why you should grant it to as few groups as possible.

9.2 Text Filters Go to com_config's Own Params

The Text Filters tab is also special. Its values are stored in the params of the com_config component itself, under a filters key:

SELECT params
  FROM jos_extensions
 WHERE element = 'com_config' AND type = 'component';

So com_config is one of the few components that stores settings about other users' behaviour inside its own row. When Joomla decides whether an editor may save a particular tag, it reads this filters data.

9.3 Why This Design

The split exists because permissions and filters are not really "site configuration" - they are access rules. Joomla keeps them in the ACL system so that the same rules engine handles global defaults and per-item overrides in exactly the same way. Global Configuration is just the friendliest place to edit the top-level defaults.

10. The Frontend com_config

10.1 Editing Without the Backend

The site half of com_config (public_html/components/com_config/) powers a few front-end editing screens. Its controllers are small and focused:

components/com_config/src/Controller/
+-- ModulesController.php     (front-end module editing)
+-- TemplatesController.php   (template style options)
+-- ConfigController.php      (user account / config form)

This is the machinery behind front-end editing: when a logged-in user with the right permission edits a module directly from the website (rather than from the backend), com_config on the site renders and saves that form.

10.2 The Frontend Module Edit Link

When front-end editing is enabled (a Global Configuration option, frontediting), authorised users see edit handles on modules. The link points back into the site com_config:

/index.php?option=com_config&view=modules&id=64

The same security rules apply as in the backend: the user must have the permission to edit that module, or the request is refused.

11. Web Services and Headless Access

11.1 No Public REST Route by Default

Many Joomla components expose a Web Services route under /api/index.php/v1/. com_config deliberately does not expose Global Configuration over REST. Site-wide settings, database credentials, and the secret key are exactly the data you do not want reachable through a public API, even with a token.

So there is no /api/index.php/v1/config endpoint to change your site name remotely. This is a safe default, not a missing feature.

11.2 Reading and Changing Settings in Automation

When you need to read or change settings from a script, do it inside Joomla's own application context, where the ACL and validation still apply:

// Inside a Joomla CLI application or plugin
use Joomla\CMS\Factory;
use Joomla\CMS\Component\ComponentHelper;

$app  = Factory::getApplication();
echo $app->get('sitename');                       // global setting

$show = ComponentHelper::getParams('com_content')
            ->get('show_title');                  // component option

For component options, you can also update the #__extensions.params JSON through the database in a controlled migration, then clear the cache. For Global Configuration, prefer editing through the backend so the file is rewritten correctly and password fields are preserved.

12. SEO and Metadata

Some of the most visited settings in com_config are the SEO and metadata options on the Site tab. They are worth a closer look because small changes here affect every URL on the site.

12.1 The Three SEF Settings

Setting	Field	Effect
Search Engine Friendly URLs	`sef`	Turns `index.php?option=...` into readable paths.
URL Rewriting	`sef_rewrite`	Removes `index.php` from the path (needs server rewrite rules).
Adds Suffix to URL	`sef_suffix`	Appends `.html` to generated URLs.

Turning on URL Rewriting without a working .htaccess (Apache) or rewrite rule (NGINX) gives "404 Not Found" on every page. Rename htaccess.txt to .htaccess first, then enable the setting.

12.2 Page Titles and Metadata

Include Site Name in Page Titles - adds your site name before or after each page title.
Site Meta Description - the default description used when a page does not set its own.
Robots - the global default for the robots meta tag (for example index, follow). Be careful: setting this to noindex hides the entire site from search engines.

These are defaults. Menu items, categories, and articles can override the description and robots value for individual pages.

13. Common Mistakes and Pitfalls

13.1 The Site Is Suddenly Offline

Symptom: Visitors see a maintenance message and cannot reach the site.

Fix: Open System → Global Configuration → Site and set Site Offline to No. If you are locked out of the backend too, edit configuration.php and set public $offline = '0';

13.2 Every Page Returns 404 After Enabling URL Rewriting

Symptom: The home page works, but every other link gives a 404.

Fix: You enabled URL Rewriting without the server rules. Rename htaccess.txt to .htaccess, or add the equivalent NGINX rule, then try again. If you cannot fix it quickly, set public $sef_rewrite = '0'; in configuration.php.

13.3 Saving Global Configuration Fails

Symptom: Clicking Save shows an error that the configuration file is not writable.

Fix: configuration.php is read-only (often 444 as a hardening step). Temporarily make it writable (644), save your changes, then set it back to read-only.

13.4 The Whole Site Disappears from Google

Symptom: Search rankings drop and pages stop being indexed.

Fix: Check the global Robots setting on the Site tab. If it is set to noindex, nofollow (sometimes left over from a staging site), search engines obey it. Set it back to index, follow.

13.5 Editors Lose Their HTML When Saving

Symptom: An editor saves an article and their iframe, script, or styling is stripped out.

Fix: That is the Text Filters tab doing its job. Adjust the filter for that user group (for example switch to a Whitelist that allows the tags you trust) - but never set "No Filtering" for groups you do not fully trust.

13.6 Stale Content After Changes

Symptom: You changed something but the site keeps showing the old version.

Fix: Caching is on. Either lower Cache Time, clear the cache under System → Clear Cache, or switch caching off while you debug.

14. Best Practices

If you remember only a few things from this article, remember these:

Know the storage map: most settings go to configuration.php, Permissions go to the #__assets root, Text Filters go to com_config's own params.
Back up configuration.php before any manual edit. It is one file, and it is easy to restore.
Keep configuration.php read-only on production, and only relax it briefly when you save.
Never expose your $secret value. Rotate it if it ever leaks.
Change SEF and cache settings on a staging copy first - they affect every page.
Read settings in code with the right API: $app->get() for global, ComponentHelper::getParams() for component options.
Set sensible global defaults on the Permissions and Metadata tabs, then override per item only where needed.

15. Quick Reference

OPEN GLOBAL CONFIG   /administrator/index.php?option=com_config&view=application
OPEN COMPONENT OPTS  /administrator/index.php?option=com_config&view=component&component=com_x
GLOBAL FORM FILE     administrator/components/com_config/forms/application.xml
COMPONENT FORM FILE  administrator/components/com_x/config.xml

STORAGE
  Global settings    public_html/configuration.php   (class JConfig)
  Component options  #__extensions.params            (JSON)
  Permissions tab    #__assets id=1 (root.1)         (rules column, JSON)
  Text Filters tab   #__extensions params of com_config (filters key)

READ IN CODE
  Global             Factory::getApplication()->get('sitename')
  Component option   ComponentHelper::getParams('com_content')->get('show_title')

KEY GLOBAL KEYS      sitename, offline, sef, sef_rewrite, caching, cachetime,
                     mailer, force_ssl, error_reporting, tmp_path, secret

16. Summary

The component com_config is small but central to every Joomla site:

It renders Global Configuration and the per-component Options screens from the same code.
Global settings are stored as a PHP class in configuration.php, not in the database.
Component options are stored as JSON in #__extensions.params.
The Permissions tab writes to the ACL root asset, and Text Filters write to com_config's own params.
You read global settings with Factory::getApplication()->get() and component options with ComponentHelper::getParams().
Global Configuration is intentionally not exposed over the REST API.

Once you know where each setting lives, Global Configuration stops being a wall of options and becomes a clear map: this value is in a file, that one is in the database, and these two are really access rules. If your site behaves in a way you cannot explain - slow pages, broken URLs, missing HTML, or a sudden drop in search traffic - the cause is very often a single setting in com_config. Knowing how it is stored and read is the fastest way to find it, and it is one of the components a Joomla professional should know well.

Peter Martin

Joomla specialist and Linux admin for fast, secure and scalable websites.

26 May 2026