## # Controlling WordPress' configurations

<br>

WordPress will not run anymore as there isn't an **index.php** in our public folder.

So we need to tell WordPress:

* where the themes are located
* where the plugins are located
* the new uploads directory

<br><br>

### # Pointing to the WordPress subfolder

We need to create a copy of the WordPress install **index.php** file so that it lives within the root of the public directory.

```
$ touch index.php
```

<br>

```
> public/index.php
```
```php
<?php
/**
 * Front to the WordPress application. This file doesn't do anything, but loads
 * wp-blog-header.php which does and tells WordPress to load the theme.
 *
 * @package WordPress
 */

/**
 * Tells WordPress to load the WordPress theme and output it.
 *
 * @var bool
 */
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . 'wordpress/wp-blog-header.php' );

```

<br><br>

### # Create a custom WP Config

If we were to setup the database and webserver, then go to our new WordPress website, we could start the famous "5 Minute Install". 

The problem is that it would ignore our unique folder structure. Hence, we need to manually create the `wp-config.php` file.

<br><br>

```
$ touch public/wp-config.php
```

> **Note:** this file is not included by default with WordPress downloads or even Composer install. So it has to be created,
either manually or using WordPress' famous "5 Minute Install".

<br><br>

#### Configure the database

```
> public/wp-config.php
```
```php
<?php

/**
 * Database name
 */
define('DB_NAME', 'wordpress');

/**
 * Database user
 */
define('DB_USER', 'root');

/**
 * Database user password
 */
define('DB_PASSWORD', 'root');

/**
 * Database host
 */
define('DB_HOST', 'localhost');

/**
 * WordPress DB Charset (is setup this way when the tables are made)
 */
define( 'DB_CHARSET', 'utf8' );

/**
 * WordPress DB Collation (is setup this way when the tables are made)
 */
define( 'DB_COLLATE', 'utf8_general_ci' );

```

<br><br>

#### Correcting the URLs

We access the WordPress admin through the `wp-admin/` folder. Hence, WP_SITEURL goes through the `/wordpress` route, whereas WP_HOME goes to the home domain.

```
> public/wp-config.php
```
```php
<?php

// >> add

/**
 * WordPress home URL (for the front-of-site)
 */
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '');

/**
 * WordPress site URL (which is for the admin)
 */
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/wordpress');
```

<br><br>

#### Custom content directories

Our **wp-content** directory is not within the Wordpress core folder, and neither is the plugins directory, so we have to manually set those.

Additionally, the themes folder is always relative to the WP_CONTENT_DIR, so we do not need to set the themes folder location.

```
> public/wp-config.php
```
```php
<?php

// > etc

/**
 * WordPress content directory
 */
define('WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content');

/**
 * WordPress plugins directory
 */
define('WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/plugins');

/**
 * WordPress content directory url
 */
define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/wp-content' );
```

<br><br>

#### Setting Up Error Logging

On production, we don't want error messages to leak out to the user, but we still want error logging on local or staging environments. On local, we may want to see all error logs on the screen:

```
> public/wp-config.php
```
```php
<?php

// >> etc

/**
 * Controls the error reporting. When true, it sets the error reporting level
 * to E_ALL. 
 */
define( 'WP_DEBUG', true );

/**
 * If error logging is enabled, this determines whether the error
 * is logged or not in the debug.log file inside /wp-content.
 */
define( 'WP_DEBUG_LOG', true );

/**
 * If error logging is enabled, this determines whether the error is
 * shown on the site (in-browser)
 */
define( 'WP_DEBUG_DISPLAY', true );

```

<br><br>

#### Stopping Users From Altering Themes & Plugins

Of course, now we are using Composer to install plugins and themes, we really don't want users being able to update, delete, or add any untested plugins and themes without going through the proper process.

It would not be helpful that our project on production contains code that a user has added that is not in our code base. Testing would be difficult, but more than that, tracking down bugs would take considerably longer.

```
> public/wp-config.php
```
```php
<?php

// > etc etc

/**
 * This disables live edits of theme and plugin files on the WordPress
 * administration area. It also prevents users from adding, 
 * updating and deleting themes and plugins.
 */
define( 'DISALLOW_FILE_MODS', true );

/**
 * Prevents WordPress core updates, as this is controlled through
 * Composer.
 */
define( 'WP_AUTO_UPDATE_CORE', false );
```

<br><br>

#### WordPress table prefix

The default for WordPress is to prefix each table name with **wp_**. Some have considered it a little extra
secure to change the table prefix to something random. However, the table prefix needs to be included here
regardless.

$table_prefix = 'wp_';

<br><br>

#### Authentication keys and salts

You can generate the salts on https://api.wordpress.org/secret-key/1.1/salt/. This adds an extra layer of security to some WordPress security actions. It already generates a salt in the database, but having them in the WP Config adds an extra layer of security.

```
> public/wp-config.php
```
```php
<?php

// > etc

/* Authentication Unique Keys and Salts. */
/* https://api.wordpress.org/secret-key/1.1/salt/ */
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' );

```

<br><br>

#### The absolute path to the WordPress directory

WordPress needs to load files starting from the public folder, not the root of the project.

```
> public/wp-config.php
```
```php
<?php

// > etc

/* Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/public');

/* Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

```

<br><br>

### # Finally, ensure routing is correct

You will need to log into the WordPress dashboard and **update the permalinks** there. This generates the .htaccess for public folder.