WordPress

XML-RPC is a protocol that allows third-party applications like Windows Live Writer and Ecto to post to a system supporting it. In this case, WordPress is the application that supports XML-RPC, but the WordPress development team has decided that they will disable XML-RPC by default starting with WordPress 2.6.

Daniel Jalkut, founder of Red Sweater Software, LLC., believes that it might help with reducing security risks, but it might have adverse effects for those who use applications that depend on XML-RPC:

But in my opinion, there are also good arguments to be made for rejecting the change as a damaging and misguided solution.

First, and obviously near to my heart, is the fact that this marginalizes remote clients. For users who would find value in a remote client, this decision will put one more roadblock in their way. Historically, the remote editor interface is already compromised such that remote editors do not have access to all the same functionality as the web interface. With this change in place, things get even worse. While a screen-scraping application will easily log in and authenticate a fragile WordPress session via the web interface, the well-behaved API clients will be refused access by default. All in the name of improving security.

Second, and probably most important, is that this is not a fundamental security improvement.

As a user who personally likes to make use of the XML-RPC system, I must say that I am disappointed with this decision. I am not exactly sure of the security implications, but I do agree that the system should be fixed, not simply disabled by default.

Daniel also brought up made an excellent point about the security of WordPress:

Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!

Well, all that reflects my thoughts exactly.

Daniel does benefit from having the XML-RPC system enabled—he is the founder of the company that develops MarsEdit. It is in his company’s best interest for this feature to be enabled by default. So, there is a conflict of interest, but even though there is a conflict, I believe his points to be valid and his words to be truthful.

Of course, you could always just enable the XML-RPC option. It is fine for those who run their own blog, but in other instances, it could cause some serious issues and confusion.

What do you think about all this? Many of you who use desktop, browser, or any other third-party application to post content to WordPress will be affected. Voice your opinion!

Performancing is pleased to release its latest free WordPress Theme, Rubidious (Latin term for “deepest red”). As the name suggests, the thing that sticks out about this theme is the deep hues of red that it uses, which create a magnificent contrast to the white content area.

The left sidebar of this theme is well-suited for navigational elements and the right sidebar is perfect for recent posts/comments, advertisements, and other larger elements.

If you like dark red and want your content to “pop” then Rubidious might be a great WordPress theme for you.

Click here to preview the theme.
Click here to download the theme.

Should you use WordPress or Drupal for your next project—this is a common and fair question to ask. I have been using both content management systems, and both have their pro’s and cons. Planning for your project’s needs is critical in determining which CMS be sufficient.

Both content management systems are a pleasure to work with, but each one is better suited for certain demands. Overall, both WordPress and Drupal offer an amazing experience, but which one is right for you?

WordPress

WordPress is one of the most sought after publishing platform by new bloggers, and is unquestionably one of the most popular.

Pro’s

• Easy process for migrating to Drupal
• Simple install
• Many themes available
• Easily customizable
• Very stable
• Quickly ready for production
• Built-in image and media handling
• Popularity ensures third-party support will not be a problem

Cons

• Look elsewhere for community-based sites
• Extendable, but there are limitations
• Questionable security (but reasonable turnaround time on fixes)
• User roles are fairly restricted

Drupal

Drupal is an excellent choice for people that wish to create expandable and community focused sites.

Pro’s

• If you can think it, you can create it
• Amazing centralized community on the Drupal site
• Powerful, extendable modules
• Relatively easy to develop modules
• Easy API reference
• Fast growing
• User roles completely customizable
• New data types (nodes) are easily created and extended

Cons

• Difficult and time consuming task for migrating to WordPress
• The available themes leave much to be desired
• Management of the site can become a full-time job
• Lack of a built-in rich text editor (can be added with a module)
• Lackluster image handling

The Outcome

The simplicity and efficiency of WordPress is amazing. I enjoy knowing that I can install WordPress and be blogging within minutes. It is familiar to me, and it works.

