PHP 8.1 adaptation

[frostmakk]

• Fixed errors and deprecate messages introduced by PHP 8.1
• Changed Joomla! out-of-date-version notification to treat 3.x & 4.x branches individually.
• Fixed Joomla! out-of-date-version notification when instance not found.
• Updated supported-environment-tables to reflect PHP 8.1 compatibility.
• Added .htaccess/web.config yes/no to 'Application Instance :: Configuration' under security.
• Moved number-of-tables from 'Performance' to 'Discovery'.
• Changed the color class in 'PHP Extensions :: Discovery' to match the one used in 'Apache Modules :: Discovery'.
• Fixed console warning in 'activate BS5 popovers, tooltips (on hover) and toasts'.

No changes to 'Forum Post Content' in this update, only screen presentation.

Don't merge this before we have checked that the next releases of Joomla!, due 07 December, are in fact compatible with PHP 8.1

[frostmakk]

Ref commit 163e859 The text-danger class was hard to read in night mode, so I made it a bit lighter. Any objections from different eye sights? Before: After:

[frostmakk]

Ref commit 27a21f4

I have removed these Apache modules from the required module array. Flagging these modules as missing are misleading people in the forum to believe that installing them will make their site work again. IMO these are nice to have modules, and not a requirement to host Joomla!. Some of them are probably superseded by better products anyway. Opposite points of view are welcome, since my knowledge of Apache is very limited.

[RussW]

Absolutely no problems with your updates/changes and especially your attention to detail, great work as always @frostmakk.

My only thoughts/observation might be that when showing the J3 version, it might be an idea to now also show a message with the J3 EOL date and that J4 is available, just to cover the bases and "suggest" that there is a limited support lifetime on J3 (even if there are further J3 releases for the moment)?

However, I am in two-minds as this might be straying from the original purpose of the FPA as a troubleshooting tool. Open to discussion and opinion...

As for removing the "Potential Missing Modules", again this swings both ways, personally I've not heard of any confusion regarding these recommendations, but that doesn't mean that it is not happening and does not ensure that these recommendations have any value for end-users. There are also new modules available that supercede mod_evasive & mod_security (such as ruid), so it may make more sense to remove these recommendations for ongoing maintenance purposes.

Thanks for your time and effort, much appreciated.

[sozzled]

However, I am in two-minds as this might be straying from the original purpose of the FPA as a troubleshooting tool. Open to discussion and opinion...

