A week ago yesterday, I launched the Anyfeed Slideshow plug-in for WordPress. There were a few bugs, which I tackled as soon as I could. It’s been a little over a week now, and I’ve averaged about 1 revision per day since then, each resolving little bugs as they popped up. I checked the statistics on the WordPress site, and wanted to share them here, because I can barely believe them!
That is not a small number!! Wow! They like it! They really like it! :D
Plans for version 1.1
As the bugs appear to be mostly worked out now, I plan to release version 1.1 in the near future. The new major version will include a number of requested new features:
- The ability to leave the title bar up, even when the mouse isn’t hovering over the plug-in
- The ability to change the color of the loading text
- A color picker instead of just text boxes in the widget configuration menu
- The ability to select the target window for slide show item links
- The option to enable (browser side) image scaling within the slide show
- The ability to show more then one concurrent widget instance
Do you have a feature you’d like to have added? Please feel free to ask below in the comments!
I am very pleased to announce my first independently published project: The Anyfeed Slideshow. This one has been a long time in the making, which started from the desire to display images from an RSS feed on a blog at the office. The idea spawned, that no other plug-in had the capability of taking any RSS feed and extracting a slide show from it, so I went to work.
The plug-in has been tested on a few different systems, all with good results. After some consideration, I added a general public license to the code and looked into registering the plug-in with WordPress. Lo and behold, as of today, the plug-in is officially published on WordPress.org, and available for download from within supporting WordPress blogs.
I’ve already had my first bug found and fixed- It would seem that single image RSS feeds wouldn’t start playing. This has since been fixed and released! Another issue reported was the error “Cannot write RSS feed”, which means the script may not have permission to write to the temp folder. That might require a proxy script to pull the file live, instead of storing and caching it locally.
In any event, I’m totally stoked.
Having used both jQuery and MooTools in various projects, it’s safe to say that both are extremely useful in the right applications, and one isn’t necessarily better than the other. No one could explain this better then Aaron Newton (MooTools contributor and author of “MooTools Essentials“):
If you go to the jQuery site, here’s what it says at the top of the page:
jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.
…and if you go to MooTools, this is what you’ll find:
MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.
I think this really sums it up. If you ask me (and you’re reading this, so I’ll assume you just have), the question isn’t about which framework is better or worse. It’s which one of these things above do you want to do? These two frameworks just aren’t trying to do the same things. They overlap in the functionality they provide, but they are not trying to do the same things.
I tend to use jQuery because of it’s smaller footprint and wider capabilities, but in my experience, MooTools tends to be a bit more precise then jQuery, so it still has a place in my arsenal.
OpenID has been a very popular way of allowing the internet to share it’s users with one another in a way that benefits everyone– without forcing the nuisance of creating yet another account to manage on the users. Some time ago, a gentleman by the name of Will Norris put together a plug-in called ‘wp-openid’ which not only provided your readers the option to log in using OpenID, but also included an OpenID Server- meaning you could use your blog’s URL to log into other places, too! How great is that?
From what I can tell, Will and a group of other talented people formed the “DiSo Project,” which has now been very quiet for quite a while. Will’s WordPress plug-in was absorbed and renamed to just “OpenID.”
All was well in the world until, to everyone’s displeasure, the plug-in’s server functions stopped working! Why was it broken? Well, it hasn’t been updated since November of 2009. What’s happened since then? Ubuntu 10.04 was released, and packaged with the new release of PHP (5.3, which had been released 10 months earlier). The OpenID server side module was full of “pass by reference” variables (&$var). This was depreciated in 5.3, causing a “call-time pass-by-reference” error every time you tried to make use of the server side of the plug-in.
How to Fix It
First, find the file. It should be located here:
<Wordpress Root>/wp-content/plugins/openid/Auth/OpenID/Server.php
Once you have the file open in any editor, do a find and replace as follows:
Find: &$
Replace with: $
Save the file and upload it back to your server (if necessary), replacing the original. You should now once more have a functional OpenID Server. Hooray!
I tend to be a bit of a perfectionist with my code. Be it HTML, XML, CSS, JavaScript or PHP, I always keep things as neat as possible and follow the rules available to me.
When writing a website from scratch, most of the developers I’ve worked with will always take the shortest, easiest methods. Images are quickly cut and saved, CSS is written out as part of the header, Javascript is written haphazardly across the body, generated XML is written as a single line, HTML is indented poorly if at all… These are the things that drive me absolutely crazy. What’s worse, many times these sites will not display accurately in browsers other then a particular version of Internet Explorer, and because everything is so haphazardly strewn about, it sometimes takes longer to fix the code so it displays correctly in other browsers then it did to write the thing in the first place!
Before I call a website complete, I have a mental checklist I run through.
- Does the site pass the W3C validator?
- Does the site pass the W3C CSS Validator?
- Is all Javascript contained within the header?
(Extra credit: Is it all in one included file?)
- Is all CSS contained within included CSS files?
(Extra credit: Is it all in one included file?)
- Are all images in formats that enable the lowest file size?
- Does the site look identical in all browsers?
This is of course not complete- but more a basic list that ensures you avoid the problems listed above. There are a number of sites which provide fantastic lists for what to check before finishing your project; The best I’ve seen so far is Launchlist, which gives you a very verbose and logical place to start from, and lets you add your own to it if they missed anything.
If only more people followed these rules, we’d avoid the issues caused by “Internet Explorer Only” websites.
