mgc8

@mnelson4 Thank you for the update, I can confirm that the newly released version works as expected on all my blogs.

Hello,

Thank you for the quick action on this.

I can confirm that updating the plugin to version 5.10.1 solved the issue on both of my blogs.

Here is a list of the common installed plugins:

 wp-security-scan
 add-meta-tags
 akismet (inactive)
 async-javascript
 better-plugin-compatibility-control
 better-search-replace
 broken-link-checker
 elegant-themes-updater
 exclude-pages
 fancybox-for-wordpress
 google-sitemap-generator
 hello-dolly (inactive)
 hikari-category-permalink
 iwp-client
 nextgen-gallery
 nospamnx
 page-links-to
 varnish-http-purge
 relevanssi
 scrapebreaker
 simple-share-buttons-adder
 simply-show-ids
 wp-piwik
 wp-maintenance-mode
 yet-another-related-posts-plugin

The templates are variations from older Elegant Themes (not Divi).

Regards,
Mihnea

I had this problem as well, caused huge issues for two of my blogs today, and hard to debug as it only showed up on posts but not pages; fortunately, I could see that YARPP had been auto-upgraded last night so I could disable it to test.

Behaviour: post loading times out with 500 error.

Example of errors logged (doesn’t matter the PHP memory limit, basically it fills it all up):

AH01071: Got error 'PHP message: PHP Fatal error:  Allowed memory size of 1073741824 bytes exhausted (tried to allocate 24576 bytes) in (...)/wp-includes/formatting.php on line 584PHP message: PHP Fatal error:  Allowed memory size of 1073741824 bytes exhausted (tried
 to allocate 65536 bytes) in (...)/wp-includes/functions.php on line 3461PHP message: PHP Fatal error:  Allowed memory size of 1073741824 bytes exhausted (tried to allocate 53248
 bytes) in Unknown on line 0'

Disabling the plugin immediately resolved the issue.

• This reply was modified 4 years, 1 month ago by mgc8.

Ok, so I tracked this down to the considerable API changes in Piwik 2.0. Frankly I believe this works only for people who use the “REST” API, it should break for everyone using the “PHP” one, given that on my system the “callPHP” function returned NULL constantly before I patched it.

Anyway, the problem is basically that Piwik switched to using namespaces extensively and all code has been re-factored to take this into account. Given that WP-Piwik includes Piwik source code directly and instantiates the “Piwik_API_Request” class, it fails silently due to the class being renamed to “Piwik\API\Request”.

So here it goes… In “wp-piwik.php”, replace the “function callPHP()” with the follwing:

function callPHP($strParams) {
                if (PIWIK_INCLUDE_PATH === FALSE)
                        return serialize(array('result' => 'error', 'message' => __('Could not resolve','wp-piwik').' "'.htmlentities(self::$settings->getGlobalOption('piwik_path')).'": '.__('realpath() returns false','wp-piwik').'.'));
                if (file_exists(PIWIK_INCLUDE_PATH . "/index.php"))
                        require_once PIWIK_INCLUDE_PATH . "/index.php";
                if (file_exists(PIWIK_INCLUDE_PATH . "/core/API/Request.php"))
                        require_once PIWIK_INCLUDE_PATH . "/core/API/Request.php";
                if (class_exists('Piwik_FrontController'))
                        Piwik_FrontController::getInstance()->init();
                else if (class_exists('Piwik\FrontController'))
                        Piwik\FrontController::getInstance()->init();
                // Add Piwik URL to params
                $strParams .= '&piwikUrl='.urlencode(self::$settings->getGlobalOption('piwik_url'));
                // This inits the API Request with the specified parameters
                if (class_exists('Piwik_API_Request'))
                        $objRequest = new Piwik_API_Request($strParams);
                else if (class_exists('Piwik\API\Request'))
                        $objRequest = new Piwik\API\Request($strParams);
                else return NULL;
                // Calls the API and fetch XML data back
                return $objRequest->process();
        }

… this should make Piwik detect the site correctly. The tracking code is still not picked up right, but I guess similar changes have to be made to the code there.

Hope this helps in tracking it down.

Regards,
Mihnea

“mgc8’s problem sounds really strange (the debug script uses the same functions as WP-Piwik itself… so a working debug script should be equal to a working WP-Piwik setup) and I’m really sorry I don’t have an idea how to solve it.”

Well, that’s quite unfortunate… Maybe we can help debug this so you can get a better idea? For the record, I just updated to the latest version of WP-Piwik (0.9.9.8) and the behaviour is the same.

Here is what the second test reports, I would guess the format is somehow incompatible with what WP-Piwik expects?

“*** Test 2/2: SitesManager.getSitesIdFromSiteUrl ***
(…)
<?xml version=”1.0″ encoding=”utf-8″ ?>
<result>
<row>
<idsite>4</idsite>
</row>
</result>
Time: 0.05s

The reason I’m saying that is because on the “Get site configuration details” page there is no proper ID detected. So it seems WP-Piwik can’t get the ID correctly, therefore it doesn’t get the tracking code either… does that make any sense?

Hello,

I am also seeing the same problem on three of my blogs, and nothing I tried so far seems to have helped:

1. Updated Piwik — it’s now on 2.0.2
2. Updated WP — 3.8
3. Updated WP-Piwik — 0.9.9.7
4. Configuration — reset, no difference
5. Auth token — reset password, copied new token, no difference

I also unticked “Enable cache” under WP-Piwik -> Piwik Settings — no difference.

I get two different errors:
– under “Home”:
An error occured: Piwik did not answer. Please check your entered Piwik URL.
– under “Piwik Settings”:
An error occured: Please check URL and auth token. You need at least view access to one site.

Of course, both the URL and auth token are correct (please note, this happens on three different blogs).

Piwik itself works perfectly fine, which is evident when I add the tracking code manually; however WP-Piwik itself does not add any code.

Running the tests under “Support” however gives correct results:
*** Test 1/2: SitesManager.getSitesWithAtLeastViewAccess ***
HTTP/1.1 200 OK, expected XML
*** Test 2/2: SitesManager.getSitesIdFromSiteUrl ***
HTTP/1.1 200 OK, expected XML

Maybe a useful hint is that the “Get site configuration details” link does not seem to get the right Piwik ID for the site, even though it does get the title and URL.

If I can venture a guess, are we facing a problem parsing the XML maybe?

Thanks for any help and please let me know if I can provide more information.

Regards,
Mihnea

Hello,

Thanks for the quick reply, I updated to the new version on several WP installations and it is working nicely, much appreciated!

Regarding the Akismet issue, indeed it displays 3.1 since that’s in the readme file, however I don’t think there is much you can do to fix it on the BPCC side; perhaps bringing this to the attention of the WP/Akismet developers could help?

Another idea may be to add a third state, e.g. yellow/orange between “green” and “red” — which would mean “should work, but no guarantee”. You could assign that state when the version number has the same major.minor (so 3.1 in this case) but no point release, since normally point releases are for bugfixes and should not influence plugin compatibility (of course, they may, so that’s why it won’t be “green”).

HTH and best regards,
Mihnea