I have tested this item ✅ successfully on 69f9d61

I have tested this item ✅ successfully on 69f9d61

Works for modules.

Same issue appear for content start+finish publishing. Perhaps a second PR for content.xml?

RTC after two successful tests.

I guess for content it would be article.xml and related if they have same issue too

May I ask what is the use case of displaying the week numbers here?
Depending on the answer we could flip the default value for this to be true (e.g. display week numbers unless someone explicitly declare in the xml that this should not appear)

I've removed the RTC label here.
The reason is if dev's/users expect week numbers to appear by default then this approach here is wrong, we need to change it in the calendar layout and the script.

@dgt41 First of all it has been standard behavior to show week numbers. But in general there are loads of various uses where business, schools, employees use week numbers for anything varying from campaigns to leave/vacation, season closing weeks and so on. Think it is a much used parameter.

The old calendar had them, and so should the new one then.

As for flipping the defaults, I always find it a bit strange if I have to set an attribute "showFoo" to false to change the default behavior. The parameter should be "hideFoo" then. An attribute which isn't specified should always be threated as "false", not "true" imho.

However for B/C, we have to switch the default behavior as this PR does show a B/C issue with the new calendar. With J4 we should reconsider the behavior and probably add a "hideWeeknumber" attribute.

@Bakual I was referring to flipping the values here: https://github.com/joomla/joomla-cms/blob/staging/media/system/js/fields/calendar.js#L82
Not in the XML, that will be awkward indeed

Huh? Switching them there would be even more strange, or not? It would mean if the attribute isn't present or "false" that the numbers show?

@Bakual a report from one user doesn't justify (IMHO) reverting this.
Also displaying all possible info wherever possible leads to a very cluttered UI and impacts UX.

It was consistent before 3.7 for article 'Start publish', 'Finish publish' and 'Created'. All did show week numbers. In 3.7 only 'Created' show week numbers. Consistent would give better UX and doesn´t make the UI seem inconsistent in what is presented to the user.

a report from one user doesn't justify (IMHO) reverting this.

That's a strange argument. How many reports do you need? Fact is the old calendar had the weeknumbers enabled by default and the new one has them disabled by default with no way for the user to enable them.

Also displaying all possible info wherever possible leads to a very cluttered UI and impacts UX.

The problem with those setting is that they are basically useless at the XML level. It's not the extension developer who decides if showing the weeknumbers is helpful or not. That depends on the user. And since the user can't customise the calendar anywhere, it has to be enabled. Imho the attribute could be removed as it makes no sense in the XML.

with no way for the user to enable them.

2 ways to do it:

• layout override
• js override

Ok, the JLayout override would be realistic, the JS override would be stupid just to add the weeknumbers.

But it's still a valid B/C issue we should fix and imho the attribute still could be removed from the XML as it's useless there.

I am closing this now as I also think we shoulld be B/C

What I simply suggest is to implement weeknumbers per default.
in /libraries/cms/html/html.php
$weekNumbers = isset($attribs['weekNumbers']) ? $attribs['weekNumbers'] : true;

and in /libraries/joomla/form/fields/calendar.php
$this->weeknumbers = (string) $this->element['weeknumbers'] ? (string) $this->element['weeknumbers'] : 'true';

Therefore it would be a voluntary act to NOT display it for a 3rd party by adding false in their xmls or any user in the layout (/layouts/joomla/form/field/calendar.php)

See new PR #16117