Web, Programming, Usability, etc.
Code
Code I’ve written, used, or like.
A Scale of Useful Things
Oct 7th
Here is a useful thing: Get good web hosting for your site. WiredTree hasn’t given me a single second of downtime (unfortunately, it’s another website, not this one). ASmallOrange is down 3-4 times per day for 20-30 minutes each time. Granted, I pay $45/month for WiredTree, and $5/month for ASO. You get what you pay for.
Here would be a useful thing: A distributed co-op system of server uptime checks. A cron job on your web server kicks off a local web page that performs 3 jobs: 1. Asks some central server (or two, or three, or a distributed network of them) for 5 urls to check for uptime. 2. Pings and tries to http-access these 5 urls. 3. Sends the results of the checks back to the server it just talked to. The 5 urls it checks are themselves other servers just like yours who’ve recently contributed uptime checks against yet other sites (maybe even yours). Everybody scratches everybody else’s back.
The tricky part is managing the DOS attack this starts. The central server would have to mete out the list of urls to check cautiously, globally distribute them, and preferably time them in accordance with the desired check frequency each site wants… and then would have to aggregate and notify each site owner of up/down events noticed by “the collective”. Difficulty: you wouldn’t want the central server giving 1000 different web sites the same url to check at the same time — or the “service” of an uptime check could be come an attack in itself, threatening the very uptime it’s supposed to harmlessly monitor.
The idea of a co-op of free service & benefits seems to have merit to me, just needs some more development. You get globally-distributed checks against your site, free, and provide a very small service yourself. Like a single antbenefiting the colony in its individual capacity, and benefiting from the colony in its massive capacity. Gotta work on that.
And here’s a completely useless thing. Paypal lets websites collect funds from visitors. But some visitors would rather call you and give their credit card number over the phone that type it on a computer. So what does the site owner do? Goes to paypal himself, places an order from his own website using the customer’s info. Works fine. Once. Try and repeat an order and paypal requires you to establish a Paypal account. Except you can’t do that, because you won’t get the email that will go to your customer. Stupid stupid stupid. Paypal is literally locking themselves out of my small, but growing business.
That’s why I’m looking into a more “mature” system for business transactions: PaySimple pre-sales support has been pretty good so far… Just still collecting facts & opinions on them.
So it’s not v0.5
Jan 9th
I have utterly failed to complete version 0.5 of the WP-Password plugin. That branch of development is gathering dust while real life intervenes. But I’ve knocked the dust off version 0.3, updated it per some feedback and debugging with gracious (and patient) users and have released version 0.4.
http://www.broome.us/wp-password
Let me know if you have any problems/questions/requests/good put-downs. 
Planning v0.5 of the WordPress Password Plugin
Jul 20th
I’ve started working on the next version of the WordPress Password Plugin (v0.5). This post is to explain what I’m planning and why, as well as to seek suggestions/feedback. This list is compiled from your suggestions and my own observations. It’s subject to change. It’s subject to not being possible to code. It’s subject to your opinions, too.
- Convert the in/ex-clusion list to separate “rules”
v0.4 converts the in/ex-clude strings to Regular Expressions. Here’s why:
Say your site is password protected, except urls containing “*not-secure”. A clever user might add “&this-is-not-secure” to the end of your urls. The system might let them in without a password then – it depends a bit on the order you put the strings in.
I convert those strings to RE’s internally and attach them to the beginning of the whole url, to try protecting against that url hack — but it’s tricky and a badly written pattern can’t always be helped.
The next version I release will do away with the texbox of patterns and converting them to RE’s in favor of a more straight forward, less hackable method:- You define “the general rule”: Whether the whole site is protected or not, by default.
- You define as many separate “exceptions to the rule” as you want – specifying the text, what “field” it must (or must not) be found (e.g. id/slug/url-path/querystring) and then whether that means the post does or does not require a password.
- Order still matters, and you’ll be able to move rules up/down in the list as needed. As well as copy/delete/etc., but that doesn’t completely deal with all the situations I’ve thought of… more in a moment…
- Resolve https:// link problems
The most common problem people have encounted so far is that version 0.4 does a bad job on https:// urls. That’s related to the RE gymnastics I’m doing internally and should go away entirely in 0.5 - Protect posts in lists
I am ashamed to say I never even thought of this until after v0.4 was out. It’s just a perspective I didn’t consider until I started thinking of how to improve the plugin.
v0.4 works by examining the urls requested from your site. It compares each url to the list of text patterns you’ve entered. If there’s a match, the plugin acts according to your settings.
Suppose you password protect a recent post, and list the x most recent posts on your homepage, in full text. If the plugin doesn’t recognize the homepage as one to protect, it also does nothing to protect the text of your post from showing there (feeds are the same way). What a stupid loophole to have overlooked!
I want to switch the hooks I use into WP’s handling system so that it’s the title (or id, or slug, or url, or querystring, or … anyone have suggestions?) of the post that’s protected, not the url. If the post is the only one being displayed on the page (e.g. that specific page was requested), and the password is required, it’s asked for. If the protected item is part of a list of posts, You can define what’s shown:- Either a piece of text you define for all such protected items (e.g. “This is password protected, you must <u>log in</u> to read it.”)
- Maybe the post’s Excerpt + text, etc.
- Maybe nothing at all.
- I’m not decided and want some feedback on this, please.
- Create a user-callable function
If you’ve ever used the Adsense Deluxe plugin, you’ll know how to call it, all you do is put <!– #adsense –> in your post’s text to stick an ad into your content. Seems it would be easy to make a similar call for Password Protection that users can call the same way: <!– #wp-password: required –> (or not-required) etc. I’m not sure how this will work yet. It would allow you to apply the plugin’s protection to a post without having to go into the admin to do it. I like that idea… just not sure how to make it work yet. - Compound/Conflicting rules
What if you want posts that fall off your homepage to be password protected, while not requiring them for your homepage content – sort of a “you must subscribe to read archives” model. I personally hate sites that do that, but that doesn’t mean I can’t make it work well.
I’ll have to resolve conflicts between rules somehow anyway. Suppose a rule in the admin protects a certain post, but a <!– #wp-password : not-required –> is found in the post’s text. Which wins? What do you think — which should win?
The “protect this post but not if it’s on the homepage” idea is similar in nature. Maybe an “inspecific” rule type should be allowed that supercedes all the other rules to say “All the rules above apply unless…” Need to figure that out. Need to also figure out how to present that option in the admin in a way that isn’t confusing as hell. The concept itself is confusing as hell though. - Different Passwords
So far the system sets 1 password for every protected item. That’s fine if you’re protecting the whole site, or granting access to the whole site. What if different posts are meant for different audiences? What if you’re writing love letters to your girl/boy friend on your site and you want some privacy, but want the rest of your family to be able to read the updates on your dog/kid/siamese twin?
Seems as long as I’m creating distinctly separate rules, I should be able to attach distinctly separate passwords to them… Or for that matter, specify that in addition to (or instead of) a password for a particular post, access is controlled by assigning specific registered Users to it.
That’s it so far. Feedback is welcome – your suggestions will definitely drive the direction/features/changes I make in this, because I get my giggles out of creating solutions people can actually use.
