Planning v0.5 of the WordPress Password Plugin

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.

  1. 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:

    1. You define “the general rule”: Whether the whole site is protected or not, by default.
    2. 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.
    3. 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…
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Watch Out For The Ooof! (Sordid Stories #2)

“Pirate Omar” is a recurring character in my daughter’s favorite story requests. He’s basically a happy-go-lucky, friendly, adventurous pirate who sleeps in his own bed (on his pirate ship, of course) all night long.

This particular story has only been told to my 2 year old son once. And yet he repeats the fun part every chance he gets.

Watch Out For The Ooof!

Once upon a time, Pirate Omar wanted to see if he could sail all the way across the ocean to the clouds far, far away.

He sailed all day and all night, and all the next day. After all that sailing he was very tired, so he went to sleep in his bed.

The next morning he woke up when he heard a sailor yell “Watch out for the Oof!”.

Pirate Omar sat straight up in his bed, curious about the funny thing the sailor said.

“Watch out for the Oof!”, he heard another sailor shout.

Pirate Omar jumped out of bed, ran up onto the deck and looked around. Everywhere was foggy and gray. He couldn’t see very much – they must have reached the clouds!

Just then, another sailor called out, “Pirate Omar! Watch out for the”

OOOF!*

A big fluffy cloud had bonked right into Pirate Omar’s head and knocked him right down. He slept all day and all night again.

  • “OOOF!” is only fully appreciated when you whack your sleepy child in the head with a pillow. At which point they’re no longer sleepy.
  • The first time you tell this story, it’s better to hit yourself with the pillow… hitting an unsuspecting, sleepy child might be considered abuse. It’ll certainly incite crying. Subsequent retellings are fair game for whacking children.