Drupal 7 has been in security only maintenance for quite some time. 10 months life left means now is time to get off it before we actually do end up with an unsupported platform, and the accompanying risks that come with that.
I understand that, but I do not understand why this required moving to a completely different platform. I understand that Drupal 8/9/10 has major changes from Drupal 7 and is not straightforward to migrate to, but there appears to be a drop-in replacement with the fork Backdrop CMS.
When it comes to websites, Hugo is extremely well established within the KDE Community at this stage, is easy to deploy and fits in well with our common website visual identity. It was therefore the most logical choice to go with platform wise - especially given the limited contributor person-power available.
"Especially given the limited contributor person-power available", a drop-in upgrade to Backdrop CMS which claims that "it will run on the same database as your current Drupal 7 project, so any customizations you've made to your Drupal 7 site will not be lost when you upgrade to Backdrop" would surely have been the path of least resistance. Was the existence of Backdrop CMS overlooked or why was it not considered?
The lack of commentary is a small oversight,
I strongly disagree. Commenting is an essential functionality of a blogging platform, so not even having considered that functionality is a major oversight. Also, the loss of all existing comments is a major data loss.
It should have been obvious from the upstart that a static blogging platform such as Hugo can by design not offer this functionality, and at the latest, it should have been noticed when migrating that there is no place to migrate all this existing data that must have been in the database right next to the posts that were migrated by the migration scripts. I do not understand why this was either completely missed or considered so unimportant that it was not even thought worth mentioning in the announcement.
however in my view that is best remedied through use of discuss.kde.org as mentioned above, rather than deploying something additional.
Unfortunately, discuss.kde.org
runs on a platform (Discourse) that did not work in any KDE browser (neither Falkon nor Konqueror) for 13 months and even now only (hopefully! I have not been able to test it yet) works with the latest major version of Falkon or Konqueror, released only 9 days ago, which will take months to make it into stable distributions. (There is a static fallback view, but it is read-only, unauthenticated-only, without search functionality, and extremely ugly.) This makes it essentially useless as a discussion platform. Moving all discussion to that broken platform is not an improvement.
On the other hand, Drupal 7 supported really any browser out there, and Backdrop CMS still comes close, they only dropped support for the Trident-based IE (which went EOL 3 years ago) in the latest major release this January. This is how things should work, and this ought to be a decision factor when picking web applications for KDE websites. There is also plenty of forum software that supports any browser, including the one the KDE forums used to run on before the switch to Discourse. This browser feature treadmill, with complete disregard to supported LTS branches such as QtWebEngine 5.15 LTS, needs to stop! (Sure, Hugo as a static platform is by itself not a problem in this regard, but it does not support commenting, so we end up forced to use Discourse, which is a problem.)
This switch was motivated by the fact that Drupal 7 is now reaching end of life and since Blogs.kde.org is the home of many individual blog for KDE hackers so it was important to keep it up to date and secure.
Drupal 7 is actually still supported for 10 more months.
Upgrading to Drupal 9 was ruled out because Drupal 8 significantly changed and the migration would have been very complex.
Was Backdrop CMS considered? According to the Wikipedia article, it is a more compatible fork of Drupal 7, and according to the Backdrop CMS developers, the upgrade should be a simple drop-in replacement, without loss of crucial functionality such as comments.
Unfortunately, the switch to a static blogging platform, Hugo, means that there is no longer a possibility to comment on blog posts. This is not mentioned in the announcement, so was that limitation even considered when the switch to Hugo was decided? And even worse, all the existing comments were not migrated and are simply gone.
blogs.kde.org
has in the past been a place for constructive discussions such as https://web.archive.org/web/20240228164658/https://blogs.kde.org/2023/08/06/lets-burn-planet-because-we-can/#comments – those are now gone (or relegated to web.archive.org
), and such discussions will also no longer be possible in the future.
Good old KDE SC? :-)
Why should I be working to help people port features to something I do not use (on the desktop, at least) (Wayland)? The whole idea that all X11 features must be either ported to Wayland or dropped is the problem, it is a requirement that just does not make sense.
(That said, I do not personally use this particular feature, so have little interest in making it work even on X11. I just see it as part of a worrying trend of feature removal.)
To achieve feature parity, instead of making Wayland better, we are making X11 worse.
The post states that keeping it would have required porting it to Wayland.
And that is exactly my point. We are losing X11 features just because they are too hard to port to Wayland.
That is not what the original post states.
Just keeping this working under X11 would have been a lot less work than trying to make it work on Wayland as well, so that would have set the "is it worth it?" bar much lower.
Quite sad to see a powerful X11 feature removed from Plasma just because it cannot easily be made to work on Wayland.
Same with Clip 3.0.2.
Kevin Kofler (b8df28c8) at 10 Dec 21:19
Fix https://bugs.kde.org/show_bug.cgi?id=478121 (Elisa mobile UI: playlist drawer cannot be closed anymore)
This is a cherry-pick of the bugfix (see !528) from release/23.08
to master
. We need this fix in master
or the regression will be back with the next feature release.
(Tested by me on 23.08.)
Kevin Kofler (b8df28c8) at 10 Dec 21:19
Make context drawer interactive on mobile (#478121)
Fix https://bugs.kde.org/show_bug.cgi?id=478121 (Elisa mobile UI: playlist drawer cannot be closed anymore)
This is a cherry-pick of the bugfix (see !528) from release/23.08
to master
. We need this fix in master
or the regression will be back with the next feature release.
(Tested by me on 23.08.)
Kevin Kofler (b8df28c8) at 10 Dec 05:45
Make context drawer interactive on mobile (#478121)
Kevin Kofler (2d73416c) at 10 Dec 05:40
Fix https://bugs.kde.org/show_bug.cgi?id=478121 (Elisa mobile UI: playlist drawer cannot be closed anymore)
Kevin Kofler (2d73416c) at 10 Dec 05:40
Make context drawer interactive on mobile (#478121)
Kevin Kofler (2d73416c) at 10 Dec 05:36
Make context drawer interactive on mobile (#478121)
... and 1 more commit
Well, we will want to merge or cherry-pick this to master too, or the regression will be back in the next feature release.