new 2.0 release

Hi,

Valentine's day is coming around the corner, and although I don't see myself as a flying cupid that shoots arrows everywhere, it is a special day to perhaps latch onto for the 2.0 release.

When I look in Github for the new 2.0 milestone, there are still some things to be verified, next to the discussion about the csstidy ticket. I estimate we might be ready to release a quick RC on monday, just to get the scope finalised and do some more non-regression tests. And after that release on tuesday, just in time for Valentine's Day - Because we love our users so much

Would that be a reasonable (if short) timeline?

I have limited time in the next few days for much of anything besides flowers. We are at a point to start the final testing and validation to move us on to the final release, though.

Of course, I forgot that valentine's day is more of less the black Friday for the flower business.

I will update the estimated date on the Github milestone.

Just to make sure, what are precisely the situations to test? Php 7.0 until php 8.0?

Upgrade from 1.4.4?

My list:

Required -

• New install completes successfully on PHP 7+
• Works without error at minimum version - PHP 7.x
• Works (may have warnings) on PHP 8.x. PHP 8.0 at a minimum
• Module updates work
• Module installs work
• Able to save preferences
• Editors work
• User registration, profile updates, group memberships work
• Upgrade works from previous versions (will need clear steps for PHP version change)
• Other prerequisites clearly defined for what needs to be changed in configuration and settings (using PDO, for example)

Recommended -

• How to determine if your modules are compatible - and a list of modules we've tested

Things we can't verify -

• If a site is using a custom block or custom tag with PHP content, we can't validate it will work on PHP 7+
• The same is true of extra plugins and preloads not distributed with the core

I was also thinking this release should address Google Analytics 4 over Universal Analytics - UA will stop working/reporting in 4 months (July 1).

This is kind of tricky, since we can't determine if a site has been converted, or if the new GA4 property tag has been created. Going through this for myself, the ID is different, so both the code and the ID need to be updated for a site.

I see you have implemented this as a plugin on this site, @fiammybe, and removed the section cf the core code that inserts the ga snippet into every page. Maybe we do that for both options - create preload plugins and have the administrator activate the one they use. Assume they are using UA (since that is what the core is injecting) and move that to preloads with the upgrade. Provide an alternative for GA4.

Perhaps we also include a warning in the admin panel for the upcoming deactivation of UA and instructions on how to switch their ImpressCMS site once they have made the switch with Google.

I agree with the Google UA towards Google Analytics 4 migration need. In the current stage, we can easily work with preloads. The issue should be discussed further though.

Currently working through some of the PHP7+ errors and requirements and removing some things that aren't used, at least in a new install (msyql support during install, for example). I've been testing with PHP7.0 to start with.

Just navigating through the administration panel, the version checker does not work on PHP7.0. The version of SimplePie (1.8) now in this release requires PHP7.2. SimplePie 1.7 will run on PHP7.0 and will also run on PHP8

Some additional findings that are not add-in library specific: sorting tables by clicking on the header link in a column is not working for custom tags, ratings, symlinks (pages), block positions, blocks, mimetypes, autotasks, and userranks. I verified these are working in 1.4.4. Trying to track it down now. I'm suspecting something with the IPF table class or filtering in the admin panel. What's missing in all of the links is "fct=" and the object name.

Found the sorting issue - a global was no longer available and needed to be replaced with icms:: static object. Discovered it as I was testing with the Content module - the admin page for it would not load after installing.

It is true that I did some major cleaning up of supposedly no-longer used attributes and functions in the core. Normally tests should have shown regressions, but no manual test is faultless I'm afraid.

The missing global is strange, I didn't change anything concerning that, as far as I know the content module did work during my latest tests.

The global variable that was coming up empty was $impresscms (and sometime $icmsModule). I'm not sure where the disconnect occurred. It may have been assigned an old variable somewhere. Better to figure it out now.

the removal of the $icmsModule variable was part of the cleanups that were marked as 'to remove in 1.4' I remember. The fix for the modules should be to use icms::$module if I'm not mistaken.

There are quite a few more occurrences of $icmsModule throughout the core. In some cases, it is also being assigned, so it is a  valid use. Rather than go though all 240 instances, I'm focusing on the results I get with some key functions and modules.

As of this point, I have tested these modules with the upcoming New 2.0 release

• imBlogging - minor updates necessary. Already committed to my repo
• imTagging - minor updates necessary. Already committed to my repo
• Content - working, once core data types handing was addressed
• iForum - not working. Needs a bit of an overhaul to deal with $icmsModule changes
• Profile - not working. Needs a bit of an overhaul to deal with $icmsModule changes
• Simplywiki - 2.0.0 RC does work (I just need to finish up the release - it's been out for a long time)

Most of what remains is going to have to be done in the modules.

PHPMailer is going to need an update, which I've got staged locally and doing  a basic test before committing. I'll put that in another PR.

Here is the main pull request - https://github.com/ImpressCMS/impresscms/pull/1430 - and my working branch - https://github.com/skenow/impresscms/tree/1.5.x-PHP7-strict

I just installed Madfish's News module to test based on this thread and found another spot in the core to adjust. I've committed the fix and it's in my pull request.

There's still more before we're clear - need to adjust icms/ipf/About.php

In doing some more testing (updating PHPMailer to a PHP7/8-compliant version), I'm running into issues installing on https. Could someone else test and confirm?

I'll verify. Can you confirm that I need to checkout this version : https://github.com/ImpressCMS/impresscms/commit/79907e64fea77dc16ecf1cf49cfafba98b1c41d6 (the latest in the ImpressCMS 1.5 branch)

Yes, the latest in the 1.5.x branch is what I'm working with.

Odd, I tried on another server and it worked fine. Now to figure out what the differences between servers is so we can identify what is the issue.

Let me know what happens when you try.

Site with problems during install: PHP 7.3.25

Site without problems during install: PHP 7.4.16

I don't think that's the problem - the PHP error log shows a parse error. PHP Parse error:  syntax error, unexpected 'https' (T_STRING) in modules/system/admin/customtag/class/customtag.php(104) : eval()'d code on line 19

Why would that even be called during installation?