[BUG]: "Name in Code" is auto-capitalized on save, breaking [[[ComponentNamespace]]] tag #1304
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: joomla/Component-Builder#1304
Reference in new issue
Block a user
What Happened?
In JCB 6.1.5, when saving a component, the "Name in Code" field is automatically modified so that the first letter becomes uppercase.
Steps to reproduce the Bug
The value is modified to have the first letter uppercase (e.g. Mycomponent).
The original casing should be preserved, as defined by the user.
This breaks functionality when using the [ComponentNamespace] tag, since namespace generation becomes invalid due to incorrect casing
Which Joomla version are you compiling in?
6.1.0
Which PHP version are you compiling in?
8.3
Which Joomla versions are you targeting?
v6
Which PHP version are you targeting?
8.1+
Which Web server is JCB running on?
Apache 2.4.66
Which Relational Database is JCB running on?
Mysql 11.6.2-MariaDB-ubu2404
Which OS is JCB running on?
ubuntu
Which JCB version are you using?
6.1.5
Where in JCB did this issue occur?
Other
On which browsers did you encounter the issue?
Firefox
Additional Comments
No response
I found what is happening, in joomla_componentModel.save()
administrator\components\com_componentbuilder\src\Model\Joomla_componentModel.save()
// make sure that the component code name is safe. if (!empty($data['system_name']) && UtilitiesStringHelper::check($data['system_name'])) { $data['name_code'] = ComponentCodeNameHelper::safe($data['name_code']); }libraries\vendor_jcb\VDM.Joomla\src\Utilities\String\ComponentCodeNameHelper.safe()
// Ensure the first character is uppercase (useful if the input string started with an invalid character) $string = ucfirst($string);.I checkt the site view model to see how the codename is saved there, and it is using another helper class to clean the strin
$data['codename'] = UtilitiesStringHelper::safe($data['codename']);I committed the changes for ComponentCodeNameHelper.safe()
Hi @oxido,
The chances of us changing this core functionality are probably close to zero. The core name of your component is used in your database naming, it is used in folder naming, it is used in class naming, and it is used all over the product in numerous ways. People have become used to the fact that whatever they put in there is going to be modeled into a capitalized implementation, which is different between Joomla 3 and Joomla 4 upwards. Joomla 3 we treated differently because it did not have namespacing, but now from Joomla 4 upwards, we have again added a namespace placeholder as well. These are very standard, strongly enforced conventions that would probably never be changed.
Here is the main objective, or motive, for why it will not change. The moment you now have a folder with lowercase, where in the past you may have added your code in lowercase but JCB took care of making it uppercase, it means your folder name had an uppercase, and the moment we no longer enforce that, you end up in your downstream application distribution network with both uppercase and lowercase folder duplication. In some systems this may not be a problem, but in other systems capitalization is not honored as well as it is in Linux. Not only is that going to bloat the code base, but it is also going to bring confusion. People might work on a file in an uppercase folder structure, not realizing that they should now be working in the lowercase folder structure.
So now we would need to write engines that clean up all the folders that have previously been created to ensure that we do not have duplicate class naming downstream. To us, from an architectural point of view, as small as this change may look to you, and as convenient as it may be, it is going to cause a cascading effect of catastrophe downstream for other extension developers who already rely on its automated behavior.
For that reason, I have spoken to our lead architect on the project, and he was not favorable toward the change. So I do not think this is going to happen. We will still give it some time and give it more thought, but just off the bat, without digging too much deeper, we are reluctant to consider this change purely because making the code name a capital in Joomla 4 is required. If you do not do it like that, it actually affects your namespacing process.
That is how JCB was coupled together. JCB's original intent was to take the little that you do and make it considerably more. So the reusing of the code name across the project in various shapes and forms, automatically taking care of its capitalization or whatever is required, was a necessity instead of adding many fields for all the different implementations, which would have added extra input requirements.
So while this may look like an easy fix, it is not really that easy and requires far more complex consideration. So yes, accept this as my apology for not accepting this change. Llewellyn will still think about it more, but from what I have heard so far, I do not think this is going to happen.
Hi @Lemuel ,
Thanks for the clarification, I understand the reasoning and the constraints around keeping this behavior consistent.
From my side, this just highlighted a small practical issue: I didn’t realize until now (in v5/v6) that the capitalization is enforced in a way that can affect case-sensitive scenarios.
So for now, it seems that [ComponentNamespace] isn’t always safe to use in every context, as it can lead to issues where strict casing matters. Maybe this is something that could be clarified in documentation or handled in a future iteration.
Thanks again for taking the time to explain.
I will clse this issue now.
I think there is a misunderstanding about the intended purpose and scope of these placeholders. This specific placeholder logic is not meant to be used in every context. It has a defined purpose, and in that purpose it behaves consistently and safely.
The placeholder in question exists to represent the component name specifically in the namespace context. That is its purpose. It is not intended as a universal replacement token for arbitrary contexts.
To be explicit, the standard placeholder behavior is:
[[[Component]]]→ component name in capitalized form[[[component]]]→ component name in lowercase form[[[COMPONENT]]]→ component name in uppercase formAnd where the namespace-safe form is needed, that conversion is handled in the namespace placeholder implementation itself.
So if someone wants the component name in a namespace, this placeholder is used for that exact purpose. If someone wants the component name in another format, there are already dedicated placeholders for that. That is the design. It is not ambiguous, and it is not inconsistent.
This is also not theoretical. We are maintaining well over a thousand classes using this namespace placeholder approach so those classes can be shared and reused across components, and it has not behaved inconsistently or unsafely in that role.
For reference, this is exactly where those placeholders are built:
.../libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Component/Placeholder.php#L113-L129
That implementation uses the safe segment namespace helper. If you inspect the
safeSegmentmethod in the namespace helper class, you will see that it applies standard namespace-safe sanitization. There is nothing unusual or unsafe about that behavior. On the contrary, it enforces the exact kind of safe namespace segment handling that is commonly expected and widely used.So from my perspective, the statement that this implementation "isn't safe" is not supported by the actual code path.
There is another important point here as well: these placeholders are not fixed in a way that prevents customization. Any of the default placeholders can be overridden by component-level placeholders. In the component configuration there is a magnifying glass icon that allows a developer to define component-specific placeholders. Where those overlap with the defaults, the component-level placeholders take precedence. So even the defaults being built in the linked class are intentionally overridable. As a side note... I will add an update to this class to make the override target the hash values set as-well
That means the system already provides both:
Because of that, I do not see a real limitation here. The architectural design is standard, the conversion behavior is explicit, and the namespace handling is already safeguarded through the safe segment helper.
I am absolutely open to contributions and improvements where there is a concrete issue to solve. But at this stage, I do not see evidence that this implementation is unsafe. If there is a specific failing example, edge case, or reproducible namespace output that violates the safety guarantees, please share it directly. That would make it possible to evaluate an actual defect instead of responding to a broad claim that does not appear to match the implementation.
Thank you again for the feedback and for engaging with the code. Constructive contributions are always welcome, but I do think it is important that we distinguish between a real implementation problem and a concern that is not borne out by how the placeholder system actually works.
Thanks for the detailed explanation, that helps clarify the intended scope of the placeholder.
I understand now that it’s specifically designed for the namespace context and that other formats are handled through dedicated placeholders or overrides. That makes sense from a design perspective.
I did, however, interpret the following note incorrectly when creating a Power:
“Although the older
[[[Component]]]placeholder still works, it is discouraged in favor of the two above.”From that, I assumed there might still be some legacy ambiguity or overlap in how the older and newer placeholders behave, which is what led to my concern.
That said, I see your point that the system is clearly defined and that namespace handling is intentionally separated and safeguarded.
Appreciate the clarification and the openness to feedback.