@test Works as expected. Before the patch, no override availab. After applying patch I can create an override.

@Devportobello i have just send you a very smal CS PR please review and merge so we can move it forward here.

I will try to test if you get the PR merged Thanks!

Has anyone tested this with a custom calendar as the one for Persian (fa-IR)?

@infograf768 I have not but the PR keeps the current code as is. Just adds the ability to create an override if you want to. I would be happy to test with a custom calendar if you can tell me where to find it and how to use it.

Although we still have some errors with Persian Calendar, because it was not updated to fully cope with the absence of mootools, we can still test by just installing Persian from install languages and edit an article to see the calendar field in Publishing Tab (second tab from right after setting admin language to Persian).
url: administrator/index.php?option=com_content

I also looked in frontend
I tested and it looks like it is fine. :)

RTC'ing as we have now 2 good tests Thanks!

note: here still need to review the layout file location

Personally I disagree with this. Anything in JHtml should already be overridable by the method used in this plugin: https://github.com/mbabker/bs3-demo/blob/master/plg_system_bootstrap3/bootstrap3.php

@wilsonge You mean to use plugins for overrides instead of JLayouts?

You can do that in the template as well - people like joostrap do. Just the risk is if it's not in a plugin is that people running early plugin events can include the wrong thing

The good thing about the plugin approach is that it's simple to share and reuse. Someone could just do Bootstrap3 plugin, put it on JED and everyone who uses a BS3 template could install it. It even can be updated using the Joomla Updater.
Not sure what is easier for template designers and users. Both have pros and negs.

With
JPluginHelper::getLayoutPath(...);
it should be possible to "build a bridge" between plugin(s) and "normal" template overrides

Dont understand why using plugin is better than layout, adding ability to modify the html markup of calendar is the goal of this PR.

It's a funny thing in JHtml. As it has its own override system, if you add JLayout into it, you get to a point where you have to figure out what you can override from where. Going the plugin route and a custom method replacing the core calendar behavior, you have more control over the entire method (from what calendar to use to its markup).

For the calendar it may be feasible to use JLayout. But if you look at the mess for tabs (https://github.com/joomla/joomla-cms/tree/staging/layouts/libraries/cms/html/bootstrap) the plugin approach looks much nicer and more flexible.

The only issue I see with needing a plugin is that frontenders are not coders. Replacing a PHP file isn't a problem but coding a plugin is something different for them.

Agree, the JLayouts is sometimes taken a little too far so we end up with too many files.

Setting it to Needs Review to have the PLT decide whether or not we go ahead with this.

If this is done this PR will need to be altered to be dealt with in the same way as the layouts for the media, versioning, radio and checkbox form fields

@Devportobello Thank you for your contribution we have decided not to include this PR as the current system already allows to override the calendar.