Category Archives: WordPress

movies, WordPress

Movie-Mine goes responsive

We’ve just completed overhauling the Movie-Mine web site to achieve what’s referred to as Responsive Web Design (RWD). Put simply, this means the site now is reasonably usable on a wide range of browsers and devices, such as smartphones, tablets, and desktop computers. As the screen or window size changes, Movie-Mine pages automatically rearrange themselves to make sensible use of the available display space, while keeping the sizes and spacing of various elements clearly organized and legible.

Now you can use Movie-Mine with your smartphone to help select a movie in the comfort of your bed, or at your local video rental store – if you are lucky enough to find one. When you are at your desktop computer you can use the extra screen space to build and massage your own watch list of potential viewing candidates, and review various sources of ideas, top movie lists, etc. Also use your phone or tablet to quickly make note of personal recommendations and tidbits of information you happen to run across. Regardless of how you get to it, Movie-Mine keeps track of your own notes and annotations, attached to any of the more than a hundred thousand movies in its datase.

The technology for Responsive Web Design

In the olden days, the more sophisticated web sites tended to use highly styled, fixed width layouts, designed to look best at some particular page size, e.g. 640X480 pixels, and then progressively larger sizes as typical displays evolved to higher resolution.  To view those sites in a smaller window, you’d have to scroll or pan to see the rest of the page, or zoom to a smaller font size. Then browser-enabled smartphones came along, and things got more complicated. At first, only companies with big budgets could afford to create alternative mobile designs and deal with complex browser and device dependencies.

Fortunately, by the time we confronted this problem, the concept of Responsive Web Design and readily available technologies supporting it had become well established. Google is pushing RWD in a major way, understandably since it’s very much in their interest. Google provides some very useful assistance to developers, including these indispensable tools:

Also note that Google Chrome’s built-in Inspect tool is extremely helpful, especially with regard to understanding CSS, and it has a handy tool for previewing a web page as it would display in a variety of mobile devices. For a good introduction to RWD, start here:

I should add that W3Schools is an excellent general reference on a wide range of web technologies. I found it very helpful in getting acquainted with RWD, and it was worthwhile to have gone through the RWD topics in the sequence they presented them. But I almost missed the somewhat understated grand finale that follows their simple RWD framework called W3.CSS. No, W3.CSS is instructive, but what I really want is Bootstrap! As it turns out, W3Schools is built on the Bootstrap framework, and they have plenty of documentation about it here:

For the most complete and authoritative reference, get it straight from the horse’s mouth:

Naturally, this is a Bootstrap-based web site.

It is reassuring that Bootstrap is very widely used, and it has evolved over a number of years as a framework for building web user interfaces and dealing with cross browser compatibility. It’s much more than a solution to the RWD problem, which was my original motivation for looking into it. With Bootstrap, you get the tools to easily build higher-level constructs like menus, modal dialogs (aka modals), and other essential web components that go one level beyond what you get from basic jQuery. Since I hadn’t yet decided on a set of UI components, I was delighted to discover that I got those for free from Bootstrap!

Bootstrap is a relatively “lightweight” framework, providing a high degree of flexibility without imposing undue complexity and constraints on the developer. By contrast, a framework like WordPress is not what you’d call lightweight. I quickly discovered the morass of complexity one must deal with to create WordPress templates, which are required for any serious degree of customization of WordPress – even the addition of a single line of JavaScript. That isn’t intended as a put-down of WordPress – after all this is a WordPress-based blog. But Movie-Mine would not have been better or easier to build with WordPress.

WordPress

security administration on a shared Apache web server

Running WordPress on a shared Linux web server is an economical way to build a web site without the hassle and expense of maintaining a dedicated server.  However, there are some useful administrative and security functions handled by the host’s Apache web server software configuration, beyond the scope of what is provided by WordPress.  While the main server configuration files generally are not accessible to users whose web sites reside on a shared server, Apache supports a powerful mechanism, .htaccess files, which can give individual users of shared web servers a high degree of control over the security and configuration of their own domains.

In my case, the immediate problem was to find a substitute for FrontPage’s directory-oriented password protection facilities.  In FrontPage, one would create a private “sub-web”, and the FrontPage Server Extensions (FPSE) provided an interface for registering users and assigning them passwords.  My problem was to continue supporting this simple model of access control (which uses the Basic Access Authentication protocol) without depending on FPSE.  This is not the sort of access control that is governed by WordPress’ blog-oriented administration features, but it’s an extremely simple application of Apache security features that can be implemented through .htaccess.

Because .htaccess files have many options and a rather obscure syntax, they can be quite confusing and intimidating.  There are many published tips and tricks on the use of .htaccess – so many that it can be hard to know where to begin.  Before you curse the complexity of .htaccess, though, remember that this mechanism spares you from the vastly greater complexity of managing your own web server, and it gives you a high degree of administrative control over your own web site running in a shared server environment.

An instructive illustration can be found in the solution to my problem of using .htaccess to replicate the access control features that were supported by FrontPage.  The only tool I needed to use was the WebShell file and directory management facility of the HSphere Control Panel, a standard feature offered by my shared web hosting service provider.  (An essential capability of WebShell that was missing from the free FTP program I’m accustomed to using is the ability to see .htaccess files at all – these and other files whose names begin with a period are not displayed in my old FTP utility!)

Using WebShell to peruse the residue of my semi-defunct FrontPage site, I could see that FrontPage’s implementation of password-protected sub-webs actually was based on the .htaccess mechanism.  The root of the password-protected sub-web contained a .htaccess file, and this referred to a standard type of encrypted password file, named service.pwd, residing in FrontPage’s hidden _vti_pvt subdirectory.  Even after the FrontPage Server Extensions ceased to operate, this access control mechanism continued to function properly.  But without the support of FPSE, it was unclear how to go about registering new users or making any other changes to my site’s password protection.

After wading though Apache documentation and various references, here’s what I came up with.  In the directory I wanted to protect I created a new .htaccess file containing this:

AuthType basic
AuthName "Montage subscriber area"
AuthUserFile [server path to password file]
Require valid-user

where [server path to password file] is the local path specification of my encrypted password file within the server filing system.  As for the password file itself, this is a text file containing entries of the following form:

joeblow:Fkazbh7cTThEY
anotherguy:dG6P5gnDxmj6M
user3:rvjN72pVDm4/w
user4:F11OoK8hj8QVo
user5:BhTY9V0rN7FKU
user6:WsmJQwNBm3rOs
etc.

I.e. each line begins with a username, followed by a colon, followed by the user’s encrypted password.  But where do the encrypted passwords come from?  There are a variety of ways to get these, including free online forms that can generate them for you.  Strangely, most of these free services also ask you to provide the associated userid, even though this should not be necessary, since the encryption depends only on the password, not the userid.  Another alternative is to create a simple PHP program, which can generate and display a valid encryption for a given password.  (Note that the encryption is really a hash, and its value is not unique.)

I was able to copy lines from my old FrontPage-generated password file, and these entries worked fine, even though I moved, renamed, and edited the password file.  For the problem of adding new users and passwords, I discovered that the HSphere Control Panel’s WebShell interface makes password file maintenance even easier, using its “Protect Wizard”.  This facility simplifies a number of basic .htaccess maintenance tasks, including the creation of encrypted password file entries in conjunction with adding, deleting, and modifying registered users.  Sheesh – if I had understood this in the first place, I’d never have had to learn as much as I did about the wonders of .htaccess!

Related references:

Here is a sampling of additional references about .htaccess tips and tricks:

WordPress

migrating to WordPress – the easy way

As of December 5, 2012, the IdeaXchg home page became a WordPress-generated blog page.  Previously, the entire site was created and maintained through FrontPage, but this became increasingly cumbersome and outdated, since Microsoft stopped supporting FrontPage long ago.

I was not looking forward to the daunting prospect of converting lots of old pages into WordPress, but I did want to preserve much of this old content, at least for the time being.  So what I’ve done is simply to keep many old pages at their old URLs, while replacing the site’s old home page with the new WordPress-based home page.  This allows me to use WordPress, while simultaneously keeping most of the old site exactly as it was, for the benefit of search engines and visitors.

As a former user of FrontPage, it was not immediately obvious that this simple approach, intermixing WordPress and non-WordPress content, could be done so easily, because FrontPage is notoriously finicky about such games.  Any addition of content to a FrontPage web has to be done through FrontPage, or one risks disastrous consequences.  Barring any obvious naming conflicts, there is no such danger with WordPress.

Of course, I’ve only punted on the conversion of old pages into WordPress, but that’s OK with me – I’m no purist.  The site didn’t get any worse than it was before, and now I can convert what old pages I care to in my own sweet time.  Meanwhile, I’ve gained immediate access to the full power of WordPress.

It should be noted, however, that the WordPress Search Widget does not encompass any non-WordPress content.  I can live with that, since my FrontPage-based Search pages stopped working a while ago, and Google search within site is more than adequate.

related references:

WordPress

non-blog pages, templates, and menus in WordPress

1 Comment

Although WordPress started out as a blogging tool, it has evolved into a general purpose content management framework.  The Twenty Eleven theme includes three template “Page” types, which I’ve illustrated here:

For historical reasons, WordPress uses the overloaded term “Page” for what might better have been called an “article”.  In WordPress, a Page refers to an item of content that is not a blog posting.  By default, these article pages are organized into an automatically generated menu structure, tied to the main menu bar at the top of each page.  The default menu organization is based on the hierarchical relationship and ordering assigned to each page, and the menu item text (navigational label) is simply the article title.

Substituting a custom menu instead of using the default menu scheme provides much greater flexibility.  (Use the Dashboard’s Appearance, Menus command to get to the menu customization screen.)  For example, you can customize the text of menu items, so they needn’t match article titles, and you can incorporate blog posts, archive pages, and types of content other than article pages into the menu.

You can build a custom menu organization that does not depend on hierarchical, parent-child relationships specified with the article pages themselves.  This avoids potentially undesirable complications due to the way that WordPress assigns URLs (permalinks) to pages.  When a page is specified as having a parent, the assigned URL is the parent page URL, followed by a slash and then the title of the child page (i.e. the “slug” form of the title).  This results in a longer URL, and one that is less likely to be stable under reorganization of the site.  For that reason, I’ve avoided using WordPress’ page hierarchy mechanism, by designating “no parent” for each of my pages.

Related references:

WordPress

paragraph formats within a post

1 Comment

Here are illustrations of the canned paragraph formats listed in the Paragraph dropdown of WordPress’ builtin WYSIWYG editor (in Visual mode):

This is the default Paragraph format.

This is Address format.
This is Preformatted.

This is Heading 1.

This is Heading 2.

This is Heading 3.

This is Heading 4.

This is Heading 5.
This is Heading 6.

This is the default Paragraph format (again). Using the default Twenty Eleven theme, it appears that only some of these paragraph formats actually look different from each other.

WordPress

embedded video post

1 Comment

Here is an example of a video embedded in a standard format posting:

All that was required was to include the URL to a YouTube video on a separate line in the text of this post.  The WordPress documentation about posting formats lists “Video” as one of the possible choices, but that choice was not presented to me in the Add New Post or Edit Post screens.  (I’m not sure if the documentation is outdated in this regard.)  Since WordPress’ auto-embed mechanism (enabled by default) seems to do a nice job within the Standard posting format, I didn’t need to specify the mysterious Video format.  See the Settings, Media screen for WordPress options relating to Embeds.

Related references:

WordPress

sample post in “Image” format

Image 1 Comment

Text of Image format posting.  Link to an external Hubble image follows, including title, alternate text, and caption:

M1 - composite of Crab Nebula - CXC, SST, HST, 350X321.jpg
M1 – composite of Crab Nebula – CXC, SST, HST, 350X321.jpg

Here’s some more text that immediately follows the image.  Note that the optional caption appears in the surrounding background area, below the image.  I elected to have the image be a clickable link directly to the source image.  (By default, clicking on the image itself does nothing.  I could easily have specified any destination URL for a click on the image, with the option to open in a separate window.)  This format of post renders all of the elements that show up in standard format, with the addition of “IMAGE” above the title in the heading that appears in the main blog page and applicable archive pages.  Another difference from other formats is that the additional information below this type of entry includes the posting date, and this is shown against a distinctive, rectangular background.

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

image – A single image. The first <img /> tag in the post could be considered the image. Alternatively, if the post consists only of a URL, that will be the image URL and the title of the post (post_title) will be the title attribute for the image.

WordPress

sample post in “Quote” format

Quote 1 Comment

Here’s the text of a sample posting in Quote format.  Under the Twenty Eleven theme (as usual), this format is rendered in the same way as a Standard form posting, except that it adds the heading “QUOTE” above the post title in the entry for this post that appears in the main blog page and applicable archive pages.

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

quote – A quotation. Probably will contain a blockquote holding the quote content. Alternatively, the quote may be just the content, with the source/author being the title.

WordPress

sample post in “Status” format

1 Comment

Text of sample Status format posting.  Note that the title, category, and tags are not displayed in the entry for this post that appears in the main blog page, but they are shown on the page devoted to this post.  Also note the default “avatar” image, which was added automatically in the main blog page entry for this post.  This avatar image also shows up in my assorted comments to various posts.  The default avatar can be changed via the Dashboard’s Settings, Discussion screen.

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

status – A short status update, similar to a Twitter status update.

Related references: