After seeing links to this article by Jakob Nielsen in numerous places, and most recently on Daring Fireball, I decided to chuck together a quick WordPress plugin to allow a user to choose to “unmask” their password as they type it.
Copy and paste the content below in a blank file and place it in your plugins directory, or download the file from here.
An example screenshot
A plugin can be a complex beast, with multiple pages of administration settings for the site owner to go through to get it all set nicely on his / her system. But, as all the code that handles the administration side of the plugin (and arguably the largest part of the plugin) is only used rarely ( and when a user is logged into the WordPress administration pages ) it seems wasteful to load it into memory each time a visitor browses the front end of your website.
A more efficient way of developing your plugin is to separate the administration and public side of your code into two distinct files. A quick check in the main plugin file to see if you are in the administration or public side of the site will enable you to load the relevant file, thus only loading the relevant part of the plugin.
Note: It is very easy using this method to get into the bad habit of duplicating code and functions. Think, instead, of having a common code file, or class, and using that rather than copying and pasting the same functions into both locations.
According to RFC 4672 JSON should be output with Content Type set to application/json. After reading through a very informative post (keep reading for there is a fantastic and enlightening discussion in the comments), it seems that the consensus is to use a Content Type of application/json for straightforward JSON requests, but to use text/javascript when passing a callback function for JSON-P.
The following snippet of code checks for the existence of a callback function, and dependent on it’s existence (or not) outputs the correct content type.
Unfortunately, when it comes to debugging, most browsers try to force you to save JSON output to a file when it is sent with the correct content type. For this we also allow for an extra query string (called “pretty”) which will output the results as a straightforward text to be viewed within the browser.
This bit of code is inspired by this post over on Ozh’s blog, and is a handy fallback for JSON encoding if the site is hosted on a server with only PHP4 (which is thankfully, reducing all the time).
Those that have tried to download some of the plugins listed on this site will have noticed that you are getting an error from the Google code repositories that held them. This isn’t Googles fault, it is entirely down to me.
Last week I read something that took my breath away (which I will go into in another post), so I decided to take some time out, have a break and count to 10.
I came back sunburned and smiling, but un-moved, and promptly deleted all of the old plugins I had released and the dev site that held the documentation.
So they are no more, I don’t have backup copies and they won’t be coming back.
The staypress plugins will be released when complete, I have big plans for them and now have the structure in place to make them really rock - I’ve also set a deadline ( and future roadmap ) and am rushing towards it full-steam.
In my present state of mind though, I don’t see the point of releasing any other plugins for WordPress on this site (develop, yes, release, no). When I feel able to structure my words adequately enough to portray my anger with out needing to resort to name calling, I will.
Until then I shall return to my darkened room and sip coffee.
In the move to the new server and the wonkiness of the DNS updates (I ended up with 2 servers pointing to one address and 3 to another) a random “Hello World” post got picked up and transmitted to all of the subscribers.
For this I am sorry, and so untill the old posts are transferred and new posts ready, I have disabled the sending of emails in Feedburner. I’m not sure how this will affect new subscribers signing up over on that site, but if you do have problems, feel free to sign up to the feed for this blog as any news will also appear here (probably first).
The RESTful API framework plugin is now available for download from here.
It also now has it’s own Google Code site as well. I will put together a short post or page going through how it is used for plugin developers very soon.
Update: I’ve just added version 0.2 to the download list (above) which now ensures the correct MIME types are set for the JSON output. I’m also going to put all the documentation for this plugin over at the Google Code page to keep things separate.
The last edit, that I am allowing myself, on the RESTful API framework plugin has just been checked into the SVN so I will be making version 0.1 available for download later this evening.
What is an API framework and why is this coming so soon?
The API framework plugin provides a parsing and authentication model for other plugins to hook into. In english, it sits in the background and looks for URLs sent in a specific format. It then grabs the URLs, parses them to work out the required area and action that is being requested, checks if the request has been registered as a public request (one that doesn’t require authentication) otherwise it retrieves and authenticates the request before passing it on to the relevant plugin for processing (passing along the relevant user id).
Finally, it retreives the results and outputs them back to the calling program. The currently available output options are JSON and JSONP. XML will be coming soon (the plugin already recognises URLs requesting an XML result set).
Effectively it means that any plugin can provide a RESTful API interface to it’s functionality without having to mess around with URLs, authentication and users.
Neat huh?
Why is this out so soon?
As a key part of the rest of my plugins will utilise the API framework, I found myself developing to a constantly changing specification. So I decided to sit down set the API framework in stone, so to speak.
As this is now done, we can move forward with everything else…
Last monday I posted about the plugin releases that I expected (hoped) to have released that week.
Unfortunately I didn’t figure the blogs.mu launch into the equation and the extra time that was required making sure everything was ready, tested and bug fixed. As well as writing a complete affiliate system plugin from scratch with less than 24 hours to launch time…
Now that it’s all up and running, quite smoothly as well thankfully, I can get back to scheduling in the StayPress system development and we can, finally, start to see some actual progress.
So, sorry for getting all your hopes up, and I hope I can give you all a nice present for being so patient.
On Monday we launched the blogs.mu system and site with quite a bit of coverage from a few tech and blogging sites, less so within the WPMU community, but on some levels that’s to be expected, as it’s of less interest to those who can install WPMU with their eyes behind their backs (yes some of them are THAT good…).
There have been a few questions and maybe some misunderstandings about the system, so I thought I would take some time out of my hectic schedule to describe the workings on the blogs.mu system, explain what it is (and more importantly what it isn’t) and how I hope that the experience in developing (and running blogs.mu) will benefit us all.
What is blogs.mu
blogs.mu promotes itself as “providing a blog network or community with the minimum of fuss”. What you see when you sign up and login to your administration area looks, to all intent and purposes, like your very own individual WordPress MU install, with your own Site Admin menu and pretty much everything you would see in a self hosted WordPress Mu system.
It looks like a WordPress MU system because, at it’s heart, that is what it is, a standard WordPress MU installation. It just happens to be shared amongst a lot more people.
What isn’t blogs.mu
Apologies for the bad title there. This is probably were a few misconceptions come in so I hope to, if nothing else, clarify some technical points here.
blogs.mu does not provide each site created with it’s own installation of WordPress MU and separate code base. That would take up a lot of space and resources on the server and, frankly, be too unwieldy for even the most geekiest of server admins.
It is also not a hacked up, heavily modified, fork of WordPress MU.
It is a clean, untouched, unmodified installation of WordPress MU with, and for me this is the most important part, zero, none, zip, not one core edit or hack.
Those who follow me in the MU forums will already know how averse I am to even touching the WordPress MU core and frequently warn others off doing so. My usual line is “you can do that with a plugin” and I’m proud to say that blogs.mu is a testament to that.
Absolutely everything that makes WordPress MU into blogs.mu is handled by a plugin (well not a single plugin, becuase that would be silly), and it is the fact that WordPress and WordPress MU are such powerful, and well thought out systems that make even thinking about such levels of customisation possible.
Hopefully (or maybe), over the course of a few posts, if people are interested, I will go through some of the plugins developed and highlight the technical and coding challenges that we encountered and, probably of most interest to the majority of you, how they where solved.