Back-end software

After some back-and-fourth discussion between the WWW and myself is to use Drupal as the primary back-end for KDE.org. We deliberated between Drupal, Wordpress, rolling our own, and a few other projects. The conversations kept rolling around to Drupal, which is used for several large and professional services, and is more content-neutral than Wordpress, which has an obvious focus on blogging.

We did shoot down creating a new framework or coding the website ground-up; KDE has done this before with "Capacity" and the major drawback is the lack of updates and dedicated developers. With a CMS like Drupal, we only need to worry about our content and site structure - rolling out own plugins for custom content. Additionally, when Drupal gets upgrades, we get upgrades. We want to avoid the "Not Invented Here" mentality and use established, trusted, quality code whenever we can.

Database / File Requirements

We would like KDE.org++ to be data-driven, moving away from our current flat-file system; currently the KDE websites are a lot of flat-file entries which means a huge amount of effort to maintain them and keep them up to date. We'd like to have a well-defined permissions system in place to allow applications developers to manage their own projects, and for those developers to be able to delegate maintainers for their pages. We would like to integrate KIdentity into this system so the entire website can be managed with our native accounts.

We would also like to make KDE.org project-centric in the database; Plasma Desktop is a project, Juk is a project, Mobile is a project, Frameworks is a project. From there, features of KDE.org will simply expand on projects; each project can do its own release announcements, classification, news posts, info pages, etc. For things like home-page announcements, we simply toggle what projects will appear where. We know there are a few things (like forums and GIT tools) which cannot or should not be remade as plugins in this manner, but we can hopefully unify a huge portion of our current disparate systems into a central CMS.

Theme/Style Requirements

We want to move the general layout and design of the website into a more version-neutral aesthetic, much like a slightly more modernised version of the forum "Neverland" theme. We will move content and imagery from projects into the forefront. if pages receive any special styling, it will be done in a way that is dynamic, and not hardcoded. Generally, the idea here is to have the project date the page, and not the page date the project; in the future when a user is browsing a "Frameworks 6 Project" the website should not need like it was made for Frameworks 5.

When we do include elements which have version-indicative styling (such as custom check-boxes or icons) we should be able to make those changes on a network-wide level through central CSS documents. Generally speaking, things like in-line CSS will be made a heinous crime.

Finally, while we want to be modern, we want to avoid being "trendy" for the sake of being trendy, or include non-standard behaviours because the web is able to now. For example, while we may want to have some nice effects for elements just scrolled onto screen, we don't want to do things like take-over the scrolling functions or have things fly in from strange directions.

Lastly, just like Plasma is becoming mobile-friendly, the KDE.org website will also become both resolution independent and form-factor adaptable.

Feedback

If you have feedback on any of these decisions, or have suggestions for alternate plans, please do post them; none of this is chiselled in stone and if there are better options available we would be very interested in hearing them.

Hi,
this is very interesting. Can we mockup a version 0.0.1 of the website IA to get an understanding of the content requirements?

As per the requirements to me things that are important include:

- Put emphasis on how people can contribute developers/designers/all-the-rest
- Allow people to donate in multiple place and multiple ways (time/money/effort/skills, etc)
- Allow the website to create workflows for organisational issues (eg I have never got a thank you email for donating to KDE, other communities are more appreciative of members that at care enough to donate some money)
- Define a high level of content strategy and tone of voice so people can get a unified experience from announcements and press releases to project pages
- Create the above to user stories (so try to understand requirements from a user perspective) and prioritise

Thanks.

I'm curious, did you consider some of the more modern CMF/CMSes like ProcessWire? I understand Drupal has the benefit of a lot of ready-made stuff, community systems etc. Yet, customizing them (and theming in general) is not as flexible as in a system, where you are in total control over your markup, using an API.

Edit: I hope going with Drupal means going straight to Drupal 8. Its theming is significantly improved over 6 & 7, although still not completely freeform: https://www.drupal.org/node/2356951 They still enforce a single template engine, but at least it is an engine (Twig) that is used in lots of other projects as well.

A very important missing feature for the current web is localization.

