kde.org website upgrade
Closed, InvalidPublic

Description

Ken is currently redesigning the website.

Todo: order content

ochurlaud created this task.May 9 2016, 2:03 PM

@kvermette I didi this with the hope it can help us managing the thing.

Could you add some notes about

  • how far you are,
  • what still remains,
  • where the code can be found so that we can help you
  • ...

Ohoooo, sorry I was not timely at all in replying at all. I haven't actively used Phabricator yet, I'll ensure I get into the habit. But! I am here because things are moving, and now I need to start getting some things online;

I've prepared some software I'd like to load into cdn.kde.org. I had an (ancient) help desk request with Ben, but I let it rot (sorry Ben); now I'm starting to need to load it up. From our old emails it seems like it's an FTP/SSH affair, and that I should be putting what I have into a segregated folder.

I'm not sure of the exact process the sysadmins have for this stuff, but I guess I'm aiming for access (even if it's limited to that folder). Once I'm able to load some stuff, good fun things will start happening fairly quickly. I'll be updating it fairly regularly as we start moving things.

I also want to ask about how I should go about staging pages/sections under development for review... Especially since the sysadmins may want to closely inspect incoming software to ensure it won't cause problems. Do we have a staging area with Git access which people can test & preview? If not, would it be possible to have one created?

Onto people;

I've gotten a fellow who is working on things like de-jqueryizing some code I wrote, making it nice and neutral while we wait to work on pages. The same guy wants to start converting pages over to the new look, he's very interested in working on clean-up, and I guess he wants to focus on getting contributor documentation pages to a very high standard.

Once we merge our stuff together I'll see about maybe getting a repo up for our work, and I should also poke him to get an account here.

On progress;

The capacity theme is being worked on, and is almost there. Once I get some files into the CDN I can start the finishing touches. I believe you saw the e.V. page, so you know (roughly) what to expect, though the design has shifted slightly based on another eV page I was smitten with.

I'm midway on writing a modernised Capacity alternative under the working name "Capacitor". Pages will need to be ported to it, but it shouldn't be painful. In some ways it's designed to be a halfway-house system, with most of it's "advanced" functionality being optional.

The system includes a router, templates, views, controllers, and extensive autoloading. It does not need to use many of these features, and it provides everything necessary for "Capacity-like" sites out-of-box. There are some built-in compatibility tools for sites making the switch. They are "co-installable" and it should be possible for a site using Capacitor to call Capacity convenience functions while it's undergoing a port - though I haven't tested this yet.

I'm also poking PlanetKDE with a stick. I've had to stop since I want the CDN to be up before I continue. I've chopped the Javascript into a fraction of its weight, removed a huge number of external dependencies, all that good stuff

I know there have been complaints that PKDE isn't on the kde.org domain. Maybe if we want we can look at setting up this new version on planet.kde.org?

...

So, yeah! I guess the big thing right now is getting access to cdn.kde.org, and I'd like to have a 'live' staging area where I can push various pages for inspection.

ochurlaud added a comment.EditedJun 23 2016, 4:16 PM

@kvermette : Do you have a contributor account? If so you can do 2 things

  • Either create a new branch in the concerned repos and redirect people there,
  • or create personal temporary repos [ 1 ]

For everything else, I cannot help, I'm just happy to see you communicate about this, and to see it's on its way

[1] https://community.kde.org/Sysadmin/GitKdeOrgManual#Personal_scratch_repositories

I have a contributor account. I'll hold off on creating repos for now though, they aren't as important; it was more of a convenience thing for demonstrating redesigned pages/areas.

I imagine I need to get ahold of Ben about FTP access to cdn.kde.org. I recall reading that Trellis is being shut down in favor of phabricator... What would the best way to request access be? :/

@bcooksley See the previous message. Thx :)

@bcooksley See the previous message. Thx :)

Well, that works. XD

@kvermette We don't do FTP access to any of our systems. Access is by SFTP (SSH keys only) usually. If you have a developer account I can grab your SSH key from there.

I'll need to double check with @imalchow how we want to architect the changes to cdn.kde.org though with the recent changes to using CDN77 for things.

@kvermette We don't do FTP access to any of our systems. Access is by SFTP (SSH keys only) usually. If you have a developer account I can grab your SSH key from there.

I'll need to double check with @imalchow how we want to architect the changes to cdn.kde.org though with the recent changes to using CDN77 for things.

Sounds good. Take your time and figure out how you want things, I'll be ready whenever you are.

It depends a bit on how the new design is layed out.
I guess the old design(s) will stay as long as we haven't ported all systems. So we need to have a top level directory based on a name or whatever. I guess/hope the new design has a working name? In this case it is also unimportant how you structure your content, as long as each design has its own directory, e.g. cdn.kde.org/neverland/css/... You get the idea.

Right now there is only neverland on cdn, so there is no directory separation, but if you feel like it, you can go ahead with the above and move them into a named directory. we can move neverland with time, if necessary (or remove it completely then).

In any case, a repo is really preferred, simply due to the thousand eyes fact, and so we have an easy way for any contributor to push fixes, whenever someone from the core developers or sysadmins are _not_ around (happened before and will happen again). That also includes the js parts, css, images... well, whatever you have that qualifies as a design. Afterall, we not only want a new design, but also new contributors ;)

I imagine we'll probably have the old designs hanging around for the next decade unless someone decides to pay for a couple full-time developers to actually overhaul the whole thing... Some people are also still converting things to Neverland. So, yeah, lets put the new stuff in a directory as they'll be co-existing for the foreseeable future.

Let's call the directory "universal" as the components it has are designed to be used on all sites, including ones actively using Neverland... In terms of structure this would make the main import addresses...

cdn.kde.org/universal/js?include=header,footer,social
cdn.kde.org/universal/css?include=header,footer,social

... Which I'm satisfied with.

I think I already cleared this, but I'll just mention it again to be 100% sure; cdn.kde.org does allow PHP and .htaccess, correct? Those are the only two requirements I have on this thing.

For access I would actually *really* prefer a repo as you mentioned, I just thought for some reason it wasn't in the cards. So, yeah, if Git access can be a thing... Please, please pretty please with a cherry on top! :D

Oh, it does not allow PHP, no. For that we would need a different server. As of now cdn.kde.org is simply that, a content delivery network, no webserver. But i guess Ben can arrange something for this.
A repo is simply a sysadmin request away, though not sure where, these days, as trellis is dead. Ben can help there as well.

As for the full time developers, no need for us to pay for it. Actually, google will pay for it. We have a student in gsoc that currently writes/improves the neverland builder, which can build any cms theme from a static html design. Why should we write all those themes by hand... ;)

Why does this new stuff need PHP? It should just be Javascript / common HTML elements / CSS Stylesheets no?

Sysadmin requests should now be filed on Phabricator. Data such as common themes definitely needs to go in a Git repository on git.kde.org.

kvermette added a comment.EditedJun 29 2016, 5:54 PM

There's two main reasons;

The first is because the CSS/JS content uses a dependency resolver, so you pick what components you want and it will spit out the minimal compiled css/js files you need. As we add more tools to it we can also add dependencies as components evolve without needing to manually add the extra files to each site or duplicate code across several files, it makes it all very organised.

It also does some super-simple pre-processing... In the future I'll add caching when we start using it in high-traffic areas to avoid overhead. When we start caching I'll also enable a minifier.

The CDN also serves some JSON-based content/structure as well. Right now it's static, but in the future I'm certain it will be PHP-generated, even if it's "rawdog style" with a cron job periodically triggering file generation. For example the header and footers import JSON data; in the future I'd like things like the latest major Plasma/Frameworks/Apps release announcements to be auto-included in the site navigation.

Cronjob or static generators are fine - however we can't execute anything at request time when using a CDN - they're purely static file serving.

Won't most of our sites be using essentially the same header/footer/etc in any case?

kvermette closed this task as Invalid.Mar 12 2017, 7:53 AM

With the homepages done and focus on the Drupal theme, I'm breakign thsi task down into smaller parts. Hope I've done so correctly.