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.

43 replies on “Planning v0.5 of the WordPress Password Plugin”