WordPress – Enable wordpress to install content via vsftpd

Umask and final permissions that you need should add up to 777. Since you need 775 permissions, you need 777 - 775 = 002 as umask.

TLDR; It is not possible to obscure WordPress by only using directives in your .htaccess file.

Now cometh a tale of woe and horror. Our friend, fbh was right about the difficulty in hiding WordPress, it be not for yellow-bellied cowards. Arr! Here be the details of this (mis)adventure. Ye be warned!

Motivation

I'm one of those guys that likes things perfect. I will spend waste time over-engineering something to be the 'right way'. One of things I didn't like about the default WordPress setup was that a user could type in http://ex.com/wp-settings.php and then all this php jargon would spew all over the place. I eventually was able to turn off errors via PHP but that led to a greater desire to only have things that made since be locatable resources from the server...and that everything else would be 404/3'ified to our custom search page. After that I got this idea that I'd like to completely hide the underlying framework (i.e. WP)... anyways... if you want to hide WP it's possible. But it's really hard.

Steps to your doom

1. Modify your PHP ini settings appropriately. (i.e. turn display errors off) You might think this is unnecessary because if we're using .htaccess to reroute things, folks won't see errors because they can't access the error causing resources (I'm looking at you wp-settings.php). But errors could occur in displayed pages, so you definitely want them off. Just because WP_* directives are set doesn't necessarily mean that things will work the way you think they will. I found that on my server I had to set the display_errors to false FIRST, because WP_DISPLAY_ERRORS assumed that the default setting was false.

   Controlling PHP ini settings may be something as simple as putting a directive in your .htaccess file. Or, in my case, as complicated as creating a CGI handler and then putting a php.ini file there. YMMV depending on your set-up.

2. Remove all access to files/directories with wp- prefix. The idea is that your WP deployment is about your content, not about WP (unless it's specifically focused on WP). It doesn't make sense for people to want to see what http;//ex.com/wp-cron.php has... unless they're up to no-good. I accomplished this via this:

    # If the resource requested is a `wp-*` file or directory, poop to a 403. 
    RewriteCond %{REQUEST_FILENAME} wp-.*$ [NC] 
    RewriteCond %{ENV:REDIRECT_STATUS} ^$ 
    RewriteCond %{REQUEST_FILENAME} -f [NC,OR] 
    RewriteCond %{REQUEST_FILENAME} -d [NC] 
    RewriteRule .* - [F,L] 
   

3. Learn how to just pass through mordor By removing all access to wp-* you can no longer gain access to the administrative part of WP. That really sucks. In addition to that downer, you've just realized that you don't know what RewriteCond %{ENV:REDIRECT_STATUS} ^$ really does. Well, what I tried to do is to give myself a 'secret' backdoor to the WP admin page. I used this code:

    # If the resource requested is 'mordor' (with or without an ending
    # slash) do a URL rewrite to `wp-login.php`. 
    RewriteCond %{REQUEST_URI} mordor/?$ [NC]
    RewriteRule mordor/?$ /wp-login.php [NC,L]
   

   So the URL: http://ex.com/mordor should bring us to the login page. The reason why we had the REDIRECT line in the step above is that since this URL gets rewritten to a wp-* URL, we don't want the first rewrite rule to get it. Since it's being redirected internally, REDIRECT_STATUS will be set correctly and it won't push us to 403/4 land.

4. Remove wp-content Wordpress.stackexchange has a great article on removing wp-content. You have to redefine some WP constants and that pretty much works. You also have to redirect all accesses from wp-content to 'whatever-content`. This probably won't be an issue if this is a clean deployment. If you're modifying a pre-existing deployment you'll have to do some extra stuff.

5. Rewrite URLs to wp-content optional RewriteRule (.*)(wp-content)(.*) $1whatever-content$3 [NC,R,L]. This goes in your .htaccess file. If your user tries to access some old content via a wp-content URL, it will get redirected here.

6. Grep and replace all references to wp-content in your DB optional. You still have wp-content in your database. If you want to WP free you need to get rid of that stuff. I exported/mysql dumped my database, did a search and replace on the wp-content string to the new string. You might say... why do I have to do this if apache will rewrite my URLs? The problem is that the source code will contain these references so if you're really interested in obscuring WordPress, you need to do this. Note: At this point I should've just stopped and accepted the reality that this wasn't going to work. But I wanted Mr. T to pity me.

7. Replace all references to wp-includes and wp-admin in the source. A lot of the WordPress functionality depends on these two directories: wp-includes and wp-admin. This means these directory names are hardcoded in the source code. This means that you would have to create new directories (since PHP uses the underlying OS file system, not apache) to access these and then WRITES THESE OUT into the emitted html. This is just way too much trouble. I quickly gave up and went to the bathroom to take a poop.

Lesson

Sure, I could've just read http://codex.wordpress.org/Hardening_WordPress and followed those steps. But I wanted the perfect site. Now I just want all those hours back. The biggest thing that prevented me from stopping was that I didn't read anywhere on the internet that this was a lot of work and almost impossible to do. Instead I read of people trying to do it with no sense of if they were successful or not. So, to my past self, whom I will send this to via Apple's Time Machine, please don't try and obscure WordPress. It's not worth it.