WordPress Theme Development single.php

Everything that WordPress does; every new post you make; every menu you create is recorded in a MySQL database. It’s what makes WordPress websites so dynamic.

This means that when you’re working in local development the database you create and grow is only accessible in one location. Your data is fixed in one system – that is unless you can find a way to transfer that database to a different location.

You will also want to transfer the work you’ve done to your web host server when you have finished developing your project.

To achieve either of these things you will need to learn how to export files from one location to another – specifically the backup SQL file.

Your exported SQL file is also your primary means of backing up the database in case the worst happens. I’ll cover how to do all of this in this post.

Transferring Data from one local system to another.

When developing WordPress websites, you’ll sometimes need to work with 2 WordPress installations and 2 databases in different locations. In all cases, your database is managed via MySQL’s database management interface, phpMyAdmin.

Go to your Local Development Server and enter phpMyAdmin. As long as your local server is active, you should be able to access it in your browser with a URL like this.

http://localhost/phpmyadmin/

Implementations of phpMyAdmin can vary. But, right from the start, you should be able to see a list of databases on the left-hand navigation. Find the database assigned to your WordPress project. If you’re unsure about these details look at the wp-config.php file in our WordPress installation.

You can also find it by clicking on phpMyAdmin’s “Databases” tab.

Databases -----> wp--subdomain-2024db

On the same row, i.e. the Horizontal navigation tabs at the top, find the “Export” Tab and click it.

Scroll down the page and look for the “Custom” radio button under “Export method”. This will open up a vast array of export options for your backup file.

"Export method" ------> Custom - display all possible options

You’ll be presented with a LOT of text, input fields and settings. We can ignore most of these, at this stage. However, the first thing to do is to select the Database you want to export your backup with.

Databases ------> wp---subdomain-2024db (example)

Format: Select the export format. We want a MySQL database, so choose SQL in the dropdown box. This will ensure that we get the single SQL file that we need.

Tables: A WordPress installation has a number of tables in its database. Ensure every table has a checkmark by its side when exporting your file.

Now it’s time to choose a file name. In the “Output” section – Ensure the checkbox “Save output to a file” is active.

Output ------> Save output to a file

File name template – Enter a descriptive name and find a secure location for it. e.g. wp—subdomain–2024db-30052024. Choose the utf-8 character set with no file compression. What we want and what we end up with is a single .sql file.

Now click the “Export” Button to generate your backup file. It will download your file to your system’s downloads folder.

It’s now time to switch to your new location, so this might be your laptop or separate PC. Once there, go into phpMyAdmin.

Import file to a new location

There are a few assumptions I have to make at this point.

• You have access to 2 WordPress installations and 2 separate databases.
• Both these databases have the same name
• You’ll have a complete installation in an equivalent location to that on your original system.
• You are organising these files with a Version Control System e.g. Git

The best way of managing the theme files themselves is by using version control. I previously mentioned that I have a collection of installations that I put in a directory called wordpress each of which has its own database.

e.g.
PC: c:xampp/htdocs/wordpress/htdocs/windows/theme_directory/wp-content/themes/theme_name
Laptop: c:xampp/htdocs/wordpress/htdocs/windows/theme_directory/wp-content/themes/theme_name

If you’re using version control, go ahead and update your files using the git pull command. Otherwise, simply copy the files as you would using your system’s GUI.

git pull 

If you have your WordPress Installation set up, the theme assigned and the database in place, what you should be able to see as it stands is your website looking like the website you designed but lacking the menu you created; lacking your website front page; or the blog homepage.

There are no Pages in place. There are no blog posts to be found other than the default sample content. No Widgets have been added and no dynamic menus are in place. The way to get these back is to import our SQL file into our database.

Importing the Database

Taking our assumptions into account we should now be “safe” to import our backup file into the new location. But if you haven’t already, select ensure the database is empty by dropping all the tables in it.

Select Database ----> "Check all" Tables ----> with selected -> delete data or table ----> Drop ----> Yes

Now find the SQL file and upload it to phpMyAdmin.

Import ------> File to import ------> Choose file ----> Select from your files

