acolonna

Hi donncha,

sorry for the late reply! nope I don’t.
I have just found out that only a portion of my website pages are served through Super cache, so will have to take all to my development machine and do apache testing from here.

Well let you know if I manage to collect useful info!

Here it is, have you ever heard of the Cookie “wordpress_test_cookie”? Used by WP to check for Cookie support?
This will interfere with the Apache rules of WP Super Cache.

I resolved that problem. It was a bug in my own i18n implementation, my bad! ??

I just installed the latest version of WP Super Cache on an install of WP 2.8.5 which didn’t have WP Super Cache before. All on (gs).

REMOTELY:
I am getting a warning on the plugin admin page, stating the wp-cron.php file can not be reached. It does have the same problem on another domain (on the same gs account).

LOCALLY:
I have two different installs on two other versions of the site, in the public folder of my machine. They are both version 0.9.6.1, yet one is stating the ploblem and the other one not! This is so weird.
Neither of the websites is listed in the hosts file.

Looks like there is a lot of unfinished work around here…

I just bumped into the same dead end. What a headache. I need to tap into the admin tables… without modifying the system code (and possibly without ugly JS fixes)

I have completed step one: I now have a working routing plugin (still has to go through some more testing).

The logic is very simple: given a set of enabled languages, the plugin looks for a language definition in the path (prefix).

If none are found, it determins what language to use (first it looks for a cookie, then it looks for a session var and finally it goes through the request headers… if no other method works it just uses the site default language).
It then redirects the client (301 Permanently moved) to the full path: this way we are sure clients are always exposed to an explicit language request in the URL.

If a language prefix is found in the URL, it removes it for WordPress to do it’s magic and saves language information in a global variable.

The plugin simply ignores everything related to ADMIN pages and system paths (using the bloginfo() function will produce full paths with language codes unless the paths point to wp-login, wp-admin, wp-content or wp-includes).

I am deliberately ignoring RSS and other functionalities, because my production site does not make use of them.

Now if this thing works correctly (it looks like it does, and it is perfectly unpluggable), the next step should be downhill: adding forms to the ADMIN section.

Hi Pinoy.ca

Seems to be working now, I checked with different browsers to have one not logged in user.. have to dig further into that. (I am also writing my own flavor of multilanguage plugin, because none of the ones around seems to work seriously… including WPML).

Well I’m starting off on a production site, based on WP (yess I am that reckless…) which I am currently learning.

I figured that *maybe* for SEO, a good idea could be forcing the language ISO code into the URL, leaving all the rest the same between languages.

I am currently in the process of hacking into the WP routing, using qTranslate as close reference. I think I already got all I could out of it, now I have to start fixing it’s issues (pre-path mode doesn’t work in some cases, for example https://domain.com/en
it looks like it needs a trailing slash).

One major issue I found is getting the path prefix to be injected in option calls (like get_option(“home”)), which are often used to build static menus and other bits of the theme.
The same options are read by the plugin itself, so they require to be virgin (also because tapping into them results in an infinite loop).

Once that is done, the rest should be fairly easy (a little DB and Admin forms…).
Probably I’m missing something here… but I’m sure I’ll notice it when I bash my head into it!!!

One quick thought that came to my mind (and after this I’m heading for my pillow): routing.

The cheap solution would be to keep it at it’s minimum: whatever WP is doing before the plugin is installed. This would mean, if English is the default language, that URL’s would use English terms and titles (assuming you are using permalinks, because there is no other way really, if you want your site to look professional) all the time, even when a user is accessing the website in French for instance.

This shouldn’t offend anyone, because let’s face it, everyone knows English (at least enough to make out the meaning of the URL they are clicking to access that deep page of your site), and still it would be only appearling in the actual URL: the link would show the translated text as it’s content.

Another solution would be to hack the routing logic, so to add something like aliases for your translated posts: based on the language the System has decided to work with (given for example the URL had a language prefix), it would match the URL parts against translated slugs.

From the outside it would be like visiting a WPML website.. but from the inside your data architecture is nice and clean!

