This could turn into a whole lot of different scenarios and options to handle through the core admin UI. Or, we can add documentation on how to add preloads that each admin would need to customize before deploying on their sites. Even now, I think of a preload generator that would allow an admin to paste in the code snippet from the other provider, select where it loads, and be able to manage it that way. That's for a later release.
For immediate consideration is what do we put into the new 2.0 release? My first reaction is to keep it simple - provide a GA4 preload template that admins can customize with their tag and include on their sites. The UA portion would remain and not interact with the GA4 plugin. Admins would need to determine the impact of having both active on a site. We deprecate the UA code with this release and move towards a more easily customized solution, removing the UA portions in a later release this year.
Universal Analytics will be deactivated in a few months. If your site uses it, you will have received already quite a few reminders about moving to Google Analytics 4. But keep in mind that the data cannot be transferred.
Sunsetting a product is always a risk to retain users, as at that moment you force them to think about their needs, and perhaps they arrive at the conclusion that their needs are better met elsewhere.
ImpressCMS has been solely supporting UA in the past (we even come from the predecessor, but that's a long time ago). Perhaps in the future we should look into opening up this interface and making it possible to easily add new analytics products, and to have multiple analytics options simultaneously active.
But for now, let's make it so that users are supported in migration from UA to GA4
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.
Things we can't verify -
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?
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 hadn't considered all those points when going for the news module. At the time, Madfish was still actively developing his modules, and his modules were based on the last version of IPF, so it seemed like a given to integrate modules that were built on the most recent best practices.
That is a momentous occasion! Thank you for putting this into the spotlight.
With the new 2.0 coming around the corner and also some movement in our newly-minted ImpressTNG branch, that number of PRs is certainly going to rise even more!
Over the years, we have used different version control repositories, our current one being GitHub. A recent merge of a pull request has pushed us to 1,000 pull requests that have been merged into our core - https://github.com/ImpressCMS/impresscms/pulls
Thanks for all the efforts that have gone into bringing us this far!
I think it's OK that we have more than one option for a type of module, that's been part of our heritage and what fuels the OSS community. There have always been multiple options for various types of content - news, blogs, galleries, downloads, links, calendars. The same is true in other environments, too - WordPress, Drupal, XOOPS.
The choices are also available in other markets - Microsoft Office (Word, Excel, PowerPoint), or Google Apps (Docs, Sheets, Slides)? Or, LibreOffice? Zoom, Teams, or Google Meet?
For me, it is the least amount of resistance to move forward. News from InstantZero is much more mature, robust, and feature rich than any other news module available. It does things - and I use them - that no other similar module does. The news module we use here is based on IPF and needs another module to create and manage categories (a good thing, actually, from a site management perspective). So does imBlogging - but it uses a different category/tag module. SmartSection had even more features - allowing a preview of an article, but viewing the entire article required another level of authentication, if you chose to do that. I'm not going to wait until one module can do it all. I don't think one module should do it all.
We can't create and support all the variations webmasters will demand, nor should we have to. That is why the marketplace exists.
The key at this point - what do we do with the core, and how does that affect the marketplace? Once I know what to aim for in module compatibility, I know what to do with my sites and the modules they use.
Hi, we arrived at the situation that our new branch number (2.0) was being overtaken by the needs of the legacy version. That is a common pitfall with long-winding releases, quite common actually.
The solution is to not give your next version a number, simple as that That way, your version number cannot be taken by the legacy codebase.
I'm a sci-fi aficionado (sometimes described as 'geek') so I would propose "ImpressTNG" as designation for our next major version. ImpressCMS - The Next Generation (cue Star Trek The Next Generation theme song). What do you think? Other proposals certainly welcome. Let's see what we can come up with