2. Extract the zip file. Open the backup.php with a text editor and edit your database and Dropbox credential.

Optionally, you can create a backup folder in your Dropbox and insert the name of the folder to the backup.php. Your database will then be backed up to this folder.

3. Save and close the file. Upload the whole backup folder to your server. Note the uploaded location relative to the server root.

4. If you are using cPanel for your web hosting, log into it and go to the cron job section.

5. Create a new cron job. You can set the time and frequency to backup the database. Under the command field, copy and paste the following command:

/usr/bin/php -q /path-to-backup-folder/backup/backup.php

Change the “path-to-backup-folder” to the location (relative to the server root) where you upload the backup folder.

6. Save the cron job.

That’s it. Now, your server will backup your database and upload it to your Dropbox account.

Note: This is a generic method for backing up any database on a Linux server. However, if you are using WordPress, there are plugins that you can use to back up your database to Dropbox. One thing to note: if you have a big database, using the plugin to backup your database will use a lot of system resources and and might slow down (or even crash) your WordPress site if your server is not up to par.

Image credit: Backup word on white keyboard by Big Stock Photo.

Whatever the reasons, rather than relying on plugins, a better alternative is to use a cron job in your server and schedule it to backup your database everyday.

Note: The following instruction can be used to backup any database. The only requirement is that you are using a Linux server to host your files.

Here is how you do it:

1. Login to your web host control panel. If you are using cPanel, look for a Cron Job icon.

2. You can set the time and frequency to backup the database. Under the command field, copy and paste the following command:

mysqldump --opt -Q -u dbusername --password=dbpassword dbname | gzip > /path-to-store-the-backup-file/db_backup.sql.gz

• Replace dbusername with the database user
• Replace dbpassword with the database user password
• Replace dbname with the database that you are backing up
• Replace the path-to-store-the-backup-file to the file path in your server where you want to save the backup

Note: In some server, you might need to put a pair of single quote around the dbpassword for it to work. For example:

mysqldump --opt -Q -u dbusername --password='dbpassword' dbname | gzip > /path-to-store-the-backup-file/db_backup.sql.gz

Email yourself the database

Storing the database on your server could take up plenty of storage space. One way you can do is to email the backup file to yourself.

1. Download this php script.

2. Extract the zip file and open the backup.php with a text editor.

3. Change the database detail:

$dbhost = "localhost"; // usually localhost
$dbuser = "dbuser"; //enter your database username here
$dbpass = "dbpass"; //enter your database password here
$dbname = "dbname"; // enter your database name here
$sendto = "Send To <sendto@email.com>"; //the email address to send the database to
$sendfrom = "Send From <sendfrom@email.com>";
$sendsubject = "Daily Database Backup"; //the subject of the email
$bodyofemail = "Here is the daily backup of my database.";

4. Save the file. Upload the whole folder to your server. Note: The folder includes a .htaccess file to prevent any access from the browser. If you want to access from the browser, remove the .htaccess file.

5. In the cron job section of the cPanel, enter the following command:

php -q /path-to-the-php-script-folder/backup.php

That’s it.

Getting Base

Base is part of the OpenOffice package, and packages for all platforms can be downloaded here. Linux users likely won’t need the manual download, as the full OpenOffice suite is typically available in the standard repositories of most distros. Ubuntu users, for example, could install with

sudo apt-get install openoffice.org-base

Creating Your Database

When you launch Base, you’ll be taken to a “wizard” which can guide you through the first few steps. While many such wizards often get in the way, the wizard for Base is well constructed and can make the initial steps much simpler than going alone, especially if you don’t have much familiarity with database software.

For the purposes of this guide, we’ll be using the wizard to create a database containing sample employee information, then building a form to manipulate that database.

On the next step, you may be asked to register your database with OpenOffice. This is not a requirement, it’s only relevant if you plan to integrate this database with other OO products.

Before proceeding, it’s recommended that you check the box for “Create Tables Using the Table Wizard“, especially if you’re new to database design.

Creating Tables

The previous step should have finished by saving your new database to a file. If you checked the box for the Table wizard, you should now be brought to a screen where you can begin laying out the information that your database will contain.