WordPress has also come a long way to maturing as a proper CMS, and more websites are finding it to be a great way to handle complex sites. (Revision 3‘s latest site was built using WordPress.) With time, I slowly see the WordPress development community making changes to the back-end to allow more expandability—similar to Drupal, but it will never be able to outperform Drupal in this manner alone, that is, unless there is a complete re-write (which is highly unlikely any time soon).

The amount of effort it requires to manage a Drupal site might not be worth it. This is also true if you are juggling multiple blogs. It can be a handful, and this is not the ideal situation for plenty of people.

I would reserve use of Drupal to sites that will be more than just a typical blog. If you want to create a community around a blog, then Drupal is perfectly fine. If your site will be handling many types of media, and needs to be extendable for the future, then Drupal, again, is an excellent choice.

To sum it all up, if you want a system that will work without the need to extend your blog into something more in the future, use WordPress, but if you want a CMS that can act as a blog and so much more, consider using Drupal. Something to keep in mind is the fact that WordPress’s export functions would easily allow you to move to Drupal, if required.

Most of the time (when I’m not busy becoming a father, like in April) Performancing is committed to bringing you a free new WordPress theme each month.

This month’s theme is called The Story Theme. It’s a 3 column design where the content is situated to the far left, followed by two contrasting sidebars.

I’m especially fond of the look of the left-margin on this theme. It’s a nice touch that I’ve not seen in a theme before, but which adds a lot of class.

Check it out and let us know what you think!

You can preview the theme here.
You can download the Story Theme here.

[intermediate] If you only use videos once in a while on your WordPress-run site, this hack probably isn’t of much use to you. But if you embed videos regularly, you probably get tired of copying and pasting the embed code all the time. Another possibility is that you want your in-post videos to show only on permalink pages, not on the home page. You can satisfy those and other functionalities by using WordPress custom fields and a little bit of HTML/ WP PHP code to control how and where your video shows up.

Sounds complicated, but if you have even a little bit of experience with coding in WordPress (a combo of HTML and PHP, with WP functions and sometimes JavaScript), then process is relatively simple. I’m assuming below that you have some experience in creating a custom field. (There’s a snapshot below if you haven’t.) Let’s go through the first-time process:

1. From your WP admin panel, create a new post. Then create a custom field: “youtube_id”. (Once you create the custom field, it will be available to all other posts, old or new.)
2. Assign to the youtube_id field the id of the youtube video that you want to embed. It’s the value after the “watch?v=” in a YouTube URL. So if the url is http://www.youtube.com/watch?v=pxNGKICfi_g, the youtube video id is “pxNGKICfi_g”. This is the value you’ll enter (without quotations) into the custom field youtube_id.
3. Save the post.
4. Insert the custom code block (shown below) in your permalink template. Usually this will be in the single.php template file of your WP theme. Place the code where you need it. I like to place videos at the end of a post, but what you do will depend on your requirements.
5. Refresh your permalink (post) page and you should see the video embedded.

Those are the steps that you take the first time, for each unique custom field you create. The next time you want to use the same field in another post, you only need to do steps #2, 3 and 5.

The Technical Details

Here are the technical details for this process.

Creating a Custom Fields

Each time you create a custom field in WP, it will be available from other posts. If you’ve never done this before, just view the snapshots below.

Snapshot 1 (above): Create a new post and scroll down in the Write panel to the Custom Fields area. In the middle column, enter the name of the custom field you want to create. (In this case, youtube_id.) Then paste or type the field value for the post you are creating/ editing. (In this case, whatever youtube id you’d like. Remember not to enter the full URL of the video, just the id.)

Snapshot 2 (above): Click the “Add Custom Field” button and you’ll see the field and its value added. This field name will now show up in the custom field drop down menu in the left column.

Custom Fields Code Block

You can create whatever custom fields you want, but without some PHP code to manipulate them, and HTML code to display them, you’ll never see the results of the field values on your web pages. The code you need for the YouTube video embed is relatively simple:

ID, 'youtube_id', true))
  {
    $values = get_post_custom_values("youtube_id");
    $youtube_id = $values[0];

?>


} ?>

