[#46622] - [6.1] Provide #__extensions.custom_data for components, menus, modules and template styles
- Fixed in Code Base
- 8 Feb 2026
- Medium
- Build: 6.1-dev
- # 46622
- Diff
- Denitz:patch-29
User tests: Successful: Unsuccessful:
Summary of Changes
We have nice #__extensions.custom_data MEDIUMTEXT column to store custom extension data, but it's not available in Joomla get extension methods.
Example: currently, if a template stores any own data in #__extensions.custom_data, it can be only retrieved via separate SQL query.
It would be nice to be able to have access to custom_data via native $app->getTemplate(true)
I.e. YooTheme will be able to use this workaround to reduce extra SQL query per page load.
Same for components, menus and modules.
Testing Instructions
Install patch.
Actual result BEFORE applying this Pull Request
You can't get custom_data via $app->getTemplate(true) and other extension get methods:
var_dump(\Joomla\CMS\Component\ComponentHelper::getComponent('com_content'));
var_dump(\Joomla\CMS\Plugin\PluginHelper::getPlugin('authentication', 'joomla'));
var_dump(\Joomla\CMS\Helper\ModuleHelper::getModule('mod_menu'));
var_dump(\Joomla\CMS\Factory::getApplication()->getTemplate(true));Expected result AFTER applying this Pull Request
You can get custom_data in all methods above.
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
No documentation changes for docs.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_templates |
| Labels |
Added:
PR-6.1-dev
|
||
| Category | Administration com_templates | ⇒ | Administration com_templates Libraries |
| Title |
|
||||||
@HLeithner I've updated the description and code to have custom_data for components, menus and modules consistently.
thanks, now we need some testers.
at least not in this pr, I think.
I have tested this item ✅ successfully on 8c93b95
Tested by code review and data insertion into db and then check via PHP. Works perfectly.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46622.
I have tested this item ✅ successfully on 8c93b95
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46622.
I have tested this item ✅ successfully on 8c93b95
I tested this PR #46622 and encountered an issue with saving custom_data.
Steps to reproduce:
- I manually set a value in the
custom_datafield of the#__extensionstable (for a specific extension). - After saving (or refreshing), when I check the value, it shows as empty.
Actual Result:
The object dump shows: public 'custom_data' => string '' (length=0)
Expected Result:
The custom_data value should be persisted and retrieved correctly.
Question:
Is this the expected behavior after the changes in this PR, or could it be a bug?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46622.
After saving (or refreshing), when I check the value, it shows as empty.
How did you save/refresh it exactly?
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-02-08 09:14:09 |
| Closed_By | ⇒ | HLeithner | |
| Labels |
Added:
Feature
PBF
|
||
Thanks
@HLeithner shouldn't we wait till we figure out if the possible bug is reality before merging?
Since his test was marked successful, I didn't expect a new bug... (didn't read the rest since we had already 2 successful tests).
so yes would be good to validate and create a new pr to fix this, but without further information who he saved it it's a bit hard.
After saving (or refreshing), when I check the value, it shows as empty.
How did you save/refresh it exactly?
I manually updated the custom_data column in the #__extensions table using phpMyAdmin, like this:
UPDATE #__extensions SET custom_data = '{"test":"value"}' WHERE extension_id = 92;
Then I refreshed the frontend page that calls
\Joomla\CMS\Plugin\PluginHelper::getPlugin('authentication', 'joomla').
The object shows custom_data as an empty string, even though the database value is present.
If my testing method is incorrect, please don't spend time on it; I just want to make sure your time isn't wasted unnecessarily.
@mortezahonar Do you have caching enabled in global config? If yes, please delete com_plugins cache after changes in database.
@mortezahonar Do you have caching enabled in global config? If yes, please delete com_plugins cache after changes in database.
custom_data is properly returned after applying the patch.
public 'custom_data' => string '{"test":"value"}' (length=16)
So everything ok now? @mortezahonar
I did a quick look and it isn't loaded anywhere in the core, for example the ComponentHelper also doesn't load it. So I'm not so sure if it should be added at all. it's a field only for 3rd party extensions (based on the relevant github pr and issue) which also means it's in your space to use it as you need it.
If we load it we should be consistent and make it available in all get functions.