Development roadmap
Given the absence of a formal roadmap for integrating CiviCRM with WordPress, I thought I'd open this issue as a focal point for discussion.
tl;dr:
I would like to integrate the following into the CiviCRM-WordPress plugin:
- many of the options currently in CiviCRM Admin Utilities
- new REST API routes to replace all
extern/*.phpscripts.
CiviCRM Admin Utilities
There are a couple of issues here that I'd like to address before proceeding.
The first is that CiviCRM Admin Utilities (CAU), when installed, applies its fixes and offers its modifications to all versions of CiviCRM, whereas the CiviCRM-WordPress plugin can (obviously) only apply fixes and offer modifications to the current version. This means, for example, that people need to upgrade CiviCRM to make use of new features in the CiviCRM-WordPress plugin.
Secondly, CAU can offer "hot-fixes" for issues as they arise because it is not tied in to the CiviCRM release cycle. This can be a benefit in certain circumstances - especially because it is already resident in the WordPress Plugin Directory and therefore site admins are notified of updates via the WordPress back end. Updating is as simple as, um, hitting "Update".
With that in mind, I do think that there are good reasons to migrate a substantial proportion of the functionality in CAU to the CiviCRM-WordPress plugin. I'll add comments below per option as and when I get a moment to do so.
CiviCRM REST API
Work has begun on a "CiviCRM WP REST API Wrapper" plugin which will replace calls to scripts that reside in civicrm/extern with routes that do not try and bypass WordPress itself. So far, there is:
- a wrapper for CiviCRM's REST API (i.e.
rest.php) although it does not yet return XML-formatted results, just JSON - a replacement for
url.phpwhich includes a filter for Mailings so thaturl.phpis never used - a replacement for
open.phpwhich also includes a filter for Mailings but does not (yet) return an image
The reason for this plugin is that those external scripts try to bootstrap WordPress from within CiviCRM even though this is not possible to do that reliably. In a WordPress context, therefore, CiviCRM needs to respect this one-way logic and adapt. The REST API wrapper will do that.
One bonus of routing all calls to CiviCRM via WordPress is that a whole heap of directory traversal code can be stripped out of CiviCRM since it is inherently fragile and often self-contradictory. An obvious example of this is the problem of symlinking the CiviCRM plugin directory which, sadly, almost never works as intended.
Another bonus is that calls to loadBootStrap() become obsolete and the method itself can just return TRUE since, after a certain version of CiviCRM, there will be no situations where CiviCRM needs to do so.
There are a number of other scripts in civicrm/extern which need to be audited - e.g. does anyone use cxn.php? and if so why? Hopefully people can contribute their understanding of these largely undocumented scripts in the comments below - and then REST routes can be created.
Proposal
What I would like to see, therefore, is WordPress-specific development to address WordPress-specific issues. I think this is necessary because some of the functionality cannot be handled by CiviCRM core alone since it may or may not be initialised.
So from my perspective, this means not cluttering "Administer --> System Settings --> CMS Database Integration" with loads of extra options with code held in CiviCRM core. It means using WordPress-native admin pages and WordPress-native functionality implemented via the CiviCRM-WordPress plugin. It could mean admins see something a bit like:
One sub-page could hold the options and settings mentioned above and another might be curated to point people to plugins and resources that are WordPress-specific and enhance the experience of CiviCRM as well as its functionality.
So then... thoughts?