And that’s it. You can scroll down the page and click “Import/Go”.

If all has gone well… you’ll see a message with a light green background on your screen like this:

Import has been successfully finished, 166 queries executed (wp---subdomain.sql)

Go ahead to your WordPress website in your new local development area and check out what has changed. Hopefully, you will be able to see right away that you have your menu area and your front page content. Start clicking these links and verify they are working correctly.

Then go to the wp-admin page and verify you can log into your website at your new location.

localhost/wordpress/theme_name/wp-admin

You can now go in and start assessing the admin area.

Verify that your settings are in place as you left them before the backup. Check your posts and pages are present.

Now review what’s happening with your plugins. One thing that doesn’t carry over in your export is active plugins. So you’ll need to download and activate them again. (That’s why I recommend keeping a note of the plugins and their details so you’ll be able to find and activate them again).

Everything that you used the plugins for is in place so once activated they should be ready to use seamlessly again.

Dashboard ----> Plugins ----> Add New

And with that… your migration from one local server location to the other is complete.

Transferring Data from one local development to a web server

Now let’s turn our attention to transferring our databases from local development into our final production server – an online server provided by a Web Host. This process will be similar to what we’ve just done with local migrations but a little more difficult.

Prepare for Database migration

The online database is ready to receive an imported file. But first, we need to upload our theme to the website.

Upload from the local “themes” directory to the one in the web server.

C:\xampp\htdocs\wordpress\subdomain_2024\wp-content\themes\subdomain_2024\

Upload to 
[web server]/public_html/wordpress/wp-content/themes/subdomain_2024

Now it’s time to clear out whatever may already be on the provided database. Go ahead and DROP (that is delete) any data currently existing via phpMyAdmin on your web server. Of course, you should be sure that you have exported any existing data into a backup SQL file.

Now on the online phpMyAdmin, on the import tab, find your backup SQL file on your computer and find the “browse” button to upload the file.

If I try to import the same file we did for the local development migrations, I expect it to come back with an error.

--
-- Database: `wp--subdomain-2024db`
--
CREATE DATABASE IF NOT EXISTS `wp--subdomain-2024db` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
MySQL said: Documentation

#1044 - Access denied for user '_sso_a7a94cdf'@'%' to database 'wp--subdomain-2024db'

Error: #1044. So we’re saying that the database names in the script and the database server on my web host don’t match.

We need to verify a couple of things.

• First, find the database name, passwords and usernames.
• Look in the backup file for references to the database name in the SQL and edit them to the correct name.
• This is a crucial part. It contains a reference to the database name on localhost.

A forensic look for the database name finds that these are the only 3 references to the database name in this file.

--
-- Database: `wordpress-jg-34081c`
--

CREATE DATABASE IF NOT EXISTS `wordpress-jg-34081c` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
USE `wp--wordpress-jg-34081c`;

Change references to URLs to the web host URL.

e.g.
INSERT INTO `wp_options` (`option_id`, `option_name`, `option_value`, `autoload`) VALUES
(1, 'siteurl', 'http://localhost/wordpress/subdomain_2024', 'yes'),
(2, 'home', 'http://localhost/wordpress/subdomain_2024', 'yes'),

If you need to go through the installation process…. don’t worry. Do it. Keep your existing login details handy. But it is much easier if you drop any existing database details and import backup SQL files directly.

Site Title: WordPress Theme Development
Username: jonniegrieve
password:

There will likely be several hundred of these instances.

Better Search/Replace…

When you’re transferring data between different base URLs, it’s likely that you’ll have to change hundreds of references to the localhost URL.

There’s a plugin you can use to help with this called Better Search/Replace.

• Better Search Replace
• By WP Engine |
• Version 1.4.7 |
• A small plugin for running a search/replace on your WordPress database.

This will help you search for references to one URL and update it in just a few seconds.

As a further measure, you can also add these statements to your config.php file.

<?php

define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');

Some tips in summary

Keep your passwords and database information secure. I have all mine in a Keepass database.

Keep your local development details the same so you can transfer easily between locations. You may need to regularly transfer backups between locations if you regularly move between systems.