TonyKO

I’ve increased max_execution _time from 30 seconds to unlimited and memory_limit from 256M to 2048M for both PHP 7.1 and 7.2 and still get the installer.php issue. This is with the developer verion of the plugin.

The last bit of the log file says the following:

INTEGRITY CHECKS:
********************************************************************************
SQL File: 4.46MB
Installer File: 32.97KB
Archive File: 91.68MB

********************************************************************************
RECORD ID:[5]
TOTAL PROCESS RUNTIME: 61.07 sec.
PEAK PHP MEMORY USED: 34.25MB
DONE PROCESSING => testpackage_v2 12 January 2019 3:19 am

So memory doesn’t seem to be an issue.

Will raise a ticket.

Hi Cory,

I’m getting the same issue and installed the developer version without it rectifying the problem.

I can download the installer file directly from the server, rename it, and it works fine.

It’s not a server issue because I have a similar test site on the same server with no problems. The only difference between the sites is some plugins (couldn’t find a conflict) and the size of the site, but I get the same issue when I run “Archive Only the Database” so size doesn’t seem to be the issue either. Bit random.

Cheers,

Tony

I can second that. Getting the following error:

Uncaught ReferenceError: aa is not defined
at getTag (wc-shortcodes.js?ver=3.14:81)
at window.wcShortcodes (wc-shortcodes.js?ver=3.14:128)
at t.onclick (shortcodes-tinymce-4.js?ver=3.14&wp-mce-4401-20160726:256)
at t.i [as fire] (tinymce.min.js?ver=4401-20160726:8)
at t.fire (tinymce.min.js?ver=4401-20160726:8)
at HTMLDivElement.t (tinymce.min.js?ver=4401-20160726:8)
at e (tinymce.min.js?ver=4401-20160726:2)
at HTMLDivElement.m (tinymce.min.js?ver=4401-20160726:2)

Haha. Ok, I won’t.

Well that’s the question. On one of the established sites where I’m getting the comment in GSC, search results don’t seem to have been affected. On a new site where I’m getting the comment, it seems to have been indexed properly. So maybe it doesn’t matter.

There is a pretty unproductive discussion about it here – https://productforums.google.com/forum/#!topic/webmasters/7uGns2lFkRA. It shows that anyone using GSC would be freaked out by it a bit.

Shouldn’t the standard WordPress htaccess rewrites in conjunction with WP Fastest Cache code in htaccess take care of it though?

In practice the non-trailing slash url does redirect to trailing slash so the GSC comment doesn’t make a lot of sense. I don’t think a further rule is required.

My point was that the WP Fastest Cache plugin is causing Google Search Console to think there is an issue. With the plugin deactivated or with a different caching plugin I don’t get the same comment when checking robots.txt in GSC. So I guess the code that WPFC adds to .htaccess conflicts with the standard WordPress trailing slash redirect somehow (without removing the functionality).

The only code in my htaccess file(s) is the WPFC code, the standard WordPress code and an http-https redirect. There will be a lot of users who haven’t checked their robots file in GSC who would have the same problem I think.

Hi there, great plugin but this issue doesn’t appear to be completely resolved.

I have added the plugin to a new site and deleted and reinstalled on older sites but the following issue doesn’t go away.

If you are in Google Search Console in the robots.txt Tester, click on the “see robots.txt live” link. If WP Fastest Cache caching is enabled, you get the <!– permalink_structure ends with slash (/) but REQUEST_URI does not end with slash (/) –> comment at the bottom. If you disable cache system in the WP Fastest Cache settings tab and refresh the robots live link, the comment disappears.

I don’t know if this damaging search rankings or not but either way it isn’t ideal!

I’m having a similar issue with an editor level client who needs to edit Woocommerce variables within product pages as well as product attribute terms outside of the product pages, both of which don’t trigger the cache clearing.

Doing a small edit to the content of affected products, updating the product and then removing that edit and updating again is a workaround, but not ideal.

Auto clearing on a custom field change wouldn’t be bad, although not sure whether that works for the product attribute terms bit and there could be a lot cache clearing if that was the case.

Being able to give editors access to the “remove from Wordfence cache” link on a page, post, custom post type basis would be the better option I think.

Cheers.

• This reply was modified 8 years, 5 months ago by TonyKO. Reason: error
• This reply was modified 8 years, 5 months ago by TonyKO.

Well this sorted itself out. It was either a Chrome update or multiple history/cookie deletions in combination with clearing the Wordfence cache. Hard to figure out.

Clearly nothing to do with the plugin!

If you inspect the page using Chrome Developer Tools and then click on the errors/warnings link at top right of console, you will see that it’s due to the Google API link – https://maps.google.com/maps/api/js?sensor=true – containing http. It should be a protocol-neutral link.

Normally you shouldn’t edit a plugin directly but because this hasn’t been updated in 2 years, you may as well. So go into the plugin file and edit themeblvd-google-maps.php. Find the link and either remove the http: (change to //maps.google.com/maps/api/js?sensor=true) or change to https://maps.google.com/maps/api/js?sensor=true – Either should work.

You will also need to go into the plugin file found at /assets/jquery.gmap.min.js to adjust the links found there.

That should do it.