Site and WordPress installation Web address

 

As we discuss in Book VI, one of the most common template tags for use in
a theme is the bloginfo(); tag, which has several parameters you can use
to call different bits of information about your site (like the site name and
description, for example). You then can call in different theme template files
and graphics (or images) into your theme. For example, the URL of your Web
site can be defined in your template files with the following template tag:

 

<?php bloginfo(‘url’); ?> // Site URL

 

In Book VI, we cover template tags and parameters in detail.

 

That template tag tells WordPress to communicate with the site database,
locate the site URL, and return it back to the template or plugin file that’s
making that database call. You can greatly reduce the number of database calls
(thereby, speeding up your site) by defining the site URL in the wp-config.
php file by inserting the following two lines on their own lines (replacing
yourdomain.com with your actual domain name, of course):

 

define (‘WP_HOME’, ‘http://yourdomain.com’); // site address

define (‘WP_SITEURL’, ‘http://yourdomain.com’); // wordpress address

 

With these two lines in place in the wp-config.php file, whenever

WordPress comes across a template tag that requests your site URL, it won’t
need to reach out to your database to discover what that URL is because it’s
defined in the file structure within the wp-config.php file. This reduces
the number of calls to the database, which, in turn, reduces the resources
your site uses on the Web server to display your Web site to your visitors.

 

Read More

Post revisions, autosave, and trash handling

The Trash feature in WordPress gives you a safeguard against permanently
deleting posts by mistake. In Book IV, you find that you can send a post or a
page to the trash and that this action doesn’t permanently delete it; instead,
WordPress stores it in a virtual trash can. (Windows users can think of it
as the Recycle Bin.) You can visit the trash can any time and permanently

delete the post or page, or you can leave it there and WordPress automati-

cally empties the trash can every 30 days. If you want to adjust this time
interval, you can add the first line of code to force WordPress to empty the
trash weekly, or the second line to disable the trash feature, completely, as
follows (on its own line):

define(‘EMPTY_TRASH_DAYS’, 7); // empty trash weekly

define(‘EMPTY_TRASH_DAYS’, 0); // disable trash

 

Read More

Post revisions, autosave, and trash handling

You can also completely disable the default revision feature by adding this line to the wp-config.php file, on its own line:

define (‘WP_POST_REVISIONS’, false); // disable post revisions

WordPress creates these revisions through the Autosave feature. By default,

WordPress automatically saves a post revision every minute. If you take a
long time to write a post, you could rack up dozens of post revisions, which
are stored in the database and take up room. You can change the autosave
interval by adding this code to the wp-config.php file on its own line (this
code changes the autosave interval to 160 seconds, specifically — you can
choose any time interval you want):

define (‘AUTOSAVE_INTERVAL’, 160); // in seconds

Read More

Post revisions, autosave, and trash handling

WordPress autosaves revisions of your posts and pages, and you can send

posts and pages to the trash can, instead of completely deleting them. You

visit the trash can and permanently delete your posts or pages. This extra

step is a safeguard in case of mistakes.

In terms of the post revisions, by default, WordPress saves unlimited revi-

sions and sometimes, depending on how often you edit and reedit posts and
pages, the saved revision list can get pretty long. You can limit the number
of revisions that WordPress will save by adding the following line to the
wp-config.php file:

define (‘WP_POST_REVISIONS’, 3); // limit number of revisions to 3

 

Read More

Tweaking the configuration file for optimization

Adding a few bits of code to your wp-config.php file can change some of WordPress’s default behaviors and improve the speed at which your site loads. In this section, I describe a few of the most popular configuration tweaks.

 

Read More

Moving the wp-content directory

When you move the /wp-content folder, you need to define the new location in the wp-config.php file so that WordPress knows where to find those necessary files. You can define the new path to the /wp-content folder by adding these lines of code to the wp-config.php file (replacing newfolder with the name of the folder you just created):

define (‘WP_CONTENT_DIR’, $_SERVER[‘DOCUMENT_ROOT’].’ /newfolder/wp-content’);

define (‘WP_CONTENT_URL’, ‘http://yourdomain.com/newfolder/wp-content’);

Read More

Moving the wp-content directory

Another directory in your WordPress installation that’s attractive to hackers is the /wp-content folder. Hackers sometimes attack this directory because it holds all your theme and plugin files. If a hacker can exploit any of the code found within those files, she can gain control of your Web site, or at the very least, mess it up a lot.

You can move the /wp-content directory to a location on your Web server
outside the WordPress installation directory, making it a lot harder, if not
impossible, for outside hackers to locate. To move the folder, create a new
folder on your Web server outside the WordPress installation directory and
then, using your FTP program, drag and drop the /wp-content folder to
the new one you just created. In most popular FTP programs, you can right-
click with your mouse and choose New Folder, which allows you to create a
new folder and give it a name.

Read More

Absolute WordPress path

The configuration file defines the absolute path, or the full directory path on your web server, to the WordPress files on your Web server. This is called once when WordPress is executed and tells the Web server where, within your directory, it needs to look for the core files to successfully run WordPress on your site. The code that defines the absolute path in the wp-config.php file looks like this:

/** Absolute path to the WordPress directory. */ if ( !defined(‘ABSPATH’) )

define(‘ABSPATH’, dirname(__FILE__) . ‘/’);

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

Read More

Database table prefix

The underscore after the table prefix isn’t required but is recommended practice to make the database tables easier to read and sort. Refer to Figure 5-1 and you see that the tables are named like this: wp_commentmeta, wp_ comments, and so on. Placing the underscore after the prefix makes for easier reading and a more organized looking database. Reading a database can be confusing enough, so make it easy on yourself and use the underscore if you choose to change the database table prefix.

 

Read More

Database table prefix

During the installation process, you can change the default wp_ prefix to
anything you want. In fact, most security experts recommend that you
change the database prefix because WordPress is a big target for hacking
(malicious scripts, spam, and so on). Web bots and spiders can be set to
look for the usual WordPress default settings and attempt to exploit them.
The wp_ database table prefix is one of those obvious default settings, so
to safeguard your installation, change the prefix to anything you choose.
However, keep in mind that if you change the prefix, you need to change it
to something very difficult for a script or an automated program to guess.
Treat the prefix like a password and make it a random string of letters and
numbers — something like sd30df43xxi54_. Just be sure that it’s unique
and difficult to guess.

If you didn’t change the table prefix during installation, you can go back and
do it later if you want to. You will need to edit the $table_prefix line in
the wp-config.php file. Also, you’ll need to alter the table names in your
database by accessing the database administration interface provided by
your Web hosting provider (like phpMyAdmin, for example) and by renam-
ing the tables to replace the wp_ prefix with the one you defined in the
wp-config.php.

Read More

Database table prefix

By default, when installing WordPress, you’re asked for the database table prefix and given the wp_ default prefix. This is how the tables in the database are defined and called by the different WordPress functions in the

code. Figure 5-1 shows Lisa’s WordPress database displayed in phpMyAdmin (a database administration interface), which displays all the tables in Lisa’s WordPress installation with the wp_ prefix.

Here’s how the database table prefix definition looks in the wp-config.php file:

/**

* WordPress Database Table prefix.

* You can have multiple installations in one database if you give each a unique
prefix. Only numbers, letters, and underscores please!

*/

$table_prefix = ‘wp_’;

Read More

Default language

 

English is the default language for every WordPress installation; how-

ever, you can use any of the language translations currently available for

WordPress by changing the WPLANG parameter in the wp-config.php file. By default, the WPLANG parameter looks like this:

/**

* WordPress Localized Language, defaults to English.

* Change this to localize WordPress. A corresponding MO file for the chosen
language must be installed to wp-content/languages. For example, install
de.mo to wp-content/languages and set WPLANG to ‘de’ to enable German
language support.

*/

define (‘WPLANG’, ‘‘);

We don’t have the room to list the all the available languages, but you

can find the specifics at the WordPress Codex page (http://codex.
wordpress.org/WordPress_in_Your_Language), which lists all the
languages you have access to, including the language code. If you want
WordPress translated into French, for example, look up the language code
on the Codex page. You can see that the code is fr_FR. To use French
rather than English, you change the WPLANG parameter to:

define (‘WPLANG’, ‘fr_FR’);

Then save the file and upload it to your server. Your WordPress Dashboard

displays in the French language, rather than the default English.

 

Read More

Discovering the Configuration File

Follow the directions in the file and visit the WordPress secret-key service
Web page (https://api.wordpress.org/secret-key/1.1/salt;
be sure to refresh this page a few times to make sure that you get unique
keys) to obtain the keys that you need to replace the existing defaults (rep-
resented in the wp-config.php file by the lines that start with define.
Copy the keys from the Web page and then replace the eight lines of default
(blank) keys in your wp-config.php file. After you do that, this section of
the file looks like this (except with your own, unique secret keys):

/**#@+

* Authentication Unique Keys and Salts.

* Change these to different unique phrases!

* You can generate these with the {@link https://api.wordpress.org/secret-key/1.1/
salt/ WordPress.org secret-key service}. You can change these at any point in

time to invalidate all existing cookies. This will force all users to have to
log in again.

* @since 2.6.0

*/

define(‘AUTH_KEY’,’OkjsE|hTe1A#+yK*;zWOh_~we{X}(uX=TUXtV`WC9Owz_eA@c_
LKH-Le;qKDPcn’);

 

define(‘SECURE_AUTH_KEY’,’mGt;>cS&Gn,weoFIoJts[.+8bm$Qk|+|a|]>u<TLQRJBH2_
eb>$TDk{ru&:|$5b’);

define(‘LOGGED_IN_KEY’,’N13G3G^n8w%B4Nge)|V6TyI!S^Td!u|6_]}8kVSDB]p|@fTu=%>)

M<s>%|t<qJb’);

