WordPress Install for the Sex Worker (or anyone really)

If you are a sex worker, statistically speaking, chances are you are using a managed host to handle the system administration of your actual WordPress install. If that is what you want to do, trust your website to a third party that may not have your best interests in mind, this page is not for you. A lot of sex workers using managed WordPress hosting have their blogs vanish because of “policy violation” and I suspect with FOSTA/SESTA it will become more common.

It takes a little technical skill, or an associate with some technical skill, but running your own host (cheap, a $5.00 or $10.00 a month virtual host is sufficient) is what I recommend.

This page is some notes I am making for those who do wish to handle the system administration of their WordPress install themselves, or who wish to have someone they know handle it according to these instructions.

WordPress prides itself on a 5 minute install. That’s bullshit. WordPress seems to have a philosophy that it is okay to make things easier for hackers if it also makes things easier for users and still has appearance of being secure. I do not like that philosophy and find it to be a dangerous one to have. This page has some set up tips that will take longer than five minutes (though I could probably still do it in five… but I wouldn’t, rushing is how mistakes happen, so I might take ten minutes) but results in a safer install than following the WordPress instructions.

A table of contents will be created soon, and other stuff may be added to this page in the future.

Please note this page does NOT deal with web design concepts with WordPress. For that, I would recommend you contact Lynn from Phone Sex Secrets.

I am more of a technical backend guy than a beautiful design guy. As a technical backend guy I have never been fond of WordPress, the way it does things from a backend perspective is horrid. But it is the dominant Content Management System in Phonesex and there are several reasons why I suggest you probably should use it even though I despise it:

  • Lots of people that can help you build your brand are very familiar with WordPress.
  • Lots of people on the Internet in general and can help you figure out things are very familiar with WordPress.
  • When you want to do something special with your site, there probably already is a plugin that does it for you.
  • Learning new content management systems is time consuming. Many come and go, and when one you learned vanishes, you have to learn a new one. WordPress has been around a long time and is not likely to vanish anytime soon.

Unless you are a code geek with money to burn, WordPress is probably the best solution for your sex-work related website.

The technical issues, some of them can be fixed. Some of them can not be fixed, but some of them can be fixed. Fixing what can be fixed is a large part of why this blog exists.

So, for those who wish to run the WordPress administration themselves, this page is for you.

Pre-Install – Server Software

WordPress runs best in what is often called a “LAMP Stack” – Linux, Apache, MySQL, PHP.

For the Linux part, I personally recommend CentOS 7. Ubuntu and Fedora also work, but those distributions tend to prefer bleeding edge over stability. CentOS is a free clone of Red Hat Enterprise Linux (RHEL) and is designed for stability. But you can use Ubuntu or Fedora if you want.

For the Apache part, use the most recent stable from Apache 2.4.x. You want HTTP/2 support, it greatly speeds up your server response time.

For the MySQL part, I recommend MariaDB 10.1.x series or newer.

For the PHP part, I recommend PHP 7.1.x or 7.2.x or newer. There are many benefits in PHP 7 over PHP 5.6, and PHP 5.6 support will be dropped soon. Most of the instructions I write on tightening up the privacy and security of WordPress will be written for PHP 7.1.x or newer. They may work on 7.0.x but I do not test with 7.0.x.

If you are using a CentOS 7 virtual machine, I recommend installing the other three components from LibreLAMP. That is a project I personally maintain and have maintained for several years now.

Pre-Install – Database

WordPress requires MariaDB or MySQL for the database engine. MariaDB is what I recommend. The original developer of MySQL sold it to Oracle but did not like what Oracle was doing, so he forked it to create MariaDB. He could not maintain the name MySQL because Oracle owned it. In the context of this article, I will use MySQL because that is the terminology people are familiar with, but I recommend using MariaDB over MySQL if you have a choice. At this point, virtually every Linux distribution ships with MariaDB and is probably what you are using, even though the command name to access it is likely mysql.

Each WordPress install should have it’s own database separate from other databases on the host including separate from other WordPress installs on the same host.

WordPress only uses one database user. That is a design flaw. One database user means that user must be all powerful. All powerful means that when WordPress or a plugin installed within WordPress has an SQL Injection Vulnerability (abbreviated as SQLi), that vulnerability can be exploited for anything on any table within the database.

The best defense against SQLi attacks are prepared statements. WordPress does not use them. They have something in their database handler they call prepared statements, but that is a lie. They only emulate prepared statements, and furthermore, they do not force plugins to use that emulation and many do not.

So each WordPress install needs to have its own database so that when a plugin is vulnerable, the vulnerability can not be used to impact other WordPress instances on the same host.

The MySQL database by default is often not as secure as it could be, but a command exists to tighten it. You should run this command to lock it down:


It will prompt you for several things. Generally you want to just answer y (for yes) to everything it asks. If you already changed the administrator password for the database, you can answer n to that prompt.

The MySQL user that connects to that database should be unique to that database. As the MySQL administrator user:

create database whatever;

That command will create a database named whatever.

grant all privileges on whatever.* to 'bettyboop'@'localhost' identified by 'fsWehQQky#4g@3';

That command creates a database user named bettyboop with the password fsWehQQky#4g@3 who can connect from the localhost and do anything on the database whatever.

flush privileges;

That command lets reloads the MySQL grant table, so that user is active.

Please note you will never need to manually enter the password, it is needed for a configuration file only, so that WordPress itself can use the user name and password. Make it a good one that has both upper and lower case letters and special characters mixed in.

