Archive for WordPress

Google
 

Google Reader Problem “Solved”

Thanks for the comment on that last post, Tyro. After I got home from work tonight, I fired up Google Reader, hit “Subscribe,” and typed in dummyspots.com. It auto-discovered the feed, forwarded to Feedburner, and picked up every post.

Whatever broke September 5, now is suddenly “un-broke.” I’m still scratching my head, but hey, it’s working.

Google Reader RSS Problem with WordPress and Feedburner

I’ve isolated my problem, but still no success in finding a cause or a solution. Perhaps some of you folks can help.

As of Sept. 5, Google Reader suddenly stopped showing any new posts on subscriptions to my site’s feed at http://dummyspots.com/feed/. The feed still validates, redirects to Feedburner just fine, and still works perfectly in other Feed Readers like Bloglines.

If you subscribe through my “Subscribe” button, it works since that links directly to the actual Feedburner feed at http://feeds.feedburner.com/dummyspots; same story if you go into Google Reader and manually type the Feedburner feed URL into the Subscribe box.

So, original feed (which redirects)- no new content since 9/5/07. Direct link to Feedburner feed- no problem.

Is there some reason why, on September 5th, Google Reader changed something that prevents it from following the Wordpress-Feedburner redirect since then??

Any help greatly appreciated. I’m about sick of this.


Foiling the Email Spambots

Wired magazine has a recent article entitled How to Hide Your Email Address from Spambots. They give some popular and effective approaches, but even having the words “contact me” in the source of your page (instead of the word “email”) can easily be caught by the spambots, and you never want an actual mailto: link in your source code.

I’d like to suggest a similar, but in my opinion simpler and equally effective alternative to the solutions they provide:

  • Use an onmouseover javascript function to break up your email address in your page’s source, but to re-assemble it when the link is clicked. Very easy, very effective.
  • Make the link a picture, not words. No keywords for the ‘bots to catch, so you don’t have to worry whether they’ll notice “contact me”, “email me” or anything similar.

This is exactly what I’ve done in my sidebar for years, and so far it’s been 100% spam-proof. Wish I could say the same for comment spam on the blog!

You’ll have to decide what you want on the image, but make it really obvious that it’s an email link. Once you have that, here’s how the code looks. It simply goes in your HTML source where the dreaded malito: link was before. Note that there’s a “fallback” a href link to your website in case the user’s computer doesn’t do “onmouseover” (if it doesn’t, they’ve got much bigger headaches than having trouble sending you mail):

<a href=”your website’s url here (NOT your email address)” onmouseover=”this.href=’mai’ + ‘lto:’ + ‘email address before the “at” sign‘ + ‘@’ + ‘email address after the “at” sign; i.e. gmail.com‘”><img
src=”link to your image here” border=”0″ alt=”Send Me Mail!” /></a>

For example, if your email address is you@yourdomain.com and the link to your contact image is http://www.yourdomain.com/images/contact.gif, the code would be this:

<a href=”http://www.yourdomain.com” onmouseover=”this.href=’mai’ + ‘lto:’ + ‘you‘ + ‘@’ + ‘yourdomain.com‘”><img
src=”http://www.yourdomain.com/images/contact.gif” border=”0″ alt=”Send Me Mail!” /></a>

The hardest part of this process for me was fooling around with the images, trying to come up with one I liked. Decisions, decisions!


DummySpots 2.0: Less Clutter, More Reader Feeder

We change, learn and grow, or we get left in the dust.

I’ve needed to upgrade my Wordpress version for some time now. Trouble is, I hacked and hacked until I had a custom theme that looked and performed like I wanted, and it’s not too upgrade-friendly.

Then it hit me: What I was shooting for back in the day, and finally ended up with a satisfactory version of, was a website, a destination. In other words, a dinosaur. RSS readers (with Google Reader rapidly becoming the de facto standard) have changed all that. People don’t click from favorite site to favorite site anymore, drilling down into each individual site’s content. They happen across one article they enjoy, they click “Subscribe” in their RSS reader, and their experience of your brilliant and witty observations begins there.

Website design has everything to do with layout (assuming you have some decent content!). Get that content front and center, make it intuitive and easy to navigate, and for Chrissakes, make it readable with the font, colors and spacing you select. And your traffic depends largely on how well your site welcomes visitors and encourages exploration.

A site that’s just an RSS feed generator, on the other hand, could be black type on a black background with no navigation or links whatsoever, and people would still get the content just fine through their reader software. And, like it or not, what most of us (and especially bloggers) have here anymore are mainly platforms for generating RSS feeds.

