I have tested this item ✅ successfully on ef22f70

I chose "Tested successfully" because it does the job, ie showing Deprecated Notices distributed all over admin.

PHP 8.1, and Error Reporting to Maximum, obviously.

Here is what I collected:

Deprecated: strtolower(): Passing null to parameter #1 ($string) of type string is deprecated in /administrator/components/com_config/src/Controller/DisplayController.php on line 53

Deprecated: Automatic conversion of false to array is deprecated in /libraries/src/Form/Field/RulesField.php on line 181

Deprecated: Function strftime() is deprecated in /libraries/src/Form/Field/CalendarField.php on line 277

Deprecated: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in /libraries/src/MVC/View/HtmlView.php on line 254

Deprecated: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in /libraries/src/Layout/BaseLayout.php on line 119

Deprecated: substr(): Passing null to parameter #1 ($string) of type string is deprecated in /administrator/components/com_fields/src/Model/GroupModel.php on line 323

Deprecated: DOMElement::setAttribute(): Passing null to parameter #2 ($value) of type string is deprecated in /administrator/components/com_fields/src/Plugin/FieldsPlugin.php
on line 197
on line 199
on line 200

I have tested this item ✅ successfully on b5d53be

@ghazal can yuo please re-test this

and if you can

• #36362
• #36360

thx

@alikon
I'll test this again as soon as @HLeithner requested changes are solved.
I have begun to test #36362 and #36360 via patchtester, not finished yet.
Right now, I got mainly deprecation notices around strftime(), but I guess this is going to be corrected.

I have tested this item ✅ successfully on 15a6683

@richard67 this PR has 2 tests - can it please be RTC now so that it can be merged quicker, to stop repeated issues being opened about it

@PhilETaylor After @alikon 's there have been made changes which were not just code style, that's why only one test is counted right now if you check in the issue tracker or here at the bottom in the CI checks.

@alikon Could you test again? Thanks in advance. I am at work now so I can't test anything myself.

ah ok missed that - some controversial changes here, but nothing that's going to break Joomla.

I have tested this item ✅ successfully on 15a6683

From a fresh install of 410 beta3.
BTW, I can apply this PR via patchtester only if I don't apply this one:

[4.0] PHP 8 Ensure that we have a valid date #36396

@PhilETaylor
Thank you for your list of PRs.

[4][com_finder] - php 8.1 serializable-deprecated with unit test #36482
[4.0 - PHP8.1] Remove call to deprecated strftime - with unit test #36469
[4.0] Fix PHP 8.1 deprecation - strtolower null param #36397
[4.0] PHP 8 Ensure that we have a valid date #36396
[4.0] PHP 8.1 deprecation notices libraries/src #36355
PHP 8.1 deprecation fixes #36306

From a fresh install of 410 beta3.

@ghazal Hmm, this PR is for the 4.0-dev branch and so not for 4.1. For lucky circumstance (no other changes on these files meanwhile between 4.0-dev and 4.1-dev) it might be that the PR worked for you. But in general it's not a good idea to test a pull request on a version based on a different branch (4.1-dev) than the target branch of that pull request (4.0-dev).

I am not sure now if I shall count your test and so set the PR to RTC.

Maybe you can test again on a 4.0.x (latest 4.0 nightly or latest 4.0.5 release? That would be great.

Or maybe @alikon can test again?

BTW, I can apply this PR via patchtester only if I don't apply this one:

[4.0] PHP 8 Ensure that we have a valid date #36396

That's expected because the other PR includes a change from this PR here, so both PRs touch the same file at the same place and so conflict with each other (which can be resolved later when one of the 2 PRs has been merged).

RTC

I have removed the Date.php changes in my PR #36396 and left the Unit Test only as the Date.php issue is fixed in the PR

I've pulled through some of the less controversial fixes into a direct commit (credit maintained) so we have most of these fixes into 4.0.6. Some of these changes just seem weird in places though (e.g. I'm not sure that JLanguage::hasKey with null should be treated as anything other than a InvalidArgumentException ?‍♂️ Let's see what's left if we merge in conflicts here and take it from there I think.

I have just fixed the merge conflicts so the checking can start.

Sorry to say but all this ?? '' within a function call is only a band aid it looks like we don't know the input and just ignore the fact that we didn't validated the input correctly.

Sorry to say I told you so... try cleaning up docblocks for a day and you will see the most Joomla methods dont know what data types they are actually handling!! Its a complete mess!

Yeah that's my fear... but doesn't mean we should continue todo so right?
We want type hinting for all function signatures for Joomla 5. (we will see if we are able to get them) but having a 4 line block at the beginning that can easily be deleted is better then having hard to find ?? '' within the code (without comment)

unfortunately Joomla is scrambling to meet the demands of 2022 when people are running PHP 8.1 (because Joomla System requirements only specify a LOWER PHP number and not an UPPER PHP number) and so these quick fixes are .. quicker... than a complete code review.

This kind of work should have been done during the PHP 8.1 RC stages... not, after PHP 8.1.1 stable was released.

Joomla, as ever, when it comes to pure PHP development is behind the curve. This is the root problem. We need more people focused on code, and less on features and pixels.

true, but doesn't mean that we should make it harder to see the problem in future refactoring.

Sorry folks. I don't have time and space in my life for this right now. Please do what you want with this PR, or just close it.