How best to resolve Wordpress theme / CiviCRM conflicts

Question

I need help where we cannot upgrade CiviCRM 5.12.4 to any higher version because of a theme conflict with a paid, premium theme, Benevolent Pro. Details are in CiviCRM 5.17.5 and WordPress 5.2.3 just won't work.

We have logged the problem with Benevolent support. Their initial response is "this is a CiviCRM error." In this case, I believe "error" is the wrong word, but rather there is some kind of conflict, because CiviCRM 5.17.5 works just fine with the stock Wordpress "2019" theme. With the stock "2019" theme, we have also removed any CiviCRM conflicts with any other plugins we use (there was one). Who is to say who is at fault in this case, and how do I diagnose? I'm including a screenshot showing javascript errors on one important contribution page for reference. My main question, though, is to whom do I register this conflict? It seems like discussions on this nice forum are not where I am going to find an answer. I am still pursuing with Benevolent support, but just looking for advice how we can ever upgrade Civi again. Btw, we quite love Benevolent Pro. As a paid, supported theme it is guaranteed to be stable as Wordpress evolution continues, something we had difficulty with a previously customized hard-coded theme that was continuing to paint us into a corner with either Wordpress or our plugin upgrades.

Thanks for any advice here! *Edit added ~midnight 10/11/2019 * Adding more details from a local xampp clone of our site. We have 2 instances, all Wordpress data identical and Civi data identical except one is at CiviCRM 5.12.4 and the broken one is at CiviCRM 5.18.2. In both cases, the URL in the address bar is http://{clone_site}.webdev/civicrm/?page=CiviCRM&q=civicrm/event/info&reset=1&id=168

In this screenshot for CiviCRM 5.12.4, note civicrm under Sources in the inspect panel shows http://sdbikecoalition.webdev/civicrm/?page=CiviCRM&q=civicrm%2Fajax%2Fl10n-js%2Fen_US&cid=&r=aMJXH and the event page (event id=168) displays correctly.

In this next screenshot for CiviCRM 5.18.2, note the civicrm under Sources in the inspect panel shows http://test.sdcbcdream.webdev/civicrm/?page=CiviCRM&q=civicrm/event/info&reset=1&id=168 and the event page (event id=168) does NOT display.

Note the difference in the Sources in the inspect panel is the Ajax injection when it works correctly. Makes no sense to me, but I'm not javascript fluent at all.

And finally, here is a screenshot of Event id=168 for CiviCRM 5.18.2 with the stock Wordpress 2019 theme. It displays correctly and note there are 2 entries under civicrm under Sources in the inspect panel, one with the event URL as in the address bar and the other with the Ajax injection.

Answer 1

Karl has already posted my solution to this issue, but for those who want to update their CiviCRM install with immediate effect, the patch can be found on the GitHub repo for the CiviCRM-WordPress plugin.

Answer 2

After inserting some debug code per recommendation at chat.civicrm.org, I discovered an even more focused repair is to just change a single line in civicrm_in_wordpress_set() within civicrm.php. Replace

$page = get_query_var( 'page' );

with

$page = $_GET['page'];

and all problems we have noted disappear. The get_query_var call involves calls to our theme (looking at the backtrace at that point) that evidently get in the way. Obviously a theme interaction, but how would I even notify Benevolent support of the conflict? It seems so simple to make this one change on the CiviCRM side, but I need to understand unintended consequences. Why was get_query_var added in the first place - it first appeared in Civi 5.13.0?

Answer 3

Here is a better answer provided by @haystack at chat.civicrm.org. Note that it works and looks to be something we want to add permanently into the CiviCRM Wordpress distribution. I might add that this knowledge and experience is way beyond what I knew previously about Wordpress under the hood and how themes interact. I learned a little along the way and am indebted to @haystack.

@nc3man I get why this change (using $_GET('page') directly) works for you, however the problem with this approach is that Clean URLs will no longer work (for those who have enabled them) if we access $_GET directly.

I have a different approach which I'd like you to try. It looks like Benevolent is making a sub-query via the benevolent_pro_customize_register_header_misc() function, so it may be that register_hooks_front_end() is being called before it actually should be. Could you amend the top of register_hooks_front_end() to read like this:

 /**
  * Register hooks for the front end.
  *
  * @since 5.6
  *
  * @param WP_Query $query The WP_Query instance (passed by reference).
  */
 public function register_hooks_front_end( $query ) {

   // Bail if $query is not the main loop.
   if ( ! $query->is_main_query() ) {
     return;
   }

   // Bail if filters are suppressed on this query.
   if ( true == $query->get( 'suppress_filters' ) ) {
     return;
   }

   // Prevent multiple calls
   static $alreadyRegistered = FALSE;
   if ( $alreadyRegistered ) {
     return;
   }
   $alreadyRegistered = TRUE;

FWIW, the new code is:

• the addition of $query as a parameter to the function
• the sanity-checking code before the line that reads // Prevent multiple calls. If you then re-check your problematic page, we can see if this helps.

Answer 4

This is a suggested answer, not complete and I don't know if it has any (many) unintended consequences. It does solve the issues with the screenshots shown in the question above for both the Join page and a stand-alone call to display a CiviCRM event.

1. The Join page shows NO javascript console errors
2. The Event pages now display correctly and contain the expected Ajax insertions when looking at civicrm under Sources in the inspection panel

The culprit was easy to locate, the top level function wp-content/plugins/civicrm/civicrm.php. In looking at the differences between civi 5.12.4 and 5.13.1 (5.13.x was when this conflict first occurred) I noticed differences on lines that were wordpress specific, even mentioning Ajax and an additional function to clean URLs'. See images below for these 2 code differences. There are others, mostly in the wordpress context, so I'm not sure which are most significant. I also diffed civicrm.php between 5.13.1 and the latest stable 5.18.2 and those differences look mostly to be to verify the correct PHP version. I know it's foolish just to replace civicrm.php all the time with the 5.12.4 version which is the solution that works here, but I hope someone who understands why those changes were made in the first place can help me resolve this. You'll get your bounty ;-)