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

Sorry, didn't see this section of the email...

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

The Wikis are on a different machine to kde.org itself i'm afraid.

Mind giving a bit of detail on how this JSON interface might work?

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

Oki.

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

We can make it so that Capacity sites have the appropriate include
path patched in yes.
For other software i'd be very wary of doing this though as we may end
up colliding with their own files but for Capacity it should be
totally fine.

We can patch in /wp-content fine, my concern here was more around the
various *.php files Wordpress tends to use at top level like
/wp-load.php, /wp-cron.php and the like.

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

Which site configuration file? I'm a bit lost on whether you're having
Capacity as the point of entry or Wordpress as the point of entry
here...

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

Yes, that can be done.

>  - Can KDE-specific plugins and our theme be git-accessible? We don't
> need all of wordpress on GIT, just the plugins and theme.

Yes, they can be - as repositories on git.kde.org :)

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

Cheers,
Ben