Capacity / Wordpress Integration Theme

[Ken Vermette]

> > Hi,
>
> Hi Oliver & Ken,
>

Howdy!


> > 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 agree that giving Capacity any sort of lifeline is less than ideal,
but I've come to realize we won't be able to just start over cleanly,
not realistically.

The biggest issue is that, if we want a clean start, it means we need
to have everything ready for a single launch. I've been pushing
against the fact that it's not as clean as installing Wordpress and
having a few people re-type pages fro some time. For various reasons
we need a slew of plugins for things like announcements, application
entries, several dynamic pages, we need page builders, translation,
etc... All of this is burdened by the fact that it all needs to
inter-operate, so we don't even get 'freebies' like known Wordpress
translation plugins.

Additionally, even just the handful of pages I prepared for the
refresh seriously burned a number of people, and I don't care to
repeat that. Yes, I *want* to tear it all down, have it all new, it's
certainly the alluring route... But pacing the update is the
responsible way to go, and people need to start seeing tractable
progress.


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

There's a bit of an update here, because I've been working on the more
'final' version of CapacityPress and a few things have changed.

While CapacityPress never required modifications to the Wordpress
core, it did require a plugin, and had minor if statements in the
theme. At this point it no longer touches the theme *at all* and
currently doesn't need a plugin. I may need to re-add the plugin for
reasons I'll explain in a moment, but it's a dead-simple
straightforward layer using standard bog-standard Wordpress APIs and
integration points.

So at this point, I'm confident in saying I've solved maintenance
issues. You patch Capacity. You turn it on in the site.inc file or on
a per-file basis. It just works.


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


The main issue here is the fact that many Capacity pages are directly
referenced, and in some cases (like applications) are generated after
an htaccess rewrite. Either way, I wouldn't want Wordpress to load
first - it is much heavier, and when CapacityPress is enabled Capacity
doesn't actually do much work. I also don't really know a single clean
way we could have Wordpress load first, but, either way, this may not
be an issue;

One thing you mentioned was caching. I may, might, maybe, kinda sorta
possibly... Have this solved, too. I'll just be brunt and say I
seriously doubt we'll get htaccess-based static caching ("advanced
caching" as referred to in plugins). We will *more likely* get PHP
caching in what the caching plugins refer to as "simple mode".  In
terms of overhead, it means we still load capacity (though it will no
longer be doing work), and Wordpress will init up to the PHP cache
loader. If I put my money on an outcome, I'd guess that a cached
CapacityPress page might be about the same as an uncached Vanilla page
or be leaner.

One thing we will need to consider though is if we want to have a
"nocache" flag in Capacity for especially dynamic pages, or at least a
lowered discard time. Anyways, I'm still testing this, but getting
CapacityPress to 'just work' with Wordpress caching is a new priority.

On a side note; with caching and Capacity, if we decide to revert
Capacity to its native theming system (chihuahua for most pages) for
any reason, htaccess caching will mean we'd have to manually clear the
cache to revert the page. PHP 'simple mode' caching would 'just work'
though, as Capcity hits before Wordpress. So either way, I'd recommend
simple mode caching.