CiviCRM Community Forums (archive)

Hi - I'm a WordPress developer, fairly new to CiviCRM but starting to find my way around.

I've managed to use a shortcode to drop Event Info where I want it on one of my WP "event"-category posts.

However, when I press the Register Now button, the registration form  (wrapped in its <div id="crm-container"> ) gets inserted into the contents of my <div id="header"> in my theme's index.php file.

So, does anyone know what determines where the CiviCRM-generated code gets inserted in a WordPress post? The current location above the top navigation bar seems a bit arbitrary and breaks the page very thoroughly.

Using the shortcode option again for the registration form is not a solution: as soon as I press the Continue button to submit the form, I get the same problem - and I suspect that the Confirmation page, Thank you page and any others generated by Civi would all behave in a similar manner.

Any help greatly appreciated.

OK. Deactivated all plugins except Civi - no difference.

Happy to try any other suggestions 

Thanks

Bill

Bill - It might help to check out the public demo which is using short-codes to insert event and online contribution pages into the front-end site. For example, an event page post:
http://wordpress.demo.civicrm.org/?p=11

Admin 'edit post' for this event page:
http://wordpress.demo.civicrm.org/wp-admin/post.php?post=11&action=edit&message=1

Thanks Dave.  I'd had a good look at the demo site - and my shortcodes are working fine. But it's a bit harder to investigate what's going on with the subsequent links from the shortcode-embedded event. 

What I'd really like to know is where to find the code that is inserting the following template into the page: /civicrm/civicrm/templates/CRM/common/wordpress.tpl   Any clues?

If that doesn't help, you'll probably need to investigate what's happening more on your site - theme issue? try the default theme (2011). etc

Indeed. And I've discovered that Civi seems to be overwriting the contents of a <div> that gets inserted by one of my WP custom fields. If I remove the custom field, everything works fine.

So ... having hit a metaphorical brick wall, I've now found a loose brick and am scraping away at the mortar   

Once I get to the bottom of this, I'll post my findings here.  Thanks all!

OK - here's what's happening...

Civi sends its output to WordPress by adding a filter to the "the_content" hook (on top of the half-dozen or so that WP already uses and one of my own). This Civi filter - civicrm_wp_invoke( ) - throws away (I think) any existing WP content for the page and replaces it with a Civi form, or whatever.

Unfortunately, this means that the "the_content" filters cannot now be used to clean up the output from the various widgets I use to make the side columns CMS-editable. Which is what I've been doing.

The Civi coders had foreseen this problem and built a "single-use-only" feature into civicrm_wp_invoke( ). It does it's hijack operation just once to output the CiviStuff and then switches itself off - allowing the other filters hooked to "the_content" to do their thing on subsequent calls. But one of my widgets at the top of the page was getting in with the first call - and so was outputting the Civi content instead of the mini-menu it was supposed to be creating. And when the time came to output the main content, the single-use policy ensured there was nothing left to place there.

...I hope you're following all this...

So... all I have to do now (I think) is to find another way of cleaning up my widget output that doesn't involve applying the filters hooked to "the_content".

Interestingly, I've been getting exactly the same behaviour with the BBPress forum plugin - so presumably this uses the same technique to get its html onto the page. But I really don't have the time to go delving into another complex plugin.

Hope this helps someone else. Thanks again for the responses. Info on the WP filter "the_content" at http://codex.wordpress.org/Plugin_API/Filter_Reference/the_content

Bill 

PS: @Dave: On a WordPress install, the crucial file is located at plugins/civicrm/civicrm.php

Hi guys,

Just wanted to point out that I'm having what I think is the same issue here.

I've got a partner developer that I'm working with, and hopefully with his input I can figure it out, but I just wanted to describe my situation and see if there's any input from the developers out there to point us in the right direction.

• No matter where I insert the CiviCRM shortcode, the form is inserted at the top of Wordpress' the_content variable, which means I don't have very specific control of where the forms are placed within the site.
• You wouldn't have noticed this before because your sample contribute forms were only on test pages. But the donations page currently calls for three different forms all on the same page, which show based on the tab selected by the user.
• Because of the way the shortcode is hooked into Wordpress, I can't actually put all the forms required on to one page. But I have a few different contribute forms going, and need them all to load together..

The desire behaviour is as follows:
Where the shortcode is in the content, the form should appear. So that means a re-writing of how the CiviCRM's shortcode is processed by Wordpress. I can't quite figure out what lines from plugins/civicrm/civicrm.php are manipulating the_content variable causing the behaviour we see.
I can sort of see the code for parsing the shortcode, and handling its arguments, but where I get stuck is on line 732 of the above named file. I assume this is the function asking Civi for the contribute form.

That's pretty much where my coding knowledge leaves me. Ideas and pointers highly appreciated!

-Mikey

Mikey

To control where the shortcode output appears in relation to the rest of the post content, I've made a minor hack to civicrm.php. All I did was to implement the output buffering suggestion made in http://issues.civicrm.org/jira/browse/CRM-9928. 

// Last bit of function civicrm_wp_frontend() ...
// (somewhere around line 340)

if ( $shortcode ) {
  ob_start(); // start buffering
  civicrm_wp_invoke( ); // now, instead of echoing, shortcode output ends up in buffer
  $buffer_content = ob_get_clean(); // save the output and flush the buffer
  return $buffer_content;
} else {
  add_filter('the_content', 'civicrm_wp_invoke');
}

Works for me, but I haven't tested beyond my specific needs.

Bill

mikey:

let me know if this works for you, and if so i'll patch 4.2 with the below fix

thanx

lobo

I can confirm the fix suggested by @wingfingerbill works, thanks!

Mikey

That'll be the "single-use" feature...

The Civi coders had foreseen this problem and built a "single-use-only" feature into civicrm_wp_invoke( ). It does it's hijack operation just once to output the CiviStuff and then switches itself off - allowing the other filters hooked to "the_content" to do their thing on subsequent calls.

You could try commenting out the line $alreadyInvoked = true; (somewhere around line 205 in civicrm.php) - but don't be surprised if that unleashes other gremlins.

Bill