Capacity / Wordpress Integration Theme

[Ben Cooksley]

On Fri, Aug 4, 2017 at 2:07 AM, Ken Vermette <vermette at gmail.com> wrote:
>> 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.
>
> It more/less depends if the theming system has changed from whatever
> we're running now to whatever is current, and from my previous
> experience phpBB is generally decent at not breaking things. Either
> way, is there a schedule for the phpBB update, or is it just something
> on the radar? It might be a good idea to try to synchronize any look
> and feel updates with a major version bump.

It's more on the radar at the moment due to lack of time to look into it.
Once we've gotten Identity overhauled it'll probably be reasonably
near the top of the todo list though.

You may want to take a look at existing phpBB styles in case there is
one that is based on the Framework you used - in which case it'll
basically be a case of slotting our header/footer in and pointing it
to our CSS file so it gets our colours / backgrounds / etc.

The community over there is pretty good from what I recall and there
is likely lots to choose from in the already done styling department
so if you've started from a pre-existing framework chances are someone
has done the hard work already :)

>
>> From what I recall of others discussing it, Mediawiki themes are not
>> fun to write.
>
> I have heard this also, which is why I imagine you don't see a whole
> lot of variety there. I'm tempted to say "when I looked it didn't seem
> that bad" but at the same time Murphy's law will rear its ugly head if
> I stick tot hat statement. Luckily, we don't need to start from
> scratch; I've found a couple themes which seem to have similar basic
> designs while also being responsive, such as 'metrolook'. Neverland
> also holds up on a technical level. I also like the idea of simply
> basing off Neverland simply so the layout doesn't changed for
> experienced wiki users, they'll just get the header/footer update and
> fresh paint.

So Mediawiki would remain independent and unattached to Wordpress (ie.
have a dedicated theme)?

>
>> 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.
>
> In terms of modification, as long as I stick to the same principles as
> CapacityPress, Wordpress Integration should be limited to the theme
> level. I think, worst case, we will need a hardcoded config file
> instead of a pretty softcoded solution. The moment we have control of
> the header and footer in a PHP environment we have all the control we
> need to integrate Wordpress. The only thing it makes this hard on is
> for things like PlanetKDE which don't use PHP...

PlanetKDE gets lots of hits, so using PHP there is probably not a good idea :)
That server also doesn't have any Wordpress setups and is totally
untuned for database heavy workflows.

>
> On an aside, caching has turned out to be a sticking point. Before I
> started testing I had forgotten that caching solutions modify
> wp_settings, which we can't use as an integration point for various
> reasons. So it looks like we'll need to use the CapacityPress plugin I
> had mentioned to perform the caching for us, so I need to write a
> caching solution inside that.
>
> As one last update; in my test installation with CapacityPress running
> it will correctly display all release announcements, all applications
> and categories, and all text general pages. Additionally, all pages
> with translations (announcements, mainly) correctly display
> translations in content. Lastly, CapacityPress will locate CSS files
> to accompany pages when in integration mode, and will insert them via
> the Wordpress APIs, meaning Capcity pages which do need special
> attention are very easy to non-destructively style.
>
> I'm going to get the last couple minor integration points required on
> the Capacity-side squared away (e.g. it's not properly integrating
> Capacity sidebars into Wordpress sidebars) and then I'll be sending up
> the Capacity patches for review, I think this should be done in the
> next few days. The patches will be inert until we make the appropriate
> config update. After that I'll finish up the Wordpress plugin caching
> and I think we'll be at the point where we can install Wordpress,
> configure the homepage, and launch the next big site upgrade. Would
> anybody be willing to get a Wordpress installation running on KDE.org?
> We'd want it directly in /trunk/www/sites/www/, but without overriding
> the index.php and .htaccess files so we don't disrupt the site. This
> should let us use the wp-admin panel to begin installing the necessary
> plugins and get things like KIdentity accounts working on it.

Couple of things here from a Sysadmin point of view...

Mixing Wordpress itself into a SVN checkout will create a bit of a
nightmare on the server.
Could we locate the Wordpress install elsewhere and have Capacity
reference it from that location?

Also a more long term question: how do we intend to handle the
situation once Capacity pages have been replaced by Wordpress pages
for the most part? (when it's just announcements/ left for instance)

In terms of security, all CMS deployments we have are configured such
that they're unable to modify themselves, which precludes installing
plugins, themes and the like. Could we get a list of plugins you'd
like to use?

In terms of why we do this - it has protected us against exploits in
the past. I've found the remnants of attempted exploits following
Wordpress.org security announcements on our systems - suffice to say
they got nowhere because we have it tightly locked down (something I
was able to confirm against our logs)

Cheers,
Ben