Posts in the Tools Category

So when I said on Monday:

Got feedback?  Let’s hear it?

…what I actually meant was:

Got feedback about the code or how the package works once it’s installed in WordPress?  Let’s hear it.

I should have realized that otherwise, the comments would turn into an argument about comment spam, fighting it, ways the general idea could be defeated, and more.  Which they did.

Look, folks, despite what some people might tell you, I’m not so arrogant as to think that I could single-handedly solve the comment spamming problem for all time.  Even if I were, I very much doubt I’d be so clueless as to think that WP-Gatekeeper was that solution.  And if both those things were the case, I’m pretty darned near certain I would have very explicitly made the claim of having beaten the spammers.  Likely in big, boldfaced, red, capitalized, blinking letters, plus a background MIDI of “We Are The Champions”.

WP-Gatekeeper is not going to stop every possible comment spam attack, human or automated, for the rest of time.  Neither is any other defense you can name, without exception.  There may be measures that currently have 100% resistance to scripted attacks.  They will one day fail—I can pretty much guarantee it.  Even today, they are defeatable by actual humans sitting at computers and posting comment spam on every site they find.  That kind of spamming is very, very rare, but it happens.  I had such an incident within the last month.  If I hadn’t been keeping a close eye on new comments just then, I’d likely have missed it completely.

I’m fully aware that there are ways a spambot could defeat WP-Gatekeeper.  At the moment, none of them can.  That will one day change, of course, assuming challenges become at all popular.  Comment spam and the fighting thereof is a dance, a tennis match, an arms race.  Neither side will ever win.  As one side adopts a new tactic, the other side will move to counter it.  The countermeasure will itself be countered.  And so it goes.  Eventually, either spambots or spam defenses (or the two in combination) will become so advanced that they’ll gain self-awareness, and then we’ll all be royally hosed.

I know this.  You know this.  Let’s move on from there, okay?

In the end, the goal is to add another arrow to the quiver at the disposal of spam fighters.  Think this approach is wrongheaded, annoying, or otherwise pointless?  Fine.  Don’t use it.  For those who want to add this kind of capability—and since I instituted it on meyerweb, I’ve had not a single piece of spam make it onto the site or hit the moderation queue, whereas in my pre-defense days, I’d get at least twenty every day—then the package is there.  You can combine it with other defenses, if you like, for even more coverage.  I may upgrade it in the future, depending how far I get in learning PHP, mySQL, and form handling, and what feedback I get from people who know PHP better than I do.  I may not, in which case the system as it stands is effective, and probably will be for a while.  Even if I do one day abandon further development, the code is out there for someone else to improve if they so choose.

In the meantime, if there’s anyone who is using WP-Gatekeeper or has looked at the code, and has feedback on the coding or the way it works for the administrator of a WP blog, please feel free to share.  Also, if anyone can point me to an example of PHP code for collecting all of the HTTP_VARS that are returned by an XHTML form and then looking through them, even when the variable names aren’t necessarily known ahead of time, I’d really like to see it.  Thanks.

• Gatekeeper In Perspective was published on Wednesday, January 26th, 2005.
• It was assigned to the Tools and WordPress categories.
• There have been twenty-six replies.

In my post on rel="nofollow", I mentioned the use of easily human-comprehensible challenge questions like “What is Eric’s first name?” as a way to defeat spambots.  There were two points made in the comments that I had considered but hadn’t brought up, given that they were tangential to the point of the post.  They were:

1. Spammers could set up a database of questions and answers used on sites.  They might or might not share it with each other, but the point is that if I set up “What is Eric’s first name?” as the sole challenge, the human running the spambot could build the ability to answer the question into the spambot, thus defeating it.  Quite true.
2. In order to make it more difficult to do this, there could be a set of challenges from which one is picked randomly.  So I might have three challenges asking for the first names of myself, Kat, and Carolyn.  Every time a comment form is delivered to a browser, one of the three challenges, picked at random, is included.  This would make it more difficult for a human spammer, since he (or she) would have to find all of the challenge questions. work out the responses, and build them all into a database, keyed to each site’s domain.

So over the weekend, I built as a proof of concept (and also as an exercise in learning more about how PHP, mySQL, and WordPress work) a WordPress package to do what described in the second point above.  It’s called WP-Gatekeeper, available from my WordPress Tools page, and if you’re brave you can give it a try.  Why brave?  Because the installation involves hacking a few WP files and adding a new entry to the admin menu, not to mention firing up a plugin.  And if you do it in the wrong order, you can break commenting for a short period.  There are DIY installation instructions on the WP-Gatekeeper page, for those who still want to proceed.  You also need to be brave because if you install it, you’re running code written—well, actually, adapted—by someone with only beginner-to-intermediate PHP skills.  I’ve been testing it locally and everything seems fine, but this is even more “use at your own risk” software than usual.  Got it?  Good.

