Getting Started with WordPress

Tips for getting your WordPress site off the ground.

This post is a compendium of “lessons learned” in the process of building this site, with the spectacular assistance and training from Nicole C. Scott.

Copyright © 2017, TreeLight PenWorks

Initial Setup

1. Post titles: Appearance > Theme Options > Blog > Custom post-page title: Off
   • So the title of the post appears in the banner, rather than “blog”.
   • Although the banner text seems small, it’s still an H1, which satisfies the SEO requirement.
2. Permalinks: Settings > Permalinks > Custom
   • You should decide early on (before migration) whether permalinks will be something like /%postname%/, or whether you want /%category%/%postname%/.
   • Reason: All links to other articles change when that setting changes, and that is not a change that can be automated afterward.
3. Project pages: Appearance > Theme Options > Portfolio
   • You should decide early on what the portfolio permalink slug should be.
     (Default is ” portfolio-project”. A better generic option is “project”. Even better
     is something specific to your type of projects: “books” maybe, or “publications”.)
   • Same reason as above: Links to project pages will change in posts and other pages. (That change could be automated later, but it’s easier to make the decision first.)
4. Media Plugins?
   • You might think that you need some Media Library plugins to help you manage media assets, but most of the time, it will turn out that you don’t. (I expected I was going to need them, but was happy to find out that my expectation was — mostly — incorrect.)
   • But default, the library is sorted so that that the most recently-uploaded files are at the top of the list. That makes it easy to find them when you are interesting recent uploads into a post.
   • If you have images that you need to reference regularly, it can be helpful to add categories to the library, for example with the Media Library Categories plugin BUT… while that plugin will let you categorize media items, you can’t use those categories to find things, unless you upgrade to the paid version. Moral: Don’t worry about it until you absolutely, positively need it.
   • The ability to upload different types of files may be needed for content migration, but there is typically little need to worry about it, because WordPress supports so many file types.
     • When you choose to upload files, the files you see are filtered. Any files you can see are files you can upload.
     • Supported file types include images, PDFs, .txt files (text), .lst files (a suffix I use for text files that contain lists), and Excel spreadsheet files (.xls and .xlsx), Word files (.doc and .docx), .mp3 audio files, .mid MIDI files, .zip and .gz archive files, among others.
     • These file types generally wouldn’t upload, and they didn’t seem to be handled by the WP Extra Files plugin, so at the moment I’m uploading them in zip files. (There are also more complicated plugins that say they are more powerful than the regular media manager, but I’m not prepared to go there yet)
       • .abc music notation files
       • .rb and .java program files
       • executable .bat and .exe files, Windows .dll files, and Java .jar files (which may be executable)
       • .sdr (SmartDraw) and .eddx (Edraw Max)  graphic source files
       • .xml files, .ps (postscript), and .svg (xml graphics) files

Getting Started

Avoid Plugins

Avoid adding plugins, at first.

• The reason: They’re more dangerous, and you may find that as you learn more, you don’t need the plugins you thought you did.
• There are also important things to know about how to choose plugins and add them, covered later.
• The exceptions are plugins that are vital to the migration process:
  • Media plugins, if needed
  • An editor plugin that gives access to tag attributes for styling (I use tinyWYM)
• The best solution is get someone who knows what they’re doing to add those at the outset.

Learn to Make Backups

• Backups for content and theme styles turn out to be quite easy, which lets you begin customizing some things right away. That way, as long as they’re careful, you can begin to get things they want them to look. (More important for someone migrating an existing site that someone who is creating a new one.)
• Site Format: (theme options)
  • The Invicta theme I use lets you backup format options with a single click.
  • wp-admin > Appearance > Theme Options > Backup
  • When you click the backup, you replace the last backup.
  • Another button lets you restore the last set of options you saved.
  • Notes:
    • Other themes may have the backup capability in a different location.
      Wherever it is, find it. If your theme doesn’t have that option, find one
      that does. This is an important capability that lets you make changes safely.
    • Theme options are saved as part of a big wad of PHP files that make up a WordPress site. It’s hard to figure which file is affected when you make a change. And when you do, you need to use FTP to save a copy of the file to your local system. So the ability to save option changes with a single click is a huge time saver.
• Site Content:
  
  • The Siteground system that hosts my site uses cPanel to manage the site.
    Content backups are made there. (Other sites may use a different mechanism. Find it.)
  • cPanel > Backups Manager > Create Backup > WordPress Database
  • This step creates a SQL file (database content) that you download and
    save on your local file system.
  • Another button lets you restore the database from a saved file.
  • Notes:
    • While theme options are saved in configuration files, content is stored in the WordPress database. So you backup your content by saving a copy of the database.
    • Another option for saving content is the Export capability. That option creates an XML file that can have everything in it, or things you select:
      wp-admin > tools > Export
    • That option is useful when migrating to another site, but it’s also a good way to preserve a copy of your content that is not database-dependent.

Alternate Activities 

At first, limit your activities to one kind of change each day: Content Migration, Site Format, or Plugins.

• Siteground creates a full site backup every day. So if you royally screw up the site,
  you can always ask them to restore yesterday’s version of the site. (Most hosting providers do so.)
• You’re not going to screw up the site by creating content, and it’s unlikely you’ll do so modifying theme options, so unless you’re modifying site files directly using FTP, the only significant potential danger is from plugins.
• When you go back a day, you go back to the content you had on that day, as well as the formatting and plugins you had. If have to go back, you get the content, format, and plugins you had on that day. Similarly if you have to go back a week.
• Doing format changes one day and content changes the next means that you can restore the site from the previous day without worrying about lost content. (You could do them on the same day, if you make backups for each, but you’ll save your sanity if you have separate lists for format changes and content changes — and it will be easier to keep track of what you did, when.)
• The nice thing about your content backups is that you have several of them, and they are cumulative. So if you have to go back a week, and you have 3 content backups, the last one includes the changes made in the first two, the one before that includes the changes made in the first, and so on.
• But if you you need to back a week, the “theme options backup” you made yesterday will no longer be available to the theme. That’s where change lists come in (discussed next).

Change Lists

• As you’re changing formats, you’ll see content changes that are needed. Add them to a list.
• Similarly, when you’re making content changes, you’ll see format fixes. Add them to a list, as well.
• Each time you make a change, move the recorded item to the “Current Change” list, or create a new item for the change you made.
• I like to make a dated list in normal font, so “20 Mar 2017” with bullet points under it that record the changes I’m making. Then, when I make a makeup, I’ll turn the heading bold: 20 Mar 2017. That way, I have a record of what I did each day, and it’s easy to see where the backups were taken. (At the start, I’m backing up every day! As I grow more confident,I’ll change to weekly.)
• That list acts as a backup, as well. If at some point it turns out that site has been hacked, or was corrupted in some other way, you can always go back to a previous point in time from a backup (the day before, for example, or the week before). The Change List then lets you step through the changes you made in the interim, to get your site back up to where it was.
• For example, as nice as the backup option is for theme options in Invicta, it doesn’t include custom CSS, or other settings outside of the Appearance > Theme Options menu (of which there are many). So a good list of format changes is a good way to back up those changes.
• I keep the CSS backed up in an EverNote change list. At the top of the page is the menu path to the CSS, followed by the complete CSS — so it is easy to restore whenever I need it. Below that is the list of changes, in reverse chronological order. Each item in that list describes the change that was made, with additional bullet points under for more detail, if needed.
• After making a change to the CSS and testing it, I copy the CSS to the CSS at the top, so I can restore it or replicate it elsewhere in a moment. Then I add an entry describing the change to the change list.
  

  Note:
  It is typically the case that deciding what to do and figuring out how to do it is what takes the most time. So reproducing changes takes only a fraction of the time it took to make the changes in the first place — as long as you have the change list. If you don’t have that list, it can take longer to recall the changes you made than it originally took to make them!

