.htaccess and WordPress Admin Bar

I have a built a number of WordPress sites for clients and my usual practice is to keep all the WP stuff in a /wordpress/ directory at root level. However, I don’t like this directory appearing in the urls, so I simply omit it from the links and use .htaccess to reinsert it silently…

# If it's not a direct request for an existing file or directory,
# then add /wordpress/ at the start of every filepath unless it's there already

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !^\/wordpress\/.*
RewriteRule ^(.*)$ /wordpress/$1 [L,NE] 

(This is a manual edit to the .htaccess file at the root level of the site. The .htaccess file in the /wordpress/ directory implements the /%postname% permalink structure.)

This arrangement worked fine until the Admin Bar arrived (WordPress 3.1?). The problem I have now – on all these sites – is that the Admin Bar (on the front end for logged-in users) is only displayed if I manually reinsert “/wordpress/” into the url in the address bar of the browser.

http://www.hlbc.org.uk/wordpress/about – Admin Bar visible

http://www.hlbc.org.uk/about – Admin Bar not visible

I rather suspect that this is something to do with the WP_Rewrite object, but I haven’t yet attempted to wrestle with this.

Can anyone give me some pointers to help me understand what’s going on? Any help much appreciated. Thanks!


@Milo: Thanks. Didn’t know about that hack. But for ease of upgrades I’d prefer something that didn’t require messing with WP core files – and I’d still like to know why my system doesn’t work!

@Sean Lee: Nice try – and useful. Spent many hours fiddling with deregistering etc and am now convinced that it’s nothing to do with javascript, but rather that without /wordpress/ in the url, I’m not regarded as logged in at all. Is this likely to be a problem with COOKIEPATH perhaps?

@Milo: I’ll give that another look and maybe try it out on the next site I do. I was initially put off by the bit about having to edit the WP index.php file. But I suppose if it’s outside the \wordpress\ directory then it’s not likely to be overwritten when upgrading. Are the 2 active lines of code in it guaranteed never to change in future versions?

1 Answer
1

OK. It appears it was a cookie path problem.

I eventually solved it by adding @define( 'ADMIN_COOKIE_PATH', "https://wordpress.stackexchange.com/" ); to the start of wp-config.php – as suggested by AppFlak.

The vital clue came from monitoring the output of wp_parse_auth_cookie() under various states.

Thanks for the ideas, guys! Makes it a lot easier with extra brains on the case 🙂

Leave a Comment