As stated earlier, we’re creating a sample database containing employee information for a fictional company. The radio buttons and dropdown menus on the wizard screen will allow you to choose from some pre-existing example fields. Here we’ve chosen a small subset of the possible employee-related fields offered by Base.

Database design is far too large a subject to cover here in detail, so we’ll just mention a few basics and leave some links at the bottom of this page for more detail. For starters, each table should represent only one idea – ie the Employee table should not contain shipping information. If you find yourself putting anything into a table that does not match with the title of that table (like Employee or Billing), it probably belongs in a different table.

Secondly, it’s important for tables to have a primary key. In short, this means that tables should generally have a column where each row in that column is unique on that table. That may sound confusing, but it typically just means that you need a column like EmployeeID, and each entry has a different, unique number. There’s (probably) no chance of two employees having the same ID number, so it makes a perfect primary key.

On the second page of the Table Design wizard, you specify what type of data will go into that field. A number like EmployeeID makes sense as an integer, and text fields like first and last name should be text (CHAR or VARCHAR). If you chose the fields from the dropdown menus in the wizard, these types should be automatically applied to the right fields.

If it’s essential that a record contain a certain field (in our example, and employee MUST have an ID number) make sure to set Entry Required to True for that field, as in the screenshot above. This can make sure that all new entries, regardless of who did it, must follow the rules of your database.

On the next page, you’ll be asked to set a primary key. As mentioned above, it’s generally a good idea to have one column in your table set as the primary key. Remember that for it to work as the primary key, each field in that column must be unique to that table. If you’re following the examples, you’d use EmployeeID as the key, since you can reliably assume that every user will have a different one.

Once you’ve named your table, you’re done setting up your database and tables. Before continuing, you have the option of remaining in the wizard to create your first form, which is what we’ll be doing for this guide.

Creating Forms

Any database can store information, but tools like Base and Access go a step further and allow you to create the interface for viewing and manipulating your data. If you’ve continued with the wizard, you are now at a place where you can build those forms.

A form in Base terms is somewhat like a web page – it’s a visual place to view, enter, and manage the information in your tables. Your form can be laid out however you choose and display only the information you select. This example builds a form from the ID, Name, and Title fields.

Most of the Form wizard options are not critical and can be safely ignored, however make sure to check the layout section and Step 6 in the wizard to decide if you want the form to be read-only.

Conclusion

Now that you know how to create a database, create and edit tables, and the basics of forms, you’re in a position to use Base as a foundation for some amazingly useful applications. Software like Base is in use by countless organizations, large and small, because it allows you to gain many of the benefits of a custom-written database application without having to actually custom write a database application. If you’ve had experiences with Base, or similar software, let us know in the comments.

• a local server application (we recommend XAMPP since it is the easiest to use and it works for all platforms)
• a copy of the WordPress software (download it from WordPress.org
• a copy of your existing WP blog database
• a FTP program (We will be using Filezilla, but you are free to use your favorite application)

Let’s get started.

Installing WordPress in your local server

I won’t go into much detail here since we have previously written plenty of articles on this. Check them out:

How To Install WordPress MU In Windows Localhost (With XAMPP)

Setup a PHP/MySQL Environment on Windows The Easy Way

How to Install and Test WordPress on Your Mac

Note: Resume this tutorial only after you have installed WordPress in your local server.

Backing up your live WP blog

You will need to get a backup copy of the database of your live WP blog. This can be achieved in two ways: plugin or phpMyAdmin.

Plugin
There are several plugins that can backup your database. My favorite is WP-db-backup plugin. You can also use WP-DBManager plugin.

Install the WP-DB-backup plugin and go to Tools -> Backup in your WordPress dashboard.

Check all the tables name.

Select “Download to computer” and click “Backup now!”.

The backup process will begin and it will prompt you to download the sql file when it is done.

phpMyAdmin
Login to your web host cPanel and click on the phpMyAdmin icon.

In the left pane, click on your WP blog database.

Click the Export button.

Scroll down to the bottom of the page. Check the box “Save as file“. Also check “gzipped”. Click Go.

Restoring the database in your local server

Start your local server. Open a browser and go to “http://localhost/phpmyadmin”. Create a new database.

Next, click on the “Import” button.

Navigate to the location where you save the database file. Click Go.

This will import your WordPress database to your local server. If your database file is more than 2MB, you might need to increase the “upload_file_limit” variable in the php.ini file.

Configure the wp-config file

In your file manager, go to the WordPress folder within the htdocs folder. Open your wp-config.php file in a text editor and change the following:

//unless you have changed the setting, else the default will be as follow
define('DB_NAME', 'wordpress'); //change this to the name of the database you have created earlier
define('DB_USER', 'root'); 
define('DB_PASSWORD', ''); //no password by default. Change this if you have added password during installation
define('DB_HOST', 'localhost'); //99% you won't have to change this

You need to add in another 2 lines:

define('WP_HOME','http://localhost/wordpress');
define('WP_SITEURL','http://localhost/wordpress');

That’s it. You have successfully cloned your live WP blog to your local server. You can login to your dashboard via the link “http://localhost/wordpress/wp-login.php” and make changes to your test site.

Note:

1. To make the permalink work properly, you will need to regenerate the permalink structure in the Permalink setting page and edit the .htaccess file)
2. For better compatibility, you might want to replace your wp-content folder in the local server with the one in the live site.

Image credit: thatcanadiangirl

Take this as my letter to WordPress (and Matt Mullenweg) and I seriously hope they can add the following features to the core in the future.

Let’s begin!

1. Database Backup/Export/Import

Being a database driven CMS, I am surprise that the default WP installation does not come with a way for you to backup your database. The Export feature is almost useless as it contains only contain your posts, pages, comments, custom fields, categories, and tags and none of the database settings that you have painstakingly set up over the years. And if you have a big blog (with tons of content), I can assure you that the Export feature is not going to work very well.

With a native database export/import function, it will be easy for the end users to backup their database and also to migrate to another server without any loss of settings.

Currently, the plugins that allow backing up of database include WP-DB-Backup and WP-DBManager

2. Contact Form

Contact form is a simple, yet essential component for every website, yet WordPress doesn’t think it is important enough to include it in the core. End users who need to create contact forms have to resort to plugins like Contact Form 7, cFormsII to create contact form for their sites. Most CMS come with this contact form creation capability, so why not WordPress?

3. Disable display of wp version in the meta tag

Everyone knows the risk of placing your wp version in the <head> tag, except for the WordPress team. Instead of removing the versioning from the meta tag, they make it appear automatically (whether you like it or not) since WP2.5 and does not provide an easy way for you to remove it. Can you imagine installing a plugin just to remove the wp-version tag? What a waste of resources.

To remove the wp version from your meta tag, you can add the following hook to your theme’s functions.php file

add_filter( 'the_generator', create_function('$a', "return null;") );

or use the following plugins: WP Security Scan or Secure WordPress

4. Changing of wp table prefix during installation

WordPress uses wp_ as the default database table prefix and we all know how dangerous that can be. Most people don’t change the table prefix simply because they don’t know how to, or they are not able to (if installed via Fantasico). Yes, I know, you can change the table prefix in the wp-config.php file before installing, but how many people really do that? In my opinion, during the installation process, there should be a field for the users to specify their preferred table prefix.

For those who wanted to change their current wp table prefix, here’s how you can do it.

5. More control over the user roles/capabilities

Have you ever wondered what is the differences between an Editor, Author and a Contributor role? I would appreciate if there is a small paragraph within the User section that explains the capabilities of each role, or a simple link that points to the WordPress documentation site.

In addition, there are plenty of time when we need to limit (or expand) the capabilities of a particular role and there is no way to do that in the native WordPress installation. Users have to use the role-manager plugin to change the capabilities of each role.

6. Choose your own admin username

The default username for administrator is, as you have guessed it, admin. Is it so difficult to let the users choose their own administrative login name during the installation process?

7. Support for mobile devices

WordPress.com realized the importance of mobile visitors (more than 60 million page views come from mobile phones per month for WordPress.com blogs) and have activated a mobile theme (to be more precise, the WpTouch plugin) for mobile users. The mobile support feature is integrated into WordPress.com and users can choose to enable/disable the mobile theme in the settings.

Isn’t it time for the users of self-hosted WordPress to get the same treatment too?

Those who want to activate mobile support for your WP blogs can install the plugins: WPTouch, WordPress Mobile Pack and wp-pda

What’s your say? What other features do you think should be included in the WP core?

Image credit: Peregrino Will Reign

