[What] many users don’t know is that the wp-config.php file may be used to specify a wide variety of configurational settings, enabling you to improve the functionality, performance, and security of your WordPress-powered site.

Did you know you can set several configuration options, usually stored in the database, as constants in the wp-config file? It saves a bit of time and processing power, as the data doesn’t have to be pulled from the database.

define('WP_HOME', 'http://diggingintowordpress.com');
define('WP_SITEURL', 'http://diggingintowordpress.com');
define('TEMPLATEPATH', '/absolute/path/to/wp-content/themes/active-theme');
define('STYLESHEETPATH', '/absolute/path/to/wp-content/themes/active-theme');

You can also disable post revisions, set the maximum number of revisions to store, or change the autosave interval for the post editor. You can even set up error logs and increase the ammount of memory allotted to PHP.

Tweetboard is a fun and engaging micro-forum type application for your website. It pulls your Twitter stream in near real-time (max 1 min delay), reformatting tweets into threaded conversations with unlimited nesting. Conversations that spun off the original conversation are also threaded in-line, giving your site visitors full perspective of what’s being discussed.

As people leave their messages on your TweetBoard, they simultaniously add them to their Twitter account, complete with a link back to the conversation, adding a bit of a viral twist.

The service is currently in public alpha. All you have to do is request an invite, which will be approved instantly, then add the JavaScript to your website, just before the </body> tag.

TweetBoard appears as a floating tab on the left-hand side of your website. When clicked, the tab slides outward to reveal the message board.

I’ve tried the service out a little bit, and have been wanting to put it live on Webmaster-Source, if just for a few days to see how people respond to it. Unfortunately, it doesn’t work well with my design. Users with 1024×768 screen resolution or lower would see the green tab floating over my main content, instead of in the extra space to the left of it. I’ve figured out a way to to hide the tab and replace it with an ordinary text link somewhere, but I don’t know how well that would work out.

Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users’ shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn’t even protect fully against snoopers.

More importantly, there’s usually nobody looking over your shoulder when you log in to a website.

This is wrong on so many levels.Have you ever set your laptop up in a public place, such as a café, a library, an airport? How often is there someone else in the room when you use a computer? Have you ever had your laptop hooked up to a projector? In Nielsen’s private world, there are only people typing away at computers isolated by four walls. In the real world, people, intentionally or not, “shoulder surf.”

The argument that “a truly skilled criminal can simply look at the keyboard” is about as logical as saying that you don’t need a key for your car or house, because a truly skilled criminal will break in anyway. Password masking protects against more casual (or even accidental) snoopers. It’s not easy at all to get someone’s password by watching them type, unless they are very slow, “hunt and peck” typist.

When you press a key, it’s only for a second. Blink. You missed it. What key did I just press? If you remove the masking feature on password fields, which is required by the upcoming HTML 5 standard, your password is shown in full for a much longer length of time.

A checkbox to toggle the functionality on and off, as Nielsen recommends, breaks a more important design and usability principle that I believe Nielsen stands behind: That you should present as few options as possible to the user.

Slashdot has plenty to say on the matter:

I’ve never been impressed by the argument that ‘I can’t think why we need this (standard) security measure, so let’s drop it.’ It usually indicates a lack of imagination of the speaker. But in this case, does usability outweigh security?

If I look outside my office window, I can see about 48 office windows (without standing up) and all of them have the lights on and it’s dusk outside. Give me a dSLR and a decent set of long distance lenses and I’ll prove you wrong.

To a usability expert, expectations are your friends. You trust them. You believe in them.

To a security expert, expectations are your enemies. You distrust them. You try to figure out what they’re hiding from you.

Of course, everyone agrees that what is expected and what happens *should* be the same, but I think here the securities guys have the more legitimate concern. Mr. Nielson doesn’t even considers the possibility that his expectations might be violated. He assumes they are benign as long as they are “usually” right.

In any computing environment, security trumps usability. Password masking is such a minor usability issue, and one that can be overcome with just a little bit of education on the matter. It’s not worth creating a security risk because one segment of the population can’t do something as simple as typing a password properly.

The discussion around this always seems to evolve into “open source” versus “author protection”. As Alex King pointed out in one of his posts, theme authors should be aware of what the GPL license exposes them too, while it provides freedom for basically everyone else.