Accordingly, WP-Gatekeeper is currently considered beta software.  I’m making it available now in the hopes that people more experienced than I with PHP and WordPress can take a look, hack on the code, and make it more efficient and the whole package easier to install.  I’m already aware that in WP 1.5, adding the admin page is much easier and doesn’t require hacking files, but I wrote WP-Gatekeeper in 1.2 and want it to work there, since that’s the latest public version.  Thus, any optimizations should work in 1.2.  When 1.5 (or whatever the next version number is) comes out, then I’ll worry about it.

Of course, there’s still nothing that prevents a spammer from registering questions and answers into a database, but the admin page makes it easy for a blogger to add, remove, modify, and re-key the challenges.  That will make tracking them more difficult, so long as a blogger puts effort into maintaining the list of challenges.  It gets back, in the end, to maintaining your blog.  The more maintenance you put into something, the better its shape will stay.

I’m also interested in suggestions for how the overall system could be made harder to bypass with a bot, and easier for a WP admin to run.  One feature I plan to add before going final is the ability to have the keys replaced on a regular basis, with the interval (daily/weekly/monthly/etc.) set by the admin.  The  other driving consideration here is that the system should be fully capable of working even if JavaScript is disabled.  It’s an accessibility thing; just go with me on this.  (Accessibility is the main reason I did this rather than install an image CAPTCHA solution, as it happens.)

Got feedback?  Let’s hear it.

• WP-Gatekeeper was published on Monday, January 24th, 2005.
• It was assigned to the Tools and WordPress categories.
• There have been sixty-eight replies.

Well, there was time off for the holidays, but now S5 is back and ready to increment its beta number.  So, without too much ado: S5 1.1b3 (248KB ZIP file).  Here’s the current testbed presentation, for those who just want to play around with it.  Because of the long holiday break, I want to add another beta round or two just to work out as many kinks as possible.  So this isn’t the last version before going final on 1.1; still, I’m interested in any problems that people encounter.

There’s really only one notable change from the previous version.  I incorporated Jordan Liggitt’s “type slide number” code into this version.  Why his, when others have done similar things?  Because his version was well-marked with comments, and thus easy for me to figure out what he’d done and how he’d done it.  So here’s how it works:

• If the user types a number (multi-digit is allowed), the script stores the number.  Inputting any non-number key clears the entered number.
• If the user hits Enter/Return while there is a number stored, the slide show jumps to that slide.  Any attempt to jump directly to a slide past the end of the slide show results in no action, although the number is still cleared.
• Hitting any of the “Next” or “Previous” keys while there is a number entered causes the slide show to skip the number entered in the appropriate direction.  Thus, entering “3” and hitting the space bar would jump forward three slides; entering 5 and hitting Page Up would jump backward five slides.  Skipping past the end of the slide show will drop you on the title slide, which is something I’m thinking about changing, though I’m not entirely certain in what way.

I’m mulling over which keys should invoke which jumping behavior.  For example, a couple of times I’ve typed a slide number and then hit the space bar to advance directly to that slide.  Instead, I jumped forward by that number, which is correct but obviously not what I was subconsciously expecting.  So I’m thinking about further restricting the keys that trigger the “jump n slides” behavior.  Anyone have suggestions based on other slide show software?

At this stage, I’m likely to put off adding the multiple-author meta that I toyed with in earlier versions.  The general need is still there, but I’m just not able to think the problem through with the kind of clarity I want.  It will have to wait for another day.  I’m also dithering a bit about the licensing, though at this point I’m leaning pretty heavily toward using Expat.  My hesitation is largely based on my very desire to make the right choice so that I never, ever have to worry about it again, you know?

Anyway, as always, feedback is welcome.

• S5 1.1b3 was published on Thursday, January 13th, 2005.
• It was assigned to the S5 and Tools categories.
• There have been thirty-seven replies.

Behold: v1.1 beta 2 of S5.  This version has a few of changes, all of which are being floated as trial balloons.  Feedback on them all is appreciated.

• Change in file structure.  Now the ui/ directory will contain only directories.  Thus, the default theme and scripts live in ui/default/.  The reason for this is so that other themes can be put in the ui/ directory without things getting too confusing.  For example, the current beta version has a v11b2/ directory (the beta’s version of ui/) that contains default/ and i18n/.  Switching between them does require manual editing of the XHTML file, as I decided to punt on dynamic theme switching for now.  This does, however, let an author carry around a single ui/ directory with a number of themes contained inside.  That way, he might have four presentations to give, each one with a different theme, but all of them sharing the same ui/ directory.

  Another advantage to changing the directory structure is that v1.0 presentations won’t be compatible with v1.1 themes.  That’s actually a good thing, since the XHTML structure changed in small but significant ways in v1.1b1.

  I thought about further splitting the default directory into “script” and “style” subdirectories, but this seemed like a bit of overkill.  However, I’m starting to wonder how to handle things like IE/Win behaviors, which I suspect will be needed before too much longer.  Why?  Look at the images in the v1.1b2 testbed: they all have flat white backgrounds.  I’d like to turn them all into PNGs with alpha channels, and I’d like to have those work as intended in IE/Win.  The only way to make that work right now is via behaviors like this one.  I’ll want to drop those behaviors into the default/ directory—my leading candidate would actually be IE7, once it gets close to being stable, mostly because it would add quite a lot to theme authors’ CSS toolkits.  But all those behavior files could clutter up the directory, for which the easiest fix is to drop them all in a subdirectory… you probably see where I’m going with this.

  That’s all for another version, though; v1.1 won’t have any behaviors packaged by default.  It’s just on my radar, and I thought I’d toss it out to see if anyone has bright ideas.

• A “header” file for themes.  You can see an example at v11b2/i18n/00_head.txt.  Briefly, this file contains material destined for the head element of any presentation that’s going to use this theme.  In the case of i18n, the only thing that changes is the link element pointing to slides.css.  Nevertheless, the header file provides all of the link and script elements that should appear in the presentation file.  This should make it easier for an editor program to just grab each block and paste them over the existing block in the presentation file.  It will also reduce ambiguity for anyone doing a manual edit to change themes.  (Open header file, drag-select, copy; open presentation file, drag-select, paste, save, done.)

• Changes to incremental class names.  In earlier versions, incremental-display objects were marked with a class of inc, and any list that should start out already showing the first list item got a class of psf.  I’ve changed those to incremental and show-first.  The new names require a little more typing, but they’re much less ambiguous and therefore much more author-friendly.  I’m interested to see if anyone has ideas for better names, especially for show-first.

As for the issue of licensing, I guess I’m little further along, but not all they way yet.  The discussion did help me focus on what I want.

• Presentation content should be under whatever license/terms the author desires.  I do not want to force all S5 presentation content to be public domain, or GPL’ed, or whatever.  If someone wants to give a highly confidential talk using S5, they should be able to put the most restrcitive license in the Universe on the content… but only on the content.

• Themes should similarly have their licenses, or lack thereof, determined by each one’s author.  If Joe Consultant wants to create a MyCoolCo theme and release it under copyright so that anyone can use the theme for their own presentations but nobody is allowed to re-use his images/look-and-feel/whatever outside the S5 theme, there should be nothing that stops him from doing so.

• The S5 system (JS, core CSS, and the way they’re put together) should be forever free to use by anyone who wants to do so.  It should be open for future development, in the event that I stop developing it and someone wants to keep going.  This would also allow anyone to fork off their own variant on S5 at any time, but that’s okay too.

  Here’s where it gets a little tricky: S5 should be able to be incorporated into any other project, commercial or not, without restriction.  Attribution to the original source is to be strongly encouraged, but not an absolute requirement.  But at no time, and in no way, should use of S5 in a closed environment ever cause a back-flow of restrictions to the original project.

In other words, anyone should be able to use S5 or a derivative work in their for-profit, wholly proprietary, patented software (or in any other circumstance).  They can even make modifications, if they like.  However, there should be no way for their use of it in a closed system to infect the original S5 source, and if their modifications make it into a future version of S5, the same should hold true.  I don’t even know if that’s possible, but it’s in the spirit of the Share Alike terms in the Creative Commons licenses.  You want to build S5 support into your $49.95 fully copyrighted and licensed editor?  Fine, no problem.  You want to extend S5 to do more cool stuff?  Also fine, but freely contribute the changes back to the place you got the code in the first place.  Don’t try to claim the original project has no right to the additions you made to it, or that the addition of those changes to the original project makes the whole thing yours.

(Not that I think any of you would do such a thing, but I have to think ahead to when S5 catches the interest of someone… well, let’s say less scrupulous.)

