I feel incredibly misunderstood. I did not ask which solution, did I? I proposed a solution. Somewhere along the way that got redirected into a Wordpress vs. Hugo vs. * argument.
To address your point though: This isn’t a “where do we get the resources” problem. We have the people to work on a Hugo implementation - that’s what I meant with having web team buy-in. In fact, the Hugo theme is already there, you can see it on kde.org, planet.kde.org, etc. what needs doing for the dot (specifically) is porting the existing posts out of Drupal and into Markdown.
I think we all agree that the status quo stinks for everyone and anything would be better than nothing. Broadly, I think the proposal is awesome. The question is whether with this proposal, we can make life better for everyone, or only some people.
Our challenge here is that there are two different sets of needs and desires:
- Developers can write their content using a text editor, markdown, git, etc, and often prefer to do so.
- Non-developers (like the promo people) cannot, and must write their content using rich and user-friendly editing tools like WYSIWYG editors.
It seems pretty clear that to address both use cases, we either need two support two different UX paradigms, or we need to only support the more user-friendly WYSIWYG style paradigm and tell technical people to use that.
Or we can decide to only address one of those use cases and revisit the other one later.
I’d add that Non-developers (like the promo people) cannot, and must write their content using rich and user-friendly editing tools like WYSIWYG editors. + much more often need to make something fancier, like custom layouts, images, additional css etc. (but thankfully not that often for the Dot)
I figure it’s also about limited features. Markdown is limited, and you simply cannot offer professional level editing and promotional content without (a lot of) extensions either for the writing or for the editor. And there’s also real-time collaboration.
In Hugo that is done in writing by using shortcodes that take advantage of HTML, and we actually have quite a lot of those already (although I’ve felt the absence of certain features myself). It’s probably possible to achieve the same amount of features (or at least the same equivalent features) that Wordpress provides in Hugo, but it would take a lot of effort.
I’d say it’s worth making a list of features that Promo needs and have the Web team see if those are achievable with Hugo in a practical manner, otherwise Wordpress + maintaining a theme would probably be the most practical solution.
The few mentioned Promo requirements were already sufficient to debunk my WriteFreely suggestion completely.
If we choose a wordpress and a theme (that may or may not look coherent with the hugo sites) and Carl and sysadmins don’t have the energy to maintain that installation and theme, we’re going to run into lots of other problems, even if the editor is more user-friendly
From the sysadmin side we don’t have a problem with maintaining wordpress. We do that already anyway.
Sorry, @sitter . I got carried away and missed the point.
Can it not be made read only , and the articles archived so links don’t break? Nobody has to touch any of those articles once they are published. Porting them to a new platform seems a pointless exercise.
For me this sounds simple
Devs - can write using rich text format there is no barrier. And They can also use markdown etc.
Non devs - can only write in rich text editors etc
There is no problem from sysadmins to host any of the two.
So the common thing amongst both group is rich text editor. It seems to be the thing that everyone can use easily.
Indeed it could be. It was brought to me as requirement that it be migrated, and I didn’t really question it. I’ll try to find out why static archival isn’t an option.
If people want wordpress for blogs.kde.org as well it becomes a non-issue for both
Couple of things to note here with my Sysadmin hat on:
- Any change in platform for blogs.kde.org realistically requires consulting with those using it - although that looks just to be a couple of people
- Maintaining a Wordpress instance is fairly straight forward and trouble free (the Drupal developers could take a page out of their book here - Drupal is an absolute nightmare)
- Likewise, the infrastructure side of hosting Hugo is fairly trouble free.
- Content migration is pretty much a requirement for both sites, but is absolutely mandatory for the Dot and has to be a full fidelity migration (no making the content static and calling it done).
I’d therefore eliminate the second line from Harald’s comparison above.
With respect to theme, we can probably start with a Bootstrap base theme and point it at our CSS/JS and see how far that gets us?
Could you make it clearer what the second line from Harald’s comparison is? “Volunteers to work on it”?
KDE websites get a lot of[quote=“bcooksley, post:36, topic:5011”]
Content migration is pretty much a requirement for both sites, but is absolutely mandatory for the Dot and has to be a full fidelity migration (no making the content static and calling it done).
I did the work 2-3 years ago to migrate the dot to Hugo by spending two full week on it. I unfortunately lost the scripts to do that, but I suppose it would take me less time to redo it now. The biggest difficulty was keeping the same url as the Drupal website use various urls scheme depending on the article and how old it is.
It made me sad that we could already have a nice and new websites 2 years ago and that it again gets blocked with the same discussion.
I personally consider the fact that people outside of the core promo team can contribute to the website really important. We regularly get merge requests for our websites from new contributors fixing typos, improving the style and adding new content. Websites should be treated like any other KDE projects and be open to new contributors.
Also in term of KDE Eco, Hugo is quite a bit better in term of energy usage as we don’t need to execute a lot of PHP code and database query for each requests.
Correct. The actual setup and maintenance would be fairly straight forward as Sysadmin already looks after a series of Wordpress instances, so this is nothing new.
The only resource required is resource for migrating content, which to my knowledge (for blogs.kde.org anyway) doesn’t exist for Hugo either.
Thanks for that detail Carl - it’s good to know that Hugo is helping with us getting contributions in the website content space.
For the URLs issue, as long as we can redirect them to the new location I don’t think we should have any issue with changing the URL format. I imagine it is the path of least resistance for us to assemble a .htaccess file or other redirector (might be worth calling in a small bit of PHP possibly depending on the number of variations around) that redirects all of the old URLs to the new Hugo URLs rather than convince Hugo to put content in the exact same place that Hugo did?
(We have a mapping table within Drupal’s database at the moment that handles the very legacy SquishDot CMS URLs and converting them to Drupal node ids and the corresponding content pages - so we’d need to bring that across too)
In terms of resolving the issues the Promo team have with Hugo, it sounds like the bulk of the issues are in the content formatting space - so from the above we need to assemble a list of must haves and see if we can make that work within a rich text editor that works with Hugo (we’ve deployed Netlify before for some of our sites and from what I heard that worked well)
It’s actually much simpler for Hugo. I migrated the old kdevelop.org website (which used some version of Drupal I think) and set up redirects in each of the post files, pointing to the old URL. Hugo takes care of the rest I believe I had scripted some way to extract the URL from the database.
Poll closed with 7 people potentially using Hugo and 5 people potentially using Wordpress; with strong preference for Hugo. We’ll get cracking on a migration plan for blogs.
Just wanted to check in regarding the status of the reinvented blogs.kde.org. Has there been any progress on implementing this?