All posts by Michael Asherman

WordPress

categories of posts in WordPress

The initial WordPress installation includes only one special posting category, “Uncategorized”, which is automatically assigned to every post, unless some other category is specified.  I’m adding “WordPress” as a new category, and assigning my initial postings to this category.  (When I switch to posting on another topic, I’ll create another category to cover it, etc.)

Reassigning multiple previously “Uncategorized” posts to a new category is rather tedious, because there isn’t a bulk operation that handles un-assignment from a category.  For that matter, it’s not entirely convenient or obvious how to do a bulk category assignment.  In the Posts screen, the first step is  to place a check-mark in the leftmost column on each posting of interest.  Then select Edit from the drop-down list entitled “Bulk Actions”.  Then Click “Apply”.  This brings up a bulk edit section in the Posts page, which includes a list of category check-boxes.

Unfortunately, while categories can be assigned to multiple posts through the bulk edit interface, it does not support a bulk un-assign or re-assign capability.  The upshot of this is that I might as well go through postings manually, one at a time, and use the “Quick Edit” command against each individual posting.  This method does support both checking and un-checking category assignments properly, and the lack of a bulk reassignment operation is no big deal since I’ve got only a handful of posts to process.  The lesson from this, though, is that it would be best to select categories carefully, in advance of making any great number of postings.

Related references:

WordPress

links in WordPress

Not to be confused with the “Link” format of posting, WordPress supports a fairly elaborate mechanism for defining and categorizing what it calls “Links”.  The purpose of these is somewhat obscured by the fact the default WordPress configuration doesn’t enable their display, although it provides a conspicuous group of Links administration facilities in the WordPress Dashboard.  There is also a sampling of links to various official WordPress resource pages, assigned to the link category “Blogroll”, but where are these links supposed to appear?

The answer is that WordPress Links are used to display a “Blogroll” on your home page, but you need to enable this feature by going into the WordPress Dashboard’s Appearance, Widgets screen.  In that screen, drag the Links item from the “Available Widgets” area into the “Main Sidebar” area at the desired position relative to the other widgets listed.  Now your site will show a new section of the main sidebar, with heading “BLOGROLL”, listing the provided sample of links to WordPress resources.

WordPress Links can be categorized, for example “Blogroll” is just the default Link Category, but you needn’t use that category name, and you can define any number of additional Link Categories.  Link Categories, however, are distinct and different from categories of Posts.  Unlike posting categories, link categories have no hierarchical structure, so it might help to think of link categories as being more like a special type of tags. What the Links widget does is simply to list each link category as a heading in the sidebar, and under that heading to display the links assigned to that category.  Link categories are listed in alphabetical order, and links under each category are listed alphabetically by link name (by default – there are additional options for the Links widget).

The preceding remarks apply to WordPress under the Twenty Eleven theme, using WordPress 3.4.2.  Other WordPress themes may deal differently with Links, and there are a variety of WordPress plugins available, for more flexible and sophisticated ways of presenting links.  Here are some helpful references about WordPress Links:

WordPress

sample post using “Link” format

Link 1 Comment

The Link format of posting is another compact flavor of posting, very similar to the Aside format, except that it displays the heading “LINK” instead of “ASIDE” in the main blog page or archive page in which the entry is listed.

What http://codex.wordpress.org/Post_Formats says about this format:

link – A link to another site. Themes may wish to use the first <a href=””> tag in the post content as the external link for that post. An alternative approach could be if the post consists only of a URL, then that will be the URL and the title (post_title) will be the name attached to the anchor for it.

WordPress

sample post in “Aside” format

Aside 1 Comment

Here’s a post originally created using the “Aside” format under WordPress 3.4.2 with the default Twenty Eleven theme.  Note the more abbreviated listing for this type entry in the main blog page.  Here are some differences from the Standard format in the way that the Aside format posting is listed in the main blog page and various archive pages:

  • the entry just has “ASIDE” as its heading, instead of the actual post title
  • there is no comments bubble on the post heading line
  • the original posting date is shown at the bottom of the post, instead of the top
  • there is no indication of category or tag assignments for this post
  • the only link to the separate post page is the one attached to the posting date

The corresponding post page does display the post title, categories, tags, and author, in the same way as a Standard format posting does.  Note, however, that the page for this individual posting does not provide any indication that it is an “Aside” format post.

What http://codex.wordpress.org/Post_Formats says about this format:

aside – Typically styled without a title. Similar to a Facebook note update.

WordPress

sample post in “Standard” format

1 Comment

