Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.4.6
-
Fix Version/s: 4.4.7
-
Component/s: WordPress Integration
-
Labels:None
Description
This is essentially the same problem as CRM-14244, except the outcome isn't that CiviCRM content is dropped into the <head>; instead, CiviCRM is prevented from being invoked at all.
Quick recap: some WordPress plugins process page content before the page loads, most notably to scrape keywords, images, and so forth to put in <meta> tags. CRM-14244 reported that on pages with the long CiviCRM URLs, CiviCRM was getting invoked at that point (since the "the_content" filter, typically used to process WordPress post/page content, triggers CiviCRM to echo all its stuff in place of the actual post/page content). This dropped the contribution page, event, or whatever within the <head>. The fix was to add more conditions to when CiviCRM is invoked, returning otherwise.
However, https://github.com/civicrm/civicrm-wordpress/pull/42 introduced a new problem: if the_content is processed in the head, the alreadyInvoked flag gets set to true even though the test for whether CiviCRM should be invoked will stop things later on. With that set to true, it'll never be invoked, even when it's appropriate.
Basically, the one line needs to be moved to after the test of whether we're in_the_loop and so forth.