I’m not by any means against freedom and open source. I’ve been preaching about the power of WordPress and the wonder that it is, but what I love more is to see a protection system for those authors that make a living out of releasing quality themes and plugins for WordPress. Somewhere along the way, in our quest for “freedom” we forgot how hard it is to earn our living, how hard it is to learn the things we now use to feed our families.

I have a similar position. I like the GPL as much as anyone who contributes to the WordPress community, and I appreciate it’s provisions for paid software, but as nice as that sounds in print, it doesn’t always work out that well in real life.

My Take on the WordPress Themes & the GPL License [Blogsessive]

I use a Twitter client on my laptop (Tweetie), and I use another (Twitterific) on my iPod Touch. And sometimes I might use either Twitter.com or Twhirl when I’m on another computer. Every time I move between devices, I lose my place in the stream of incoming tweets. Any good Twitter client remembers the last tweet you read. The only problem is that little bit of information (simply the numerical ID of a tweet) is locked down to one device.

I propose that Twitter add a new API method that accepts the ID of a single tweet, and stores it. Then any Twitter client could request that information and use it to display the tweets from where you last left off.

Something along the lines of statuses/last_read and statuses/mark_read perhaps?

It’s a little thing that bothers me, and something I’d love to see added to the API.

But let’s focus on the URL shortener for now. Ow.ly has a clean, easy to use interface. The resulting URLs are along the lines of http://ow.ly/fA3N. As of yet, there is no API available, though one is in the works.

Time for the controversial part.

Ow.ly’s short URLs display a thin, unobtrusive toolbar at the top. This means that the page is, of course, displayed in an iframe. Unlike the ever-popular DiggBar, there are no ads, and they’re not going to steal your incoming links.

The toolbar doesn’t get in the way too much. (It’s hard to see it in the screenshot, isn’t it?) Most of the services it offers are beneficial to your users. An easy link to retweet the link (it opens a sliding panel with a form to post the link to Twitter), a similar button which reveals a similar panel full of links to share the link on various social media sites, and a link back to the original tweeter’s Twitter profile are among the most prominent features. If you want to view the page without the toolbar (perhaps to get the full page URL) you can click the little “x” button in the corner.

When an Ow.ly page is loaded, the server sends a “HTTP/1.1 301 Moved Permanently” header, along with one listing the original URL. This means search engines and the like will ignore the fact that the Ow.ly URL exists, and follow the invisible header information to the original location.

I think this feature benefits both end users and publishers. It makes it ridiculously simple to rebroadcast a page via Twitter, StumbleUpon, Digg, Facebook, Delicious, or whatever social media service they prefer. It provides plenty of value for the screen real estate the toolbar takes up, and it doesn’t take away any traffic or links from the publisher. Sounds like a win-win situation to me.

What’s your opinion? Good or bad, why?

First of all, slow down. Google can read iframes and JavaScript. Google very likely is already programmatically diferentiating between comments and page content anyway, and tweaking their rankings accordingly. PageRank is not a cut-and-dry “links in minus links out equals rank.” It’s a complex system involving a lot of calculations on Google’s part. I imagine they value links differently depending on what sort of link it is.

Second, stop worrying about it. Google’s business is to provide good results. If everyone tries to cheat the system with a bunch of silly schemes (such as PageRank sculpting and JavaScript links) Google will just change things again. If everyone plays by the rules, and doesn’t worry about their ranking too much, it all works out in the end.

For me, a changelog is a very important thing it is all about justifying to your users why they should upgrade to the latest version of your plugin as well as reassuring them that the changes made have been made for specific reasons and helping them to understand the impact the changes may have on there usage of your plugin.

Some plugins are already starting to take advantage of this new feature. Others, such as my own, already have changelogs, but they aren’t yet formatted in the manner required to trigger the creation of a separate Changelog tab.

Changelogs, Changelogs, Changelogs [westi on wordpress]

The only problem? As soon as you drop a widget into a sidebar, it appears on your blog. That means one or two visitors might see an unconfigured widget before you have a chance to edit and save the settings. (This was brought to my attention recently by WP Weekly.)

Luckily, there’s a workaround…

Below the “Available Widgets” section, there’s a box marked “Inactive Widgets.” It serves as a holding ground for widgets you want to temporarily remove from display, but don’t want to reset their settings.

What you want to do is drag a widget from the Active Widgets box to the Inactive Widgets, where you will be able to edit the widget settings. Next, drag the widget to the sidebar. It takes a little bit of extra effort, but if you don’t want unconfigured widgets showing on your blog, it might be worth it to you.