• In the early stages, record not only the change you made, but the place you made it, as well.
• Later, you might write “set date format”. But early on, it makes more sense to record the places you made that change, and the setting you used. For example, I like the European date format (27 Mar 2017). And I had to look up the settings to use to get that format. Then, as I was stepping through the customization options, I wrote:
  • Current: Format Changes
    • Settings > General > Custom Data format: j M Y
    • Appearance > Theme Options > Blog > Date Format: j M Y
• Those notes form a preliminary knowledge base — things you can refer to later, if you want to back out the change. (At the beginning, especially, you’ll stumble across things you’ll have a hard time finding later. Your notes give you a way to get back to that cool setting you found.)
  

  Tip:
  As in this post, I highlight WordPress paths in bold so they’re easy to find later, when I’m looking for them.

• They also form a backup. If a change totally screws things up, you can always go back to the last saved version (either yours or Siteground’s), to re-do the changes.
• That statement is particularly true for theme options. Suppose the site is hacked, or corrupted, and you have to ask your host to restore the system to the way it was yesterday, or last week. When you do that, everything goes back to the way it was on that day — config files, database — everything. In other words, the “options backup” that the Invicta theme has stored is not the one you made an hour ago, but the one that was in place on that day.
• You don’t mind about the database. You can then upload your stored SQL file to recover the content you had yesterday. If it was the files that were problem, you now everything back except for the theme settings. (At that point, you’ll be glad that theme changes are clearly separated from content changes, as they will be easier to find and apply.)
• On the other hand, if it was the database that was the problem, you’ll need to do a lot of work to recover your content. So backing up your database should happen once a week, at least. (Or whenever you have added more than you would like to lose!)

Change History

• After making a backup, change the title “Current Changes” to the date the backup was made.
• So if the backup for format changes was made on 27 Mar 2017, change “Current Changes” to that date. (That list will only have format changes, remember.) At the same time, identify the type of changes that were made (Format or Content)
• Once you’ve made a format backup, confine yourself to Content changes, until you’ve made a Content backup, etc.
• As with change lists you see on software updates, the lists are easiest to manage if the most recent changes are at the top. That way, you’re not constantly scrolling to the end of the file.
• As each set of changes is backed up, you get a list that looks like:
  • 27 Mar 2017: Format Changes
    • …changes…
  • 23 Mar 2017: Content Changes
    • …changes…
  • 22 Mar 2017: Content Changes
    • …changes…
  •  20 Mar 2017: Format Changes
    • …changes…
• Note that you can have multiple Content changes in a row (or multiple Format changes, if you want)–but since only the latest format settings are backed up, it’s a good idea to let the most recent changes sit for a day or so as you use the site, to be sure you like what you have before you replace your backup.
• The Current Changes section is above that, ready to become part of the change history when changes are saved.
• Above that is a list of “Fixes Needed”.
  • As you’re working in one area, that’s where you record things you plan to work on next, in the other area.
  • Or maybe you’ll have two sections: Format Fixes Needed, and Content Fixes Needed, since you’ll probably make notes for things you want to change, but don’t yet know how, or if you even if you can.
• At the top of the page is the dates for the last backups, along with the directions, so I don’t have to think about how to do it.
• So in the end, the “Backups & Change Lists” notes look like this:
  • Backups
    • Theme Options
      • wp-admin > Appearance > Theme Options > Backup
      • Thu 16 Mar 2017 — {summary of the changes}
    • WordPress Database
      • cPanel > Backups Manager > Create Backup
      • Thu 16 Mar 2017 — c:/{path-to-the-file}/{database-name}.sql.gz
  • Fixes Needed
    • …
  • Current: Format Changes (or Content Changes)
    • …
  • 27 Mar 2017: Format Changes
    • …
  • 23 Mar 2017: Content Changes
    • …
  • 20 Mar 2017: Format Changes
    • …

Next Steps

1. Adding and Updating Plugins
2. Content Migration

Copyright © 2017, TreeLight PenWorks

Please share!