So, it took nine days, but it finally happened: someone has left a comment on the DragonFlyEye.Net blog looking for my JavaScript Animated Collapsing Categories Widget to be usable for Links as well. For those of you who are not aware, the new version of WordPress changes the way Links work slightly, by making Links Categories part of the Categories table of the database.
That means that my plugin could potentially be used for Links, but as it sits, that’s not the way it works. In fact, it works with 2.1, but it’s a bit wonky. So, I’ve avoided upgrading because I didn’t want to distract myself from other projects to make this adjustment. Now people are asking for it (and this is a very downloaded piece of code, I can assure you), so I have no choice: I’m “On the Code Again.”
January 31, 2007, 10:18 am FireBug, Bay-bay!
Whilst playing around with the latest development on the DragonFlyEye.Net site, I’ve rediscovered a plugin I installed a while back, FireBug. FireBug is a plugin for Firefox that. . . well, . . . it does so many things, its tough to put it in one sentence. Actually, they did a good job of it here:
Firebug - Web Development Evolved
Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.
Even this is something of an understatement. I had been using FireBug as a way to see what errors were coming up in my JavaScript, but basically, that’s nothing more than a shortcut to the JavaScript Console. When I checked out the FireBug site again, I noticed that it said that it required the DOM Inspector component of Firefox to unleash it’s full potential. So, I uninstalled the old version and installed Firefox 2.0.0.1 (which also rocks, by the way). That’s when the real fun started.
Most of us who work with web development know that the biggest hassle, especially with JavaScript, is knowing exactly what’s been output and what’s been changed in the HTML when an application runs. Even if you right-click and “View Source,” you still end up with *none* of the changes added by the JavaScript.
But not with FireBug, baby! You can actually see the DOM as it happens at any specific moment, and watch the changes happen. Holy crap, is that ever helpful! No more guessing, no more hoping you’ve nested things exactly right. Now, you can see for sure. Best of all, they package it in the ever-helpful DOM format with plus sign navigation like you’re used to with Windows Explorer.
And how about those CSS woes associated with JavaScript? Is the DIV that I’m adding really going to inherit those properties, or is it inheriting those properties? Well, without FireBug, you just have to try it and see. *With* FireBug, whilst traversing the DOM, you can click on any section and get to see it’s associated styles. You see what style is being applied, what style is being inherited, and what the fully-computed style will be:
Firebug - Web Development Evolved » Blog Archive » Computed Style
I promised myself I wouldn’t add any more features to 1.0, but with the freshly posted Beta 9 I broke that promise to restore a feature from version 0.4 which many users have missed. The Style tab now allows you to show the computed style of an element instead of the list of cascaded CSS rules. To turn this on, look in the Options menu of the Style tab.
Yeah, baby, yeah! There are so many other features and doo-dads, it’s hard to list them all. Besides, I don’t work for the company, after all. I just ran across this because I’d run across a pod-cast about Ajax by some English dude who I think helped develop it. Cheers to you, dude, if you read this! For both the pod cast and the plugin.
Oh! One more thing I find super-bitchin’ about this plugin: it shows you the download times for every single component of your page. That’s an awesome tune-up feature and helps you make informed decisions about what code to keep and what code to lose or at least avoid loading when unnecessary. That’s led to a new revolution (I’m sure, entirely obvious to many) in the way that I’m approaching my JavaScript loading for the website.
Vive la revolucion!
Technorati Tags: Design, Tools, FireBug
powered by performancing firefox
January 25, 2007, 3:34 pm Those Pesky Feeds!
I’ve found this very annoying, myself: Google has indexed my RSS feeds, thus pulling some searchers into unexpected directions. I’m sure I don’t need to tell most people who concern themselves with SEO: when people end up somewhere they don’t want to be, they don’t look deeper and they don’t come back. They just leave. Joost de Valk of SEO Egghead proposes the following intriguing solution:
SEO Egghead by Jaimie Sirovich » Noindex, follow for RSS Feeds?
I won’t go in to why search engines seems to be indexing feeds — fact is: they do. The feed for my personal blog has PageRank 4 at the moment, which goes to show that Google even assigns some weight to it. Now think about it, wouldn’t it be cool if you had the equivalent of a noindex, follow (not nofollow) robots meta tag for RSS feeds? That way, the feed could be followed, search engines could spider and assign weight to the links within, yet it wouldn’t show the contents of your feed in the SERPs.
I bet I already know what you’re thinking: “Oh, yes, Tom. That’s just what we need right now, more complexity for RSS!” Well, I agree that RSS is a horribly disorganized pseudo-standard right now, and that writing for RSS is a pain. However, are you really worrying that much about your feeds? Wouldn’t it be far, far more productive to create a basic feed and leave the coding to someone like FeedBurner? I certainly do.
Regardless, if you really care about your readers ~ if you really care about your ranking, in other words ~ you should be concerned about what does and what does not get indexed from your site. Google putting up links guaranteed to drive users off your web page for good is not a good thing.
My question for him is: why would you even want your feed to be indexed at all? His solution for the indexing problem is to allow Google, MSN and others to crawl your feed, index and the links off of it, but then just not put out the link to the feed itself for public consumption. That’s predicated on the notion that you would actually want that information indexed, presumably a second time.
One of the big challenges, especially where blogs are concerned, is eliminating duplicate content: information that can be found on your site more than once in exactly the same format. For example, Google may index the root of your blog and grab an article once, the two or three categories to which that article is published (thus indexing the same article a second time), and then the actual article permalink as well.
Most of us understand this to be an invitation to a duplicate-content penalty, search engines having detected this duplicate content as an attempt to rank a page higher than it’s actually worth. It seems to me that allowing the feed to be crawled but not indexed is more complex than it’s worth.
Far better would be to avoid indexing this feed altogether. Just leave the feeds alone and stick with the content pages. The only good reason I could think of for bots to search the feeds might be to catalogue the available feeds on the Internet, but as I understand it, no such service exists at Google, Yahoo! or MSN, exactly.
Technorati Tags: Search Engine Optimization, Google Ranking, RSS Feeds
powered by performancing firefox
January 18, 2007, 2:11 pm I’m Playin’ with WordPress 2.1 ~ Link Categories
Since I’ve become such a fan of developing Widgets and stuff for WordPress, I’ve decided I’d better get ahead of the curve and download the most recent release candidate for WordPress 2.1. The final product is due out by the end of the month, and that’s not very far away at all.
So, I signed up for the Testers mailing list and downloaded the most recent candidate to a Dev server to try out. The nice thing is: I’ll be able to read along as the new version (and future versions) progresses, maybe throw my two cents in, where appropriate.
For example: my primary motivation was to find out what, exactly, would change in the new version and how that would affect my JavaScript Collapsing Categories Widget. Well, the situation seems a bit confused, if you ask me. Indeed, the “Links” section of the Admin panel has been removed. However, the wp_links table in my database remains (this is a fresh installation, so it’s not a remnant of the old version). New links do not become new Posts, they go right into the exact same table they’ve always gone into.
The only thing that has changed is that they’ve dropped the wp_linkcategories table and rolled all of that into the wp_categories table. At the risk of sounding obtuse, I don’t quite get what this improves. Certainly, it makes life difficult for all of us who’ve made Plugins that affect Categories, since we now have to come up with an entirely new version that matches the new standard. I’m going to take this as an opportunity to make a new version of my plugin that affects *both* Categories and Links, in terms of the final UI. But I still don’t get what they improved by making this change.
I presume, but I don’t know, that they’ve incorporated something that will automatically import the wp_linkcategories list into the wp_categories list, but I’ve not had the pleasure of trying this out for myself. I would definitely recommend backing up your Blogroll before upgrading, that much is certain.
I’m going to get into other specifics about the new version in a sec, but for now, I just wanted to highlight this one rather important (to some of us, anyway) new change.
January 16, 2007, 12:21 pm WordPress 2.0.7, Patch it Up, Y’all!
While we all anxiously await the release of WordPress 2.1, the ever-vigilant WordPress team is still keeping its eye out for serious security concerns so you don’t have to! Witness the 2.0.7 release which takes care of a PHP vulnerabilty, while also addressing a FeedBurner problem along the way:
Development Blog › WordPress 2.0.7
We know it sucks to have a release only 10 days after our last one, but we think it’s important enough for your blog to be secure to do it, and hopefully only having to change a few files will make the upgrade easier than normal.
Get it patched, y’all! Spread the news to your friends! Don’t wait for someone else to figure out the vulnerability before you make the Folgers Switch. . . .
Technorati Tags: WordPress, Security, PHP, Vulnerability
powered by performancing firefox
January 15, 2007, 12:40 pm Don’t Ignore Those Title Tags!
Many of us have a natural aversion to using things like link TITLE tags or ALT tags for images as ways of enhancing the SEO benchmark of our websites. This is owing in large part to the fact that those attributes have so often been manipulated by the “Black Hats” among us that we presume those things will either be ignored or penalized.
But even though there is a long history of abuse, that does not mean that simply employing these attributes automatically means Google penalties. The fact is that Google has focused more and more on not only the content of a webpage, but its readability as well. The logic is that a page with readable content is more valuable than one that is a disorganized mess, but also that information which is unreadable may also be in some way hidden from the user, and therefore a classic Black Hat SEO trick.
So if you can’t see link TITLE attributes or image ALT attributes right away, doesn’t that mean they’re the sort of stuff Google avoids? No, they aren’t, because what they are is Accessibility options for the blind, among other things. They are necessary components of webpages which are helpful to the disabled, and even if your not interested in SEO, you should not ignore them. Besides that, link TITLEs often provide important information (such as the website they’re going to, or the fact that they point to a PDF doc) that doesn’t belong in the article, but which might be helpful to the reader. But since this discussion is about SEO, here are a few pointers to keep in mind when using them:
Hmm. . . come to think of it, this is a pretty good list of suggestions for just about all things communication in the first place! That’s no accident, that’s the way it is. These days, SEO is more about streamlining information than it is “magical HTML tricks” designed to fool anybody at all. Clarity is key, as is accessibility, as is usability. Before you go trying out the latest SEO gadget, ask yourself: “how does this new trick make my site better for the user?” If you cannot answer that question, you should not bother implementing your new-found gadget.
Keep that in mind and you’ll do fine.
Lorelle has a great wrap-up of some of the most recent teasers concerning the newest version of the non-wordpress.com WordPress software. Bottom line: plugin creators, check those queries!
Glimpses of WordPress 2.1 « Lorelle on WordPress
So there is a lot of great things to look forward to with the new version. And another reminder - if you are a WordPress Plugin or Theme author, make sure yours is up-to-date and will handle the transition. It’s expected to be a huge update for a lot of users.
The newest version of WP seems to be designed to eliminate a large number of MySQL-related security concerns that have previously been patched as stop-gap measures. They appear to be tightening up the allowed SQL statements and pseudonyms available directly through WP. There are other, less obvious changes, such as eliminating the “Links” as their own distinct entities, and rather grouping them in with Categories with their own unique category IDs. This should prove interesting.
My recent JavaScript Animated Collapsing Categories list is probably going to need to be retooled to not include link categories, but until I know exactly how those two are going to combine, I won’t know for certain how. I trust all will be explained in time.
Speaking of explainations, the WordPress Hooks Blog has documented a few of the new Hooks available for the first time in WP2.1. You see? The WordPress giveth and the WordPress taketh away. . . .
Most of the hooks they’ve documented so far appear to primarily concern logon issues. This is a nice touch, as many of us use external schemas of our own design and like to be able to integrate the WordPress environment with whatever else we may have going on. Also, these actions and filters may allow for better integration between WordPress and bbPress, the bulletin board system developed by the same folks.
Another bit of tasty-treat WordPress has added into the system is a new Custom Header API, providing developers with a new way to dynamically allocated headers to your WordPress blog. Sounds neat? I thought so, the possiblities are fairly endless: custom headers for users, custom headers for Categories, headers that work with script.aculo.us to provide morphing notifications of changed states (such as “comment posted,” or somesuch). They just keep going.
One that Lorelle either did not catch wind of, or perhaps one that did not impress her is much is the new Administration Panel option that allows users to “Manage Posts,” filtering by Category. This was a bit of information I found just yesterday on the WordPress Support site, dropped in there by Kafkaesqui, one of the moderators. I presume the man knows what he’s talking about and certainly hope he is right. Particularly if you need to move things around or eliminate outmoded Categories (particularly a concern of political blogs, for sure!), being able to filter your posts is vital to administering them.
I did a bit of digging around, since I haven’t had much time to pay too close attention to the new version of WP, and I’ve discovered a wish-list of new features on Boren.nu. Some of these have already been realized, but perhaps this is a tantalizing list of what-ifs? Also, don’t miss his WordPress Category feed if you want to hear the latest and greatest about the world of WordPress and WhatsNext.
Technorati Tags: WordPress, Development
powered by performancing firefox
January 11, 2007, 12:58 pm Awesome FeedBurner WordPress Tool!
So, I’ve been using FeedBurner for my non-blog feeds for quite a while, now. However, I’ve been hesitant to switch over to FeedBurner for my blog feed because I didn’t want to strand people who had been using the old feed link. (I believe I was just discussing the problem of stranding links, wasn’t I?) Well, lo and behold, there comes the following plugin for WordPress:
FeedBurner Plugin // Ordered List by Steve Smith
So What Does This Do? Using some WordPress plugin magic, and user agent detection, this plugin simply forwards all your feed traffic to FeedBurner. The plugin will detect all ways to access your feed (e.g. http://www.yoursite.com/feed/ or http://www.yoursite.com/wp-rss2.php, etc.), and redirect them to your FeedBurner feed so you can track every possible subscriber. It will forward for your main posts feed, and optionally your main comments feed as well.
Woo Hoo! If you’re like me, you said “Eu-freakin’-reca!!” and promptly read the download and installation instructions. The great thing about this is that you get all the advantages of using FeedBurner without the problem of stranded subscribers who don’t show up when you’re trying to get a feel for your subscribership on various feeds.
Technorati Tags: FeedBurner, Feeds, Syndication
powered by performancing firefox
January 11, 2007, 9:08 am 301’s, Legacy Links And SEO
It is always worth considering what changing your web layout will do to your hit rate. If you’ve been out there a while, you’re going to need to consider that there’s some guy out there with a page of yours either bookmarked or even linked on his page. When you delete that content and don’t follow up with a redirect, you suffer dead links and dead leads no one will bother to follow. Jaimie Sirovich picks up with the 301 “Permanently Moved” linking discussion:
SEO Egghead by Jaimie Sirovich » Cashing In With Legacy Link Equity
Your computer sucks. The Core Duo is dead – now you need a Core 2 Duo! Well, at least nobody is selling them. And if the web page was located at /Core-Duo.html, one can 301 redirect /Core-Duo.html to /Core-2-Duo.html. This channels the legacy equity to related updated content. This practice is superior to returning a URL not found (404) error, both because it transfers equity contained by that URL instead of dispensing with it, as well as refers any old links to relevant updated content.
Over at my political site, DragonFlyEye.Net, creating the latest version of the site required many of the same considerations. My last setup was largely produced with independent pages for the home page and each of the section home pages, with each calling a specific article ID from the database through a GET request (”index.php?art_id=25,” etc.). When I went to the new “Clean URLs” schema, I had to provide a way that old links to content did not go away.
Even more vexing, the reason for moving to the “Clean URLs” schema was largely a security issue, so providing for the old style links meant allowing a certain amount of risk. Moreover, making the changes via Apache was going to be inefficient because I go through a web host and would therefore need to rely on htaccess directives, which are much slower than httpd.config mods.
My solution, while not giving away the farm, was to use a fair amount of regular expression comparisons so that only those variables whose format I could predict would be allowed to work unmolested and all other queries would be pushed back to the home page of their respective sections.
Now I am beginning to realize that my current naming convention leaves something to be desired, inasmuch as the URL does not include the title, which is a helpful SEO tactic. Still, this is not the biggest problem the website has ever faced, and doubtless there are bigger fish to fry. Perhaps in some later incarnation, this issue will be addressed; perhaps by the time some newer incarnation is developed, Google will have grown bored of title-bearing links.
Only time will tell.
Technorati Tags: SEO, 301, Redirect, Design
powered by performancing firefox
January 10, 2007, 1:06 pm “You”: The Person of the Year. . . Again?
UPDATE: About that whole “Customizable Dashboard,” thing, someone already beat me to it, but I seconded the motion as well. Good! I hope this idea gains some traction and we get what we want. In the meanwhile, I’m about to go check out “Dasher,” a plugin I found that’s supposed to do the same thing.
The WP Development Blog has announced a couple of new features for the WordPress world, WordPress Ideas and WordPress Kvetch, both aimed at more directly responding to the needs of WordPressers of the world. One is to suggest things, and the other is to complain about things, so I guess it’s kind of a question which you need to do more that determines where you post, eh?
Development Blog › Ideas and Kvetch!
If you could add anything in the world to WordPress, what would it be? If you could name the thing that frustrates you the most about WP, what would that be? Now you can tell us. We’re announcing new projects—two sides of the same coin.
Well, as soon as I get done posting this update, I’m going to put my two cents in at both places. Time to plead for a more liberal, less rigid Dashboard, for one.
Technorati Tags: WordPress
powered by performancing firefox
Next Page »