Capacity / Wordpress Integration Theme

[Ben Cooksley]

On Sun, Jul 30, 2017 at 7:10 PM, Ken Vermette <vermette at gmail.com> wrote:
> I just checked my testing setup, I've been running a clone of kde.org
> on PHP 7 this entire time without breakage or logged errors. For all
> intents I'm on Ubuntu LTS (Specifically, what KDE Neon is using.)
> About the only thing I can think might break is if there's some really
> weird configuration voodoo, because otherwise everything seems to be
> running fine.

Wow. Nice to know Capacity works under PHP7.

>
> This brings me to Mediawiki and phpBB.
>
> If it seems good to everyone, my cursory research has found that I can
> do to the wiki and BB what I've been doing with Capacity, making them
> use the Wordpress theme. Some sources I read also offered the source
> code for getting the basic setup on the wiki.
>
> As a shim, linking Capacity to Wordpress is a no-brainer since it's a
> transitional thing. But I'd like to know if everyone would be
> comfortable with MediaWiki and PhpBB also getting the Wordpress
> integration treatment. Like Capacity, there's no hacking Wordpress
> itself. For these two systems it would also be a theme-level
> treatment, so it shouldn't be a maintenance burden. I think the
> benefits are pretty obvious; all major systems will be tightly
> integrated (template-wise), maintenance and upgrades are centralized,
> and everything will be kept in sync. Future design changes no longer
> depend on rolling out against several systems.

phpBB might be a bit more problematic here, as we need to do a major
update to that.
That is stuck waiting for the Identity overhaul though, as newer
versions of phpBB have support for OAuth authentication flows.

>From what I recall of others discussing it, Mediawiki themes are not
fun to write.

>
> The only real downside is that I'll be updating the theme specifically
> for multi-system usage, or creating a generic plugin to help with
> things like making this efficient. I've been brainstorming and it's
> quite doable, but it still means putting our eggs in one basket. If in
> the future someone decides to change the theme and does a poor job, it
> risks the wikis and BB boards. Also, if things are on other servers,
> it means installing Wordpress if they wish to use the integration,
> even if its hidden.
>
> In terms of performance, I'm working to minimize the work Wordpress
> needs to do to run the theme, which I believe will actually make it
> fairly palatable even for situations where we can't cache as much as
> we'd like.
>
> I'd be really, really for taking this route. Before I seriously start
> the work on this I need to ask; are the Wikis and BB boards on the
> same server as (potential) Wordpress installations? Are there other
> issues with centralizing themes to Wordpress?

My big question here, before we start talking about technical details
is how much control Wordpress has over the theming, considering for
phpBB at least I know the various sub-elements on the page are all
individual templates. How does this work?

I'm also not sure how much modification phpBB / Mediawiki would need
to support such integration? Code modifications have bitten us quite
hard with the Forum and have done so in the past with Bugzilla as
well.

Cheers,
Ben

>
>
> On Sat, Jul 29, 2017 at 5:12 PM, Albert Astals Cid <aacid at kde.org> wrote:
>> El diumenge, 30 de juliol de 2017, a les 9:02:01 CEST, Ben Cooksley va
>> escriure:
>>> 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.
>>
>> Given how simple capacity is, i doubt it should be really much hard to fix if
>> it breaks.
>>
>> Cheers,
>>   Albert