Capacity / Wordpress Integration Theme

[Ben Cooksley]

On Fri, Aug 18, 2017 at 5:45 AM, Ken Vermette <vermette at gmail.com> wrote:
> 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.

We'll be bumping a major version i'm afraid - from 3.0 -> 3.1.
Upgrading the forum is a non-trivial task, but if you'd like to work
on a theme for 3.1 that would certainly help.

Cheers,
Ben

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