Long Term / KDE.org Design Update

[Ingo Malchow]

Am Donnerstag, 26. März 2015, 19:25:34 schrieb Ken Vermette:
> It is, but as far as I've seen it can only be used for other sites using
> capacity; I'm mostly hoping for a client-side CMS-agnostic solution which
> could run regardless of what is happening server-side. That way we could
> keep components across sites like Planet, .org, forums, wikis, etc etc -
> and provide updates without having to mess with any of em'... This mostly
> applies to headers/footers, but we'd probably get other utilities.
> 
> I'd like the limit of the interaction required by whatever is using the
> API; keep things out of the server-side so we don't need to worry about
> individual CMSs. Ideally, something handled on the template level that
> doesn't require maintaining extra plugins or extensions.

This is also partly already done. E.g. the "KDE Links" on the footer bar on 
the forum (or other sites using neverland) are displayed by a small js script 
that gets loaded via the current cdn setup. The sites that want to use it just 
need to load the script. Those that use neverland should already load it per 
default.
So yeah, something work was already started on. As such, +1 :P

> 
> On Thu, Mar 26, 2015 at 7:07 PM, Albert Astals Cid <aacid at kde.org> wrote:
> > El Dijous, 26 de març de 2015, a les 18:50:57, Ken Vermette va escriure:
> > > > The CDN subdomain is hosted on a completely separate system to most of
> > > > the others.
> > > > It shares server space with download.kde.org and files.kde.org, and
> > > > runs behind Incapsula which provides caching.
> > > > 
> > > > You wouldn't be able to do much in the way of dynamic content there as
> > > > a result, as accessing the various databases would be impossible at
> > > > the moment.
> > > > (Out of interest, what are you trying to achieve?)
> > > 
> > > Mainly, one of the things I'd like to do is centralise the javascript
> > > and
> > > serve out a general-purpose JSON feed/API from a single subdomain ("
> > > wapi.kde.org", for example); common content which would be digested by
> > 
> > all
> > 
> > > websites and centrally maintained. The goal being to shift complexity
> > 
> > away
> > 
> > > from individual systems wherever possible. Then, at most, indivdiual
> > > websites would only need to provide configuration options.
> > 
> > Isn't that what capacity is doing already?
> > 
> > Cheers,
> > 
> >   Albert
> > 
> > _______________________________________________
> > kde-www mailing list
> > kde-www at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-www

-- 
Ingo Malchow
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-www/attachments/20150327/3e815ca8/attachment-0001.sig>