I used to visit sites and click around on their various links, digging down into their content. But to be honest, I haven’t visited most of my favorite sites in weeks or months, short of clicking on an individual post to leave a comment. Some folks had changed their layout months before, and I never knew it. The ones where I did know were only because they mentioned it in a post, which I read on my RSS reader, of course.

As well, many of you fellow bloggers may have noticed this phenomenon: All those nice links in your sidebars and headers are getting fewer and fewer hits as time goes by. I’ve lost count of how many times I’ve directed readers to Trader Mike’s classic expectancy article in emails, only to find out that they didn’t know that article existed because they didn’t get it via their feed.

In short, all of us website builders have been doing something similar to setting up a bookstore- so that all of our content is visible, readable and readily available. What we have to realize is that, more and more, people aren’t visiting the “store” and browsing through our content any more. They’ve subscribed from home, and only receive and read the latest issue. Our brick- and- mortar business is waning, even though it’s only virtual.

So for any of you folks who visit my actual site, you’ll see the new look. Leaner, cleaner, faster, cheaper. I couldn’t find a Wordpress Theme I liked, so this one is another “Will special”, which means I’ll be tweaking it and squashing bugs for some time.

If you want to read the old stuff, it’s still here. You’ll just have to dig a little deeper. And there’s still a secret link and a breadcrumb or two for the true freaks. (Yeah baby, I know who you are).

Meantime, see ya on the feed.

WordPress Print Styling

Spent some time this evening working on a print stylesheet for the site. The sheet itself isn’t hard at all, just tedious.

A print stylesheet is to a printout of your site what your “normal” stylesheet (”style.css” for most) is to the “screen” (monitor display) version: it defines what the output looks like when anyone hits print or print preview while reading your site.

Most sites, and certainly most WordPress sites, have no defined print style, and so what you see on the screen is far from what you get on your printer. What you’ll get is the content of the site with no CSS styling or formatting at all. Ugly, and hard read. Just click “File / Print Preview” on a few sites and you’ll see what I mean. [As of this writing, I don’t have the print stylesheet finished for my “index” page, so you can hit Print Preview right here and see the ugliness.]

A print stylesheet lets you control exactly what prints and exactly how it looks. Very cool.

How to do it? Here’s the best reference for WordPress users: Styling for Print from the WordPress codex.

Basically you take your current style.css stylesheet, and save a copy as print.css. Edit the print.css file and add a line at the beginning that says “@media print {” then put the closing brace “}” at the very end of the stylesheet, so the whole thing is contained within that declaration. Then add a line in your header to link the site to the new “print” stylesheet in addition to the original one. Just under the usual stylesheet declaration, you add something like:

<link rel=”stylesheet” type=”text/css” media=”print” href=”<?php bloginfo(’stylesheet_directory’); ?>/print.css” />

Note the media=”print” part! That’s what tells the browser this stylesheet is only for printer output!

Now edit away on the print.css stylesheet, “hiding” all the ids and classes you don’t want on the printout (e.g. some people don’t want the header or sidebars to print) by using the declaration {display: none;}. You can also doodle with the width of some elements (content, post or whatever) to get the most use out of your paper.

Then, what took the most time for me: change all your {font-size} declarations to pixels instead of em or percent. These relative font sizing designations are more desirable for the “screen” display, as they allow user-resizing of text and are more “accessibility” friendly. But printers like pixels, and you’ll find that stuff doesn’t look the same printed as it did on your monitor. Depending on the font, it may be unreadable. So for the “print.css” stylesheet, I changed all the font-size properties to pixels, then kept going back and doodling with them until I got a reasonably readable printed output.

Finally, you’ll find that there are many classes and ids you can just delete from the print.css stylesheet - for instance, all those which fall within another class which you’ve already blanked with {display: none;}. You’ll probably end up with a print.css stylesheet that’s very short and to the point, as compared to your “screen” stylesheet.

Important: We all know to measure twice and cut once, right? The web corollary is save a backup of your original and only work on copies! Once you start messing with print.css, you’re destined to leave an extra curly brace here or forget a semicolon there. Keep an untouched copy of the last clean, working version as a backup so you can revert to it when things mess up. And I do mean when, not if.

Anyone who’s an HTML, CSS or PHP guru (or any other kind of guru) can tell that I’m certainly NOT one. Everything I know is from “on the job training,” so there are bound to be better/ faster/ cheaper/ sexier ways to do everything than the way I do it. I’d certainly defer to the experts on any of this.

But maybe this’ll getcha started. ;-)