Commit 481990d4 authored by haystack's avatar haystack

remove branch-specific instructions

parent fdd3e294
...@@ -5,55 +5,7 @@ This is the development repository for the *CiviCRM* plugin for *WordPress*. Wha ...@@ -5,55 +5,7 @@ This is the development repository for the *CiviCRM* plugin for *WordPress*. Wha
[]( [](
### "hooks" Branch Instructions ### ### Contribute ###
This version of the plugin now invokes CiviCRM on the front-end before any template is reached. I have split the handling of Civi into the four contexts in which it may be called:
* In WordPress admin
* On the wpBasePage
* via AJAX/snippet/iCal etc
* via a shortcode
The plugin now invokes Civi on the admin side properly, so that Civi's resources are only added when the Civi admin page is loaded. Previously they were added on every admin page.
On the `wpBasePage`, the Civi content is rendered into a property, then returned later when called for by `the_content()`. I have added things like filtering 'wp_title' and the page title with the title of the Civi entity. This works nicely, but introduces a new issue, which is that I think the logic of displaying the Civi title in the Civi template is the reverse of what it should be... I don't want the Civi title to be rendered on wpBasePage, because I am now able to override the theme's page title. In shortcodes, by contrast, I *do* want the Civi entity's title, because, by default, it forms a part of the parent page and does not try to hijack it. Hijacking has become an option in the modal dialog. See below.
AJAX/snippet/iCal calls exit much earlier now, which seems appropriate. As a result, I've ditched the multi-purpose `wp_frontend()` method, which I think was causing confusion by trying to be, um, all things in all contexts. I realise that this still requires the `is_page_request()` method to distinguish between contexts - this still needs thinking through.
And lastly, shortcodes...
When there is a single shortcode to display, its markup is generated and stored, then returned when the shortcode is rendered in `the_content()`, regardless of whether it's an archive or singular page/post.
Multiple shortcodes are not handled particularly well as yet (there is dummy content that links to the singular page it is embedded in) but the architecture is there to enhance this. At present, Civi is only allowed to be invoked once - I assume this was by design? - and this would have to be changed if multiple shortcodes are to be rendered on the same page.
I have added an option in the CiviCRM button modal dialog which allows a single instance of a shortcode to "hijack" the containing page - it overwrites the HTML title, page title and page content with the relevant parts of the CiviCRM entity that the shortcode represents. To enable this, a change to CiviCRM core is required. You must replace `function setTitle()` in '/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/WordPress.php' with...
function setTitle($title, $pageTitle = NULL) {
if (!$pageTitle) {
$pageTitle = $title;
// always set global
global $civicrm_wp_title;
$civicrm_wp_title = $pageTitle;
$context = civi_wp()->civicrm_context_get();
switch ( $context ) {
case 'admin':
case 'shortcode':
$template = CRM_Core_Smarty::singleton();
$template->assign('pageTitle', $pageTitle);
The commit trail is a bit ragged since I was making such wholesale changes, but I think if you read through the code as it stands, it will make more sense than the current version of the plugin.
### Contribute ###
If you want to contribute to the development of this plugin, please bear the following in mind: If you want to contribute to the development of this plugin, please bear the following in mind:
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment