Capacity / Wordpress Integration Theme

[Ken Vermette]

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.

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.

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?


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