In a sense, I want to prevent major infection of licensing terms in both directions.  I’m not entirely sure where that leaves me, but I’d like to work it out before 1.1 goes final.

• S5 1.1b2 was published on Thursday, December 9th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been thirty-one replies.

Okay, S5 version 1.1 is now at beta 1 status.  In the process, I’ve rearranged the S5 sub-site a bit.  The testbed is now in a new location that will let me more easily manage version changes, and also keep test files out of the main directory.  The testbed demonstrates, at least right now, various forms of incremental rendering, including both text and image techniques.

There are some changes to note in 1.1b1:

• The controls div is now a child of the layout div, and is thus no longer structurally confined to the footer.  This makes a few things easier, but it does mean any 1.0 themes are likely to get mangled a bit.  I decided to do this now in order to minimize disruptions.  The structure reference does not reflect this, as it documents v1.0, but will when v1.1 is finalized.  I was able to convert the default theme, I18N, and a new theme to handle this new structure without much trouble.
• I’ve refactored some of the CSS files to make them more compact.  Nothing earth-shaking, but I thought I should mention it.
• The slideshow configuration meta elements have been renamed to defaultView and controlVis, and have slightly different accepted values, but otherwise do exactly what they’ve done since they were added.
• I’ve added an authaffil meta element, with syntax set up to allow multiple authors to be listed.  I’m considering making the value format a little more machine-readable, but we’ll see what you all think first.
• I fixed the Safari bug where it advanced the slide show when opening an external link.  Yay me.

I’m in the process of setting up an archive for ‘official’ S5 versions, so that you’ll still be able to download the S5 1.0 UI folder even when we’re up to 1.725 or whatever.  This will be in place for the launch of v1.1.  Yes, I hear you: use SourceForge!  I’m abstaining for now, because I don’t have time to figure out how to set up a project on their system, let alone how to fix their UI so it isn’t confusing and frustrating.  Mine may not be much better right now, but at least mine’s easy for me to fix (and I’ll get to it soon, I promise).

The other major addition I have planned is to create a set of guidelines for theme packaging.  For example, every theme should contain a file titled 00_head.txt that contains the head-based elements (links and so forth) that should be used in a presentation file in order to make the theme work.  This will make it much easier for presentation authors to use themes without having to understand the ins and outs of the S5 file structure, and for theme authors to only have to package the files they want to change.  Hopefully that will make more sense once I write the guidelines.

And finally, you may have noticed that I’ve stopped superscripting the 5 in S5.  Practically nobody else was doing it, and it was getting to be a pain even for me to type, so I figured I’d go with the flow.  I’ll change the documentation eventually.

So please test out the testbed and let me know if anything goes seriously awry.  If anyone wants to try hooking up the 1.1b1 UI files to their own presentation, I’d be interested in hearing the results.  Remember, though: make sure your presentation file’s XHTML validates!  If you report problems in an invalid presentation, I’m not going to look at it until the validation errors are corrected.  That’s because the DOM routines depend on well-formed markup, and it would be futile for me to try to debug any problems caused by invalid markup.

With luck, we’ll only need one or two beta cycles before 1.1 can go final.

• S5 1.1b1 was published on Thursday, December 2nd, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-eight replies.

Hey, we’re moving quickly: S⁵ 1.1a5 is now up.  The current testbed file uses XHTML 1.0 Transitional, the better to accomodate the “allow external links to open in new window” feature I added with prompting from Peter Murray and assistance from Dave Marks.  I’m thinking about generalizing the routines to just mark any link that starts http://... as an external, window-spawning link, but that to me seems a little too intrusive.  I tend to think it’s better to let the author mark which links should spawn new windows, and which should not.  If I’m wrong, let me know.

Among other bug fixes: incremental slides now wind and unwind correctly, and don’t leave the last point on the slide stuck in the “current” state even when you loop through the slide show more than once.  The show/hide for the controls has a slightly different behavior now, so I’m looking for feedback there.

The last bug I want to squash before exiting the alpha stage is that in Safari, when you click on an “external” link, it still advances the slide show one step.  All other browsers I tested (IE/Win, Firefox) didn’t, as was the intent.  I can’t quite figure out how to fix Safari’s problem, which seems to center on the new hasValue() function.

(singing) Beta slide show, here we come…

• S⁵ 1.1a5 was published on Thursday, November 18th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-four replies.

Hooray, we’re up to 1.1a4!  The only real change here is that I’ve added a “what do you want to hide, the controls or just the popup menu?” feature.  This is handled with the following meta element:

