Conflicting Files ? Success

User tests: Successful: Unsuccessful:

avatar thednp
thednp
30 Sep 2020

Pull Request for Issue #30272.

Summary of Changes

As discussed in the #30272 report, Joomla does not support namespaced templates, this commit solves that.

  • the create() method now checks for namespaced template extension types
  • the getNamespaces() method properly recognize Administrator and Site templates; in addition, it will look for templateDetails.xml file instead of extensionName.xml and read the designated namespace (Line 182)

Testing Instructions

In order to enable namespace for templates, here are the few steps, we'll use the default site template:

  • open site/templates/cassiopeia/templateDetails.xml and add between <description> and <files> the following
<namespace path="src">Joomla\Template\Cassiopeia</namespace>
  • delete site/administrator/cache/autoload_psr4.php
  • login to your site/administrator
  • open the newly created site/administrator/cache/autoload_psr4.php, the last element of the return object should be
'Joomla\\Template\\Cassiopeia\\Site\\' => [JPATH_SITE . '/templates/cassiopeia/src']
  • optional: create a custom field in site/templates/cassiopeia/src/Field folder and add it to the templateDetails.xml along with addfieldprefix="Joomla\Template\Cassiopeia\Site\Field" attribute added to the parent <fieldset>
  • optional try and call the newly added custom field from your namespaced template into a module/plugin, test it out

Actual result BEFORE applying this Pull Request

The namespacemap.php class had no support for Site Templates / Administrator Templates. addfieldpreffix couldn't be used with template defined custom fields.

Expected result AFTER applying this Pull Request

Site Templates / Administrator Templates can be developed with namespace features.

Documentation Changes Required

Yes. (I wish I knew where)

Questions

  • should I commit this change to the 4.1-dev branch as well?
  • should I commit this change to the staging branch? If yes, where is the namespacemap.php file?
avatar thednp thednp - open - 30 Sep 2020
avatar thednp thednp - change - 30 Sep 2020
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 30 Sep 2020
Category Libraries
avatar thednp thednp - change - 30 Sep 2020
The description was changed
avatar thednp thednp - edited - 30 Sep 2020
avatar SharkyKZ
SharkyKZ - comment - 30 Sep 2020

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

avatar thednp
thednp - comment - 30 Sep 2020

@SharkyKZ what do you suggest?

avatar thednp
thednp - comment - 30 Sep 2020

@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.

avatar SharkyKZ
SharkyKZ - comment - 1 Oct 2020

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

avatar thednp
thednp - comment - 1 Oct 2020

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.

avatar SharkyKZ
SharkyKZ - comment - 1 Oct 2020

I mean copying the template using Copy Template button.

avatar thednp
thednp - comment - 1 Oct 2020

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.

avatar SharkyKZ
SharkyKZ - comment - 1 Oct 2020

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

avatar thednp
thednp - comment - 1 Oct 2020

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.

avatar SharkyKZ
SharkyKZ - comment - 1 Oct 2020

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.

avatar thednp
thednp - comment - 1 Oct 2020

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.

avatar thednp thednp - change - 1 Oct 2020
Title
Add namespace support for templates
[4.0] Add namespace support for templates
avatar thednp thednp - edited - 1 Oct 2020
avatar thednp thednp - change - 1 Oct 2020
Labels Added: ?
avatar thednp
thednp - comment - 2 Oct 2020

@SharkyKZ what is the resolution for this issue?

avatar SharkyKZ
SharkyKZ - comment - 2 Oct 2020

My opinion hasn't changed since the last comment.

avatar thednp
thednp - comment - 2 Oct 2020

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

avatar thednp
thednp - comment - 5 Oct 2020

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

@brianteeman, @PhilETaylor @eddieajau @wilsonge ?

avatar PhilETaylor
PhilETaylor - comment - 5 Oct 2020

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.

avatar thednp
thednp - comment - 5 Oct 2020

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?

avatar zero-24
zero-24 - comment - 5 Oct 2020

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?

avatar thednp
thednp - comment - 5 Oct 2020

@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.

avatar zero-24
zero-24 - comment - 5 Oct 2020

@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.

avatar thednp
thednp - comment - 5 Oct 2020

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

avatar SharkyKZ
SharkyKZ - comment - 5 Oct 2020

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.

avatar zero-24
zero-24 - comment - 5 Oct 2020

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?

avatar SharkyKZ
SharkyKZ - comment - 5 Oct 2020

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

