Using the "alternative way"

echo JHtml::calendar(null, 'test', 'id-test', '%Y-%m-%d', 'class="blah" readonly="true"');

I get:
before:

Warning: Illegal string offset 'class' in .../libraries/cms/html/html.php on line 965
Warning: Illegal string offset 'class' in .../libraries/cms/html/html.php on line 966

and after:

Notice: Undefined variable: readonly in .../libraries/cms/html/html.php on line 1022
Notice: Undefined variable: disabled in .../libraries/cms/html/html.php on line 1022

No big deal

I would also opt for a type hint (even if this breaks b/c again...)

I don't see the point in this PR anyhow. Attribs has a docblock of array since 2011 - I don't really see the need to all this stuff just to keep compatibility with 1.5

Thanks @elkuku and @roland-d the notices shoud fixed now.

@wilsonge

Than we shoud do somthing that not allow using a string instend an array. e.g. with is_string and if this is true send a log message and remove/don't use it.

If php errors are being thrown when you're putting a string in that really should be enough of a hint you should be using the documented method :p

Like I don't think we need to log every change in the api since 1.5 - that would be crazy!!

@wilsonge so i shoud remove the JLog thing?

Well I mean your thing is still expecting attribs to be an array for the readonly and disabled stuff and allowing a string you're never going to be able to work out if that's the case. An array should have been used since 1.6/1.7 (2011 anyhow) and so I think we just should force people to pass in an array

@wilsonge Is it not considered a B/C break if we now force an array?

As for the JLog entry, I think it should be removed, this will create a huge log for users and nothing they can do about it.

We need to decide if we can force the array or just leave it as is.

It would be for Joomla 1.6 when the change was made. Since then it's been labelled as an array and it should be called as such. Just because a string happened to work still doesn't mean that it's correct. https://github.com/joomla/joomla-cms/blob/df0b2d024a324ec426ce7f0c27f034505056d44a/libraries/joomla/html/html.php#L662 This is the line in 2010 (so pre J1.6) - where you can see it should only be an array or null.

If it currently works with a string, why change it and risk a broken extension?

As for the log: The deprecation logging will only be written if the user enabled that option in the debug plugin. By default it's turned off.

I would probably add the deprecation message in case someone passes a string and remove that possibility with 4.0.

Except it hasn't worked with a string for 8 months. If someone hasn't fixed their extension by now they have a problem :P Meh whatever works for you guys tho

I'd say leave it as it is now and force the array in Joomla! 4.0.

Except it hasn't worked with a string for 8 months.

I haven't tested it. Just reading the conversation :)
If it currently doesn't work, and isn't meant to work anyway. What are we trying to fix?

That's my point :P I don't see the need for this

Except it hasn't worked with a string for 8 months.

hmm it has worked but only with a warning if you have error reporting on. (IIRC)

For me it is more a "issue" by the extentions developer. But i think we don't break anything if we handel it as proposed.

Actually I believe it does work, it only triggers some warnings, the style is still applied. So this change fixes those warnings.

It may not supposed to be working but since it does, we may as well get rid of those notices. Comes Joomla! 4, we can cast it to an array.

Or maybe we just accept arrays as well as strings, since now both of them are working without warnings/notices...
• The Joomla! Way ™ •
Just fix the doc block

Please look at
#3654

and let's decide what we do as we have already the issue in core with smartsearch

thanks @wilsonge it is fixed now

I don't see why we need to add a log message. If now it works with strings and arrays why? And if not are we going to add a log message for each function that is not used properly? I can understand that we avoid the warning and/or add the support for strings but why the log entry?

Also no being an array doesn't convert it into a string. If you still want to add a log entry you should change the message to only talk about the array requirement and avoid describing the type received just in case someone passes an object......

I would also suggest to cast (string) $attribs when using it and, as pointed by @elkuku, if the function is now going to support strings change the $attribs type to mixed in the doc block.

@phproberto I have remove the JLog.