Pinoy.ca, very acute suggetsion. The first attempt at optimization that can be performed on any conditional in any language.
Great!

As regarding the homepage I must admit I haven’t taken the time to tackle it yet, I’ve been covering thousands of kilometers on my bike to get back home from my holidays.

Will get back to work tomorrow and hunt it down. If anyone comes up with an idea, be my guest!

thanks for the side view, I’ll definitely check out the expressions!

Ok, after a full day of work and a series of headaches I hoped this plugin would save me, here is a new set of rewrite rules. I am in no way a regex or mod_rewrite expert, so please keep both eyes open for problems.

By the way, if anybody knows of a valid regex tool for mac, I once used to use a fantastic one on Windows, but there apears to be no professional apps on Mac for that.

Here we go:

# BEGIN WPSuperCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
AddDefaultCharset UTF-8

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
# RewriteCond %{HTTP_USER_AGENT} !^.*(Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile|iPhone|iPod|KYOCERA/WX310K|LG/U990|MIDP-2.0|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|Playstation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|Windows\ CE|WinWAP).*
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(\w+(?:/\w+)*)/*$ /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
# RewriteCond %{HTTP_USER_AGENT} !^.*(Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile|iPhone|iPod|KYOCERA/WX310K|LG/U990|MIDP-2.0|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|Playstation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|Windows\ CE|WinWAP).*
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(\w+(?:/\w+)*)/*$ /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
</IfModule>
# END WPSuperCache

Basic modifications:

1) corrected regex pattern typo against REQUEST_METHOD;
2) corrected a lack of precision in the regex pattern against HTTP:Coockie, looking now for “wordpress_logged_in” rather than “wordpress”, left in the other cases (this should be bugfixed specifically, I did not replicate all use cases: only log in-log out);
3) commented out HTTP_USER_AGENT rule (I don’t see why mobile devices should be fed live data while desktops see the cached pages.. unless you need to give them a mobile-specific “supercached” file), left it there for who needs it: I tend to make one-size-fits-all websites unless mobile devices are a major share of the target audience;
4) corrected the regex pattern in the RewriteRule to strip out trailing slashes (I’ve noticed they are harmless on a UNIX server, but always better be more elegant than less).

Left to do:
I can not figure out why the hell the homepage is shown when I type the address to the public root (that is with NO REDIRECTION taking place at all).
This has been driving me nuts for the past few hours, and I’m sick of it so will leave it there for now. This means that your frontpage will be served through the Legacy WP Cache, which only marginally cuts the script footprint (in my case only 40% less than the uncached page).

..to be continued..

another error is on the user agent rule: it must be all upper case, like this: %{HTTP_USER_AGENT}, not %{HTTP_user_agent}

Ok, I have noticed three problems in the rewrite rules:

1) RewriteCond %{REQUEST_METHOD} !=POST should be replaced with RewriteCond %{REQUEST_METHOD} !POST (it is a regex and does not need the “=” sign);

2) RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$ does not work (when a user logs out of wordpress, a cookie permains, making this rule fail). What is this intended for, is it to filter logged in users? As it is it does not work.

3) the paths do not work on my local machine. I was able to define a good path by trial and error with the help of mod_rewrite logs. Have to figure out how I can fix it for the MediaTemple (gs) path architecture too, without logs.

I confirm that on my local machine, commenting out the second issue and fixing the others, I got Super Cache working.
Will keep you posted.

For reference, I will append the log info about the second issue:

RewriteCond: input='wordpress_test_cookie=WP+Cookie+check; wp-settings-1=m0%3Do%26m1%3Dc%26m2%3Dc%26m3%3Dc%26m4%3Dc%26m5%3Dc%26m6%3Dc%26m7%3Do%26m8%3Do%26align%3Dnone%26urlbutton%3Durlpost%26imgsize%3Dfull; wp-settings-time-1=1250760657' pattern='!^.*(comment_author_|wordpress|wp-postpass_).*$' => not-matched

I am having trouble debugging the rewrite rules, is there any tool you can point out?

I need to get this working.