[support-system-faqs]
Frequently Asked Questions
Things to Know Before Installing WordPress
Before you begin the install, there are a few things you need to have and do.
These are:
- Access to your web server (via FTP or shell)
- A text editor
- An FTP Client
- Your web browser of choice
Things You Need to Do to Install WordPress
Begin your installation by:
- Checking to ensure that you and your web host have the minimum requirements to run WordPress.
- Downloading the most current version of WordPress.
- Unzipping the downloaded file to a folder on your hard drive.
- Creating a secure password for your Secret Key
- Keeping this webpage open so you have it handy during the installation.
WordPress 5 Minute Install
Famous 5-Minute Install
Here’s the quick version of the instructions for those who are already comfortable with performing such installations. More detailed instructionsare below this 5 minute install.
If you are not comfortable with renaming files, step 3 is optional and you can skip it as the install program will create the wp-config.php file for you.
- Download and unzip the WordPress package if you haven’t already.
- Create a database for WordPress on your web server, as well as a MySQL (or MariaDB) user who has all privileges for accessing and modifying it.
- (Optional) Find and rename wp-config-sample.php to wp-config.php, then edit the file (see Editing wp-config.php) and add your database information.
- Upload the WordPress files to the desired location on your web server:
- If you want to integrate WordPress into the root of your domain (e.g. http://example.com/), move or upload all contents of the unzipped WordPress directory (excluding the WordPress directory itself) into the root directory of your web server.
- If you want to have your WordPress installation in its own subdirectory on your website (e.g. http://example.com/blog/), create the blog directory on your server and upload the contents of the unzipped WordPress package to the directory via FTP.
- Note: If your FTP client has an option to convert file names to lower case, make sure it’s disabled.
- Run the WordPress installation script by accessing the URL in a web browser. This should be the URL where you uploaded the WordPress files.
- If you installed WordPress in the root directory, you should visit: http://example.com/
- If you installed WordPress in its own subdirectory called blog, for example, you should visit: http://example.com/blog/
That’s it! WordPress should now be installed.
WordPress Detailed Instructions
Detailed Instructions
Step 1: Download and Extract
Download and unzip the WordPress package from https://wordpress.org/download/.
- If you will be uploading WordPress to a remote web server, download the WordPress package to your computer with a web browser and unzip the package.
- If you will be using FTP, skip to the next step – uploading files is covered later.
- If you have shell access to your web server, and are comfortable using console-based tools, you may wish to download WordPress directly to your web server using wget (or lynx or another console-based web browser) if you want to avoid FTPing:
- wget https://wordpress.org/latest.tar.gz
- Then unzip the package using:
tar -xzvf latest.tar.gz
The WordPress package will extract into a folder called wordpress in the same directory that you downloaded latest.tar.gz.
Step 2: Create the Database and a User
If you are using a hosting provider, you may already have a WordPress database set up for you, or there may be an automated setup solution to do so. Check your hosting provider’s support pages or your control panel for clues about whether or not you’ll need to create one manually.
If you determine that you’ll need to create one manually, follow the instructions for accessing phpMyAdmin on various servers, or follow the instructions for Using Plesk, Using cPanel or Using phpMyAdmin below.
If you are installing WordPress on your own web server, follow the Using phpMyAdmin or Using the MySQL Client instructions below to create your WordPress username and database.
If you have only one database and it is already in use, you can install WordPress in it – just make sure to have a distinctive prefix for your tables to avoid over-writing any existing database tables.
WordPress - Editing wp-config.php
Editing wp-config.php
One of the most important files in your WordPress installation is the wp-config.phpfile. This file is located in the root of your WordPress file directory and contains your website’s base configuration details, such as database connection information.
When you first download WordPress, the wp-config.php file isn?t included. The WordPress setup process will create a wp-config.php file for you based on the information you provide.
You can manually create a wp-config.php file by locating the sample file named “wp-config-sample.php” (located in the root install-directory), editing it as required, and then saving it as wp-config.php.
To change the wp-config.php file for your installation, you will need this information:
- Database Name
- Database Name used by WordPress
- Database Username
- Username used to access Database
- Database Password
- Password used by Username to access Database
- Database Host
- The hostname of your Database Server. A port number, Unix socket file path or pipe may be needed as well.
If your hosting provider installed WordPress for you, get the information from them. If you manage your own web server or hosting account, you will have this information as a result of creating the database and user.
Configure Database Settings
Important:never use a word processor like Microsoft Word for editing WordPress files!
Locate the file wp-config-sample.php
in the base directory of your WordPress directory and open in a text editor.
Default wp-config-sample.php
wp-config-sample.php
. The values here are examples to show you what to do. Do not change these details here by editing this page, change them on your web server. If you make changes here by using the edit button, they will not work and you will be showing your password details to the world.// ** 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' ); /** MySQL hostname */ define( 'DB_HOST', 'localhost' );
Set Database Name
Replace ‘database_name_here‘, with the name of your database, e.g. MyDatabaseName.
define( 'DB_NAME', 'MyDatabaseName' ); // Example MySQL database name
Set Database User
Replace ‘username_here‘, with the name of your username e.g. MyUserName.
define( 'DB_USER', 'MyUserName' ); // Example MySQL username
Set Database Password
Replace ‘password_here‘, with the your password, e.g. MyPassWord.
define( 'DB_PASSWORD', 'MyPassWord' ); // Example MySQL password
Set Database Host
Replace ‘localhost‘, with the name of your database host, e.g. MyDatabaseHost. A port number or Unix socket file path may be needed as well.
define( 'DB_HOST', 'MyDatabaseHost' ); // Example MySQL Database host
MySQL Alternate Port
If your host uses an alternate port number for your database you’ll need to change the DB_HOST value in the wp-config.php file to reflect the alternate port provided by your host.
For localhost:
define( 'DB_HOST', '127.0.0.1:3307' );
or in some cases:
define( 'DB_HOST', 'localhost:3307' );
For specified server:
define( 'DB_HOST', 'mysql.example.com:3307' );
Replace 3307 with whatever port number your host gives you.
MySQL Sockets or Pipes
If your host uses Unix sockets or pipes, adjust the DB_HOST value in the wp-config.php file accordingly.
define( 'DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock' ); // or define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' ); // or define( 'DB_HOST', 'example.tld:/var/run/mysqld/mysqld.sock' );
Replace /var/run/mysqld/mysqld.sock with the socket or pipe information provided by your host.
Database character set
As of WordPress Version 2.2, DB_CHARSET was made available to allow designation of the database character set (e.g. tis620 for TIS620 Thai) to be used when defining the MySQL database tables.
The default value of utf8 (Unicode UTF-8) is almost always the best option. UTF-8 supports any language, so you typically want to leave DB_CHARSET at utf8 and use the DB_COLLATE value for your language instead.
This example shows utf8 which is considered the WordPress default value:
define( 'DB_CHARSET', 'utf8' );
There usually should be no reason to change the default value of DB_CHARSET. If your blog needs a different character set, please read Character Sets and Collations MySQL Supports for valid DB_CHARSET values.
Database collation
As of WordPress Version 2.2, DB_COLLATE was made available to allow designation of the database collation (i.e. the sort order of the character set). In most cases, this value should be left blank (null) so the database collation will be automatically assigned by MySQL based on the database character set specified by DB_CHARSET. Set DB_COLLATE to one of the UTF-8 values defined inUTF-8 character sets for most Western European languages.
The WordPress default DB_COLLATE value:
define( 'DB_COLLATE', '' );
UTF-8 Unicode General collation
define( 'DB_COLLATE', 'utf8_general_ci' );
UTF-8 Unicode Turkish collation
define( 'DB_COLLATE', 'utf8_turkish_ci' );
There usually should be no reason to change the default value of DB_COLLATE. Leaving the value blank (null) will insure the collation is automatically assigned by MySQL when the database tables are created.
If DB_COLLATE and DB_CHARSET do not exist in your wp-config.php file, DO NOT add either definition to yourwp-config.php file unless you read and understand Converting Database Character Sets. And you may be in need of a WordPress upgrade.
Security Keys
In Version 2.6, three (3) security keys, AUTH_KEY, SECURE_AUTH_KEY, and LOGGED_IN_KEY, were added to ensure better encryption of information stored in the user’s cookies. (These collectively replaced a single key introduced in Version 2.5.) In Version 2.7 a fourth key, NONCE_KEY, was added to this group. When each key was added, corresponding salts were added: AUTH_SALT,SECURE_AUTH_SALT, LOGGED_IN_SALT, and NONCE_SALT.
You don’t have to remember the keys, just make them long, random and complicated — or better yet, use the online generator. You can change these at any point in time to invalidate all existing cookies. This does mean that all users will have to login again.
Example (don’t use these!):
define( 'AUTH_KEY', 't`DK%X:>xy|e-Z(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@}IcnCa|' ); define( 'SECURE_AUTH_KEY', 'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj' ); define( 'LOGGED_IN_KEY', 'MGKi8Br(&{H*~&0s;{k0<S(O:+f#WM+q|npJ-+P;RDKT:~jrmgj#/-,[hOBk!ry^' ); define( 'NONCE_KEY', 'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe' ); define( 'AUTH_SALT', '7T-!^i!0,w)L#JK@pc2{8XE[DenYI^BVf{L:jvF,hf}zBf883td6D;Vcy8,S)-&G' ); define( 'SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F }F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #' ); define( 'LOGGED_IN_SALT', 'w<$4c$Hmd%/*]`Oom>(hdXW|0M=X={we6;Mpvtg+V.o<$|#_}qG(GaVDEsn,~*4i' ); define( 'NONCE_SALT', 'a|#h{c5|P &xWs4IZ20c2&%4!c(/uG}W:mAvy<I44`jAbup]t=]V<`}.py(wTP%%' );
A secret key makes your site harder to hack and access harder to crack by adding random elements to the password.
In simple terms, a secret key is a password with elements that make it harder to generate enough options to break through your security barriers. A password like “password” or “test” is simple and easily broken. A random, unpredictable password such as “88a7da62429ba6ad3cb3c76a09641fc” takes years to come up with the right combination. A ‘salt is used to further enhance the security of the generated result.
The four keys are required for the enhanced security. The four salts are recommended, but are not required, because WordPress will generate salts for you if none are provided. They are included in wp-config.php by default for inclusiveness.
- WordPress Support Forum – HOWTO: Set up secret keys in WordPress
- Wikipedia’s explanation of Password Cracking
- Huffington Post – 17 Tips You Can Do Today to Protect Your Online Passwords
Advanced Options
The following sections may contain advanced / unsupported information, so please make sure you practice regular backups and know how to restore them before experimenting on a production installation.
table_prefix
The $table_prefix is the value placed in the front of your database tables. Change the value if you want to use something other than wp_ for your database prefix. Typically this is changed if you are installing multiple WordPress blogs in the same database.
// You can have multiple installations in one database if you give each a unique prefix. $table_prefix = 'r235_'; // Only numbers, letters, and underscores please!
A second blog installation using the same database can be achieved simply by using a different prefix than your other installations.
$table_prefix = 'y77_'; // Only numbers, letters, and underscores please!
WordPress address (URL)
WP_SITEURL, defined since WordPress Version 2.2, allows the WordPress address (URL) to be defined. The value defined is the address where your WordPress core files reside. It should include the http:// part too. Do not put a slash “/” at the end. Setting this value in wp-config.php overrides the wp_options table value for siteurl.
If WordPress is installed into a directory called “wordpress” for the domain example.com, define WP_SITEURL like this:
define( 'WP_SITEURL', 'http://example.com/wordpress' );
Dynamically set WP_SITEURL based on $_SERVER[‘HTTP_HOST’]
define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );
Dynamically set WP_SITEURL based on $_SERVER[‘SERVER_NAME’]
define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress' );
Blog address (URL)
WP_HOME is another wp-config.php option added in WordPress Version 2.2. Similar to WP_SITEURL, WP_HOME overrides thewp_options table value for home but does not change it permanently. home is the address you want people to type in their browser to reach your WordPress blog. It should include the http:// part and should not have a slash “/” at the end.
define( 'WP_HOME', 'http://example.com/wordpress' );
If you are using the technique described in Giving WordPress Its Own Directory then follow the example below. Remember, you will also be placing an index.php in your web-root directory if you use a setting like this.
define( 'WP_HOME', 'http://example.com' );
Dynamically set WP_HOME based on $_SERVER[‘HTTP_HOST’]
define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );
Moving wp-content folder
Since Version 2.6, you can move the wp-content directory, which holds your themes, plugins, and uploads, outside of the WordPress application directory.
Set WP_CONTENT_DIR to the full local path of this directory (no trailing slash), e.g.
define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/blog/wp-content' );
Set WP_CONTENT_URL to the full URI of this directory (no trailing slash), e.g.
define( 'WP_CONTENT_URL', 'http://example/blog/wp-content' );
Moving plugin folder
Set WP_PLUGIN_DIR to the full local path of this directory (no trailing slash), e.g.
define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/blog/wp-content/plugins' );
Set WP_PLUGIN_URL to the full URI of this directory (no trailing slash), e.g.
define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins' );
If you have compability issues with plugins Set PLUGINDIR to the full local path of this directory (no trailing slash), e.g.
define( 'PLUGINDIR', dirname(__FILE__) . '/blog/wp-content/plugins' );
Moving themes folder
You cannot move the themes folder because its path is hardcoded relative to the wp-content folder:
$theme_root = WP_CONTENT_DIR . '/themes';
However, you can register additional theme directories using register_theme_directory.
See how to move the wp-content folder. For more details how the themes folder is determined, see wp-includes/theme.php
.
Moving uploads folder
Set UPLOADS to:
define( 'UPLOADS', 'blog/wp-content/uploads' );
This path can not be absolute. It is always relative to ABSPATH, therefore does not require a leading slash.
Modify AutoSave Interval
When editing a post, WordPress uses Ajax to auto-save revisions to the post as you edit. You may want to increase this setting for longer delays in between auto-saves, or decrease the setting to make sure you never lose changes. The default is 60 seconds.
define( 'AUTOSAVE_INTERVAL', 160 ); // Seconds
Post Revisions
WordPress, by default, will save copies of each edit made to a post or page, allowing the possibility of reverting to a previous version of that post or page. The saving of revisions can be disabled, or a maximum number of revisions per post or page can be specified.
Disable Post Revisions
If you do not set this value, WordPress defaults WP_POST_REVISIONS to true (enable post revisions). If you want to disable the awesome revisions feature, use this setting:
define( 'WP_POST_REVISIONS', false );
Note: Some users could not get this to function until moving the command to the first line under the initial block comment in config.php.
Specify the Number of Post Revisions
If you want to specify a maximum number of revisions, change false to an integer/number (e.g., 3 or 5).
define( 'WP_POST_REVISIONS', 3 );
Note: Some users could not get this to function until moving the command to the first line under the initial block comment in config.php.
Set Cookie Domain
The domain set in the cookies for WordPress can be specified for those with unusual domain setups. One reason is if subdomains are used to serve static content. To prevent WordPress cookies from being sent with each request to static content on your subdomain you can set the cookie domain to your non-static domain only.
define( 'COOKIE_DOMAIN', 'www.askapache.com' );
Enable Multisite / Network Ability
WP_ALLOW_MULTISITE is a feature introduced in WordPress Version 3.0 to enable multisite functionality previously achieved through WordPress MU. If this setting is absent from wp-config.php it defaults to false.
define( 'WP_ALLOW_MULTISITE', true );
Redirect Nonexistent Blogs
NOBLOGREDIRECT can be used to redirect the browser if the visitor tries to access a nonexistent blog.
E.g., http://nonexistent.example.com or http://example.com/nonexistent/.
define( 'NOBLOGREDIRECT', 'http://example.com' );
Debug
The WP_DEBUG option, added in WordPress Version 2.3.1, controls the reporting of some errors and warnings and enables use of theWP_DEBUG_DISPLAY and WP_DEBUG_LOG settings. The default value is false.
define( 'WP_DEBUG', true ); define( 'WP_DEBUG', false );
Additionally, if you are planning on modifying some of WordPress’ built-in JavaScript or Cascading Style Sheets, you should add the following code to your config file:
define( 'SCRIPT_DEBUG', true );
Then the uncompressed versions of scripts and stylesheets in wp-includes/js, wp-includes/css, wp-admin/js, and wp-admin/css will be loaded instead of the .min.css and .min.js versions.
In WordPress versions since 2.3.2, database errors are printed only if WP_DEBUG is set to true. In earlier versions, database errors were always printed. (Database errors are handled by the wpdb class and are not affected by PHP’s error settings.)
Disable Javascript Concatenation
To result in a faster administration area, all Javascript files are concatenated into one URL. If Javascript is failing to work in your administration area, you can try disabling this feature:
define( 'CONCATENATE_SCRIPTS', false );
Configure Error Logging
Configuring error logging can be a bit tricky. First of all, default PHP error log and display settings are set in the php.ini file, which you may or may not have access to. If you do, they should be set to the desired settings for live PHP pages served to the public. It’s strongly recommended that no error messages are displayed to the public and instead routed to an error log. Further more, error logs should not be located in the publicly accessible portion of your server. Sample recommended php.ini error settings:
error_reporting = 4339 display_errors = Off display_startup_errors = Off log_errors = On error_log = /home/example.com/logs/php_error.log log_errors_max_len = 1024 ignore_repeated_errors = On ignore_repeated_source = Off html_errors = Off
About Error Reporting 4339
This is a custom value that only logs issues that affect the functioning of your site, and ignores things like notices that may not even be errors. See PHP Error Constants for the meaning of each binary position for 1000011110011, which is the binary number equal to 4339. The far left 1 means report any E_RECOVERABLE_ERROR. The next 0 means do not report E_STRICT, (which is thrown when sloppy but functional coding is used) and so on. Feel free to determine your own custom error reporting number to use in place of 4339.
Obviously, you will want different settings for your development environment. If your staging copy is on the same server, or you don’t have access to php.ini, you will need to override the default settings at run time. It’s a matter of personal preference whether you prefer errors to go to a log file, or you prefer to be notified immediately of any error, or perhaps both. Here’s an example that reports all errors immediately that you could insert into your wp-config.php file:
@ini_set( 'log_errors', 'Off' ); @ini_set( 'display_errors', 'On' ); define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', false ); define( 'WP_DEBUG_DISPLAY', true );
Because wp-config.php is loaded for every page view not loaded from a cache file, it is an excellent location to set php.ini settings that control your php installation. This is useful if you don’t have access to a php.ini file, or if you just want to change some settings on the fly. One exception is ‘error_reporting’. When WP_DEBUG is defined as true, ‘error_reporting’ will be set to E_ALL by WordPress regardless of anything you try to set in wp-config.php. If you really have a need to set ‘error_reporting’ to something else, it must be done after wp-settings.php is loaded, such as in a plugin file.
If you turn on error logging, remember to delete the file afterwards, as it will often be in a publicly accessible location, where anyone could gain access to your log.
Here is an example that turns php error_logging on and logs them to a specific file. If WP_DEBUG is defined to true, the errors will also be saved to this file. Just place this above any require_once or include commands.
@ini_set( 'log_errors', 'On' ); @ini_set( 'display_errors', 'Off' ); @ini_set( 'error_log', '/home/example.com/logs/php_error.log' ); /* That's all, stop editing! Happy blogging. */
Another example of logging errors, as suggested by Mike Little.
/** * This will log all errors notices and warnings to a file called debug.log in * wp-content (if Apache does not have write permission, you may need to create * the file first and set the appropriate permissions (i.e. use 666) ) */ define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
A refined version from Mike Little.
/** * This will log all errors notices and warnings to a file called debug.log in * wp-content only when WP_DEBUG is true. if Apache does not have write permission, * you may need to create the file first and set the appropriate permissions (i.e. use 666). */ define( 'WP_DEBUG', true ); // Or false if ( WP_DEBUG ) { define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 ); }
Confusing the issue is that WordPress has 3 constants that look like they could do the same thing. First off, remember that ifWP_DEBUG is false, it and the other two WordPress DEBUG constants do not do anything. The PHP directives, whatever they are, will prevail. Except for ‘error_reporting’, WordPress will set this to 4983 if WP_DEBUG is defined as false. Second, even if WP_DEBUG istrue, the other constants only do something if they too are set to true. If they are set to false, the PHP directives remain unchanged. For example, if your php.ini file has the directive display_errors = On, but you have the statement define( 'WP_DEBUG_DISPLAY', false ); in your wp-config.php file, errors will still be displayed on screen even though you tried to prevent it by setting WP_DEBUG_DISPLAY to false because that is the PHP configured behavior. This is why it’s very important to set the PHP directives to what you need in case any of the related WP constants are set to false. To be safe, explicitly set/define both types.
For your public, production WordPress installation, you might consider placing the following in your wp-config.php file, even though it may be partly redundant:
@ini_set( 'log_errors', 'On' ); @ini_set( 'display_errors', 'Off' ); define( 'WP_DEBUG', false ); define( 'WP_DEBUG_LOG', false ); define( 'WP_DEBUG_DISPLAY', false );
The default debug log file is /wp-content/debug.log. Placing error logs in publicly accessible locations is a security risk. Ideally, your log files should be placed above you site’s public root directory. If you can’t do this, at the very least, set the log file permissions to 600 and add this entry to the .htaccess file in the root directory of your WordPress installation:
<Files debug.log> Order allow,deny Deny from all </Files>
This prevents anyone from accessing the file via HTTP. You can always view the log file by retrieving it from your server via FTP.
Increasing memory allocated to PHP
Also released with Version 2.5, the WP_MEMORY_LIMIT option allows you to specify the maximum amount of memory that can be consumed by PHP. This setting may be necessary in the event you receive a message such as “Allowed memory size of xxxxxx bytes exhausted”.
This setting increases PHP Memory only for WordPress, not other applications. By default, WordPress will attempt to increase memory allocated to PHP to 40MB (code is at the beginning of /wp-includes/default-constants.php) for single site and 64MB for multisite, so the setting in wp-config.php should reflect something higher than 40MB or 64MB depending on your setup.
WordPress will automatically check if PHP has been allocated less memory than the entered value before utilizing this function. For example, if PHP has been allocated 64MB, there is no need to set this value to 64M as WordPress will automatically use all 64MB if need be.
Please note, this setting may not work if your host does not allow for increasing the PHP memory limit–in that event, contact your host to increase the PHP memory limit. Also, note that many hosts set the PHP limit at 8MB.
Increase PHP Memory to 64MB
define( 'WP_MEMORY_LIMIT', '64M' );
Increase PHP Memory to 96MB
define( 'WP_MEMORY_LIMIT', '96M' );
Administration tasks require much memory than usual operation. When in the administration area, the memory can be increased or decreased from the WP_MEMORY_LIMIT by defining WP_MAX_MEMORY_LIMIT.
define( 'WP_MAX_MEMORY_LIMIT', '256M' );
Please note, this has to be put before wp-settings.php inclusion.
Cache
The WP_CACHE setting, if true, includes the wp-content/advanced-cache.php script, when executing wp-settings.php.
define( 'WP_CACHE', true );
Custom User and Usermeta Tables
CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE are used to designate that the user and usermeta tables normally utilized by WordPress are not used, instead these values/tables are used to store your user information.
define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' ); define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );
Note that even when you set the ‘CUSTOM_USER_META_TABLE’, a usermeta table is still created for each database with the corresponding permissions for each instance. By default, the WordPress installer will add permissions for the first user (ID #1). You also need to manage permissions to each of the site via a plugin or custom function. If this isn’t setup you’ll experience permission errors and log-in issues.
When using CUSTOM_USER_TABLE during initial setup it is easiest to: Setup your first instance of WordPress. The define statements of the wp-config.php on the first instance pointing to where you currently store user data wp_users by default, and then copying that working wp-config.php to your next instance which will only require you to change the $table_prefix = variable. At this point the install will run as expected; however, do not use an e-mail address that is already in use by your original install. Use a different e-mail address. Once you have finished the setup process log in with the auto generated admin account and password. Then promote your normal account to the administrator level. Log out of admin. Log in as yourself. Delete the admin account and promote the other user accounts as is needed.
Language and Language Directory
WordPress Version 4.0 allows you to change the language in your WordPress Administration Screens.
WordPress v4 and above
Change the language in the admin settings screen. Go to Settings > General and select Site Language.
Save queries for analysis
The SAVEQUERIES definition saves the database queries to an array and that array can be displayed to help analyze those queries. The information saves each query, what function called it, and how long that query took to execute.
First, put this in wp-config.php:
define( 'SAVEQUERIES', true );
Then in the footer of your theme put this:
<?php if ( current_user_can( 'administrator' ) ) { global $wpdb; echo "<pre>"; print_r( $wpdb->queries ); echo "</pre>"; } ?>
Override of default file permissions
The FS_CHMOD_DIR and FS_CHMOD_FILE define statements allow override of default file permissions. These two variables were developed in response to the problem of the core update function failing with hosts running under suexec. If a host uses restrictive file permissions (e.g. 400) for all user files, and refuses to access files which have group or world permissions set, these definitions could solve the problem. Note that the ‘0755′ is an octal value. Octal values must be prefixed with a 0 and are not delineated with single quotes (‘). See Also: Changing File Permissions
define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) ); define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );
Example to provide setgid:
define( 'FS_CHMOD_DIR', ( 02755 & ~umask() ) );
WordPress Upgrade Constants
You should define as few of the below constants needed to correct your update issues.
The most common causes of needing to define these are:
- Host running with a special installation setup involving symlinks. You may need to define the path-related constants (FTP_BASE, FTP_CONTENT_DIR, and FTP_PLUGIN_DIR). Often defining simply the base will be enough.
- Certain PHP installations shipped with a PHP FTP extension which is incompatible with certain FTP servers. Under these rare situations, you may need to define FS_METHOD to “ftpsockets”.
The following are valid constants for WordPress updates:
- FS_METHOD forces the filesystem method. It should only be “direct”, “ssh2”, “ftpext”, or “ftpsockets”. Generally, you should only change this if you are experiencing update problems. If you change it and it doesn’t help, change it back/remove it. Under most circumstances, setting it to ‘ftpsockets’ will work if the automatically chosen method does not.
- (Primary Preference) “direct” forces it to use Direct File I/O requests from within PHP, this is fraught with opening up security issues on poorly configured hosts, This is chosen automatically when appropriate.
- (Secondary Preference) “ssh2” is to force the usage of the SSH PHP Extension if installed
- (3rd Preference) “ftpext” is to force the usage of the FTP PHP Extension for FTP Access, and finally
- (4th Preference) “ftpsockets” utilises the PHP Sockets Class for FTP Access.
- FTP_BASE is the full path to the “base”(ABSPATH) folder of the WordPress installation.
- FTP_CONTENT_DIR is the full path to the wp-content folder of the WordPress installation.
- FTP_PLUGIN_DIR is the full path to the plugins folder of the WordPress installation.
- FTP_PUBKEY is the full path to your SSH public key.
- FTP_PRIKEY is the full path to your SSH private key.
- FTP_USER is either user FTP or SSH username. Most likely these are the same, but use the appropriate one for the type of update you wish to do.
- FTP_PASS is the password for the username entered for FTP_USER. If you are using SSH public key authentication this can be omitted.
- FTP_HOST is the hostname:port combination for your SSH/FTP server. The default FTP port is 21 and the default SSH port is 22. These do not need to be mentioned.
- FTP_SSL TRUE for SSL-connection if supported by the underlying transport (not available on all servers). This is for “Secure FTP” not for SSH SFTP.
define( 'FS_METHOD', 'ftpext' ); define( 'FTP_BASE', '/path/to/wordpress/' ); define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' ); define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' ); define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' ); define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' ); define( 'FTP_USER', 'username' ); define( 'FTP_PASS', 'password' ); define( 'FTP_HOST', 'ftp.example.org' ); define( 'FTP_SSL', false );
Some configurations should set FTP_HOST to localhost to avoid 503 problems when trying to update plugins or WP itself.
Enabling SSH Upgrade Access
There are two ways to upgrade using SSH2.
The first is to use the SSH SFTP Updater Support plugin. The second is to use the built-in SSH2 upgrader, which requires the pecl SSH2 extension be installed.
To install the pecl SSH2 extension you will need to issue a command similar to the following or talk to your web hosting provider to get this installed:
pecl install ssh2
After installing the pecl ssh2 extension you will need to modify your php configuration to automatically load this extension.
pecl is provided by the pear package in most linux distributions. To install pecl in Redhat/Fedora/CentOS:
yum -y install php-pear
To install pecl in Debian/Ubuntu:
apt-get install php-pear
It is recommended to use a private key that is not pass-phrase protected. There have been numerous reports that pass phrase protected private keys do not work properly. If you decide to try a pass phrase protected private key you will need to enter the pass phrase for the private key as FTP_PASS, or entering it in the “Password” field in the presented credential field when installing updates.
Alternative Cron
Use this, for example, if scheduled posts are not getting published. According to Otto’s forum explanation, “this alternate method uses a redirection approach, which makes the users browser get a redirect when the cron needs to run, so that they come back to the site immediately while cron continues to run in the connection they just dropped. This method is a bit iffy sometimes, which is why it’s not the default.”
define( 'ALTERNATE_WP_CRON', true );
Disable Cron and Cron Timeout
Disable the cron entirely by setting DISABLE_WP_CRON to true.
define( 'DISABLE_WP_CRON', true );
Make sure a cron process cannot run more than once every WP_CRON_LOCK_TIMEOUT seconds.
define( 'WP_CRON_LOCK_TIMEOUT', 60 );
Additional Defined Constants
Here are additional constants that can be defined, but probably shouldn’t be. The Cookie definitions are particularly useful if you have an unusual domain setup.
define( 'COOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'home' ) . '/' ) ); define( 'SITECOOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'siteurl' ) . '/' ) ); define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' ); define( 'PLUGINS_COOKIE_PATH', preg_replace( '|https?://[^/]+|i', '', WP_PLUGIN_URL ) ); define( 'TEMPLATEPATH', get_template_directory() ); define( 'STYLESHEETPATH', get_stylesheet_directory() );
Empty Trash
Added with Version 2.9, this constant controls the number of days before WordPress permanently deletes posts, pages, attachments, and comments, from the trash bin. The default is 30 days:
define( 'EMPTY_TRASH_DAYS', 30 ); // 30 days
To disable trash set the number of days to zero. Note that WordPress will not ask for confirmation when someone clicks on “Delete Permanently”.
define( 'EMPTY_TRASH_DAYS', 0 ); // Zero days
Automatic Database Optimizing
Added with Version 2.9, there is automatic database optimization support, which you can enable by adding the following define to your wp-config.php file only when the feature is required
define( 'WP_ALLOW_REPAIR', true );
The script can be found at {$your_site}/wp-admin/maint/repair.php
Please Note: That this define enables the functionality, The user does not need to be logged in to access this functionality when this define is set. This is because its main intent is to repair a corrupted database, Users can often not login when the database is corrupt.
Do not upgrade global tables
A DO_NOT_UPGRADE_GLOBAL_TABLES define prevents dbDelta() and the upgrade functions from doing expensive queries against global tables.
Sites that have large global tables (particularly users and usermeta), as well as sites that share user tables with bbPress and other WordPress installs, can prevent the upgrade from changing those tables during upgrade by definingDO_NOT_UPGRADE_GLOBAL_TABLES. Since an ALTER, or an unbounded DELETE or UPDATE, can take a long time to complete, large sites usually want to avoid these being run as part of the upgrade so they can handle it themselves. Further, if installations are sharing user tables between multiple bbPress and WordPress installs it maybe necessary to want one site to be the upgrade master.
define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );
View All Defined Constants
Php has a function that returns an array of all the currently defined constants with their values.
print_r( @get_defined_constants() );
Disable the Plugin and Theme Editor
Occasionally you may wish to disable the plugin or theme editor to prevent overzealous users from being able to edit sensitive files and potentially crash the site. Disabling these also provides an additional layer of security if a hacker gains access to a well-privileged user account.
define( 'DISALLOW_FILE_EDIT', true );
Please note: the functionality of some plugins may be affected by the use of current_user_can('edit_plugins') in their code. Plugin authors should avoid checking for this capability, or at least check if this constant is set and display an appropriate error message. Be aware that if a plugin is not working this may be the cause.
Disable Plugin and Theme Update and Installation
This will block users being able to use the plugin and theme installation/update functionality from the WordPress admin area. Setting this constant also disables the Plugin and Theme editor (i.e. you don’t need to set DISALLOW_FILE_MODS and DISALLOW_FILE_EDIT, as on its own DISALLOW_FILE_MODS will have the same effect).
define( 'DISALLOW_FILE_MODS', true );
Require SSL for Admin and Logins
Note: WordPress Version 4.0 deprecated FORCE_SSL_LOGIN. Please use FORCE_SSL_ADMIN.
FORCE_SSL_ADMIN is for when you want to secure logins and the admin area so that both passwords and cookies are never sent in the clear. See also Administration_Over_SSL for more details.
define( 'FORCE_SSL_ADMIN', true );
Block External URL Requests
Block external URL requests by defining WP_HTTP_BLOCK_EXTERNAL as true and this will only allow localhost and your blog to make requests. The constant WP_ACCESSIBLE_HOSTS will allow additional hosts to go through for requests. The format of the WP_ACCESSIBLE_HOSTS constant is a comma separated list of hostnames to allow, wildcard domains are supported, eg *.wordpress.org will allow for all subdomains of wordpress.org to be contacted.
define( 'WP_HTTP_BLOCK_EXTERNAL', true ); define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );
Disable WordPress Auto Updates
# Disable all automatic updates: define( 'AUTOMATIC_UPDATER_DISABLED', true );
Disable WordPress Core Updates
The easiest way to manipulate core updates is with the WP_AUTO_UPDATE_CORE constant:
# Disable all core updates: define( 'WP_AUTO_UPDATE_CORE', false ); # Enable all core updates, including minor and major: define( 'WP_AUTO_UPDATE_CORE', true ); # Enable core updates for minor releases (default): define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Reference: Disabling Auto Updates in WordPress 3.7
Cleanup Image Edits
By default, WordPress creates a new set of images every time you edit an image and when you restore the original, it leaves all the edits on the server. Defining IMAGE_EDIT_OVERWRITE as true changes this behaviour. Only one set of image edits are ever created and when you restore the original, the edits are removed from the server.
define( 'IMAGE_EDIT_OVERWRITE', true );
Double Check Before Saving
Be sure to check for leading and/or trailing spaces around any of the above values you entered, and DON’T delete the single quotes!
Before you save the file, be sure to double-check that you have not accidentally deleted any of the single quotes around the parameter values. Be sure there is nothing after the closing PHP tag in the file. The last thing in the file should be ?> and nothing else. No spaces.
To save the file, choose File > Save As > wp-config.php and save the file in the root of your WordPress install. Upload the file to your web server and you’re ready to install WordPress.
Why we don't recommend Hosting
Why we don’t recommend hosting.
We don’t like Not recommending our competition as it’s not polite, so we decided, with good reason, to not recommend anyone.
Our hosting does not appear in any top 10 WordPress hosting list we can find because we do not have an affiliate program, the reason we don’t offer an affiliate program is we would rather our customers speak for us, not a blogger being paid to speak for us.
We did however manually check a top 10 recommended web hosting companies claims of who the trusted brands they hosted are.
Of the 36 companies they listed only Four, YES FOUR, Actually Host with them.
To read the entire article see Here
Managed WordPress vs Linux Cloud Server
Managed WordPress vs Linux Cloud Server
When Web Hosting 4 Business was created we set up our Linux system to be specifically suited to hosting WordPress CMS websites, because we Love WordPress. We knew we had created a solid base for our customers to utilise the CMS to it’s optimum performance level while maintaining all of the benefits of a standard Linux set up. The proof of succeeding in our goal was in the load speed of our clients websites, which is now 20% of your Google score.
We always assumed that a Managed WordPress hosting solution was going to be quicker than ours at loading a WordPress site but that the small loss of speed outweighed the advantage of our clients having full control and no Limitations on what software they could and couldn’t run. (subject to our Google Clause*)
We recently ran a test comparing a site hosted on a top 10 Managed WordPress Host vs a site hosted on our Linux Cloud Server that has been designed and set up specifically for WordPress while maintaining all the functionality and freedom of a cloud server space.
To be honest we were expecting to get our face wiped in the dirt, then something unexpected happened.
We Won. Not only did we win on speed but we actually wiped there face in regards to compliance and Performance Grade.
For the test we randomly chose a client from there displayed list and the client from our client list with the largest Home page. We then ran a speed test on pingdom within 10 seconds of each other at 11:30 PM so as to ensure a light internet load. Both sites were tested from Stockholm, Sweden.
The Managed WordPress Host:
Our Linux custom solution:
They say a Picture is worth a 1000 words.
Webhosting 4 Business and WP Support Services are Proud to be able to say that our custom Linux cloud hosting solution really is the best place for WordPress Based Website.
Does server speed actually make a difference?
We recently had a brilliant opportunity to prove that server speed makes a massive difference to your site and it’s overall success in search engine rankings.
We had just built a new responsive site for a Graphic Design company based in the UK with operations in India. The client had acquired a new .london domain and wanted the new site, which would be hosted by W4B, to also be uploaded to there US servers run by the hosting company that had been there web host for years.
This gave us a unique opportunity to compare the identical site on two separate platforms. The .london on our servers and the .com on there US based servers.
The sites are absolutely identical down to the last piece of custom css.
Utilising the Pingdom Website Speed Test we tested both sites from
The .london site is hosted on our hi speed servers based in Manchester, England and the .com site is on a server in Houston, Texas.
As the company is based in the UK we tested Amsterdam 1st.
As you can see the difference in load speed is rather dramatic, but we also scored 11 points higher in performance and our delivery system made the packet a full 1 mb smaller.
For the full report including all the cities and full screen shots of the tests Read More
Search Engines and Server Speed
Introduction
The challenge of a search engine is to provide the most relevance to its users.
Website response speed helps search engines to assess the site’s relevance because speed is one of the criteria recognised in a successful site.
If a more powerful, faster server is used, the site loads more quickly and is rewarded by being moved higher in a the search engines’s displayed results.
As of September 2015 a Wikipedia survey showed that 67.49 per cent of all world wide searches are made on Google.
That’s 1,100,000,000 people using Google per day, so if your website is not listed on the search engine, you can guarantee people aren’t looking at it.
What affects SEO?
Search engines place weight on several other factors when it comes to ranking the importance of sites.
The web servers should respond quickly for the best SEO results so as not to interfere with a search engine’s crawling.
Because search engines reward sites for giving good customer experience, server speed and a quick web response time can really help businesses when it comes to SEO.
This is because a fast response time offers visitors a good internet experience.
A fast web server allows a site to be indexed faster and updated more frequently by search engine spiders and robots.
So businesses and organisations should look for a server of a higher specification with excellent connectivity to host their websites.
Before a business invests in a server it is important to research the hosting provider to make sure they are able to provide the high quality hardware and speed necessary for effective SEO.
Because server speed and SEO are intrinsically connected, the more a business invests in its server, the higher in the search engines it will go. A well marketed, extremely visible site brings in more visitors and when a site handles more visitors or traffic, search engines see it as being an important site and reward it.
Additionally, when a site is visible to more people, in all likelihood the business sales will increase and the company’s brand will be promoted.
Search engine popularity: an overview
Although different search engines work in slightly different ways, in essence what they do is trawl the internet looking for relevant information to feed back to the searcher.
There are a plethora of search engines available to web users.
Google is the world’s most popular search engine, with a market share of 67.49 percent as of August, 2017. Yahoo! comes in at second place.
The world’s most popular search engines are:*
Search engine | Market share in August 2017 | |
---|---|---|
67.49% | ||
Yahoo! | 10.77% | |
Bing | 10.67% | |
Baidu | 8.13% | |
AOL | 1.08% | |
Ask | 0.21% | |
Lycos | 0.01% |
*Wikipedia
In the UK, Google handles even more of the market share.
This statistic shows the leading search engines in the United Kingdom (UK) ranked by market share for the twelve months to July 2017.
Google was the most popular search engine during the year, with a Massive 83.49 percent share of the search market.
.Other search engines don’t come close with Yahoo operating at a mere 3.56%.
Rank | Search Engine | Volume | |||
1 | 83.49% | ||||
2 | Bing | 11.06% | |||
3 | yahoo | 3.83% | |||
4 | ask | 0.19% |
*Source statista.com.
Your Google Ranking
The following information has been provided by Google:
1. How does load time affect my landing page quality?
You are able to see a grade for your landing page’s load time in your AdWords account. “Load time” refers to the amount of time it takes for a user to view your landing page after clicking your ad. Several weeks after your load time grade becomes visible, it will begin to impact your landing page quality and, therefore, your Quality Score. We recommend working to improve your load time during this interim if it’s received a low score.
2. Why is load time a factor?
Users value ads that bring them to the information they want as efficiently as possible. A high-quality landing page should have a fast load time as well as feature unique, relevant content. Fast load times also benefit advertisers because users are less likely to abandon a site that loads quickly.
3. How is my load time graded?
Each of your keywords will receive a load time grade based on the average load time of the landing pages in the ad group and of any landing pages in the rest of the account with the same domain. If multiple ad groups have landing pages with the same domain, therefore, the keywords in all these ad groups will have identical load time grades. When determining load time grade, the AdWords system follows destination URLs at both the ad and keyword level and evaluates the final landing page. If your ad group contains landing pages with different domains, the keywords load time grades will be based on the domain with the slowest load time. All the keywords in an ad group will always have the same load time grade. Google evaluates your load time in relation to the average in your servers geographic region.If your website is hosted in India, your landing page load time will be compared to the average load time in that region, even if your website is intended for the UK.
4. How can I see if my load time is good or not?
If your keyword is graded “This page loads slowly” your landing page quality and Quality Score will be negatively affected. If your keyword is graded “No problems found” landing page quality and Quality Score will not be affected. One exception is if your keyword is graded “No problems found” and “Load time is faster than average” this may have a positive effect.
How can I improve my load time?
The AdWords system re-evaluates landing pages on a regular basis. If you make significant improvements to your landing page’s load time, you should see improved Quality Scores. Note that your Quality Score may update incrementally over a number of weeks after you improve your load time.
To improve your load time:
Use fewer and faster redirects
Don’t use interstitial pages (advertising pages before site content)
Compress the size of your page
WordPress - Version History
WordPress Release history
Main releases of WordPress are codenamed after well-known jazz musicians, starting after version 1.0.[37]
Version | Code name | Release date | Notes |
---|---|---|---|
0.7 | none | 27 May 2003[38] | Used the same file structure as its predecessor, b2/cafelog, and continued the numbering from its last release, 0.6.[39] Only 0.71-gold is available for download in the official WordPress Release Archive page. |
1.0 | Davis | 3 January 2004[40] | Added search engine friendly permalinks, multiple categories, dead simple installation and upgrade, comment moderation, XFN support, Atom support. |
1.2 | Mingus | 22 May 2004[41] | Added support of Plugins; which same identification headers are used unchanged in WordPress releases as of 2011. |
1.5 | Strayhorn | 17 February 2005[42] | Added a range of vital features, such as ability to manage static pages and a template/Theme system. It was also equipped with a new default template (code named Kubrick).[43] designed by Michael Heilemann. |
2.0 | Duke | 31 December 2005[44] | Added rich editing, better administration tools, image uploading, faster posting, improved import system, fully overhauled the back end, and various improvements to Plugin developers. |
2.1 | Ella | 22 January 2007[45] | Corrected security issues, redesigned interface, enhanced editing tools (including integrated spell check and auto save), and improved content management options. |
2.2 | Getz | 16 May 2007[46] | Added widget support for templates, updated Atom feed support, and speed optimizations. |
2.3 | Dexter | 24 September 2007[47] | Added native tagging support, new taxonomy system for categories, and easy notification of updates, fully supports Atom 1.0, with the publishing protocol, and some much needed security fixes. |
2.5 | Brecker | 29 March 2008[48] | Major revamp to the dashboard, dashboard widgets, multi-file upload, extended search, improved editor, improved plugin system and more. |
2.6 | Tyner | 15 July 2008[49] | Added new features that made WordPress a more powerful CMS: it can now track changes to every post and page and allow easy posting from anywhere on the web. |
2.7 | Coltrane | 11 December 2008[50] | Administration interface redesigned fully, added automatic upgrades and installing plugins, from within the administration interface. |
2.8 | Baker | 10 June 2009[51] | Added improvements in speed, automatic installing of themes from within administration interface, introduces the CodePress editor for syntax highlighting and a redesigned widget interface. |
2.9 | Carmen | 19 December 2009[52] | Added global undo, built-in image editor, batch plugin updating, and many less visible tweaks. |
3.0 | Thelonious | 17 June 2010[53] | Added a new theme APIs, merge WordPress and WordPress MU, creating the new multi-site functionality, new default theme “Twenty Ten” and a refreshed, lighter admin UI. |
3.1 | Reinhardt | 23 February 2011[54] | Added the Admin Bar, which is displayed on all blog pages when an admin is logged in, and Post Format, best explained as a Tumblr like micro-blogging feature. It provides easy access to many critical functions, such as comments and updates. Includes internal linking abilities, a newly streamlined writing interface, and many other changes. |
3.2 | Gershwin | 4 July 2011[55] | Focused on making WordPress faster and lighter. Released only four months after version 3.1, reflecting the growing speed of development in the WordPress community. |
3.3 | Sonny | 12 December 2011[56] | Focused on making WordPress friendlier for beginners and tablet computer users. |
3.4 | Green | 13 June 2012[57] | Focused on improvements to Theme customization, Twitter integration and several minor changes. |
3.5 | Elvin | 11 December 2012[58] | Support for the Retina Display, color picker, new default theme “Twenty Twelve”, improved image workflow. |
3.6 | Oscar | 1 August 2013[59] | New default theme “Twenty Thirteen”, admin enhancements, post formats UI update, menus UI improvements, new revision system, autosave and post locking. |
3.7 | Basie | 24 October 2013[60] | Automatically apply maintenance and security updates in the background, stronger password recommendations, support for automatically installing the right language files and keeping them up to date. |
3.8 | Parker | 12 December 2013[61] | Improved admin interface, responsive design for mobile devices, new typography using Open Sans, admin color schemes, redesigned theme management interface, simplified main dashboard, Twenty Fourteen magazine style default theme, second release using “Plugin-first development process”. |
3.9 | Smith | 16 April 2014[62] | Improvements to editor for media, live widget and header previews, new theme browser. |
4.0 | Benny | 4 September 2014[63] | Improved media management, embeds, writing interface, easy language change, theme customizer, plugin discovery and compatibility with PHP 5.5 and MySQL 5.6.[64] |
4.1 | Dinah | 18 December 2014[65] | Twenty Fifteen as the new default theme, distraction-free writing, easy language switch, Vine embeds and plugin recommendations. |
4.2 | Powell | 23 April 2015[66] | New “Press This” features, improved characters support, emoji support, improved customizer, new embeds and updated plugin system. |
4.3 | Billie | 18 August 2015[67] | Focus on mobile experience, better passwords and improved customizer. |