The first chunk, in PHP code, checks to see if the current post page has a custom field titled “youtube_id”. If it does, then grab the value of the field, save it into $youtube_id, and substitute it into the HTML code chunk below. There are two places in the HTML chunk where $youtube_id is used. The result when that HTML code is rendered is the proper YouTube embed code.

To use this code in your WP site, copy from above and paste into it your single page template file (usually single.php). The video size is the default YouTube size of 425 px wide x 355 px high. You can change this, of course, simply by adjusting those numbers in the HTML code block (both locations). YouTube will then resize the video upon rendering.

Example

At Posters@Filmscenic, I’ve set up a single page with video embedded. To see a page without video, look at the Leatherheads snapshot below.

Now look at the snapshot of The Ruins page, below, which has a YouTube centered under the poster.

In the case of Posters@Filmscenic, I inserted the code into “the loop” in single.php, just before the ratings stars code. If you download a copy of my single.php, you can see where the code has been placed, just near the top of a loop of code.

Hopefully this is a sufficient example for you to do something similar. Give it a try, and if you still have questions, drop a comment here and I’ll do what I can to answer.

My post Why I Hate WordPress 2.5, about the newly released version, touched a nerve. If I’m not mistaken, there were more people that disagreed with me than agreed, though most disagreers seemed to admit they were not power users. (Am I mistaken?). One person, whose very short comment was deleted, signed themselves “Fah Q”. (Pronounce it quietly, in case you’re at work.)

Obviously, some people took exception to my views, but I’d like to point out a few things: (1) The post wasn’t called “Why WordPress Sucks”; (2) I’m entitled to my opinion, and I did invite others to respond; (3) I still love WordPress. In fact, here are some of the reasons why I love WordPress, and will continue to love it over any other CMS/ blog platform:

1. It’s open source.
2. There is a lot of online documentation at the WordPress Codex.
3. There is community support through the WordPress forums.
4. There is additional peer support, thanks to all the bloggers who write tutorials. What other platform have you seen dozens of blogs spring up around? Maybe I haven’t looked for it, but in four calendar years, I haven’t stumbled across any slice of the blogosphere as dedicated to another platform.
5. WP is flexible and its use goes beyond just blogs, as per 48 Ways to Use WordPress.
6. You can implement advanced features, particularly via Custom Fields.
7. There is a plugin architecture and lots of third-party free and paid plugins. You can learn a great deal about creating your own plugins by studying what’s out there. This is a fast-track method over spending months poring over documentation.
8. There are literally hundreds (thousands?) of free themes. There are also many premium professional themes (some free), that make your site look like a magazine rather than a blog.
9. There seem to be far more designers online who can build a custom WP theme for you.
10. WP has true future-dating in the timestamp. (Though possibly not in V2.5, as I had difficulty with this version.)
11. Overall, WP has an architecture that you can very easily contribute to, learn from, and even making a living from, all the while enjoying warm community support.

Sure, other platforms have many of these features/ factors, but collectively, WordPress seems to be the only one that has them all. That’s why I picked WP and spent the last three years learning how to customize installations, and writing about some of my findings. (I’ve been posting numerous “WordPress Hacks” tips here at Performancing and will continue to do so. I’ll also be releasing some research-supporting WP themes.)

So do you use WordPress (self-hosted), and if so, what made you choose WP over other blog platforms? If you have a love for something other than WP, what is it, and why do you think your choice is better than WP?

[intermediate] Sonzy, a member of Hive, wanted to know, after moving a static HTML site to WordPress, how you retain the old URLs. That is, the old site’s URLs ended with “.htm”, and WP changes these to URLs based on postname and possibly the date, depending on how have WP permalinks set up. There are a few options, if your old URLs ended with .htm, .html, or other variations.

1. Use 301 redirect rules in your web server’s .htaccess file. Drawbacks:
   1. You are changing your entire site’s URLs. Doing this might incur a temporary SERPs (Search Engine Results Pages) penalty and changing your rankings. (I’m not saying this will happen, just that it might.)
   2. The average blogger might not understand .htaccess rules.
   3. The .htaccess might not be accessible through your hosting account. (Depends on the host.)