avatar zero-24
zero-24 - comment - 5 Oct 2020

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?

avatar Fedik
Fedik - comment - 5 Oct 2020

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

// The namespace node
$namespaceNode = $xml->namespace;
// The namespace string
$namespace = (string) $namespaceNode;

or I am wrong?

avatar thednp
thednp - comment - 5 Oct 2020

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

avatar SharkyKZ
SharkyKZ - comment - 5 Oct 2020

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.

avatar wilsonge
wilsonge - comment - 11 Oct 2020

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

avatar dgrammatiko
dgrammatiko - comment - 11 Oct 2020

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)

avatar thednp
thednp - comment - 14 Oct 2020

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?

avatar thednp
thednp - comment - 5 Nov 2020

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

avatar SharkyKZ
SharkyKZ - comment - 5 Nov 2020

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.

avatar wilsonge
wilsonge - comment - 5 Nov 2020

OK then let's block copy in namespaced templates then

avatar thednp
thednp - comment - 5 Nov 2020

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

avatar dgrammatiko
dgrammatiko - comment - 5 Nov 2020

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)

avatar wilsonge
wilsonge - comment - 31 Dec 2020

@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

avatar thednp
thednp - comment - 12 Jan 2021

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

avatar gostn
gostn - comment - 12 Jan 2021

pr have not the needed 2 successfully test.

avatar wilsonge
wilsonge - comment - 12 Jan 2021

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.

avatar thednp
thednp - comment - 12 Jan 2021

@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.

avatar thednp
thednp - comment - 9 Feb 2021

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.

avatar joomla-cms-bot joomla-cms-bot - change - 10 Feb 2021
Category Libraries Administration com_templates Libraries
avatar thednp
thednp - comment - 10 Feb 2021

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?

avatar richard67
richard67 - comment - 10 Feb 2021

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

avatar thednp
thednp - comment - 10 Feb 2021

@richard67 yes please

avatar richard67
richard67 - comment - 10 Feb 2021

@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.

avatar richard67
richard67 - comment - 10 Feb 2021

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

avatar thednp
thednp - comment - 10 Feb 2021

@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.

avatar thednp
thednp - comment - 11 Feb 2021

@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?

avatar thednp
thednp - comment - 13 Feb 2021

@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?

avatar richard67
richard67 - comment - 13 Feb 2021

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.

avatar richard67
richard67 - comment - 13 Feb 2021

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

avatar thednp
thednp - comment - 13 Feb 2021

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.

avatar richard67
richard67 - comment - 13 Feb 2021

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

avatar thednp
thednp - comment - 13 Feb 2021

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".

avatar dgrammatiko
dgrammatiko - comment - 13 Feb 2021

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

avatar thednp
thednp - comment - 13 Feb 2021

@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.

avatar dgrammatiko
dgrammatiko - comment - 13 Feb 2021

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

avatar thednp
thednp - comment - 13 Feb 2021

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.

avatar dgrammatiko
dgrammatiko - comment - 13 Feb 2021

@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

avatar thednp
thednp - comment - 13 Feb 2021

@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

avatar Fedik
Fedik - comment - 13 Feb 2021

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.

avatar thednp thednp - change - 13 Feb 2021
The description was changed
avatar thednp thednp - edited - 13 Feb 2021
avatar richard67
richard67 - comment - 13 Feb 2021

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.

avatar dgrammatiko
dgrammatiko - comment - 13 Feb 2021

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

avatar richard67
richard67 - comment - 13 Feb 2021

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?

avatar Fedik
Fedik - comment - 13 Feb 2021

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 ;)

avatar dgrammatiko
dgrammatiko - comment - 13 Feb 2021

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)

avatar richard67
richard67 - comment - 13 Feb 2021

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.

avatar dgrammatiko
dgrammatiko - comment - 13 Feb 2021

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

avatar brianteeman
brianteeman - comment - 16 Feb 2021

Nothing to do with me I am afraid

avatar alikon
alikon - comment - 16 Feb 2021

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

avatar thednp
thednp - comment - 16 Feb 2021

I know @alikon , perhaps you can score one?

avatar Fedik Fedik - test_item - 20 Feb 2021 - Tested successfully
avatar Fedik
Fedik - comment - 20 Feb 2021

I have tested this item successfully on 1d98ab1

works good for me


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30816.

avatar dgrammatiko dgrammatiko - test_item - 20 Feb 2021 - Tested successfully
avatar dgrammatiko
dgrammatiko - comment - 20 Feb 2021