So now there is a database created that can be used.

Database Name: whatever
Database User: bettyboop
Database Password: fsWehQQky#4g@3

With those things we can configure the database.

Directory Permissions for WordPress Install

WordPress recommends you give the web server write access to everything in the wordpress folder. That is dangerous.

Part of the bad design I bitch about regarding WordPress, it has configuration files in the web server root. That is bad enough, but giving the web server write permission to those configuration files is just insane unless you are trying to make things easier for hackers.

There are some directories within the WordPress folder that the web server does need write access to. I do not like doing that, it is also a design flaw, but there really is not a way around it without completely rewriting WordPress core.

From a unix command line:

cd wp-content
[ ! -d uploads ] && mkdir uploads
[ ! -d upgrade ] && mkdir upgrade
sudo chown alice:apache plugins
sudo chmod 775 plugins
sudo chown alice:apache themes
sudo chmod 775 themes
sudo chown alice:apache uploads
sudo chmod 775 uploads
sudo chown alice:apache upgrade
sudo chmod 775 upgrade

Replace alice with your shell account username, and replace apache with the account the web server daemon runs as (which is apache on many Linux distributions, including CentOS).

What that does, it gives the web server write permission to the plugins and themes directories, which WordPress needs to install plugins and themes through the web interface, and it gives the web server write permission to the uploads directory, which is needed for uploading images and multimedia.

You do not absolutely have to give the web server write permission to the plugins and themes directory, but unless you want to manually install every theme and plugin and manually update every theme and plugin, then you do need to. If you have a dedicated system administrator, it should be their job to manually update themes and plugins and then you do not need to (note to dedicated system administrators who manage many installs – make yourself a dedicated git server so all you have to do to install a theme or plugin is run a git clone command, and to update a theme or plugin, issue a git pull command. I know many dedicated system administrators have not figured that out yet, so they instead do things the unsafe way).

WordPress Configuration File

In the root of your WordPress folder is a file called wp-config-sample.php. Copy that file to a file called wp-config.php and edit it.

The following changes will need to be made:

MySQL Settings

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');
/** MySQL database username */
define('DB_USER', 'username_here');
/** MySQL database password */
define('DB_PASSWORD', 'password_here');

That is where you enter the database name, the database user, and the user password that were created earlier.

Authentication Unique Keys and Salts

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

Those need to be unique to your WordPress install.

They need to be defined as salts that have a lot of entropy, they are used to define CSRF tokens and need to be impossible to brute-force guess.

This, btw, one of the design flaws of WordPress. These are very important salts, yet they are in a directory the web server has write permission to, meaning it is possible for a bug in WordPress to allow a hacker to modify what these salts are. Proper CSRF token generation uses a cryptographically secure pRNG (pseudo Random Number Generator) to generate a 128 bit (or larger) token and does not involve static salts. WordPress uses a predictable way to generate CSRF tokens that involves static salts that must be kept secure, and then generates tokens smaller than 128 bits.

My PluggableUnplugged WordPress plugin partially fixes the WordPress CSRF token generation, but not completely, so these salts need to be good.

To generate the salts, I have a standalone PHP script that you can use to generate quality salts on your system. You can download it here:


That will not modify the wp-config file for you, but it will generate high quality salts that you can have 100% certainty no one else has ever seen. To use it:

php mksalts.php

Just copy and paste the results into your configuration file. I do not understand why WordPress does not ship with a utility like that as part of core. Well, if they did CSRF tokens the right way, they would not need a utility but since they do it the wrong way, it is troubling that they do not provide a utility yet at the same time offer a remote website that can generate them – and possibly logs what IP addresses requested generation along with what was generated. Yes I am paranoid, but you get hacked less often when you are paranoid and act accordingly.

Note that whenever you change the salts, all logged-in users will have to log in again. So unless you know a hacker got your config file, do not change them except during system maintenance when the system is going to be down anyway.


WordPress does some things the wrong way, very wrong way. When you want to use the admin interface to install a plugin or theme, WordPress knows it has to have write access to the plugins and themes directories. But the way it checks is wrong. Instead of checking for write access to the actual directories it needs write access to, it checks to see if it has write access to the root directory.

That test should fail if you are set up securely, resulting in WordPress then asking you for an FTP password. I shit you not. One of the biggest rules in security is to very carefully guard your passwords, yet WordPress literally encourages people to enter them into a third-party form on a fucking web page.

To prevent it from doing this and allowing plugins and themes to be installed through the admin interface, add the following line to your wp-config file:

/** Direct FileSystem Access */
define('FS_METHOD', 'direct');

With that defined, WordPress will skip the check that fails and your web interface will be able to install and update plugins and themes.

It will not be able to update WordPress core, but updating WordPress core through a web interface really is too dangerous to allow.

Run the Web Based Installer

Now everything should be set up for you to start your web server and connect, where you will be prompted to create an admin username and password. Congratulations, WordPress is installed in a relatively safe manner.

Adult Content Labeling

If you run an adult content website, the responsible thing to do is send a label with your content so that parental content filters can block it. It is voluntary, but it is the right thing to do.


The gist is to a one file WordPress plugin that sends the header and adds the label to your WordPress generated web pages. Place it in your plugins directory and activate it, and your site will send the RTA header and have the RTA meta tag.

When following the link, just click the raw button to get the raw script.

Flower from Colorado

Because why not?

Pink flower

Anonymity protected with AWM Pluggable Unplugged