define(‘NONCE_KEY’,’pOj/Uj?&+AJVO9SnRhr<e8:dO+A8>XgSO5SuUYpvkjy@%O:Hi

< Z->|!~YIA+Yq’);

define(‘AUTH_SALT’,’8c%^y1/Kts3(I|N9/:`DM(j+qx.rKQh+I##E~e!Oq7|

@p5j^D1:Yic+GQtlX>d’);

define(‘SECURE_AUTH_SALT’,’!$Fi=K0jfK([;1x~EzN,QQOja_y5a|oxl_On~7AIT&8<dE:)

M|DGc?Cb:sQiTor’);

define(‘LOGGED_IN_SALT’,’N&j*A6khkJb}DhN>)+||e2}(:^Oo+mw!~DV0V;3W:75C|KCrHK[)

7th_w:3%Fqe’);

define(‘NONCE_SALT’,’xscOi.7I=%1;=-{mWjN=+gN03].RjLR6|ZpvbZt@

bqK{p$2p;M.%,&i#9U8SLZ’);

You can change the secret keys any time by editing the wp-config.php file and replacing the keys with new ones. Doing so doesn’t affect the function-

ing of your Web site, but it does require that users log in to your site again, if they were already logged in, because changing the keys changes user

authentication and retires the cookies that had already been placed in their browsers.

Read More

Secret keys (salts)

Secret keys enhance WordPress security through user authentication with the placement of a cookie in the user’s Web browser. They are also referred to as salts, a word commonly used in cryptography to represent random keys, such as in a password. Secret keys in your wp-config.php file make your site harder for outside sources to gain access to because they add random keys to the user password.

These keys aren’t populated during the WordPress installation, so after the
installation is complete, you need to visit the wp-config.php file to set the
keys so that your WordPress installation has unique keys that are different
from any other installation — making it more secure because the keys are
specific only to your site. By default, the code in the file looks like this:

/**#@+

* Authentication Unique Keys and Salts.

* Change these to different unique phrases!

* You can generate these with the {@link https://api.wordpress.org/secret-key/1.1/
salt/ WordPress.org secret-key service}. You can change these at any point in
time to invalidate all existing cookies. This will force all users to have to
log in again.

* @since 2.6.0

*/

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’);

Read More

Database information

The database information section of the wp-config.php file contains the

database credentials that are required for WordPress to connect to your
database. During installation, the WordPress installation script populates

this data after you input the database name, username, password, and host in the installation form (see Book II, Chapter 4). The following lines of code show you what this section of the file looks like in its default form:

// ** 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’);

 

Read More