If you are new to blogging and are looking to install your first WordPress blog, then it is easy. Simply change the $table_prefix entry in wp-config.php file, upload the file to the server, then proceed on with the famous 5-mins installation.

For those who have already been blogging for sometime, follow the method below to change your table prefix.

Preparation

Download the following two plugins, install and activate them in your WordPress blog.

WP-DBManager (plugin download page)

WordPress Table Rename (modified version,  original download page)

Note: I have make a slight modification to the WordPress Table Rename plugin to include changes in the later version of WordPress, but credit must be given to SEO Egghead for creating such an useful plugin.

Get started

Before you do anything to your database, first perform a db backup.

On the left pane, go to Database –> Backup DB. Do a backup of your database.

Next, go to Settings –> Table Rename

Enter a new term for the table prefix.

Click the Create New Tables button to generate new tables with the new prefix. If you have a big database, this process will take a long time.

When it is done, you will see the success message.

If you have a big database, the page might issue a timeout and show a blank page.

Verify your new database tables

Now go to Database->database. You should see the new tables in place.

Migrating your blog

While the plugin provides a way to change the table_prefix value in wp-config.php file, it won’t work in most cases unless you have set the wp-config.php file readable/writable (which I strongly advised against). The best way is to change the value manually.

With your favorite FTP program, download your wp-config.php from the root server.

Open it up with any text editor and scroll down to the section where you see

$table_prefix = 'wp_'

Change it to

$table_prefix = 'YourNewPrefix_'

Save it and re-upload this file back to the server.

Almost there

You have just completed the migration from the old table prefix to new table prefix, there are still several things that you need to do

1. Browse through your site and make sure all the pages, images and content are loading correctly. If you see errors, or that the site is not loading, change the $table_prefix back to ‘wp_‘ and re-upload back to the server.

2. Browse through the settings for each individual plugin and make sure that all the configurations are intact. Some of the plugins use the table prefix for their storage and these values were not changed by the plugin. For such plugins, you will see the settings fall back to their default values. What you have to do is to reconfigure it and re-save it. It will now store in the database with the new table prefix.

3. (Optional) Go to the Database –> Empty/Drop Tables, check the Drop button for all the table with the old prefix. Click the Empty/Drop button to remove them from your database.

Important: Do this only if you are sure that the new tables (with the new prefix) are working correctly.

Note that this is purely optional. Leaving your old table in the database will not hurt your blog and it can serve as a backup and allow you to switch back to them quickly in the event your blog got hacked into. However, if you have a big database, the extra tables could add plenty of overhead to your server. So, make your own judgement.

Last part

Once you are happy with everything, backup the new database. If you have previously schedule a daily backup, you have to reschedule it again to include the new tables.

You can also deactivate and uninstall the WordPress Table Rename plugin. There is no use for it now.

That’s it. You have successfully changed your WordPress database table prefix.

Image credit: naokomc

If you have not been doing regular housekeeping and database maintenance, either because you don’t know how to do or you are just plain lazy, here are 8 useful tricks that you can use to clean up your WordPress database easily and quickly.

1) Turn off/delete post revision

While the post revision is a good way to make sure that any changes to a post is documented, it can be a waste of database and server resources if you are the only user of the blog and does not collaborate with other authors for article writing.

To prevent the post revision from cluttering your database, it is best to turn it off once and for all.

You can easily turn off post-revision by adding the following line to the wp_config.php file

define(‘WP_POST_REVISIONS’, false);

If you want to keep the post revision for record purpose, you can limit the number of revisions saved per post. In your wp_config.php file, add the following line instead:

define(‘WP_POST_REVISIONS’, no_of_revision);

and replace the no_of_revision by the number of revision copy you want to keep.

Removing existing post revisions

Turning off the post revision feature only restrict WordPress not to keep any revision for future posts. It does not delete the existing post revisions in your database. To delete all instances of post revision and all its related entries), we will make use of the delete-revision plugin with some simple modification (the plugin only delete the post revision. It does not delete all other unused entries that are related to the post revision).

Download the plugin delete-revision to your desktop.

Extract the zip file. Open up the delete-revision folder and load the delete-revision.php file in a text editor. Scroll down to the line 140 where you see

$sql = “DELETE FROM $wpdb->posts WHERE post_type = ‘revision’”;