The new web should detect the browser's preferred language and show the contents accordingly. It should be easy for translators to add and update translations using the web interface as in wikimedia or integrating the translations in http://i18n.kde.org

jmaspons wrote:The new web should detect the browser's preferred language and show the contents accordingly. It should be easy for translators to add and update translations using the web interface as in wikimedia or integrating the translations in http://i18n.kde.org

Plans for a translation web platform: https://community.kde.org/Akademy/2015/ ... n_and_i18n
My own post requesting evaluation of Mediawiki translate extension as translation platform.

beluga wrote:I'm curious, did you consider some of the more modern CMF/CMSes like ProcessWire? I understand Drupal has the benefit of a lot of ready-made stuff, community systems etc. Yet, customizing them (and theming in general) is not as flexible as in a system, where you are in total control over your markup, using an API.

Edit: I hope going with Drupal means going straight to Drupal 8. Its theming is significantly improved over 6 & 7, although still not completely freeform: https://www.drupal.org/node/2356951 They still enforce a single template engine, but at least it is an engine (Twig) that is used in lots of other projects as well.

I imagine we'll be writing the majority of our own modules, as we're a bit of a niche. I like that Processwire seems to use internationalisation which isn't far off from what is currently used. I don't see lots of OAuth2 support though. :/

But the CMS hasn't been cemented; there's still time to investigate.

Kver wrote:I imagine we'll be writing the majority of our own modules, as we're a bit of a niche. I like that Processwire seems to use internationalisation which isn't far off from what is currently used. I don't see lots of OAuth2 support though. :/

But the CMS hasn't been cemented; there's still time to investigate.

Oh, that is nice to hear
Today I learned that the theming of Drupal 8 is still complex, so the inclusion of Twig into the mix apparently did not magically turn everything into rainbows and ponies.

Is KDE Identity an OAuth2 service, then? (I tried searching for the info, but nothing turned up..)
To make things simple, a solution might be to use HybridAuth: http://hybridauth.sourceforge.net/apidoc.html

Hybrid_Auth class provide a simple way to authenticate users via OpenID and OAuth.

There is already a module for ProcessWire using HybridAuth. It might be used as proof-of-concept.

The thing that jumps at you when reading people's experiences with ProcessWire is that they really like how PW doesn't get in their way.
A couple of examples of "separation of concerns", showing how setting stuff up is a matter of taste & needs:
https://github.com/fixate/pw-mvc-boilerplate
https://github.com/jdart/Spex
From the docs: http://processwire.com/docs/tutorials/h ... ate-files/

People that have used WordPress's Advanced Custom Fields plugin or a "content construction kit" for some CMS (like Seblod/K2/ZOO for Joomla!) will get the idea of ProcessWire very quickly.
If there is a content type that doesn't fit the default "Everything is a page" philosophy, then one might create a custom db table for it and still be able to use the PW API.

Edit: adding a bit more info, as I noticed neverendingo's very valid requirement "the sysadmins are also able to handle the system while running".
There is a solution that is not finished and that is transitioning to a new developer:
https://processwire.com/talk/topic/2117 ... e-changes/
https://github.com/mindplay-dk/SystemMigrations

Somewhat related, there is also version control for content: https://processwire.com/talk/topic/6333 ... n-control/

KDE Identity is currently an LDAP service, but long term we do want to turn it into an OAuth2 service.

bcooksley wrote:KDE Identity is currently an LDAP service, but long term we do want to turn it into an OAuth2 service.

If we built the login modules for KDE.org + 1 in OAuth2, what turnaround time might we expect for the KDE Identity conversion?

Not sure at this stage unfortunately - it will depend on how long the build out will take for the new Identity site, converting the existing Identity information and adjusting some / all of our sites to use it.

I've been using KDE for a long time and am excited about the idea to improve the KDE.org web ecosystem. I'm hoping that the ideas I put forth here as initial points of discussion will be considered.

I think making a choice on a framework, language or platform should be decided after requirements have been defined. Rolling your own functionality and releasing the source allows the community to more easily assist in contributing to the continuance of the services provided on the kde.org domain space. Drupal as a development platform may be suitable for content-rich sites, but until there's a design in place for the following, I think platform and architecture should be shelved for discussion:

• Central Authentication/One Identity authority for KDE.org only; use of Drupal would require Drupal customization just to allow it to live in the same ecosystem.
• The list of services the KDE.org domain space wishes to offer with an audit on current nomenclature.
• Content Modernization
• I18n action plan.

I think updating the web ecosystem of KDE to include user services would also be prudent. Sometimes I feel that KDE has a web-identity crisis and that authority for information and user-driven content via services lacks cohesion. Unless you are intending to contribute to KDE you may be a KDE user who has never created a user account. Providing value added web services to long-time community supporters would be a strong argument for KDE moving forward. I would love to discuss these topics further and elaborate on these concepts.

(posted in the wrong topic, so trying here again)

Are there any updates on this? I was made aware that neon.kde.org.uk might be the playground for this. But it looks more or less like a finished production website.

neverendingo wrote:(posted in the wrong topic, so trying here again)

Are there any updates on this? I was made aware that neon.kde.org.uk might be the playground for this. But it looks more or less like a finished production website.

Sorry for the lack of responses on these forums, here's an infodump:

Yes! neon is the playground site for a set of modular components and general styling aids I've been working on. It's not 100% finished, but it's nearing production quality.

Currently the header and footer can arbitrarily be inserted into any page with only some basic boilerplate. You just add jQuery of some version (It's not reliant on advanced features), a CSS file, and a script file. You can specify what components you want in a manner identical to the Google Fonts API.

You can also specify language in a build that I have, though it's incomplete and I'm likely going to scrap my current implementation. Either way, it'll just accept the language in a "lang" variable. I'll want to consult with everyone over whether it should default to English if the site doesn't specify a language, if it should attempt to select a language based on the users' system language, or if autodetection should be specified in the lang option as something like "?lang=fr-ca,auto".

Include in Header, remove components as necessary:

Code: Select all

   <script src="//example.cdn.kde.org/jquery.js"></script><!-- Optional if jQuery is not on the current site -->
   <script src="//example.cdn.kde.org/js?include=header,subHeader,footer,layout,social&lang=fr-ca,auto"></script>
   <link href="//example.cdn.kde.org/css?include=header,subHeader,footer,layout,social&lang=fr-ca,auto" rel="stylesheet" type="text/css" />


The modular parts, as they are now, are bundled with 3 unique colour schemes: General, Developer, and Professional. General is the white theme seen on the neon website, Developer is a blue theme with tweaks for more readable content aimed at things like API pages, technical documentation, and developer-centric info pages. Professional is a dark theme aimed at high-end applications and features. General is the "most complete" theme, but Developer and Professional are catching up and will offer numerous tweaks geared towards their target audiences. For example "Developer" will offer more readable fonts and strip out unnecessary animation.

The modular parts should be hosted from a central CDN, so I'll probably pop onto the mailing list in the next few days to get some GIT info. In terms of the server-side software, it's just a very minimal PHP utility and doesn't require a larger CMS. Once it's on a real CDN I'll have HTML boilerplate samples I'll be putting in a guide on the wiki for actually inserting the content, and I'll make a blog post as well.

In terms of compatibility, these things should work almost anywhere, and I've put in a great deal of effort to ensure that you can just drop these into existing sites without breaking them. The API is entirely HTML-driven, so no PHP inclusions are required; even static HTML pages can use the parts. They're also built to pull their content from the CDN, so we can update links and media remotely. Pages can include their own links in the header and footer (as seen on the neon site, again), using plain old HTML.

Right now the modular parts include the universal header, a basic subheader for site-specific links, a footer, social links, and some page style helpers. Before I start looking to more formally include this stuff in our infrastructure I want to modify the page helpers to something more easily integrated into existing sites, flesh out the developer and professional styles, and see if I can slim down the boilerplate a little more.

Thanks for the updates, sounds good.

Note: Most likely this attempt tries to not be a theme on its own, but rather styling an existing theme. For this of course the theme code needs to stay as-is. (this is an assumption, i have no real idea what is done and how)

Due to latest circumstances some themes - like this one for phpbb - need to be rewritten to be compatible with an update to the core (and that is really needed). So the html structure is likely up for change.