Pretty Links conflicts with WP Super Cache

If you can omit caching from all Pretty Links that would be ideal. Caching can cause some troubles, especially with click tracking and reporting.

Thank you. I tried a number of things — and, I guess, I got it 90% resolved, though with some uncertainty remaining. Have a look at these attempted solutions:

1) I used a slug prefix like “go/” as in mydomain.com/go/prettylinkslug and then added the string /go/ to the WP Super Chase exceptions. But it did not seem to work. I still got the error on Meta Refresh redirects

2) However, it then seemed to work Internet Explorer. And the redirect link also worked in a Chrome Incognito browser. However, in a normal Chrome browser of latest build I get a white screen with the message
Fatal error: Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0

3) So I suspected is there some issue with the Chrome Browser cache. So I deleted the Chrome Browser cache via Ctrl+Shift+Del and then selecting all options and deleting cached files, cookies, etc. Now, reloading the page via the meta refresh link worked, a BUT then it stopped working again. So I tried to add the meta tag <meta http-equiv=”Cache-Control” content=”no-store” /> to suppress Browser caching in chrome. But it had no effect.

4) The I noticed that the issue did not re-appear immediately upon first re-load, but AFTER A WHILE. In fact, it happened as soon as I re-logged back into WordPress. That’s when the error kicked in again. When I log out of WordPress, then the PrettyLink meta refresh redirect works!!

5) So this led me down the path that there must be some issue with the WP Cache function “[x] Don’t cache pages for known users. (Recommended)” — Here is was wild. First I enabled the tickmark, thinking that it would serve non-cached pages when logged in. Right? But, totally counter-intuitively, the error persists; it only resolves when DISABLING the function, i.e. [] Don’t cache pages for known users. (Recommended)”
This does not make sense, but it solves the re-direction issue.
Now, I have to keep monitoring my membership plugin, because with memberships I would actually prefer to serve non-cached pages to logged-in users. Well, let’s see.

I’m not familiar enough with WP Super Cache to say for sure, but if you allow users to sign in to your site, I’d definitely recommend keeping the [x] Don’t cache pages for known users. (Recommended) option enabled to prevent other possible issues with your users.

You might need to do some kind of regex on the /go/ option in the WP Super Cache settings – then flush all caches out.

/go/.* or something like that maybe.