<meta name="controls" content="hide" />

That will hide all the controls.  The default behavior is “show”, which shows the controls but not the menu.  The testbed file is currently set to hide the controls by default.

Only here’s the problem: the modifications I made broke the system in IE/Win.  It returns the ever-so-helpful message “Unknown runtime error” and a line number that doesn’t seem to make any sense to me, so I’m not sure exactly what’s broken, nor why.  Assistance appreciated. Okay, that problem got fixed with a rename suggested by Michael Moncur.  The problem now is the control menu doesn’t appear when you mouse over the lower right corner, although the controls show up okay.  This may be my fault, but help in figuring out how to make IE/Win consistent with Safari and Firefox is needed.  Thanks. Those of you using Safari or Firefox will see things as intended, at least until the IE/Win thing is fixed.  I’m especially interested in feedback regarding how the controls reveal and hide themselves in the testbed presentation.

I suspect I’m getting close to the end of feature additions for v1.1; at this point, I’d like to clear up any lingering bugs, possibly rework how the default settings are represented in the meta elements (but not their intent), and write up a quick guide on creating and using themes.  I think that will be more than enough.  I don’t want to try to tack on too much at once with each revision.

• S⁵ 1.1a4 was published on Wednesday, November 17th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been fourteen replies.

We’re up to 1.1 alpha 3, with the big news this time around being incremental display.  So far, the way this works is that you can class a ul or ol element, and have the bullets in that list be incrementally displayed.  This is easier to understand by seeing than by reading an explanation, so go check out the alpha testbed.  In the first slide, all the bullets are displayed incrementally; you move through them by using any “next” action (keyboard or mouse).  You can also back up using a “previous” action.  The exception to this is the next and previous controls in the lower right-hand corner of the slide.  These always move forward or backward by one slide.

On the first slide, all of the bullet points are greyed out until you advance through the slide.  On the second slide, the first point is pre-highlighted.  This is intentional; it shows the difference between the two ways of presenting an incremental list.  On the third slide, the main-level points are all normal but the sub-list is incremental.  Again, this is intentional.  The highlight effect is completely CSS-based (using the class current), so every theme can have its own incremental-display look.  I picked red because it was really, really obvious, and I was too lazy to think about what color would fit in better with the default theme.  I’ll get around to tidying that up later.

The one thing I’ve made the system do but am not sure about is that when you back up to a slide that has incremental display, it starts out looking normal and then “un-highlights” as you move backward through the points.  I’m not sure that this is desirable, but at the same time I think it could be very useful.  (Plus you can always skip back a whole slide by using the lower-right controls.)  I’d like to hear feedback on what people think about the way the incremental display works now, and how it could be better.

For those who want to play around with incremental display, you add a class of inc to a list whose items you want to be incremental.  If you want a slide to start with the first point highlighted, add psf to the class value, so you have class="inc psf".  If you want to reveal arbitrary elements one by one on a slide, individually class them with inc.

I don’t have all of the contributed code merged into the JS yet, but I’ve seen everyone’s contributions from earlier posts, so please be patient.  I’m still at a loss as to how to make the intra-slide links work in Safari, and could use help figuring out what’s wrong there.  To test it, hit the “skip to summary” link on slide 1 of the testbed.  For that matter, if you uncomment the li:after rule in pretty.css, you’ll see that Safari keeps adding “NaN” into the classes of incrementally-displayed list items when you move back and forth from one incremental slide to another.  I can’t figure that one out, either.  Help is always appreciated.

So from my original 1.1a2 to-do list, the following are still left to do:

1. A way to choose whether to show/hide all of the navigation controls, or just the menu. Indicating the preferred behavior via a meta tag is starting to feel more like the right way to go, since it means the presentation author can decide whether he wants the controls to be visible or hidden.  The problem of exactly how to manage the behavior is as yet unresolved.
2. Better, possibly more dynamic, theme selection.  I still don’t have a clear idea of how this would really work.  It might be better to simply write a clear description of how to associate a new theme with the presentation file, and write up guidelines for theme authors.
3. A way to indicate the target resolution in the CSS, so that the scripts can use that for scaling purposes (and thus make the scaling more intelligent).  I’m actually leaning pretty heavily toward dropping this, because I don’t see a pressing need to include it at this stage.  For the purposes of scaling foreground iamges, it wouldn’t be much more powerful than the author managing scaling via CSS.

And there you have the current state of s⁵ development.  Feedback is welcome.  Ever forward!

• S⁵ 1.1a3 was published on Saturday, November 13th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-one replies.