This is the default posting format, using WordPress 3.4.2 with the default Twenty Eleven theme.  Note the prominent font used to display the post title, and the bubble at the right of the title in the entry for this post on the main blog page.  If there are comments, the bubble displays the number of comments, and it links to the place where comments are listed and a form is provided for entry of new comments, on a separate page devoted to this single posting.  The original post date is automatically shown below the title, and you can see the exact time of this posting by hovering the mouse over the date.  (This date and time correspond to the initial posting, not to any further updates that may have been made to the post.)  On the main blog page, the post title links to its corresponding page, and this link is also attached to the posting date displayed below the title.

Below the text of the post, there is another automatically generated line of information, which shows the categories and tags that have been assigned to this post.  The main blog page doesn’t display the author, but this is shown on the separate page for this post (with a link to the archive page of all posts by that author).

(See http://codex.wordpress.org/Post_Formats for more about available posting formats.)

WordPress

WordPress site backup

Whenever I begin using a new development tool, one of my first tasks is to understand how to backup my work and then actually test the backup and restore procedures.  Of course, our web hosting service performs its own regular backups, but I am not content to rely exclusively upon that.  I want to be in control of my own, deliberate backups as well.

The HSphere Control Panel (version 3.5.1) provided by our web hosting service includes a button for launching phpMyAdmin (version 3.5.3), which can be used to generate a backup of the entire MySQL database supporting our WordPress web site.  There is a WordPress Codex page that describes how to use the phpMyAdmin facility, but this documentation is somewhat outdated.  Here are the steps I’ve been using, attempting to reconcile outdated WordPress Codex information with phpMyAdmin 3.5.3:

  1. Launch the HSphere Control Panel for my web site.
  2. Click on the phpMyAdmin icon – this launches in a new browser window.
  3. Select the site’s WordPress database, listed at left on the phpMyAdmin screen.
  4. Click the Export tab.
  5. Choose the option “Custom – display all possible options”.
  6. Under “Output:”, choose “Save output to a file”.
  7. Under “Object creation options, Add statements:”, check the option to “Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT statement”.
  8. Also under “CREATE TABLE options:”, check the “IF NOT EXISTS” option.
  9. Leaving other options at their default settings, click the Go button.
  10. In the Save As dialog, navigate to the desired local directory and save the generated .SQL file.

The resulting .SQL file is just a type of text file, more readable in WORDPAD than in NOTEPAD, because of line termination issues.  The initial size of this file, uncompressed, was 267KB, i.e. well under 1MB.  As the size of this file increases, I will use one of the available compression options that phpMyAdmin supports, e.g. to produce a much smaller ZIP file.

WordPress supports its own administrative facilities for Export and Import (under the Dashboard’s Tools menu), providing a convenient sort of backup/restore capability, although that is not their primary intent.  These commands are mainly intended for moving content from one site to another, including support of many non-WordPress blogging systems, using a special type of XML file representation.  The resulting files are much more compact (initially just 7KB) and readable than the MySQL database dumps generated by phpMyAdmin, but they constitute a less complete form of backup.  Here’s an excerpt from Export screen about WordPress’ XML file format:

This format, which we call WordPress eXtended RSS or WXR, will contain your posts, pages, comments, custom fields, categories, and tags.

Aside from backing up the site’s WordPress data, there is also the matter of backing up its installed programs, plugins, etc.  While our hosting service handled the installation, and they may take responsibility for WordPress updates, I thought it advisable to make a backup of the entire initial WordPress installation.  This was easy to do via FTP in one fell swoop, although it took a fair amount of time to work its way through the entire WordPress sub-tree, which contained 1,755 files in 118 folders, totaling 13.1 MB.  (With ZIP compression this reduced to 5.49 MB.)  I don’t expect to perform this type of FTP-based backup on a regular basis, but it seems like a good idea to do it again after installing any new WordPress plugins.

Related references:

WordPress

converting site from FrontPage to WordPress

IdeaXchg started as a FrontPage-based web site on a shared Linux host, running Apache web server.  At long last, prompted by an Apache upgrade that no longer supports the FrontPage Server Extensions (FPSE) and years after Microsoft stopped supporting FrontPage, we’re migrating to WordPress version 3.4.2.  Our web hosting service supports WordPress at no extra charge, and they handled the WordPress installation, providing us with a new “wp.” subdomain in which to experiment with WordPress without disrupting the old FrontPage-based portion of our web site.

As an introduction to WordPress, I’ll begin by exploring its features and using them to make a series of postings about the experience of learning to use WordPress from scratch.