Answers.Body: <p>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</p>
  
  <blockquote>
    <p>$page = get_query_var( 'page' );</p>
  </blockquote>
  
  <p>with</p>
  
  <blockquote>
    <p>$page = $_GET['page'];</p>
  </blockquote>
  
  <p>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?</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-13T04:30:20.063Z
Answers.Text: Appreciate your time and efforts on this!
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-13T01:34:24.717Z
Answers.LastActivityDate: 2019-10-13T05:05:31.953Z
Answers.LastEditDate: 2019-10-13T05:05:31.953Z
Answers.UserDisplayName: Karl Rudnick
Answers.Body: <p>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.</p>
  
  <blockquote>
    <p>@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.</p>
    
    <p>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:</p>
  
  <pre><code> /**
    * 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-&gt;is_main_query() ) {
       return;
     }
  
     // Bail if filters are suppressed on this query.
     if ( true == $query-&gt;get( 'suppress_filters' ) ) {
       return;
     }
  
     // Prevent multiple calls
     static $alreadyRegistered = FALSE;
     if ( $alreadyRegistered ) {
       return;
     }
     $alreadyRegistered = TRUE;
  </code></pre>
    
    <p>FWIW, the new code is:</p>
    
    <ul>
    <li>the addition of $query as a parameter to the function</li>
    <li>the sanity-checking code before the line that reads <code>// Prevent multiple calls.</code>
    If you then re-check your problematic page, we can see if this helps.</li>
    </ul>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-13T22:56:10.600Z
Answers.Text: @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.
Answers.UserDisplayName: Karl Rudnick
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-13T22:52:16.810Z
Answers.LastActivityDate: 2019-10-14T09:28:29.403Z
Answers.LastEditDate: 2019-10-14T09:28:29.403Z
Answers.UserDisplayName: Karl Rudnick
Answers.Body: <p>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.</p>
  
  <ol>
  <li>The Join page shows NO javascript console errors</li>
  <li>The Event pages now display correctly and contain the expected Ajax insertions when looking at civicrm under Sources in the inspection panel</li>
  </ol>
  
  <p>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 ;-)</p>
  
  <p><a href="https://i.sstatic.net/xRbED.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/xRbED.png" alt="enter image description here"></a>
  <a href="https://i.sstatic.net/SEJ5o.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/SEJ5o.png" alt="enter image description here"></a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-12T03:42:29.857Z
Answers.LastActivityDate: 2019-10-12T04:51:53.940Z
Answers.LastEditDate: 2019-10-12T04:51:53.940Z
Answers.UserDisplayName: Karl Rudnick
Answers.Body: <p>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 <a href="https://github.com/civicrm/civicrm-wordpress/pull/166" rel="nofollow noreferrer">the GitHub repo</a> for the CiviCRM-WordPress plugin.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-14T16:15:20.137Z
Answers.Text: Thanks again. By clicking your post, Christian (aka "haystack"), I hope that means you get the bounty. Well deserved ;)
Answers.UserDisplayName: Karl Rudnick
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-15T17:40:04.603Z
Answers.Text: Also, I just implemented Clean URLs on our test site at https://test.sdcbcdream.org, which is not at Civi 5.18.2 with your civicrm.php update. Instead of referencing events as https://test.sdcbcdream.org/civicrm/?page=CiviCRM&q=civicrm/event/info&reset=1&id=168, we can now use https://test.sdcbcdream.org/civicrm/event/info/?reset=1&id=168 . Beautiful ;)
Answers.UserDisplayName: Karl Rudnick
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-16T08:04:56.020Z
Answers.Text: Thanks for the points @KarlRudnick - I'm not sure what they're useful for, but hey, gotta love gamification :)
Answers.UserDisplayName: Christian Wach
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-16T08:05:20.577Z
Answers.Text: Glad you like Clean URLs too.
Answers.UserDisplayName: Christian Wach
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-28T18:34:40.370Z
Answers.Text: I just grabbed the Civi 5.18.4 download and the patch to civicrm.php to register_hooks_front_end() was not included in this update. When will it appear in official downloads, so that I don't have to insert it on my own?
Answers.UserDisplayName: Karl Rudnick
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-05T09:23:36.473Z
Answers.Text: @KarlRudnick It would be better to ask this on the CiviCRM-WordPress repo on GitHub.
Answers.UserDisplayName: Christian Wach
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-14T09:23:43.507Z
Answers.LastActivityDate: 2019-10-14T09:23:43.507Z
Answers.UserDisplayName: Christian Wach
Body: <p>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 <a href="https://civicrm.stackexchange.com/questions/33195/civicrm-5-17-5-and-wordpress-5-2-3-just-wont-work">CiviCRM 5.17.5 and WordPress 5.2.3 just won&#39;t work</a>.</p>
  
  <p>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.</p>
  
  <p>Thanks for any advice here!
  <a href="https://i.sstatic.net/G5Czv.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/G5Czv.png" alt="enter image description here"></a>
  <strong>*Edit added ~midnight 10/11/2019 *</strong>
  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&amp;q=civicrm/event/info&amp;reset=1&amp;id=168</p>
  
  <p>In this screenshot for CiviCRM 5.12.4, note civicrm under Sources in the inspect panel shows <a href="http://sdbikecoalition.webdev/civicrm/?page=CiviCRM&amp;q=civicrm%2Fajax%2Fl10n-js%2Fen_US&amp;cid=&amp;r=aMJXH" rel="nofollow noreferrer">http://sdbikecoalition.webdev/civicrm/?page=CiviCRM&amp;q=civicrm%2Fajax%2Fl10n-js%2Fen_US&amp;cid=&amp;r=aMJXH</a> and the event page (event id=168) displays correctly.
  <a href="https://i.sstatic.net/O8OiQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/O8OiQ.png" alt="enter image description here"></a></p>
  
  <p>In this next screenshot for CiviCRM 5.18.2, note the civicrm under Sources in the inspect panel shows <a href="http://test.sdcbcdream.webdev/civicrm/?page=CiviCRM&amp;q=civicrm/event/info&amp;reset=1&amp;id=168" rel="nofollow noreferrer">http://test.sdcbcdream.webdev/civicrm/?page=CiviCRM&amp;q=civicrm/event/info&amp;reset=1&amp;id=168</a> and the event page (event id=168) does NOT display.
  <a href="https://i.sstatic.net/fy1XC.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/fy1XC.png" alt="enter image description here"></a></p>
  
  <p>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.</p>
  
  <p>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.
  <a href="https://i.sstatic.net/YUt8L.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/YUt8L.png" alt="enter image description here"></a> </p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-04T16:51:45.970Z
Comments.Text: 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.
Comments.UserDisplayName: Karl Rudnick
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-04T17:15:58.757Z
Comments.Text: 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?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-04T21:13:13.550Z
Comments.Text: /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 https://test.sdcbcdream.org/civicrm/?page=CiviCRM&q=civicrm/event/info&reset=1&id=168 . So this is not just a CiviContribute issue.
Comments.UserDisplayName: Karl Rudnick
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-04T21:20:52.990Z
Comments.Text: 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?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-04T21:35:52.947Z
Comments.Text: [civicrm component="contribution" id="7" mode="live" hijack="0"] Note that our staff uses the block editor Elementor because they are not too technical. That shortcode is a caption in the Elementor image block if that helps. Just another layer to deal with...
Comments.UserDisplayName: Karl Rudnick
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-04T22:25:13.067Z
Comments.Text: However, the event link above See https://test.sdcbcdream.org/civicrm/?page=CiviCRM&q=civicrm/event/info&reset=1&id=168 is not working from a non-Elementor created page and that link is just an href hyperlink reference. Nothing fancy.
Comments.UserDisplayName: Karl Rudnick
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-04T22:43:21.700Z
Comments.Text: sorry for the double negative above. The event href hyperlink is on a page that was NOT created or edited with Elementor and it can't resolve the CiviCRM Event page. fwiw, it is the Dec 3 hyperlink on this page: https://test.sdcbcdream.org/smart-cycling/ . Note there are no problems on https://sdbikecoalition.org/ (Civi 5.12.4) for either the Join page or the hyperlinks on the Smart Cycling page.
Comments.UserDisplayName: Karl Rudnick
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-11T07:17:43.073Z
Comments.Text: Just calling attention to an edit of the original post to show the same event (id=168) displayed correctly with CiviCRM 5.12.4 and NOT displayed at all with CiviCRM 5.18.2, all things being totally equal except CiviCRM version. Notice the Ajax in civicrm Sources in the debug panel for Civi 5.12.4. There is no Ajax in civicrm Sources for Civi 5.18.2. I could not add images in these comments, so I just added to the original post to show that it is not just the shortcode on our Join page.
Comments.UserDisplayName: Karl Rudnick
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-11T07:31:58.267Z
Comments.Text: And just added a last screenshot with the debug panel for the same event, CiviCRM 5.18.2, but with the stock Wordpress "2019" theme. It displays correctly and the details in the debug panel under Sources are yet again different.
Comments.UserDisplayName: Karl Rudnick
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-11T11:42:21.107Z
Comments.Text: Have you also tried the wordpress channel at https://chat.civicrm.org?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-11T15:57:14.480Z
Comments.Text: Yes, I have. I got a couple good suggestions. That seems to be a disorganized blog stream, so hard to focus threads on a single issue. Isn't there somewhere to register this stuff? I'm going to start debugging with Phpstorm to see where the disconnect is. Funny that this suddenly happened with the release of CiviCRM 5.13.0, whereas no (obvious) changes have happened with either Wordpress or our Benevolent Pro theme, which we always keep both up to date.
Comments.UserDisplayName: Karl Rudnick
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-14T14:03:06.420Z
Comments.Text: @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: https://github.com/civicrm/civicrm-wordpress/pull/144 Your URLs would then be of the form: http://test.sdcbcdream.webdev/civicrm/event/info&reset=1&id=168
Comments.UserDisplayName: Christian Wach
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-14T16:24:00.620Z
Comments.Text: Thanks, @ChristianWach. Clean URLs is an improvement of which I will also take advantage, now that we can continue forward with Civi stable releases.
Comments.UserDisplayName: Karl Rudnick
Tags: <wordpress><theme>
Title: How best to resolve Wordpress theme / CiviCRM conflicts
ThreadText: # How best to resolve Wordpress theme / CiviCRM conflicts
  
  (Asked by: username_0 on 2019-10-04)
  
  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](https://civicrm.stackexchange.com/questions/33195/civicrm-5-17-5-and-wordpress-5-2-3-just-wont-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](https://i.sstatic.net/G5Czv.png)](https://i.sstatic.net/G5Czv.png)
  **\*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](https://i.sstatic.net/O8OiQ.png)](https://i.sstatic.net/O8OiQ.png)
  
  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](https://i.sstatic.net/fy1XC.png)](https://i.sstatic.net/fy1XC.png)
  
  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](https://i.sstatic.net/YUt8L.png)](https://i.sstatic.net/YUt8L.png)
  
  **Tags:** wordpress, theme
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_1**: 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?  
  > **username_0**: /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 https://test.sdcbcdream.org/civicrm/?page=CiviCRM&q=civicrm/event/info&reset=1&id=168 . So this is not just a CiviContribute issue.  
  > **username_1**: 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?  
  > **username_0**: [civicrm component="contribution" id="7" mode="live" hijack="0"] Note that our staff uses the block editor Elementor because they are not too technical. That shortcode is a caption in the Elementor image block if that helps. Just another layer to deal with...  
  > **username_0**: However, the event link above See https://test.sdcbcdream.org/civicrm/?page=CiviCRM&q=civicrm/event/info&reset=1&id=168 is not working from a non-Elementor created page and that link is just an href hyperlink reference. Nothing fancy.  
  > **username_0**: sorry for the double negative above. The event href hyperlink is on a page that was NOT created or edited with Elementor and it can't resolve the CiviCRM Event page. fwiw, it is the Dec 3 hyperlink on this page: https://test.sdcbcdream.org/smart-cycling/ . Note there are no problems on https://sdbikecoalition.org/ (Civi 5.12.4) for either the Join page or the hyperlinks on the Smart Cycling page.  
  > **username_0**: Just calling attention to an edit of the original post to show the same event (id=168) displayed correctly with CiviCRM 5.12.4 and NOT displayed at all with CiviCRM 5.18.2, all things being totally equal except CiviCRM version. Notice the Ajax in civicrm Sources in the debug panel for Civi 5.12.4. There is no Ajax in civicrm Sources for Civi 5.18.2. I could not add images in these comments, so I just added to the original post to show that it is not just the shortcode on our Join page.  
  > **username_0**: And just added a last screenshot with the debug panel for the same event, CiviCRM 5.18.2, but with the stock Wordpress "2019" theme. It displays correctly and the details in the debug panel under Sources are yet again different.  
  > **username_1**: Have you also tried the wordpress channel at https://chat.civicrm.org?  
  > **username_0**: Yes, I have. I got a couple good suggestions. That seems to be a disorganized blog stream, so hard to focus threads on a single issue. Isn't there somewhere to register this stuff? I'm going to start debugging with Phpstorm to see where the disconnect is. Funny that this suddenly happened with the release of CiviCRM 5.13.0, whereas no (obvious) changes have happened with either Wordpress or our Benevolent Pro theme, which we always keep both up to date.  
  > **username_2**: @username_0 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: https://github.com/civicrm/civicrm-wordpress/pull/144 Your URLs would then be of the form: http://test.sdcbcdream.webdev/civicrm/event/info&reset=1&id=168  
  > **username_0**: Thanks, @username_2. Clean URLs is an improvement of which I will also take advantage, now that we can continue forward with Civi stable releases.  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_2 on 2019-10-14. Score: 3 | Accepted answer
  
  username_0 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](https://github.com/civicrm/civicrm-wordpress/pull/166) for the CiviCRM-WordPress plugin.
  
  > **Comments:**
  > **username_0**: Thanks again. By clicking your post, username_2 (aka "haystack"), I hope that means you get the bounty. Well deserved ;)  
  > **username_0**: Also, I just implemented Clean URLs on our test site at https://test.sdcbcdream.org, which is not at Civi 5.18.2 with your civicrm.php update. Instead of referencing events as https://test.sdcbcdream.org/civicrm/?page=CiviCRM&q=civicrm/event/info&reset=1&id=168, we can now use https://test.sdcbcdream.org/civicrm/event/info/?reset=1&id=168 . Beautiful ;)  
  > **username_2**: Thanks for the points @username_0 - I'm not sure what they're useful for, but hey, gotta love gamification :)  
  > **username_2**: Glad you like Clean URLs too.  
  > **username_0**: I just grabbed the Civi 5.18.4 download and the patch to civicrm.php to register_hooks_front_end() was not included in this update. When will it appear in official downloads, so that I don't have to insert it on my own?  
  > **username_2**: @username_0 It would be better to ask this on the CiviCRM-WordPress repo on GitHub.  
  
  ---
  
  ### Answer by username_0 on 2019-10-13. Score: 3
  
  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?
  
  > **Comments:**
  > **username_1**: Appreciate your time and efforts on this!  
  
  ---
  
  ### Answer by username_0 on 2019-10-13. Score: 2
  
  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.
  
  > **Comments:**
  > **username_0**: @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.  
  
  ---
  
  ### Answer by username_0 on 2019-10-12. Score: 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](https://i.sstatic.net/xRbED.png)](https://i.sstatic.net/xRbED.png)
  [![enter image description here](https://i.sstatic.net/SEJ5o.png)](https://i.sstatic.net/SEJ5o.png)
  
  
  ---
  
  