I'm working on a photography portfolio site. One page shows a bunch of thumbnails and one full-size image. Clicking on a thumbnail displays the full-size version of that image. I have been doing this with page refreshes but have decided to add Ajax capability.
The Ajax Javascript issues a GET with a URL something along the lines of:
The folioAjaxSvr.php script spits back some xml. And this all works fine.
Except ... if the site in question also hosts a Wordpress blog. This means the .htaccess file contains the following lines:
# BEGIN WordPress
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Now, as far as I can see, this should not cause a problem, because the !-f condition should come into play - after all, I'm requesting an actual file. But what happens is that, while the Ajax stuff still works, it takes a lo-o-o-ng time for the xml to be sent back - up to 20 seconds. If I click on another thumbnail, I get a shorter delay, but still fairly long, maybe 7 seconds (this is all happening across a LAN by the way, not the interweb). After that, the response is normal - unless I refresh the page, whereupon I get the initial delays again.
I've give the site plenty of memory (32M) for PHP scripts in php.ini.
If I comment-out the WordPress rules, no problems, so these rules are affecting the response somehow.
The Apache logs show no errors.
The fact that the delay reduces the second time and is gone by the third time suggests cacheing at work somewhere, but I've no idea where.
I tried doing something slightly different. I changed the URL sent by the Ajax script to this form:
And added this rule to .htaccess BEFORE the WordPress stuff:
RewriteRule ^folioAjaxSvr/imgdata/(.*)/(.*)/(.*)$ portfolioAjaxSvr.php?pm=imgdata&pdir=$1&img=$2&dir=$3 [L]
Still the same problem. Again, commenting-out the WordPress stuff makes the problem disappear even though, as I understand it, that [L] flag means the .htaccess script should stop there and never get to the WordPress rules.
Huh?
This might be some screwy problem with my own server, but I don't want to go through the process of uploading all this to the live server and find it's the same problem there.
I'd appreciate any suggestions as to where I start looking.
The Ajax Javascript issues a GET with a URL something along the lines of:
The folioAjaxSvr.php script spits back some xml. And this all works fine.
Except ... if the site in question also hosts a Wordpress blog. This means the .htaccess file contains the following lines:
# BEGIN WordPress
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Now, as far as I can see, this should not cause a problem, because the !-f condition should come into play - after all, I'm requesting an actual file. But what happens is that, while the Ajax stuff still works, it takes a lo-o-o-ng time for the xml to be sent back - up to 20 seconds. If I click on another thumbnail, I get a shorter delay, but still fairly long, maybe 7 seconds (this is all happening across a LAN by the way, not the interweb). After that, the response is normal - unless I refresh the page, whereupon I get the initial delays again.
I've give the site plenty of memory (32M) for PHP scripts in php.ini.
If I comment-out the WordPress rules, no problems, so these rules are affecting the response somehow.
The Apache logs show no errors.
The fact that the delay reduces the second time and is gone by the third time suggests cacheing at work somewhere, but I've no idea where.
I tried doing something slightly different. I changed the URL sent by the Ajax script to this form:
And added this rule to .htaccess BEFORE the WordPress stuff:
RewriteRule ^folioAjaxSvr/imgdata/(.*)/(.*)/(.*)$ portfolioAjaxSvr.php?pm=imgdata&pdir=$1&img=$2&dir=$3 [L]
Still the same problem. Again, commenting-out the WordPress stuff makes the problem disappear even though, as I understand it, that [L] flag means the .htaccess script should stop there and never get to the WordPress rules.
Huh?
This might be some screwy problem with my own server, but I don't want to go through the process of uploading all this to the live server and find it's the same problem there.
I'd appreciate any suggestions as to where I start looking.