I tend to agree; there's a limit to how far one might push certain recommendations. There's nothing technically or morally wrong with using older versions of J! (although I wouldn't use anything older than the latest J! 3.10) and there are dozens of ways that the CMS developers can remind people about updating ... if the CMS developers really wanted to do that. From a troubleshooting perspective, it might be nice for the FPA tool to report on inadequate PHP quotas (e.g. Max. Upload Size and Max. POST Size) but we can leave that for the present.

In general, however, any recommendation, nudging in the right direction or whatever else may be included in the FPA tool, one needs to be a little careful that suggestions are always evidence-based and not motivated by external factors that are not under our control. Remembering that the original EOL targets for J! 1.5 and J! 2.5 were quite fluid and they were extended; the EOL deadline for J! 3.x could change between now and August 2023.

As I say, there's nothing technically wrong with old versions of J! and people will continue to use them for as long as they wish. Whether there are self-diagnosis aids—like the FPA—still around to help people troubleshoot their antique J! websites should not be our problem. As long as the source code used in the FPA can work happily with most versions of PHP then most people will be quite happy, I think.

Good work, @frostmakk for taking the lead running with PHP 8.1. I don't have a PHP 8.1 testing environment, however.

[frostmakk]

My thoughts behind splitting the latest-J-version notification was from a security perspective to show the latest available 3.x version to people who have chosen not to go with v4 yet for various reasons. I didn't want to be a v4 pusher while sitting on the fence my selves waiting for extensions to catch up. The plan was that when the day comes that v3.x goes EOL , I would update the script to only show the supported v4.x version.

We need to be thoughtful of what is presented in the Forum post output. I have seen several cases where what is meant as a suggestion or observation from the FPA are mistaken as the truth, the whole truth, and nothing but the truth, so help me God. It's nice to see that the FPA enjoy high credibility, but it's not perfect, and one can never underestimate the gullibility of people.

On the matter of Joomla! being PHP 8.1 "compatible". I can not see that that will be fully achieved in the next release, so I will probably have to make another update to the PR when verified. I have tested the 4.0.5 release candidate, and there are still lots to do to become E_ALL free. Some might claim that it is compatible, but that is only with production level error-reporting. If you want to debug something, and let the E_DEPRECATED errors seep through, it crashes. So what do You think? Do we stamp it as compatible under these circumstances?

[RussW]

More than happy to go forward with the versioning display plan, it is sound and more correct regarding the two current versions roadmap.

Again, more than happy with your thought process about being more cautious with regards to FPA suggestions and observations or recommendations, as you say people do tend take things more literally today without putting much thought behind it. So, let's go with removing the "Potential Missing Extensions" section to avoid confusion and reduce any contention in the forum.

PHP8.1 has introduced some (expected) deprecations which still need to be addresses in Joomla Core, so it's good to be ahead of that curve with FPA as 8.2 & 3 have further changes to the JIT process that are road-mapped for more deprecation of older 7.4 classes and functions.

[sozzled]

Very quickly, I tried to put together the file fpa-en.php from the PR. I had some problems trying to run it in PHP 8.0 (see screenshot below). I have not yet tried to use PHP 7.4 or PHP 8.1; it's early days yet but I thought I would let you know how I'm going with FPA within a Wampserver environment:

UPDATE: It may have been a temporary problem because I am able to run it again using both PHP 8.0 and 8.1. I'll post the generated reports on the forum soon. :)

[sozzled]

See https://forum.joomla.org/viewtopic.php?f=804&t=990341

[RussW]

I might be missing something or misunderstood the results here @sozzled but....

Like AWS Hybrid Services, why on earth are you running Apache Modules rather than CGI? (They should be hung, drawn, quartered and put in front of my mother to explain why they skipped school!)

session_cache appears to to be misconfigured (enabled but not setup) No database credentials (password missing, not a valid production environment) Configuration file with incorrect permissions (modeset 666)

PHP8 assumes some modicum of 21st Century server configuration, hence the apparent errors you are observing. Apache module mode is not compatible with PHP8 JIT and will only report more errors on PHP8.1, session_cache requires a location (configured within PHP)

Sorry mate, it looks like your test/dev environment needs a little modernising or reconfiguration.

[sozzled]

The point of the test was not to specifically draw attention to my test environment. The point of the test was to demonstrate that the FPA works; it appears to work. As for how Wampserver running on Win 8.1 Pro sorts things out, that's just something I'll work through at my own convenience (perhaps). I don't know a lot about configuring Wampserver so that it passes muster. The point is that it's a test environment (it's not a commercially-hosted webserver) and sits on a PC located downstairs under the house. I'll dig around at some time to work through what Apache add-ons I can incorporate into Wampserver but I can't afford to stray too far away from how my webhost has set things up on their Unix server environment. As far as practicable, I try to replicate (within Wampserver) what my webhost provider does; there's a limit, obviously, to how close I can get my test environment to mirror a real one. :laughing:

I also have to say that, at the time I ran the test with PHP 8.1, I hadn't properly configured the PHP environment by using more "meaningful" settings, e.g. Max. Upload Size, Max. POST Size and Memory Size (which I've since done). The point is that this environment is typical of a vanilla_flavoured, out-of-the-box Wampserver that many J! users will be familiar with.

When I encounter problems—as I'm sure I will in future—with J! x.y on PHP 8.x, I'll do the right thing: ask the question at the J! forum, post the FPA and deal with them as I'll need to deal with them. Thanks anyway for your concerns. :smile:

[frostmakk]

Got a comment in the Forum from Per Yngve Berg that "777 permissions should not be shown in red on a Windows server". It's so rare to get feedback on the FPA itselves that I would like to encourage this and implement it as an improvement. My first though was to have the permissions for configuration.php and the "elevated" permissions presented in black instead of red in the post output, when $isWINLOCAL == true. After implementing this, and while testing, I realised that we could probably exchange the entire permissions listing with a text like "Not Applicable. Windows localhost." and save a ton of characters. Any comments or opinions?

[sozzled]

I love that idea, @frostmakk. You wouldn't believe how many times people read the FPA report and then prattle on about all kinds of rubbish that has nothing to do with the issue for which the FPA report was posted in the first place. One of those issues relates the the peculiarities of the Windows OS that doesn't use Unix-like file permissions.

It may not even matter if the text "Not Applicable. Windows localhost." appears in relation to the configuration.php file permission but, for the present, I wouldn't necessarily change the 666 to something else ... although you can bet that someone will write "you shouldn't use 666 for that file; you should make it 444" (which of course is inapplicable in the Windows environment. Yep, for that file only, present 666 in black lettering or maybe leave it green, I dunno. The issue isn't actually with the way the FPA reports things; the issue is the way with which people interpret what they see.

[RussW]

I haven't look in to the routine yet to consider a plan of attack, just thinking out loud;

How about we automatically disable the "Elevated Permissions" if it's a Windows host as we can't accurately determine that status anyway (I'm assuming Windows users always get "Top 10 Elevated" warnings anyway at the moment)

And in line with @frostmakk suggestion, can I suggest that maybe we don't completely remove any "known folder" permissions checks functionality for Windows user, but instead we use is_readable (first) and then is_writable (if is_readable = true) and present that information back to Windows users? (Read = Yes / Write = Yes etc)

This way, we should at least catch "writeable/unwritable" folder errors which could be causing extension install problems (which may actually be more meaningful to Windows users than unix style modeset permissions anyway)

Just a little house-keeping, I feel that the permissions discussion and any following work should also be a seperate github issue and have it's own dev branch & PR after the implementation of this current PR.

[frostmakk]

Agreed. I'll put on my todo list a separate session regarding permissions, that also includes the screen presentation.

[frostmakk]

I think we are good to go as it is now. Please do a final test. If no objections I will release tomorrow.

[frostmakk]

Thanks. 1.6.4 released.