hpr-knowledge-base/hpr_transcripts/hpr1026.txt

Episode: 1026
Title: HPR1026: Setting up a WordPress blog: part 4
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1026/hpr1026.mp3
Transcribed: 2025-10-17 17:37:16

---

Hello, this is Frank Bell again with the fourth of four podcasts on setting up a WordPress
blog.
These podcasts are intended to people who are relatively new and inexperienced in working
with WordPress and databases.
You are an experienced and proficient blogger and a database administrator.
You probably will be wasting your time to listen to this unless you want to send me an email
and tell me about all the mistakes I've made.
Of course, the most obvious aspect of maintaining any website is to maintain backups.
You want to back up the files that you placed on your website.
In the case of a WordPress blog, these would include the WordPress PHP files, your theme
files, and your plugin files, and other such things.
You also need to maintain and back up your database, which is a separate procedure and
one that I think many, relatively new or less experienced bloggers, don't pay enough
attention to.
However, if you've ever gotten that dreaded message, cannot create database connection.
You know how important that is.
First I'll talk briefly about files, when to back them up, obviously after the initial
setup.
Now, if you've tested out your files on your local computer using a program such as ZAMP
where you can run your own Apache server, database, PHP, and Perl, and test everything
before you uploaded it to your hosting service, you already have backups.
If you don't, if you've gone to a hosting service and had them automatically installed
WordPress, and then you've configured up your thing, once you're pretty satisfied with
how everything's going and how everything looks, it's a good idea to fire up your FTP
client and download copies of all those files.
This of course also applies if you're doing an HTML website.
Once you have it looking the way you wanted to download copies of the files to your local
computer, how often should you back up the files?
In addition to backing them up after a initial setup, I would recommend for a hobbyist website,
such as mine, to back them up when you make significant changes.
In the case of a WordPress blog, the files don't change all that much unless you make
a radical change, such as installing a new set of plugins, or installing a new thing.
The other item that's subject to change is Media.
If you like to upload pictures, audio, and items such as that, those will be changing
as you upload them.
I upload a lot of snapshots.
I happen to live, you're a golf course, there's lots of wildlife, and I'm frequently uploading
pictures of turtles and red-winged blackbirds and e-grats, and other wildlife that's around
some times of flowers, because I'm a rose fancier, and you know that we rose fansiers
are pretty fanatical about our roses.
My brother lives in an area where there are lots of eagles, and from time to time he
sends me pictures that I can post, he sent me a beautiful sequence recently of an eagle
actually fishing, grabbing the fish, tucking the fish into his talons, tucking his talons
up under his breast and flying away, wheeling and flying away with his prey.
I had a great time playing with those in the game, and creating blog posts that showed
the sequence as it happened, giving Duke credit to my brother, of course, in the process.
If you use the WordPress Uploader, which I described in an earlier podcast, by default
it organizes your uploads by month for 2012, there's an O1 directory for files uploading
January, an O2 directory for files uploading February, and so on.
So if those are the only files that change, media that you have uploaded, you can download
through FTP, the new folder is on a monthly basis, and maintain a local backup of those
files.
Hopefully you will also already have copies of the original picture files that you edited
and prepared for being uploaded and displayed on your blog.
My practice developed over the years has been to periodically do a complete backup of
all the files.
I do this usually every two to three months, not really on a set schedule, but when it feels
like I spent long enough since the last one, and I'll point my FTP client, I commonly
use GFTP to add my directory on my hosting service, and just download everything.
If I were a business or some huge organization, I might be running incremental backups, but
my blog is a hobby, it's a hobby I'm deeply invested in, but it's still a hobby, and I
don't need to do daily incremental backups.
There, frankly, is nothing on there that's important.
There's stuff that I feel very proud of, there's also stuff I don't feel proud of, but
stuff that in the grand scheme of things is basically a lone, hobbyist shooting his
mouth off on the internet.
And I don't kid myself that people will be celebrating my birth 200 years from now the
way that they are celebrating Charles Dickens' birth.
Personally, I do not celebrate Dickens' birth.
I think he exemplifies what happens when you pay a writer by the word, but that's just
me.
So that's enough about backing up files for now, simple using FTP to copy them and keep
them organized on your hard drive.
I'll talk about what to do with them after you get them in a moment.
The other aspect, though, and the one I think too often bloggers neglect is the database.
Back when I was very new to this, I'd probably been blogging for two, two and a half years,
I had my database crash.
It was when I was cell posting, I had no one to blame, but myself, I had not educated
myself to take proper care of it, and it decided one day just to give me the fingering
go away.
I actually lost about three months' worth of my dribble, which could not be recovered
in that.
Since then, I went out and educated myself, and I'm going to describe what I do as routine
maintenance for my databases, and I do this frequently.
I used to do it once a week, now my database has gotten much larger, it's about 200, slightly
more than 200 megabytes, and an SQL file, when I do a database dump fairly sizable for
a small little notice website on the back orders of the inner tubes.
I do this now every two to three days.
It doesn't take long, three or four minutes, I do it manually, I have a gone to the trouble
of automating it, if I were a business, again, I would automate it.
If it were on my own local server, I would automate it, but it's out on a web hosting service
and rather than figuring out how I can automate it out there, it just seems to be easier to
do it manually.
To do this maintenance, I use PHP, MyAdmin.
PHP MyAdmin is included with the great majority of web hosting services.
If your hosting service uses cPanel, there is actually a PHP MyAdmin icon directly in
the cPanel interface, if it uses parallels, getting to the database and the PHP MyAdmin,
it's a little different to find out how to access it, see your hosting providers, help
pages, or information.
If you are a self-hosting and you don't have it installed, go get it, it generally will
come with most server database server packages.
Once you are logged in to PHP MyAdmin, you will see Narrow column on the left, which will
list the databases, there will be your database or your blog database, there will also be
the information schema, which is used by MySQL to format itself.
You are interested in your database, let's say it's called Dribble, you click on Dribble,
and that will open up a list of the tables on the left and on the right I keep buying the
bulk of the page.
At the header it will say your server name, the name of your database, and various options
you have to view the PHP structure, you can enter an individual command and SQL statement
through PHP MyAdmin, you can search, you can do a query, you can export, you can import
and do other database operations.
The bulk of the screen will be taken up by a list of the tables and the tables, there
will be several columns, the name of the table will be on the left, then there will be
a column of actions you can take, such as to browse the database and look at the individual
entries, to look at the structure of it, to search the table, to insert, drop or empty
the database, generally we are not going to do any actions, unless we are actually database
administrators and know what we are doing, though from time to time I have used the browse
to find a particular entry that I want to either modify or remove, generally though I say
out of this area, it will tell you there will be a column that tells you how many records
are in the database, for instance my post database, I am looking at it now at 34,276 records,
that is not just post, there are about 12,000 posts, it will tell you what type of database
it is and how it is collated, the size and megabytes to go to my post, it is 59.7 megabytes
and finally a column that says overhead, overhead is cropped, that builds up in the tables
in usage, the more overhead the slower the table is to respond, the slower a table is to
respond, the more likely you are to get that treaded error creating database connection
message, sometimes that message may occur because the database is broken, many times it
may occur simply because the database is being slow, in rare cases that message may occur
because the SQL server itself is not running, so the door is closed, during the regular
maintenance that I am talking about will go a long way to reducing the number of times
you or one of your visitors might see that message, here is what I generally do because
I am doing routine maintenance here, I am not trying to troubleshoot a problem, I go to
the bottom of the list of tables and there is an item on the far left that says check
all, and that means to put a check mark in the selection box, so I click that and check
marks appear in the selection boxes next to all the tables, then I go over to a dialogue
that says with selected and I select check table, and at that point the check gets instituted
and in a matter of a few seconds the display changes and that list of tables is replaced
by an item which at the top tells what SQL query was run, in this case it was check
table with the list of tables, and the list of tables below that and if all goes well
letters OK should appear at the right of that list, I then go back and I click the name
of my database again and I repeat that same process only this time when I go to with selected
I select repair table, what repair does is get rid of that crust in the database, the repair
may take a little longer, so when the confirmation comes up and I go back now the overhead column
is empty, there is no the overhead has been removed from the tables, I will generally
go ahead and do this a third time and this time when I click with selected I select optimize
table on the theory that it can't hurt and it might help, after repair the optimized
seems to take almost no time, I have not investigated this perhaps repair, if so fact it also
does not optimize, but this is the habit I have developed and quite happy with it, and
this is the kind of maintenance that will keep your database happy and healthy, but if the
server crashes all the maintenance in the world cannot bring back a dead database, so what
you need then is to back up your tables and get them to your local computer so that you
have a copy, you can do this in my SQL by clicking export and the export dialog will appear,
I generally accept the defaults which is to create an uncompressed SQL file which is
simply a text file which is organized in such a way that you can import it into my SQL
and it's really important to go down to the bottom and make sure that saved as file is
clicked, it's my personal opinion that the saved as file dialog should be in a more
prominent location, I think it should be at the top rather than at the bottom, however
that may be, I'm not the author of the program so I can complain but I have to pretty much
use it as it is, and once you click save as file you can click go on the bottom right of
the page and your browser will present whatever style of file dialog your browser normally
presents, it will say whether you want to open the file or save it, you select save and
then it will give you an option to pick a directory, and at this point I also will change
the file name, the file name will generally be your database name, let's say it's dribble,
dribble.sql and I will change it to add the month, year and day, so I will insert that
information before the file extension, so the file name becomes something like dribble
2012 hyphen 04 hyphen 30.sql and direct it to save, there are also other ways, for
some reason the phpmyadmin export hasn't been working very well for me lately, I don't
know if it's been browser related or what, I'm testing it in another browser, even right
now as I was doing this to keep my memory fresh as I reported this podcast, my hosting provider
also gives me an interaction on the command interface, their hosting dashboard or whatever
they call it, where I can tell them to create a backup, and then the dialog says this
may take up to two hours, it probably takes a lot less than that, but I've been using
that recently, and that will place the backup in the directory on my website that exists,
it's called db backups and exists for receiving backups that you have ordered in that way, so
I generally have been requesting that backup coming back later, at that point I renamed
the files using gftp to put in the year, month, day and download them with ftp, and that's
a little cumbersome but it's been working out just fine for me, once I have the files downloaded
there is another step, so I've got the original database out there on the web server, I've got
a copy on my local machine, with it both of them go at once, unlikely these days, I've
been playing with computers long after remember when file corruption was an ever constant
danger, we were at the expression save early and often originated because at any minute
you're a DOS 3.2 computer mic beside the crash, but it's still, it's not a backup unless
it's on removable media, it's great to have backups on electronic media, but I want
something for my purposes that doesn't depend on power to be saved, so on a regular basis
I will burn my website backups, the files and the database backups to cd or dvd, it used
to be cd, now it's gotten so big that I'm usually burning it to dvd, I do not compress them
usually when I do this, media is cheap, if I have to do a restore, it's a lot easier for
me, just open up the cd and find the file as opposed to copy the contents of the cd onto
a hard drive, then decompress the file, then look for the one I'm looking for, the other
thing I commonly do is keep at least several layers of backups on my hard drive for ready
access, commonly at least three, sometimes more depending on how industrious I've been,
if something happens and I go to backup number one and it's no good, I can go to backup number
two, even to backup number three, if I have to, so far I've never had to do anything quite
that drastic, at least not since that crash that I mentioned early in this podcast, so this
is in short what I do to backup and maintain my blog site, I download copies of all the website
files at time and creation after significant modifications, I regularly do routine database
maintenance in the form of a check, repair and optimize, and regularly export the database into
SQL files, download the SQL files, and then burn these to cd or a dvd for archiving purposes,
if I were again a business or some kind of huge organizational entity, I would automate this
much more so than I've done so, but from the standpoint of you as a hobbyist who's trying to
maintain your own blog and first getting started, I think these guidelines will help you protect
the integrity of your data and the integrity of your databases. See the show notes for links to
WordPress articles on database and site maintenance. Thank you very much for listening,
and I hope to be back here at HPR soon. If you want to email me, you can email me at frank
at pineviewfarm.net, pineviewfarm is all one word, no spaces, no punctuation,
and my website is www.pineviewfarm.net. Thank you very much.
You have been listening to Hacker Public Radio at Hacker Public Radio. We are a community
podcast network that releases shows every weekday on day through Friday. Today's show,
like all our shows, was contributed by an HPR listener by yourself. If you ever consider
recording a podcast, then visit our website to find out how easy it really is. Hacker Public Radio
was founded by the digital dog pound and the infonomicum computer club. HPR is funded by the
Pineview Revolution at binref.com. All binref projects are crowd-responsive by linear pages.
From shared hosting to custom private clouds, go to lunarpages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under a creative comments,
attribution, share a like, details or license.