replace it with

$sql = “DELETE a,b,c FROM $wpdb->posts a LEFT JOIN $wpdb->term_relationships b ON (a.ID = b.object_id) LEFT JOIN $wpdb->postmeta c ON (a.ID = c.post_id) WHERE a.post_type = ‘revision’”;

(Code adapted from Lester Chan)

Save the file. Upload the whole delete-revision folder to your blog plugins folder.

Activate the plugin. Go to the Delete-Revision page under the Setting section. Run the application to scan your database for all instances of post revisions and delete them from your database.

If you are keeping copies of post revision in your database, you should run the Delete-Revision manager once every few months to clean up your database.

2) Delete unused images

Everytime you upload an image, WordPress automatically create duplicate copies of that image and resize them to thumbnail and medium size. Most of the time, these images are not used. In addition, there could also be some images that you have uploaded, but did not use them in the post. These unused images could easily add up to a massive size and cause unnecessarily burden to the server and database.

The DUI (Delete Unused Images) plugin scans your WordPress blog and find those images that are not used or referenced to by any of the posts/pages. It then proceeds to delete them from the database/server.

To use the plugin, you have use a FTP program to chmod the Uploads folder (the folder where images are stored) to 777. Once you have deleted the unused images, chmod the folder back to 755 again to prevent access from other people.

Similarly, you should run this plugin every few months to clear up your database.

3) Optimize database

As you add or remove entries into the database, pocket of spaces are created. These are useless space and could cause your database to swell quickly. You can easily free up these spaces by running a SQL optimize table query in myphpadmin.

If you are not technically inclined or find it troublesome to log into your myphpadmin, the best way is to use the plugin WP-DBManager to manage your database.

Install and activate the plugin. Under the Database -> Optimize Database options, select the table that you want to optimize and click the Optimize buttonto start the optimization. It should take less than a minute.

You can also schedule it to optimize the database every few days/weeks/months

Go to Database -> Database option. Scroll down till you see the Automatic Optimizing of DB. Set the frequency for it to auto-optimize your database.

4) Delete unwanted plugin

If you have decided that you have no use for a particular plugin, deactivated them and delete them from your server. The more (unused) plugins you keep in your server, the longer it takes for WordPress to generate the plugin list and the higher tendency that it will slow down the loading time of your blog.

5) Uninstall plugin completely

When you deactivated/uninstall a plugin, the options or the tables that the plugin created are not removed. As you install and uninstall a lot of plugin, there will be more and more orphaned options and tables that are taking up precious space in your database.

For plugins that have created table entries in the database, you can use the abovementioned WP-DBManager to drop the respective table from your database.

For those plugins that have created options, you have to use the Clean Option plugin to hunt down the orphaned options and delete them from the database.

6) Remove unused themes

Similarly, if you have plenty of unused themes in the server, delete those that you don’t use.

7) Check your site for deadlinks

While it is an usual practise to link to other posts/blogs/domains in your articles, you should check frequently that the linked post/domain still exist and you are not left with a dead link. It can be very frustrating for your reader to follow your link only to find that the destination page is no longer around. In addition, too many dead links can also affect your search engine ranking. I am sure this is not something that you want to see.

The broken link checker plugin checks your new article for broken links as soon as it is published. It also scans your old posts when you are logged into the Admin page. Any broken links found are reported to you and you can choose to edit or unlink them from the posts.

8) Delete spam comment

It is common to receive tons of spam comments, sometime as soon as you post the article. Even though these spam comments are not shown in your blog, they are still gathered in your database to educate “intelligent” anti-spam plugins. If you received plenty of spam every day (or every hour), this could be taking up a lot of valuable database space. To erase the spam, either go to the Comment -> Spam page, check all the spam comments and select Delete from the dropdown box.

Alternatively, you can use the WP-Optimize plugin to clean up all spam and unapprove comments

The WP-Optimize plugin also comes with other features such as delete revision, optimize database table and change your username. Personally I would prefer to use the WP-DBManager to optimize my database table as it allows me to schedule the optimization task on a regular basis. In addition, the WP-Optimize is only tested for WP2.7, so if you are still using a WP version less than 2.7, you have to use it at your own risk.

What other ways do you use to clean up your WordPress database?