I have tested this item successfully on 1d98ab1


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30816.

avatar richard67 richard67 - change - 20 Feb 2021
Status Pending Ready to Commit
avatar richard67
richard67 - comment - 20 Feb 2021

RTC


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30816.

avatar laoneo
laoneo - comment - 24 Feb 2021

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?

avatar Fedik
Fedik - comment - 24 Feb 2021

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.

avatar Fedik
Fedik - comment - 24 Feb 2021

@laoneo Site/Administrator is working:

Screenshot_2021-02-24_19-02-07

avatar laoneo
laoneo - comment - 24 Feb 2021

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

avatar dgrammatiko
dgrammatiko - comment - 24 Feb 2021

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

avatar thednp
thednp - comment - 24 Feb 2021

@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.

avatar Fedik
Fedik - comment - 24 Feb 2021

On components I guess the client is after the vendor

it the same,
image

avatar laoneo
laoneo - comment - 25 Feb 2021

@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.

avatar Fedik
Fedik - comment - 25 Feb 2021

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 😉

avatar dgrammatiko
dgrammatiko - comment - 25 Feb 2021

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

avatar Fedik
Fedik - comment - 25 Feb 2021

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.

avatar rdeutz
rdeutz - comment - 10 Mar 2021

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.

avatar thednp thednp - change - 10 Mar 2021
Title
[4.0] Add namespace support for templates
[4.1] Add namespace support for templates
avatar thednp thednp - edited - 10 Mar 2021
avatar thednp
thednp - comment - 10 Mar 2021

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.

avatar rdeutz
rdeutz - comment - 10 Mar 2021

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.

avatar thednp
thednp - comment - 10 Mar 2021

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

avatar richard67 richard67 - change - 12 May 2021
Build 4.0-dev 4.1-dev
avatar thednp
thednp - comment - 22 Sep 2021

Guys what's the status of this please?

avatar dgrammatiko
dgrammatiko - comment - 22 Sep 2021

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/)

avatar Fedik
Fedik - comment - 22 Sep 2021

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 ;)

avatar dgrammatiko
dgrammatiko - comment - 22 Sep 2021

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.

avatar richard67 richard67 - change - 1 Feb 2022
Title
[4.1] Add namespace support for templates
[4.2] Add namespace support for templates
avatar richard67 richard67 - edited - 1 Feb 2022
avatar richard67 richard67 - change - 1 Feb 2022
Status Ready to Commit Pending
avatar richard67
richard67 - comment - 1 Feb 2022

Back to pending due to merge conflicts after rebase.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30816.

avatar richard67
richard67 - comment - 1 Feb 2022

@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.

avatar dgrammatiko
dgrammatiko - comment - 1 Feb 2022

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

avatar thednp
thednp - comment - 1 Feb 2022

@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?

avatar dgrammatiko
dgrammatiko - comment - 1 Feb 2022

@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... 🤷‍♂️

avatar thednp
thednp - comment - 1 Feb 2022

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.

avatar laoneo
laoneo - comment - 1 Feb 2022

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

avatar dgrammatiko
dgrammatiko - comment - 1 Feb 2022

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:
Screenshot 2022-02-01 at 17 20 21

For a child template is like:
Screenshot 2022-02-01 at 17 20 30

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

avatar laoneo
laoneo - comment - 1 Feb 2022

I mean the whole copy template function
image

avatar dgrammatiko
dgrammatiko - comment - 1 Feb 2022

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)

avatar dgrammatiko
dgrammatiko - comment - 1 Feb 2022

@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.

avatar laoneo
laoneo - comment - 1 Feb 2022

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

avatar dgrammatiko
dgrammatiko - comment - 1 Feb 2022

Ok, where do we disagree?

avatar laoneo
laoneo - comment - 1 Feb 2022

@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.

avatar dgrammatiko
dgrammatiko - comment - 1 Feb 2022

No disagree, here I would go one step further.

Can you explain that step?

avatar laoneo
laoneo - comment - 25 Feb 2022

To load a template by service provider.

avatar dgrammatiko
dgrammatiko - comment - 25 Feb 2022

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...

avatar HLeithner
HLeithner - comment - 21 Oct 2022

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

avatar HLeithner HLeithner - close - 21 Oct 2022
avatar HLeithner HLeithner - change - 21 Oct 2022
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2022-10-21 12:58:11
Closed_By HLeithner
Labels Added: Conflicting Files ?
Removed: ?

Add a Comment

Login with GitHub to post a comment