Kimberly

I ended up downgrading back to the working version (prior to 4.1.2 or lower)

Yea i too reported this error last week. The author forgot to set the offset variable to 0 when there is no numerical value to parse out.

Sadly, he didnt correct it in the latest release (came out a few days ago) so hopefully he will finally take notice of this error now that we’ve both reported it.

For now i just manually fixed his bug since it was creating a massive error_log file over time.

If he doesnt correct it in the next release, then, due to the other recent bugs being reported, i will likely downgrade back to the more stable older version. That or just apply my own php fixes for all the new bugs since they are all quick & easy to fix.

that was a bug we fixed in the w3tc-fixed community build a while back.

Performance > General Settings > Debug — Uncheck all the boxes

Hi again @leanda …

Update:

Seemed to work fine (no admin bar). My steps were:

1. Switched my server environment to use PHP v5.3
2. Installed a fresh copy of v0.9.5.2 in my WordPress 4.7.2
3. Turned on Page Cache & Minify and navigated my website
4. Saw the garbled (strange) symbols you were originally getting
5. Followed the steps above to download the raw file of PgCache_ContentGrabbber.php.
6. Uploaded this new file via FTP to the w3-total-cache directory
7. Flushed All Caches
8. While on the Admin page i visited the website just to see the admin bar…perfectly normal to see the bar while logged in. I navigated to several pages. I also checked the cache directory (via FTP) to verify that these pages were not being cached (since my setting is to not cache pages for logged in users)
9. I logged out of admin page
10. I navigate to my website and visit several pages. I see no Admin bar
11. I check via FTP to see the pages are now being cached to disk — they are.

Conclusion:

So i get a sense it may have been something else that was causing the problem because i was not able to duplicate your issue, unfortunately.

From what you’re saying your admin pages were being cached when you were logged in. Or i wonder if you were actually logged still, after the change, when this was happening?

If you have the means to do some experimentation i’d love to get more info to see if it indeed still happens on your end — ensuring you are logged off after making the change. And seeing if these admin pages are being cached to disk.

Thanks for the info
Kimberly

hi again @leanda … very interesting. I am at a loss. When i do a file compare the only change is line 1244.

For the fun of it i will download a fresh official copy of v0.9.5.2 right now (i assume you haven’t changed anything else in your files besides that 1 line) and use the exact steps to modify the file and see if i can hopefully get the admin page glitch you are seeing. I will update what i find.

Thanks for the info
Kimberly

Hi @jonathandavis .. if you’re using a WP’s multi-site feature or WPMU (multi-user version of WP) you will need to configure w3tc at your master location. That is why it could be disabled.

Hi @leanda … Curious…when you say you “switched the PgCache_ContentGrabbber.php file with the new version” can you be more specific?

When switching the PgCache_ContentGrabbber.php file you would need to do it this way:

1. Clicked the link Nigro gave above
2. Clicked the Files Changed tab
3. Clicked the View button
4. Clicked the Raw button
5. Then within your browser you Save As (in Chrome) or Save Page As (in Firefox) — to save the page as a raw .php file to disk.
6. Upload that saved file to your server

Then that would have been correct. The only change in that saved file is just line 1244. It should work just fine — no admin bar glitch.

However, if you did it in a different way (e.g. you went to the main site page — away from Nigro’s link — and downloaded the w3tc-fixed zip file so as to extract the PgCache_ContentGrabbber.php) there is a chance the file you downloaded includes other changes…changes that might depend on other changed files that you didn’t get/seeing. So it all depends on what you did.

The easiest approach in this context is to just modify line 1244 manually, as you discovered.

Regards
Kimberly

• This reply was modified 7 years, 9 months ago by Kimberly.
• This reply was modified 7 years, 9 months ago by Kimberly.
• This reply was modified 7 years, 9 months ago by Kimberly.

Seems its an issue with the pingdom tool e.g. its serving up an old cache version of your page with the previous expiration time value u had.

When using the more comprehensive GtMetrix site instead you can see from the following link your problem doesnt occur and you can even see the response headers under the Waterfall tab that they are indeed sending back the correct expiration times: https://gtmetrix.com/reports/www.pkookshop.com/STmt4aBv

• This reply was modified 7 years, 9 months ago by Kimberly.
• This reply was modified 7 years, 9 months ago by Kimberly.

Place it in the “Ignored query stems” box.
the wording is incorrect when it says “query string”

I will inform the WooCommerce author of this error (the wording error is done by that plugin not w3tc).

• This reply was modified 7 years, 9 months ago by Kimberly.
• This reply was modified 7 years, 9 months ago by Kimberly.

This was a bug i fixed and placed into the W3 Total Cache Fixed community build. The w3tc author will eventually incorporate our many fixes into the next release (as he’s done in previous releases) but if you cant wait 3+ more months then you can always use the fixed release.

Kimberly

Expires is a browser cache header. It’s indicating to the browser to not cache the page (1981) but to serve up a fresh one by hitting your server which in your case since you are using a cache engine will serve back a cache version of the page. Is your Browser Cache option enabled in Performance > General Settings? Its there where u set the Expires time.

From what i see, from your headers, it looks like its serving a cached page fine.

• This reply was modified 7 years, 9 months ago by Kimberly.

Never mind…i added the feature into W3TC making this plugin now irrelevant.

• This reply was modified 7 years, 9 months ago by Kimberly.

Ok, delete the wp-content/w3tc-config directory and if you see an advanced-cache.php, db-cache.php, and object-cache.php files in the wp-content dir then delete those too.

We are just trying to restore access to your admin page.

• This reply was modified 7 years, 9 months ago by Kimberly.

Inside your wp-config.php file remove the define('WP_CACHE', true); line