Hi
I wanted to share my plan for coming releases. This is just meant as a foundation - to cover what really needs to be done. If there are additional ideas, that would be great. Meaning: If someone wants to develop something for these releases, please just coordinate on Github or here and do so! :)
We need to make a new release soonish, a 2.4.1. Especially the serendipity_plugin_comments bug needs to be fixed in a release, but there are other needed fixes, as the report that in some specific installations PHP warnings do not get hidden all the time (which works in many other installations), the non-working Spartacus downloads of viewtopic.php?t=25672 and it seems like the importers are broken, viewtopic.php?t=25713.
That release can't be done now, as not all fixes are there yet, but it would be good not to wait too long.
Following this, there will be a need for a release covering PHP 8.1 and 8.2. More by chance 2.4.0 seems to be already compatible with PHP 8.1, apart from the strftime removal, https://github.com/s9y/Serendipity/issues/784, which produces only warnings so far. For both those versions, the core, themes and important plugins need to be tested again.
:!: PHP 8.0 as main version currently gives us a timeline: We have until Nov 2023 to release a new stable supporting at least PHP 8.1. :!:
Apart from PHP: There was a big smarty upgrade which we really should add to that release, as it is supposed to give proper PHP 8 support (maybe making some of our template workarounds unnecessary?). Other bundled libs should be updated as well.
Vague ideas to go beyond the minimum that are in my head and someone could pick up:
1. The fediverse thing got a big boost because of Twitters downfall. Adding parts of that world could be worth it now, like webmentions (despite my misgivings about their bad spec)
2. Adding a better WYSIWYG editor could be a worthwhile project, at the beginning as just an alternative. There are some nice projects out there with markdown support for example.
3. The importer bug highlights the need of unit tests for imports, which is quite a bit of legwork, but not all that complicated probably
4. I feel like there is a lot of value in our old themes. Some are seriously nice, others nice in a retro way, very little is junk. That is why I invested quite some time trying to make all of them not fail, but they deserve a second pass, making all of them work properly with serendipity (modernizing their output where needed while preserving their design ideas).
5. It would be time to revisit the caching layer. It is currently provided by voku/simple-cache, a project which seems abandoned. Also, I never got around to show the main advantage of such a modular layer, combining Serendipity with Redis as cache. To measure the effect and document how to do it would be great, with a new caching lib.
Short term release plan
Re: Short term release plan
Hello there, I needed a bit time, but anyway.
The first important thing would be to use milestones on Github to tag for which version it should be fixed (2.4.1 and 2.5.0). If we mark everything with milestones, we could always have an up-to-date release plan for everybody.
Here is my small which-list (I know Xmas is gone
)
2.4.1 (PHP 7/8)
- fix the "critical warnings" bug somehow which produces things like https://github.com/s9y/Serendipity/issues/798
2.5.0 (PHP 8+)
- fix strftime deprecations, switch to PHP8 (see https://en.wikipedia.org/wiki/PHP#Release_history)
- better rewrite the error handling ($serendipity['production'] = true/false/debug) with design patterns
- remove non-UTF8 translations
- reformat all code (e.g. https://github.com/PHP-CS-Fixer/PHP-CS-Fixer), remove "?>"
- jQuery 3.x
- HTTP2
3.0.0 (PHP 8+)
- would be great to put the plugins from core and additional into two separate folders. Otherwise it's hardly possible to upgrade with Git
- mass rename for plugin folders: e.g. serendipity_event_photoblog -> event/photoblog and scripts (include/functions_*) - it's a mess to find the right files, at least for me
The first important thing would be to use milestones on Github to tag for which version it should be fixed (2.4.1 and 2.5.0). If we mark everything with milestones, we could always have an up-to-date release plan for everybody.
Here is my small which-list (I know Xmas is gone
![Very Happy :D](./images/smilies/icon_biggrin.gif)
2.4.1 (PHP 7/8)
- fix the "critical warnings" bug somehow which produces things like https://github.com/s9y/Serendipity/issues/798
2.5.0 (PHP 8+)
- fix strftime deprecations, switch to PHP8 (see https://en.wikipedia.org/wiki/PHP#Release_history)
- better rewrite the error handling ($serendipity['production'] = true/false/debug) with design patterns
- remove non-UTF8 translations
- reformat all code (e.g. https://github.com/PHP-CS-Fixer/PHP-CS-Fixer), remove "?>"
- jQuery 3.x
- HTTP2
3.0.0 (PHP 8+)
- would be great to put the plugins from core and additional into two separate folders. Otherwise it's hardly possible to upgrade with Git
- mass rename for plugin folders: e.g. serendipity_event_photoblog -> event/photoblog and scripts (include/functions_*) - it's a mess to find the right files, at least for me
Re: Short term release plan
Hey
I think it's a good idea to update the milestones and create fitting issues again.
I don't know how to fix the critical warning issues. I currently can only imagine a timing error (like: error happens before our error handles is set), that some PHP server configurations block our re-configuration, or that a plugin undo our changes. Currently I can't even reproduce the issue, so this won't be fixed from my side.
I think it's a good idea to update the milestones and create fitting issues again.
I don't know how to fix the critical warning issues. I currently can only imagine a timing error (like: error happens before our error handles is set), that some PHP server configurations block our re-configuration, or that a plugin undo our changes. Currently I can't even reproduce the issue, so this won't be fixed from my side.
Re: Short term release plan
The relevat code is in https://github.com/s9y/Serendipity/blob ... c.php#L317 (replaces the error handle with s9y's "errorToExceptionHandler") and the function itself in https://github.com/s9y/Serendipity/blob ... c.php#L122
I can reproduce it if I update my page to the current master without setting $serendipity['production'] = true. Without this information the production level is determined by the version string, see https://github.com/s9y/Serendipity/blob ... nc.php#L57
I think it's not very difficult to fix, when simplifying - but I don't want to remove relevant parts.
I can reproduce it if I update my page to the current master without setting $serendipity['production'] = true. Without this information the production level is determined by the version string, see https://github.com/s9y/Serendipity/blob ... nc.php#L57
I think it's not very difficult to fix, when simplifying - but I don't want to remove relevant parts.
Re: Short term release plan
Wait, that might be a misunderstanding. It is supposed to be based on the version string. The bug is that despite the version string marking a stable, some installations show error messages anyway. I don't see how setting `$serendipity['production'] = true` manually could fix that? And I think it did not work for the reporters.
If you set your blog to the current master of course you get the warnings, as it is an alpha, you are supposed to get the warnings. We are supposed to fix them! :) Hiding them during the alpha phase would make that harder.
If you set your blog to the current master of course you get the warnings, as it is an alpha, you are supposed to get the warnings. We are supposed to fix them! :) Hiding them during the alpha phase would make that harder.
Re: Short term release plan
The problem is that all warnings are treated as error. That means every double language string definition has to be fixed - or we have to make ugly exceptions. Currently only `$serendipity['production'] = true` is working.
Re: Short term release plan
In 8.0 we indeed fixed all warnings in the core apart from doubled language constants, where we suppressed the errors in the language file loading function. But sure, in 8.1 and 8.2 there will be new warnings that would need to be addressed.
Re: Short term release plan
I made two bigger branches to fix PHP8.1/8.2 warnings. I can't fix all other found bugs like https://github.com/s9y/Serendipity/issues/800 at the same time.
I had to update Smarty to v4.3.0 (https://github.com/smarty-php/smarty/re ... tag/v4.3.0) in order to have PHP8.2 support. Without that the screen was full of warnings and critical errors. I included the package with composer, so I also had to rename some paths in the code.
I also included a strftime polyfill which seems to work great.
I made similar changes to additional plugins, but didn't increase the version number or update logs, nothing is finished yet.
There should be nothing that breaks the current code.
My question: Can we merge the improvements already made in already? At least it is a good starting point to fix warnings because it is no longer completely broken.
Here are the branches:
https://github.com/s9y/Serendipity/compare/php82_fixes
https://github.com/s9y/additional_plugi ... hp82_fixes
I had to update Smarty to v4.3.0 (https://github.com/smarty-php/smarty/re ... tag/v4.3.0) in order to have PHP8.2 support. Without that the screen was full of warnings and critical errors. I included the package with composer, so I also had to rename some paths in the code.
I also included a strftime polyfill which seems to work great.
I made similar changes to additional plugins, but didn't increase the version number or update logs, nothing is finished yet.
There should be nothing that breaks the current code.
My question: Can we merge the improvements already made in already? At least it is a good starting point to fix warnings because it is no longer completely broken.
Here are the branches:
https://github.com/s9y/Serendipity/compare/php82_fixes
https://github.com/s9y/additional_plugi ... hp82_fixes
Re: Short term release plan
Open a PR and let's invite feedback. I think we can merge it, apart maybe from the PHP 8.0 requirements I saw in the composer file (that would make the upgrade path harder), but that can be discussed in the PR. Everything else looked very clean and helpful.