KZeni

I see what you mean. I appreciate your quick response, and I’ll look to see if I can come up something in the meantime ??

Hmm, how about a simple:

global $post;
if($post->ID) // Use the post id to make it permalink agnostic (for IIS6 compliance)
	$url = '/index.php?page_id='.$post->ID;
else // Utilize the request url
	$url = wpcf7_get_request_uri();

Would that work?

I was hoping updating to WordPress 3.2.1 (from 3.1.x) would do something magic & it would start working… nope :-/

Hi Frederick,

I replied to the email that you sent me in regards to taking a closer look at the problem. Just want to make sure you didn’t miss it ??

I contacted my hosting provider (Rackspace Cloud Sites), and they show that the pages are indeed pulling from the cache files. However, they weren’t able to determine why the cache files are being recreated for every page view.

Help would be greatly appreciated.

Here’s the debug report:

<!-- Performance optimized by W3 Total Cache. Learn more: https://www.w3-edge.com/wordpress-plugins/

Minified using disk
Database Caching 81/367 queries in 0.399 seconds using disk
Object Caching 4183/5450 objects using disk

Served from: www.*DOMAIN*.com @ 2011-06-23 18:51:29 -->

<!-- W3 Total Cache: Page cache debug info:
Engine:             disk (enhanced)
Cache key:          *PATH*/_index.html.gzip
Caching:            enabled
Status:             not cached
Creation Time:      11.544s
Header info:
X-Pingback:         https://www.*DOMAIN*.com/xmlrpc.php
Content-Type:       text/html; charset=UTF-8
Last-Modified:      Thu, 23 Jun 2011 23:51:29 GMT
Vary:               Accept-Encoding, Cookie
Expires:            Fri, 24 Jun 2011 00:51:29 GMT
Pragma:             public
Cache-Control:      max-age=3600, public, must-revalidate, proxy-revalidate
Etag:               32537051685b1d7990413466278b3f7e
X-Powered-By:       W3 Total Cache/0.9.2.3
Content-Encoding:   gzip
-->

I removed the URL from the debug info since it’s a development site at the moment. It doesn’t matter which page you visit since this issue is site-wide, and the timestamp is different on every page view.

I approve of this message, and would love to see that implemented considering it really is a quick fix.

True, but the Pro version seems to have been made by someone who forked the project & wasn’t an original developer (at least they aren’t mentioned in the credits of the non-pro version).

Therefore, one proposed way to get this feature implemented is to have the original developer(s) sanction the development of this feature (requiring no real work from the original developers). I personally wouldn’t want to spend time doing this just to find that development has been abandoned.

I’ve only posted this here… so if anyone knows how to contact one of the developers directly, please do (or let me know how I could get in contact with them).

Right. The devs could set up a kickstarter page… just saying.

@bdeaton108 I know it does that in the public view (ie. the blog’s homepage), but this was happening on the admin’s “Edit Posts” and “Edit *insert Custom Post Type here*” pages.

UPDATE: I didn’t have any posts (the site was entirely based on pages), and that was causing the 404 error. When I created a custom post type, it didn’t have anything in it so it was showing a 404 error because there wasn’t any posts to show.

I went to “Add New” (loaded just fine) for each section that was showing a 404 error… added an item… and now it’s fully working.

This seems like a bug, because I’d imagine that it should show the regular page only without any posts in the list (instead of a 404 error).

Still not working =/
Hopefully there’s something in here: https://codex.www.ads-software.com/Upgrading_WordPress_Extended

Update (haven’t fixed my site yet, but here’s what I’ve tried):
– Deactivated & reset the plugins folder via FTP & checked using phpMyAdmin.
– Activated the “twenty ten” theme.
– Due to the large number of reports of Platinum SEO being the cause, I deleted all instances of psp_ & aiosp_ using phpMyAdmin (it was activated on the site before so the options still remained in the database).

All three of these in combination didn’t result in a fix for my site =(
Still looking…

I’m having a similar issue where I can access the pages, but not the posts or custom post types (displays a 404 error). Disabling the plugins, using the default twenty ten theme, re-uploading the wp-admin files, and re-installing the whole version didn’t fix the issue. It seems like it’s a server and/or database related issue at this point (due to lack of other options that I’m aware of), but it’s a site that was running 2.9.2 without any problems before the upgrade.

I’ll keep this topic bookmarked if I (hopefully) come across a fix.