Capacity / Wordpress Integration Theme

[Ken Vermette]

On Sat, Aug 5, 2017 at 3:57 AM, Ben Cooksley <bcooksley at kde.org> wrote:
> 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 :)

I think phpBB is pretty good about keeping the theming API compatible,
unless we're bumping a major version. It's been quite a while since
I've worked with it though. Either way, I think we can mostly just
keep Neverland, tweak the CSS a bit (mostly removing textures and
swapping colours, maybe checking responsiveness in places); beyond
that it's mostly gluing on the new header and footer in the right
places. Neverland on a technical level is pretty solid.


>>> 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)?

I'd still like to import the header and footer, but one thing I've
been considering is adding a simple JSON API for kde.org sites to sync
navigation. It was actually part of a much earlier plan, and I'm
circling back around to it for cases where Wordpress integration is
undesirable. If the wikis are on the same server, for now, I'd like to
piggyback off Capacitypress for the header/footer.

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

Yeah, Planet operates entirely on a cache so the software doesn't
matter as much, but at the same time I don't want to mess with
something that isn't broken. I was just bringing it up as an example
of something not as easy to integrate. Maybe one day I'll do something
for it, but not for a long, long time.

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

This all gave me pause for a bit... Had to re-think some of my plans.

So, if we install Wordpress elsewhere, can we configure the server (a
la how we have Capacity configured in the sites file) so other sites
can include Wordpress core? Capacitypress hinges on being able to
include some of the Wordpress loader files. At the same time it may
mess with asset paths, so we may need to configure that a bit as well.

I was thinking about it though, and the moment we can include
Wordpress in a similar manner to Capacity, it might actually be a real
boon. We get our "clean room" wordpress installation and it's a
relatively simple modification to a few files currently on kde.org to
make them passthoughs. Alternatively, and I'm not an expert on server
configuration, I'd like to know if you had thoughts on how we
configure things. The main thing I need is the ability to include
files in our Wordpress installation in Capacity. The paths are stored
in the site config file, so the paths can be what you need them to be.

For the security, I was hoping to run updates through the WP update
mechanism, but as long as our in-house plugins can be updated through
git, I have no problem with that. I was also working to split the
Aether Wordpress theme to a KDE.org-specific version, and a general
purpose version, so it kinda works out anyway.

 - Piwik (statistics)
 - Elementario (page builder, will eventually be replaced, but will
let promo people make nice pages via drag-and-drop)
 -- Or something similar like Live Composer, there's a few page
builders out there.
 - CapacityPress integrator plugin (will also provide cached headers
and footers to non-wordpress sites)
 - WP Super Cache
 - KDE Content Plugin (in-house, provides our dynamic homepage content
and a couple KDE-specific goodies)
 - The Aether Theme

... And I think that's it. Ideally if we can have Capacitypress,
Aether, and our general content plugin be connected to git repos that
will do us quite well. For plugins that we need, here's a
top-of-my-head list:


So, TLDR for what I'm asking for:
 - Can we configure the server so Wordpress PHP files can be included
similarly to how we include Capacity
 - Can KDE-specific plugins and our theme be git-accessible? We don't
need all of wordpress on GIT, just the plugins and theme.
 - Unless there's some server magic I don't know about which you can
educate me on. I'm a bit ignorant on what can be done.