Capacity / Wordpress Integration Theme

[Ken Vermette]

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.html>