This doesn't work well because templates support copy function.

@SharkyKZ what do you suggest?

@SharkyKZ I can confirm, using the template defined custom fields in the options of a plugin doesn't work, so please what do we need to change to make it work? I really think this is important.

This works fine, just not when copying templates. If it doesn't work for you at all, the issue must be elsewhere.

What do you mean "when copying templates" please? You mean multiple template styles? If that's what you mean, I tested that as well, no issue at all.

I mean copying the template using Copy Template button.

Well, after a Copy Template I'm getting some strange errors:

JInstaller: :Install: File does not exist site\tmp\template_copy_5f7581c597a87\Field
Template Install: Could not copy files from the files source.

Error installing template
Unable to install new template from temporary folder.

After correcting the folder structure, (I moved Field folder inside src and updated templateDetails.xml) (facepalm) the installation went fine. I think I understand your concern, the new template still keeps the old namespace for it's custom fields and other functionality, if you delete the original template, the new template will throw lots of crits.

I'm now going forward with testing custom fields defined with modules and see how they work across extensions, I suspect it's going to work the same as for the templates (template defined custom fields don't work in plugin options) given both types have same namespace logic.

Modules don't have the same issue because there's no function for copying module extensions.

Yea, I can confirm, custom fields defined within modules work across extensions. I don't know how to make it work for templates but at this point, I'm happy the template defined fields work inside its back-end panel.

I'm now going forward with testing if Helper from src folder work properly in template index.php and html + html/layouts overrides. If this test is successful, I think we're good. Would you agree?

Obviously we need to document this limitation if this change goes through.

No. This is not acceptable in its current state. Eventually we could remove copy template functionality completely. But until then I suggest to use a plugin for registering template namespaces.

In my view adding a plugin to host libraries, helpers, fields and other resources is just like a template framework, which is not the point I'm trying to make. I was initially a template developer, I used to work with all these frameworks, but after some more experience I came to the point where templates can do anything a framework like T3/T4/Helix can do, and without the troubles of maintenance. I want to avoid bloatware and corruptible code as much as possible, clearly Joomla can & should do without.

On the other side, I stand by you. I really hope we implement this feature, I think we can bring back people to Joomla with awesome templates.

@SharkyKZ what is the resolution for this issue?

My opinion hasn't changed since the last comment.

Would be a pity to have Joomla 4 without namespaced templates.

Please who else has a say in this? Is this feature never gonna come to Joomla 4?

@brianteeman, @PhilETaylor @eddieajau @wilsonge ?

LMAO that you think my opinion counts for anything in joomla's architectural direction.

The technical reason why namespaced templates is not easy to achieve has been outlined already.

The only way to implement the copy function is to have the copy function make changes to the namespaces within all the files it copies - which is a recipe for pain as disaster... but not impossible.

I was looking at commit authors and figured you could have a say in it. Thanks for your input.

What is more important for Joomla: namespaced templates or copy template functionality?

Well what holds us back merging what is in this PR and check on the copy feature whether that is a namespaced template and than point to documentation how to copy such templates. I would say this would be a fair compromise what does others think?

@zero-24 for some reason, the classes defined within namespaced template (mostly fields) cannot autoload in plugins or other extensions, this is, as @SharkyKZ pointed out, related to copy template functionality. I can confirm with my tests.

@zero-24 for some reason, the classes defined within namespaced template (mostly fields) cannot autoload in plugins or other extensions, this is, as @SharkyKZ pointed out, related to copy template functionality. I can confirm with my tests.

Yes that is the reason i suggested to not allow namespaced templates to be copied than via the GUI. So both ways are possible the only disadvantage for namespaced templates is that there is no simple copy feature anymore from the backend for the reasons pointed out here.

Sounds good for me. Imma make a great template without any framework, and you will love it :)

What is more important for Joomla: namespaced templates or copy template functionality?

Copy function could be removed completely. Maybe too late for 4.0. But certainly in 5.0.

And templates can already be namespaced, but without using the namespace mapper.

What is more important for Joomla: namespaced templates or copy template functionality?

Copy function could be removed completely. Maybe too late for 4.0. But certainly in 5.0.

And templates can already be namespaced, but without using the namespace mapper.

Why should we not allow using the namespace mapper + add that condition to the copy feature?

I didn't say we shouldn't. Just clearing the misconception that templates can't be namespaced already.

I didn't say we shouldn't. Just clearing the misconception that templates can't be namespaced already.

Ok so this (merging here and add a condition to the copy feature) would be a good way to go forward right?

I not tried, but I think there should not be problem with copied template, it will continue to use namespace of Source template, that is okau

or I am wrong?

@Fedik in my test I can confirm that. Copied templates makes use of Joomla\Template\originalTemplate from namespace map.

It will use whichever is added to namespace map last. Even if it did use the original path, that would still be wrong.

@zero-24 It's fine I guess.

Potentially in this case the compromise might be delaying the autoloading of templates - what if we only added the template that's being actively loaded on the page by adding it into HtmlDocument::_loadTemplate? Then you'll never have duplicates even if templates have the same class names (obviously this is undesirable but.....)

I also like @zero-24 's suggestion of disabling the copy functionality btw if the template is namespaced. With the child template functionality merged and the further stuff @dgrammatiko has planned which should go into 4.1 - i suspect the common usecase for the copy button will be less useful.

I think one way or another we need a solution before this can be merged though

i suspect the common usecase for the copy button will be less useful.

Actually that was one of the things which hold me from pushing any changes in the PR for the com_template. Personally I think there shouldn't be a copy button mainly for few reasons:

• The core doesn't offer such functionality for any other pieces of code (module, plugin, component)
• It's plain wrong (at least in my pov) to blindly copy someone else's code (even if it's OSS or you've paid for it) through a click of a button.
• With the sub templates/child templates forking a template makes 0 sense

That said maybe we can rethink the namespace (eg in the xml define namespace=foo) so the child templates can extend from the parent namespace (? rough idea, I have no clue what the details could be here, obviously needs some proper research)

has planned which should go into 4.1

I need to find some time to clean up the PR and write the description (that's gonna be lengthy, it will serve also as the base for the docs)

I'm glad you guys didn't forget about this, what's up? I'm personally all in with any of your decision guys. What @dgrammatiko explains makes complete sense to me.

Do you guys think this change has any chance to go though the next beta release?

After 3 weeks, what's the verdict of this commit please?

I would not go with @wilsonge's suggestion to autoload only active template classes. That would mean having to manually load classes in com_templates forms, com_ajax (once that is eventually fixed) and anywhere else where we need non-active template. Would be better off with devs using own autoloader in such case.

Blocking copy function in com_templates for namespaced templates would be acceptable for me.

OK then let's block copy in namespaced templates then

Feel free to commit to this branch. Is it possible?

OK then let's block copy in namespaced templates then

@wilsonge can you clarify which templates could be namespaced?

What I mean is it will be way easier for me (#30359 ) to have the namesapaced templates following only the new, inheritable way (child templates)

@wilsonge can you clarify which templates could be namespaced?

Any templates could be (although I don't think any in core will be). It's more to allow templates with complex PHP logic to autoload their code rather then bundling it in their own index.php

@wilsonge will this PR get approved in the next beta please?

pr have not the needed 2 successfully test.

Someone needs to add the code change for disabling clone when this attribute is present. Then it needs two tests. I think it's unlikely this makes it to 4.0 unless that is done very quickly.

@wilsonge the Joomla news ask for feedback and contribution to the project, here I am.

From my experience, Joomla extensions sell the most Joomla, especially templates. If this doesn't go to Joomla 4.0, I don't know who will develop templates with addfieldpath and other legacy class standard. I certainly won't, and I love Joomla, I won't let go so easlilly.

So please, get me someone willing to contribute and / or is able to provide guidance on this task, I'm willing to work on it.

Hi guys @wilsonge @SharkyKZ and anyone else. I'm back to work on Joomla and I've researched the new Beta7 code.

Probably the easiest way to disable template copy for namespaced templates is to do the following:

• administrator\components\com_templates\src\View\Template\HtmlView.php ~line 261 could check for the current template if is namespaced,
• the code I have in mind

Method 1

$btnClass = checkNamespacedExtension($this->template) ? 'btn-primary' : 'btn-primary disabled';
ToolbarHelper::modal('copyModal', 'icon-copy', 'COM_TEMPLATES_BUTTON_COPY_TEMPLATE', $btnClass);

This method might require small tooltip for the button itself to let the user know why the action is not possible.

Method 2

if ( !checkNamespacedExtension($this->template) )
  ToolbarHelper::modal('copyModal', 'icon-copy', 'COM_TEMPLATES_BUTTON_COPY_TEMPLATE');
}

This method is probably better, the template developer can provide documentation on the issue.

Come on guys, lets do this!

The thing is: I don't know how to check if an extension is namespaced without loading the XML file, you guys probably know a better way.

Guys, a little help?

$templateDetails = JPATH_SITE.DIRECTORY_SEPARATOR.'templates'.DIRECTORY_SEPARATOR.($this->template->name).DIRECTORY_SEPARATOR.'templateDetails.xml';
$templateXML = simplexml_load_file($templateDetails);

if ( (string) $templateXML->namespace === null || (string) $templateXML->namespace === '' ) {
  ToolbarHelper::modal('copyModal', 'icon-copy', 'COM_TEMPLATES_BUTTON_COPY_TEMPLATE');
}

This effectively disables copy template feature when that template is namespaced. You guys agree? You guys have a better idea?

You need to solve conflicts in that file. Do you need help with that?

@richard67 yes please

@thednp I've solved the merge conflict on GitHub. That means if you need to do more changes locally later for some reason, you have to pull changes first from remote so you see them locally.

@thednp For namespace stuff I'm not really the expert, so let's wait for feedback from others here.

@richard67 thank you very much, I wish you stay close to this, it's really important IMO.

In brief: this last change was discussed above and needed to complement the original commit to fully enable namespace for templates. Perhaps you would be kind enough to validate this as soon as bots do their checking, would be so grateful.

Thanks again.

@wilsonge @dgrammatiko @SharkyKZ @zero-24 and any other reviewer.

As you can see I've implemented all discussed above:

• namespace related changes to the namespacemap.php class to enable the feature for templates;
• disabled the COPY TEMPLATE button in the Template Manager, when the template extension is namespaced.

However there's room for improvement. I was thinking lately of a new utility to be added either to the namespacemap.php class or the extension parent class, something to return the extension namespace. But since this is not justifiable only for templates, I think a namespace object property for all namespaced extensions might be actually better, it can hugely optimize the creation speed of the namespacemap file.

• we basically store the extension namespace at installation, and just like that you have $this->template->namespace similar to $this->template->name for instance,
• core extensions might need to add/update this property probably in the db
• when creating the administrator/cache/autoload_psr4.php file, it only needs to check this property, no need to load the entire XML file for each extension, every time the namespacemap file is created.

Please let me know what you guys think?

@SharkyKZ am I to understand that my commits are bad or the above idea about storing the extension namespace into the extension object is bad?

Also, again, what are we waiting for in merging this in?

I'm just thinking about another way to do it which does not require to read the XML (or from database, if it would go that way) each time:

When installing or updating a 3rd party template, the installer would check the XML if the template is namespaced or not, and set a new column "namespaced" or "nocopy" to either 1 or 0 in the template styles table for that template. For the core templates we would set this in the installation.sql (and the update sql for previous J4 beta versions).

The backend then would only have to read that flag from database together with the other stuff.

But anyway I think it needs some kind of decision which way to go.

Well, I suggested something similar above and got downvoted once, I believe db changes are not desirable (possibly due to the J3 J4 compatibility layers). At this point, I believe this might be the right decision.

... I mean which way to go with the template copy functionality as such, with respect to child templates.

Child templates is not going to be implemented afaik. I personally don't mind, the template styles can serve the same purpose to some extent, except template overrides, but those view files can be extended within the template itself without any way to break the layout or anything.

The "copy template" feature was something for back-up purposes I believe, but "won't work well" with namespaced templates. I think namespace is a very specific and "must be unique identifier".

Child templates is not going to be implemented afaik.

Child templates are already implemented what's missing is the GUI updates and I'm working on them as we speak #30359

FWIW child templates will not be forkable, there's not need for that in the core

@dgrammatiko interesting, will that interfere or break the namespaced templates? I believe not, I guess a template and all its child-themes use the same namespace, the child-theme feature is more like a way to override the layouts in this order (I guess):

• child-theme layout
• parent layout
• core default layout

I really hope these two features won't collide.

interesting, will that interfere or break the namespaced templates?

For the old templates the copy/fork will work as before (assuming that this PR is merged then if there's a namespace field in the XML that will be respected, eg no copy)
For the new mode (parnt-child), there won't be a copy/fork anymore (you can have unlimited childs of a parent template without breaking anything and most important updates won't also break anything)

the child-theme feature is more like a way to override the layouts in this order:

Yes, the layout overrides but also the static assets overrides as well

Yes, the layout overrides but also the static assets overrides as well

@dgrammatiko That is crazy good.

Now would a namespace property of the template extension help you or your feature in any way?

Me and @richard67 were talking about this.

@thednp I was thinking if it would make any sense to consolidate some of the 3 new fields, with child templates we introduced parent and inheritable and with this, we're introducing namespace but I guess they're not really relatable although requiring all the new mode templates to be namespace is something that would be quite logical for me. My 2c

@dgrammatiko I think child templates will very much like to do use Joomla\Template\Cassiopeia\Site\SomeClassName, it will only make more sense to merge this PR right here :D

I'm just thinking about another way to do it which does not require to read the XML

For now it is fine as it is.
Joomla do not store Namespace anywhere in database for any extension, at least I not found.
However some "helper" to check an extension "Namespace" would be useful in future, I guess.
But it another story.

Joomla do not store Namespace anywhere in database for any extension, at least I not found.

I didn't think about storing the namespace, I thought about storing a flag telling if the template is namespaced or not, so here we would just check that flag to see if we can copy or not. That flag would be set by the installer when installing or updating a template.

I thought about storing a flag telling if the template is namespaced or not

We can assume that the new mode templates are namespaced so we can use the already existing parent, inheritable flags

We can assume that the new mode templates are namespaced so we can use the already existing parent, inheritable flags

Can we also assume that the old mode templates are not namespaced?

I thought about storing a flag telling if the template is namespaced or not

We should not make anything special for template, it just another kind of extension.
When Joomla will have BlablaHelper::getExtensionNamespace() (or something more smart), that would be enough, and will cover much more than just template.
But as I said, it is another story ;)

Can we also assume that the old mode templates are not namespaced?

Assume was the wrong verb. I meant we can force the new mode to be only namespaced and let the legacy part die slowly... The effort is not that much for devs: add the 3 fields parent, inheritable and namespace and also move the assets to the media field from the files, it's like 5 minutes if you do it manually or a simple script can do that automatically (I'm ignoring here the namespace parts in the PHP files but also that shouldn't be a painful task)

Assume was the wrong verb. I meant we can force the new mode to be only namespaced and let the legacy part die slowly...

The point here in this PR is we have to check if we are not namespaced, and only allow copy then. So as long as the legacy part exists and legacy templates can be namespaced, we can't rely on parent and inheritable only.

So as long as the legacy part exists and legacy templates can be namespaced, we can't rely on parent and inheritable only.

Right, this is the current approach and it's fine. What I'm trying to say here is that we're already introducing a new mode for templates and it might be wise to make the new mode namespaced by default. Also as side effect ignore legacy namespaced templates. The reason is way fewer things to break and less code to patch in the next major version (?) where the legacy templates will not be supported anymore

@SharkyKZ @wilsonge @Fedik @dgrammatiko @infograf768 @richard67 @brianteeman

Are we RTC yet?

Nothing to do with me I am afraid

@thednp before to move a pr on RTC status, we require at least 2 succesfull test

I know @alikon , perhaps you can score one?

I have tested this item ✅ successfully on 1d98ab1

works good for me

I have tested this item ✅ successfully on 1d98ab1

RTC

The only input I have is that we have back end and front end templates, so it is a similar situation like with components. So wondering if we should add the client also into the namespace path?

So wondering if we should add the client also into the namespace path?

It makes sense. I didn't paid attention but I guess it already should work like that.
I will try to test this case, later.

@laoneo Site/Administrator is working:

Nice. On components I guess the client is after the vendor...

Nice. On components I guess the client is after the vendor...

It would make sense to have Joomla\\Template\\Site\\Cassiopeia as it's closer to the media parts: media/templates/site/cassiopeia (that's for the new mode, childs) but meh

