2

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! enter image description 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. enter image description here

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. enter image description here

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. enter image description here

  • Just a word on my experience. I have 40+ years experience in scientific programming, in scientific/engineering languages from Fortran through C and C++ and am especially comfortable with all aspects of unix (linux for web developers). I can get around php code, but am no expert. I have virtually no experience with java and javascript. I also have a local xampp version of our website in a virtual linux machine on my laptop where I also have Phpstorm installed, so I can set breakpoints, look at code, etc. I just don't know where to begin with this issue. My guess this might be namespace failure. – Karl Rudnick Oct 4 at 16:51
  • Can you clarify what "/join" is? I'm thinking it's a wrapper page provided by the theme, maybe configured by you somewhere, that is trying to display your contribution page but is expecting JAVASCRIPT back but getting HTML. Is that how that theme works? – Demerit Oct 4 at 17:15
  • /join is a basic Wordpress page. It has a single image that you see at the top. The CiviCRM shortcode is simply the caption for that image. There are some other areas, for example an event page (not a contribution page) where the shortcode does not work. See test.sdcbcdream.org/civicrm/?page=CiviCRM&q=civicrm/event/… . So this is not just a CiviContribute issue. – Karl Rudnick Oct 4 at 21:13
  • 2
    Thanks. I agree it's not civicontribute, what I mean is something (maybe the shortcode? theme?) is making a call to the server expecting javascript in return and it's getting html. In fact in my console when I visit test.sdcbcdream.org/join I see an extra message that seems to confirm this The script from “https://test.sdcbcdream.org/join/?page=CiviCRM&q=civicrm%2Fajax%2Fl10n-js%2Fen_US&cid=&r=Hi0Km” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type. Can you edit your question to include the shortcode? – Demerit Oct 4 at 21:20
  • 1
    @KarlRudnick FWIW 5.13.0 was when the Clean URLs code was released into the wild. It involved a lot of changes to make it possible. See the PR for details if you want to implement them on your site: github.com/civicrm/civicrm-wordpress/pull/144 Your URLs would then be of the form: test.sdcbcdream.webdev/civicrm/event/… – Christian Wach Oct 14 at 14:03
2
+50

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.

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?

  • Appreciate your time and efforts on this! – Demerit Oct 13 at 4:30
1

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

enter image description here enter image description here

1

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.
  • @haystack also noted "Also FWIW, it seems to me that the Benevolent theme shouldn't be initialising Customizer code on every front-end page load. The Customizer has its own hooks which the theme should make use of. But given that it is (and given that any number of other themes might do something similar) then it's worth us trying to identify and accommodate this sort of behaviour." This is why I think it might be important for other CiviCRM admins using a variety of other themes. – Karl Rudnick Oct 13 at 22:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.