Capacity / Wordpress Integration Theme

Ben Cooksley bcooksley at kde.org
Sat Jul 29 21:02:01 UTC 2017


On Wed, Jul 26, 2017 at 5:21 PM, Ken Vermette <vermette at gmail.com> wrote:
>> > Hi,
>>
>> Hi Oliver & Ken,
>>
>
> Howdy!

Hi 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 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;

The main reason I was asking this is because I fully expect the
upgrade to PHP7 (if a newer version of PHP5 doesn't do it first) to
break parts of Capacity. I'm not sure to what degree this breakage
will be.

The current server that hosts all of the Capacity sites runs Ubuntu
14.04, and I fully expect to be upgrading that container sometime in
the next 6 months or so to the current LTS release, 16.04.

The code within individual Capacity pages shouldn't be affected much,
it'll be the Capacity core that breaks.

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

Okay. That's good to hear.

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

Cheers,
Ben


More information about the kde-www mailing list