2. Use a WordPress URL redirection plugin. Drawbacks:
   1. This one is relatively easy to implement, but I’ve only ever tried it from within WP. That is, I didn’t move from a static HTML site. I already had a WP site and wanted to go from an old permalink URL structure to a new one. I haven’t tried it, but I think using a plugin will complicate matters in this case, unless you find a specific plugin designed to handle this.
   2. You are changing your entire site’s URLs. (See above)
3. Tweak the new permalinks and URL slugs in WordPress. This ensures that all your URLs stay the same as on your static HTML site. Drawback:
   1. Lot of manual work. Unless you know how to write SQL queries, you’re going to have to do this manually. (Even if you do know SQL, you may not want to use it.)
4. Install WordPress over top of your existing site. In the past, I’ve successfully had two different websites living on the same domain. One was a static site that had URLs with .html, and the newer site was in WordPress. This is a fairly simple upgrade. Drawbacks:
   1. The old /index.html page will still exist, but will not get served. That will be auto-redirected to / (your new WP home page). However, all the other old URLs will exist and be visible. So you’d have to manually port any content/ media from the old home page to the new one.
   2. Unless you change the layout of the old pages to match, they will have a different theme than your new WordPress site.

These are the options I’ve used to date, for moving from a static HTML site to a WordPress site. (This will apply for any platform that does not generate an /index.html for the home page.) Options 3 and 4 both retain the old URLs (with the exception of the old homepage for option 4).

If you’re dead set on changing your old pages to WordPress but want to retain the URLs, option 3 is what you want. (If anyone has other suggestions, please do comment.) However, if you have lots of posts, expect tedious porting work ahead. (Note: You could have a situation where a search spider comes along and indexes your new URLs and finds your old ones missing. I’m merely pointing this out, but I’m not sure what the likelihood of this happening, on average, is.)

Option 3: Manually Tweaking Your URLs in WordPress

Now to provide a quick overview of the process you might apply, to port a static HTML site to WordPress.

Assumptions:

1. Your static site’s URLs end with .htm (though other extensions should work).
2. You want to retain all old URLs when you move the site to WordPress.

Moving process:

This is a generic process. I’ll not get into the nitty gritty details unless someone asks.

1. Backup all your existing static content to somewhere other than your web server. Keep the old pages as they are.
2. Make a list somewhere in a file of all your old URLs, matched with each page’s title. Keep this file open, as a reference.
3. Install WordPress and configure it as you like.
4. Go into the “permalinks options” and adjust as necessary. E.g., if old URLs are of the form /this_is_page_1.html, then you can use the permalink option /%postname%/ (provided that the old URLs are partially based on the old page titles). If your old URLs used year and/or month and/or day, things get a bit more complicated, but the same general process applies. Just pick the most suitable WP permalink option, or customize as necessary.
5. On a post-by-post basis, compare your new WP URLs to the old ones. If they are all identical, you’re done. If not, go to step 6.
6. On a post-by-post basis, use the Write/Edit panel to edit the new WP posts. Change the post “slug” to match. (Depending on which WP version you’re using, it might be labelled “permalink”.) Manual changes to a post (or page) slug partially overrides the permalink options. (It does not affect any date, category, or post id segments of the URL.)

Keep in mind that in WP, URLs are assigned based on the title of the post or page, as well as which permalink option you’ve used. For simplicity of explanation above, I’m assuming that neither old nor new URLs have any dates in them.

Summary

Before deciding on the course of action, weigh out the consequences of each option, as well as the work you’ll need to do to port your site. If you’re not sure which permalink option to use, drop a comment here with a few examples of your old URLs and how you want them now. I’ll do my best to answer.

WordPress users might be wondering whether they should upgrade to the new WP 2.5 release candidate. There are lots of assessments so far, and most seem to be either neutral or negative. I used it early this week at one client’s site, who immediately did an upgrade. First impression: dislike the admin panel. Then just to test, I installed WP 2.5 on one of my own sites this afternoon. I’ve spent the past few hours tonight, screaming with disappointment, scaring my cat. Here’s why:

