Capacity / Wordpress Integration Theme

Wed Jul 19 10:25:35 UTC 2017

On Wed, Jul 19, 2017 at 5:24 AM, Olivier Churlaud <olivier at churlaud.com> wrote:
>
>
> Hi,

Hi Oliver & Ken,

>
> Just to say it again: having the whole kde.org still there might not be the solution.
>
> Having a brand new website would allow us to write again (and better) the important and relevant pages, and drop the others.
>
> I'm pretty sure that having capacity running and keeping all the pages will end in keeping the same content, which is not readable.

For some parts of the site this is quite true, yes.
However for others (like /announcements/) the vast majority of content
basically needs to stay intact as is.

>
> I'm 100% ready to help with writing some content (I don't have time for the technical part). But to me, the content seems as old as the capacity theme, so it has to change too. This doesn't have to be your (Ken's) job. It only needs to have the right infra.
>
> That's why I think a nice hidden-future.kde.org, only WordPress with the plug-ins (custom or not) allowing to deal with everything needed would allow us to move forward on content. (everything being: announcement, twitter/FB threads, application catalog, internationalization).
>
> TL;DR:
> If the new WordPress loads the old capacity pages, the kde website will still be crappy and read old..

>From what I understood of Ken's proposal, he was going to have
Capacity load Wordpress. This is something i'd caution against as it
probably means modifications to the core of Wordpress, which will be a
maintenance nightmare.

Because capacity has fairly small requirements from the individual
page side of things, i'd suggest doing things the other way around
instead.

Wordpress should boot first, and an integration plugin should
determine if this is a page we should try to serve from a Capacity
style directory. It can then setup a small shim environment and load
the page content then insert that inside a regular Wordpress theme
page. I'm hoping that would also allow us to utilise Wordpress
caching.

Only the actual *.php page parts of Capacity would be kept -
everything in websites/capacity would be retired by this approach as
the Wordpress module would replace it.

Thoughts?

>
> Cheers,
> Olivier

Cheers,
Ben

>
>>Date: Mon, 17 Jul 2017 17:50:20 -0400
>>From: Ken Vermette <vermette at gmail.com>
>>To: kde-www <kde-www at kde.org>
>>Subject: Capacity / Wordpress Integration Theme
>>Message-ID:
>>       <CAFtcy6x_Y4PqzowpCtc3CGdEfxGo9xMfhNwTny5NJR6GQoKdRw at mail.gmail.com>
>>Content-Type: text/plain; charset="utf-8"
>>
>>Hello everyone, this is an update on the website redesign stuff; I know
>>it's been a while since my last update, so I'll also be going over some
>>plan changes.
>>
>>Mainly I'd like to go over the plan for our existing Capacity pages,
>>and
>>how we can get Wordpress deployed before we have the 'complete
>>solution' to
>>replace absolutely everything we need it to handle.
>>
>>The original plan had a "scorched earth" policy where we would just
>>start
>>the new site fresh, along with some custom plugins we would have to
>>provide
>>the dynamic pages we need. This had several issues, and as attractive
>>as a
>>fresh start is... things like dead links, loss of important pages, and
>>the
>>dependency on a robust-and-mature replacement out-of-box has been
>>dragging
>>the next phase of site updates. It required the theme, a page builder,
>>language integration for that page builder, and various other plugins
>>for
>>things like the homepage, applications, and announcements.
>>
>>So for the past couple weeks I've been working on solutions going the
>>other
>>way - making Wordpress fit into our current system, and I've landed on
>>something which seems to be workable, with only has relatively minor
>>issues
>>compared to a full-out deployment.
>>
>>The new plan I'm working towards is a Capacity Wordpress theme and a
>>Wordpress Capacity plugin which joins the two together. The aim is to
>>have
>>capacity pages import Wordpress directly, then communicating with a
>>plugin,
>>Wordpress will take over page rendering using the theme layout,
>>settings,
>>navigation, etc. Using some voodoo hacks it essentially turns Capacity
>>into
>>Wordpress when this theme is enabled on a Capcity-driven page. The
>>content
>>rendering is still done via Capcacity function calls, so it breaks
>>nothing,
>>but everything beyond the content is Wordpress driven. That being said,
>>I'm
>>still working out the fineries, there's still some visual compatibility
>>issues, and it requires a patch to Capacity as well which I want to
>>smooth
>>out. If it sounds a bit confusing, here's the essential workflow:
>>
>>1. Capacity page is requested
>>2. Per-page Capacity config has the Wordpress installation linked (if
>>it's
>>not, nothing special happens)
>>3. Wordpress is loaded (if failure, Capacity works as usual)
>>4. Capacity verifies the Capacity compatibility plugin is active in
>>Wordpress (if disabled, Capacity works as usual)
>>5. Via the plugin, Wordpress captures the body content and runs it as
>>the
>>output to an otherwise standard Wordpress page
>>6. Everything is awesome.
>>
>>Eventually, we want to move pages out of Capacity and into Wordpress
>>completely at some point. This, too, is handled by the same
>>theme/plugin
>>combo in development. It might be patched in later as it's a massive
>>hack
>>right now, but using this plugin we'll be able to set redirects within
>>Wordpress as we complete replacement pages; capacity pages should
>>immediately and automatically redirect when superseded this way, and we
>>can
>>even SEO the pages is desired by flagging the redirect. As a special
>>bonus
>>to this, it means that as we replace pages it won't destroy the
>>existing
>>capacity content and the pages will be able to provide a "view legacy
>>content" link - probably by a nice clean URL flag instead of cordoned
>>off
>>folders. Expanding the steps above, step 4.5 is "check to see if
>>Wordpress
>>has content to use instead of the Capacity content, if so, use that".
>>Beyond that it keeps all current workflows intact, so for better or
>>worse
>>everyone gets to keep things as-is until we override the pages
>>directly,
>>and even then reversion will be a simple Wordpress toggle.
>>
>>All that said and done, right now my prototype is super hackish with
>>lots
>>of hardcoded paths, but I've proven to myself that the concept works.
>>
>>So, this is the "have our cake and eat it too" solution I have at this
>>point. The main downsides I can see with it at this point mostly
>>pertains
>>to a potential performance penalty; every page we switch will have both
>>Capacity and Wordpress run in it. I don't know how much juice our
>>servers
>>have or even if it will make a significant impact, but it means pages
>>using
>>the compatibility layer will have the performance cost of an uncached
>>wordpress page. That being said, this is being done as a per-page
>>toggleable 'switch', so when we're ready to begin deploying it we can
>>enable pages gradually and see if my performance concerns are
>>justified. If
>>performance is an issue we would need to look into a plugin-level
>>caching
>>solution, but I don't want to put the cart before the horse. The next
>>issue
>>is that navigation links and other wordpress-driven page content will
>>not
>>have il8n until a solution is devised, but page content and
>>theme-specific
>>content will use standard translation pot files as we use now which may
>>be
>>fine. Lastly, the live search functionality of the new design will not
>>have
>>a way of searching static pages, but it's a feature we don't have at
>>all
>>right now.
>>
>>
>>In term of deployment, the plan is fairly straightforward;
>>
>>1. When finished the integration utilities, we apply a patch which
>>enables
>>the compatibility layer on the Capacity level. Pages not using it won't
>>see
>>any impact.
>>2. We install Wordpress on kde.org, installing the Aether theme,
>>Capacity
>>integration Plugin, and homepage content plugin.
>>3. We convert the "Aether" pages we have now to use Capacity/Neverland
>>instead of AetherLibs.
>>4. Finally, we add a config line to each Capacity page setting the
>>Wordpress path. This will automatically convert the page to
>>Wordpress/Aether. Minor CSS tweaks and overrides may be required to
>>smooth
>>out content, but nothing too invasive. Everything will become
>>responsive.
>>
>>We can purposefully limit the rollout of wordpress-enabled pages if
>>desired; going from Capacity to Wordpress is going to have some
>>overhead,
>>and we can also limit the exposure of any issues which may need to be
>>ironed out. That being said I don't want a repeat of the initial
>>kde.org
>>redesign where I blindsided most of you, so I'll make sure we have a
>>proper
>>review of the changes before anything goes in so there isn't too much
>>'ironing out' needed.
>>
>>
>>Questions/Concerns?
>>
>> - Ken
>>-------------- next part --------------
>>An HTML attachment was scrubbed...
>>URL:
>><http://mail.kde.org/pipermail/kde-www/attachments/20170717/81818b19/attachment-0001.html>
>>
>>------------------------------
>>
>>Subject: Digest Footer
>>
>>_______________________________________________
>>kde-www mailing list
>>kde-www at kde.org
>>https://mail.kde.org/mailman/listinfo/kde-www
>>
>>
>>------------------------------
>>
>>End of kde-www Digest, Vol 172, Issue 6
>>***************************************
>
> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.