There is no one to bite the proverbial bullet though and make and maintain a theme.
Take a look at processwire demo here
It’s a backend only cms, so the frontend would need to be implemented from scratch. It’s very powerfull but at the same time also easy to use (if you know PHP devs).
I used it in the past (moved from WordPress) and loved it. The community is also very nice and helpfull.
Here’s something I quickly put together https://i.imgur.com/1rwIQq4.png left is the backend, right the frontend.
This is the code to get and display the posts
$pages_ = $pages->find("template=blog_post,sort=-created");
foreach ($pages_ as $page_) {
$thumb = $page_->image->first() ? "<img src='{$page_->image->first()->size(100, 100)->url}' />" : "";
echo "<div class='card'><h3><a href='{$page_->url}'>{$page_->title}</a></h3>";
echo "<span>by {$page_->createdUser->name} on <a href='{$page_->parent->url}'>{$page_->parent->title}</a> ({$page_->httpUrl})</span><hr>";
echo "{$thumb}</div>";
}
I’m willing to work on this if you decided to go with processwire.
Here’s a talk about it
And a video from 2010 by the creator
1 Like
So the problem is not of “which solution” but of “where do we get the resources” – which is an endemic KDE problem. I feel that if we implement one of the other solutions, the problem will be the same: we will still have to adapt it, develop themes for it, maybe even implement currently non-existent features to make up for its shortcomings. All those things will also have to be maintained.
Would an off-the-shelf theme for WP not solve things quicker? There is metric s**t-ton of those. Maybe something that looks vaguely like what we want that can be tweaked over time and resource permitting?
Let’s get practical: What look are we thinking? Something like this, right?:
If so, time to start looking for the closest free theme and see if it can be adapted, instead of going round in circles.
Because this discussion has more or less run its course, don’t you agree? The people who blog regularly already know what they want, and you (Harald) have nailed the problem. Might as well get to solving it.
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.
1 Like
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.
1 Like
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.
Though from experience it’s probably not nearly as little work as one might imagine. Getting rid of dynamic javascripty bits and preserving paths so as to not break any links is quite the effort.
In hindsight I should probably have gone where the discussion took us…
Since software appears a contentious issue let’s do some quick polling among contributors. Frankly I thought this a no-brainer since kde.org publication already uses Hugo so I assumed dot, and by extension blogs, would work the same way. Serves me right for assuming too much.
Some things to keep in mind for the poll:
- this is about blogs.kde.org!
- only vote if you intend to use the software. IOW if you intend to run a KDE blog on blogs.kde.org
- we have no volunteers for a wordpress-based setup, so I have no idea when/if that would materialize
Here’s my totally comprehensive 
and totally unbiased pro-cons list
| Hugo | Wordpress | |
|---|---|---|
| Theme |  |
 |
| Volunteers to work on it | |
|
| Easy layout / WYSIWYG editing | |
|
| Established workflow for multi user setup on KDE infrastructure | |
|
Software to Use for blogs.kde.org
- Want Hugo (i.e. you will not use it if we pick Wordpress)
- Prefer Hugo but would use Wordpress
- Want Wordpress (i.e. you will not use it if we pick Hugo)
- Prefer Wordpress but would use Hugo
0
voters
1 Like
Soooo… Not dot.kde.org?
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).
[/quote]
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)