Specific Issues

These are some specific WP 2.5 issues that I’ve encountered tonight, while testing an installation.

1. Admin panel. I really dislike the new admin panel. They took a familiar layout, changed it, and even changed the names of some of the most important links. Why? There’s absolutely no reason for this. If it ain’t broke, don’t fix it.
2. Manage panel. The Manage panel is now missing important post information, which is now all hidden. So if I want to publish a whole whack of posts in sequence, it’s a right pain in the behind. Actually, it’s worse – read on.
3. Write panel. I despise the new Write panel. Not only has it been completely rearranged when it didn’t need to be ( and not very well), some of the features don’t work properly. It’s bad enough that the timestamp feature has been buried, but I also can’t seem to manually change the time stamp. I change and save the timestamp, but the Manage panel has buried timestamp info. When I mouse over the “x minutes ago” nonsense, I see the wrong timestamp. It gives me the real timestamp when I made the last edit. Again, they fixed something they shouldn’t have and made it worse.
4. Write/ Save. If you publish a post then edit later, when you “Save”, the session does not close. They’ve removed the “Save and continue editing” button and changed the functionality of the “Save” button. Another huge mistake. If the functionality I want/need is still there, its not very evident. I figure that as an experienced WP user, it should be easier, not harder, for me to upgrade to a new version.
5. Custom fields. I’ve wasted two hours on one project, thanks to the absolutely unreliable behavior of “create custom fields”. It’s taken me hours to enter fourteen posts, each of which has 6-20 custom fields. But every time I “Publish” a post after creating and entering all the custom field information, every single field expect the last one I created disappears into the ether. I can’t express how pissed off I am about this. I have another 200 posts to add, and now I have to uninstall WP 2.5, manually upload an older version, set it up, then start this project all over again.
6. Drafts. Every time I create a new post, there are a multiple draft versions created, whose existence seem to have no relation to any activity on my part. What’s more, there are two types of drafts. I get one single draft that has the post title correct, but it’s in addition to my published post. Then there are anywhere from 3-5 drafts whose title is created from a timestamp. If this is happening automatically, there is hopefully a way to turn off this irritating behavior. I just haven’t found it yet. I just can’t fathom any reason for this useless feature. This is not the right way to do versioning. Now, I have to waste my time deleting multiple drafts for every single post I create.

General Issues

These are general points about WP 2.5.

1. Automattic fixed things (features, links) that really didn’t need fixing.
2. An experienced user like myself has some expectation that the interface of the software I use daily doesn’t get chewed up and spit out in a completely unintuitive manner – and actually functions properly.
3. Most of the other new user features don’t interest me, with the exception of multi-image upload and auto-update of plugins (provided that my hosts support the latter).
4. I was excited about some of the developer features – such as shortcodes – but give the monstrous figurative headache WP 2.5 has given me, I have no intention of wasting my time. If I can’t expect simple features to work properly, why should I waste my time with advanced features?

Summary

Automattic, you seriously dropped the ball on this. WordPress 2.5 is an enormous disappointment in the simplest of features. As an experienced (but retired) programmer, I can say with confidence that you don’t release significant interface changes in mid-version software. People that are expecting minor fixes might be shocked. V2.5 should have been renumbered to V3.0. If it had, more people might think twice before making a “big jump” from 2.x to 3.0. I’m so glad that I didn’t install WP 2.5 on a production site, but I do have to use it on several client sites – something I don’t relish.

You’ve now lost one of your most active WordPress evangelists (see 28 Ways to Use WordPress Custom Fields and 48 Unique Ways to Use WordPress). (I’ll still continue to write about WP in general.) I’m a freelancer and time is money. There’s only so much time I have available to waste on new software that violates general development principles. It seems, then, that my several dozen sites will not be upgraded for a long, long time.

For those of you that have taken the plunge and upgraded to WP 2.5, what has been your experience so far?