@laoneo I only duplicated what the code does for modules, it makes sense to have a proper order like Joomla\\Template\\Site\\Cassiopeia for all namespaced templates/extensions.

On components I guess the client is after the vendor

it the same,

@Fedik thanks for clarification. I guess we are here good to go. But somehow we need a deprecated message that copying a template is not recommended anymore.

I think it enough to note somewhere on release page or https://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4#Templates

Something like: "child template" replaces the copy feature, especially for a namespaced template.
It requires documentation anyway ?

Something like: "child template" replaces the copy feature, especially for a namespaced template.
It requires documentation anyway

We can't really expose child templates without having a GUI in place

We can't really expose child templates without having a GUI in place

Yeah right, I forgot.
Then just note that "copy" will not work for a namespaced template.

I am moving this to 4.1, we are in beta and this is a new feature. Thank you all who have been working on this and bringing it to the state it is now. But if we want to get 4.0 out of the door we need to make a cut.

Side note: this decision has be discussed in the production department and the maintainers team. It's not just mine even if I support the decision.

I don't understand why it's considered a new feature since J4 was booted with namespace support for all extensions except, interestingly, com_ajax and templates, but anyways. More updates work for the future I guess.

It's a new feature because it adds a new functionality to the system. It also has some side effects e.g. the copy function of the template. The change is too big as we can do this at the state we are now. Hope this explanis it a bit better.

Yes yes, also the transition from Joomla 1.5 code, finally.

Guys what's the status of this please?

I'm in favor of this but since we're introducing a new mode for templates maybe we should make it a required field for any template that implements child templates and leave the current templates unaffected. What I mean is if someone wants to namespace their template they also need to support child templates (basically one more field in the XML <inheritable>1</inheritable> and move all the static assets to media/templates/(administrator || site)/templateName/)

maybe we should make it a required field for any template that implements child templates and leave the current templates unaffected

This PR already RTC,
I think it is better if something new will go separately, unless it really issue ;)

I think it is better if something new will go separately, unless it really issue ;)

It's not something new, it's a concern raised before https://github.com/joomla/joomla-cms/pull/30816/files#r582107454 Also probably the reason why this PR is not merged yet.

Back to pending due to merge conflicts after rebase.

@thednp We had to rebase the PR to 4.2-dev, which has caused merge conflicts now.

As I can see you have meanwhile deleted the branch for this PR. Does that mean you won't continue this PR and someone else shall take it over? Or are you still available to work on it?

In the latter case you would have to restore the patch-2 branch and update it to latest 4.2-dev. We could help with that if necessary. Or you redo the PR with a new branch for 4.2-dev.

Just let us know if you continue or someone shall take it over.

Thanks in advance.

It's a pity that this didn't make it with the new mode templates...

@richard67 my Joomla PRs, especially the color-picker one, have taken so much of my time I don't even know anymore. @dgrammatiko you referring to child templates? Is this PR crucial for that feature?

@thednp child templates don't depend on the namespaces but it would have been great to have them right from the start fro the new templates that support child templates. It will happen at some point because there's a need for namespaces...
Also sorry that the cooler picker is still not merged and the project has to rely on an abandoned/non maintained script for the picker... ?‍♂️

I hope I will have news for you @dgrammatiko soon, I finally found some time and context to learn about custom element slots and I'm planning to release an improved color-picker version to npm (you will also be mentioned), so anyone interested in implementing it in Joomla / Wordpress etc should have a painless transition from what ever color-picker to possibly the best color picker you could ever dream of.

As a side note, I wish these improvements would have been implemented into J4.0 already. We're talking small bits of QOL that could make a big difference for our users. Lots of wasted potential.

The only problem which blocks namespaces for templates is the copy function. Right? Can this be removed with child templates?

Can this be removed with child templates?

You cannot (by design) copy neither a parent or a child template, so this was never an issue

For a parent template the toolbar is like:

For a child template is like:

Both toolbars missing (on purpose, because I had big hopes for this PR) the Copy Template button. Anyways maybe in 4.2...

I mean the whole copy template function

I mean the whole copy template function

The button exists only for Legacy templates because nobody wanted to break B/C in a minor. For the templates that either support child templates or are child templates the button is not available (I've updated my previous comment). Also the idea was to have them only in the new mode, eg the template needs to support child templates to be able to use namespaces (not in this PR, maybe thus the confusion)

@laoneo what I'm trying (probably poorly) to say is that the changes in this PR from the libraries/namespacemap.php is all it's needed for the templates that support child templates.

Partially agree as I would like to see a bootTemplate function which uses the service provider as well.

Ok, where do we disagree?

@laoneo what I'm trying (probably poorly) to say is that the changes in this PR from the libraries/namespacemap.php is all it's needed for the templates that support child templates.

No disagree, here I would go one step further.

No disagree, here I would go one step further.

Can you explain that step?

To load a template by service provider.

To load a template by service provider.

@laoneo could you write some pseudo code for the provider? I struggle to figure out how the boot process would look like (I mean not for a helper, that would be probably the same as it is for modules but for the entry points like index.php, component.php, etc). Maybe I'm missing the file/folder structure that such templates should follow...

Since the original branch has been deleted I recreated the Pull request and updated it to a more proper version at #39011

I'm closing this for now, thanks