Categories
Technology Weblogging

Multi-blog Multi-user metadata support

Recovered from the Wayback Machine.

In my comments, Eric Wallace asked about multi-weblog support. I can answer him, with a few caveats, that yes, the first alpha release of Wordform will have multi-weblog support. The caveats are that this support, in addition to multi-user support, will be added as formalized extensions to the base product.

Much of the work I’m doing in the administrative pages is to make much of the interface dynamic, so that I, or another developer, can extend the options available within the tool itself — not just within the weblog pages shown to the public. By doing this, the base Wordform release will be very simple and easy to use and hopefully will meet the needs of 95% of the weblogging user base.

Now, for the other 5% of webloggers who want to get down and funky, well, they have some interesting possibilities available to them, as time goes by; including three extensions, called Administrative Extensions that will release with Wordform 1a.

The first Administrative Extension is multi-user support, and this will add in the User management page, in addition to a drop down in the edit page allowing an administrator to pick which user to write as. For the non-administrative users, they will only be able to post as themselves.

To meet this functionality, the Profile page will be pulled out of the Users page, so that everyone can manage their own profile, regardless of Extension installed. In the Users Management page, though, those with administrative permissions will be able to assign Profile types to users, as well as define what accessibility each profile will have.

The User Management page will also allow the administrators to assign individuals to specific weblogs, which leads to the next major extension: multi-weblog support.

The developers of WordPress had added blog number to tables in 1.2 (correction: I don’t find these, so will need to add), but hadn’t implemented multi-weblog support, because this is not an easy change and I can respect this, having to struggle with solutions myself. Specifically one problem with PHP is that you have to set directories to write by the world to add files, and this isn’t necessarily secure.

I’ve thought about this one for a long time, and the implementation I’m going to support is something a little different–matching Movable Type’s way of doing business more than WordPress.

If you install the Multi-Weblog Administrative Extension, an administrator gets an option to create a new weblog. This weblog will be added to the database system, and you’ll be asked for specific URLs of the home page, archive structure, and so on — just as with permalinks options page now. You’ll be given a second of permalink entries for an .htaccess file for the new weblog, but you won’t add them to the existing .htaccess file for the initial weblog installation; you’ll add them to the .htaccess file at the new location.

(There will probably be one more file that needs to be copied to the new location. Hopefully no more.)

The new location will act as a separate weblog, but it will be run on the same Wordform installation.

So I have a weblog at practicalrdf.info and one at weblog.burningbird.net. The practicalrdf.info site is a subdomain installed in /home/shelley/www/rdf, and weblog is installed in home/shelley/www/weblog. I install Wordform at weblog.burningbird.net (in /home/shelley/www/weblog) and generate permalink entries for the .htaccess file at weblog.burningbird.net.

When I add the second weblog at practicalrdf.info, I’ll generate a second set of .htaccess rules for this new weblog, which will be added to the .htaccess file at practicalrdf.info (at /home/shelley/www/rdf). These rules will, among other things, define which weblog number the pages belong in, and will also handle redirects for comments, trackback and so on, because the application files for all of these are still back at weblog.burningbird.net.

Both weblogs will be in the same database tables, separated by weblog number, very similar to how Movable Type works now.

From the Command Central page, you select the weblog you want to work in, just like Movable Type, and everything is filtered to that specific weblog. Again, just like Movable Type. The only difference is that there won’t be static pages at the site for the archives.

The basic installation of Wordform will be adjusted to pass weblog number, regardless of whether this extension is installed, so that it can be dropped in with minimum impact. This is the most major change I’m making when moving WordPress to Wordform.

Each weblog will be able to create its own separate wp-content subdirectory, to handle separate photo uploads and plug-ins and themes. However, activation of plug-in and themes is separate for each weblog.

The last Administrative Extension released with Wordform 1.a, is the primary influence for me to fork WordPress, and that’s the Metadata Extension. I want to cover this, very carefully, in a separate post, but for now, briefly, the Metadata extension allows developers to define a new RDF triples based meta-vocabulary, which can then be added to the installation–just as you add a plug-in. The developers will include, as part of the extension, an easy to use form for the weblogger to add data.

As a person adds a new post, they’ll have the option to add the metadata for one, two, or a dozen vocabularies, based on a dropdown box available from the edit page. They could add poetry metadata (’bird’ is used as metaphor for ‘freedom’ in this poem, named ‘ ‘, discussed in this weblog post with URI of _____); podcast metadata; photo metadata; metadata for recipes; geography — any vocabulary that is defined as a ‘metadata’ extension within the Wordform accepted format.

Just like with the feeds now, you can access a page like http://wordform.org/2004/12/comment-spam-prevention-in-wordform/rdf, and get the RDF/XML for all the vocabularies with data defined by the weblogger. Or you can pass in http://wordform.org/2004/12/comment-spam-prevention-in-wordform/rdf/poetry, just to ge the RDF/XML for the Poetry vocabulary defined for the post.

Before the developers assume this is a way for me to sell my RDF book, tools will be provided to make this easy to do for the developers (i.e. they won’t have to ‘learn’ RDF–they should, but they won’t ‘have to’). I’ll also be using RAP (the RDF API for PHP) to manage all the RDF bits.

I have been promising both threadneedle and Poetry Finder for close to three years now. Finally I have the vehicle to deliver on my promises.

More on metadata extensions in Wordform later this next week.

Categories
Technology Weblogging

Comment spam prevention in Wordform

I believe that, eventually, most comment spam strategies will have to have a system-wide component in place to truly combat this problem — something to watch for comment spam patterns happening on a server, and throttle accordingly. However, that’s something that can’t really be handled with the application. So, I’ll focus on what I can do in Wordform.

My comment spam protections are not going to include a blacklist, in any shape or form. These require too much processing, and are too vulnerable to corruption. Instead, I’ll use a variety of techniques that combined should protect a site — even a heavily hit site.

First, I’ve added individual comment moderation so that you can turn moderation on for a specific post, or a group of posts. When this is turned on, a message will show near the comment form stating that the comment is currently moderated.

Next, I’m adding new capability to search in comments for those that fall into a range of dates, and then be able to delete all comments that match a search criteria. With this, if you do get hit, it should be easier to delete the spam.

(I’m also adding a one-touch button to globally approve, or delete, all moderated comments.)

The comment posting page will have a throttle that can be configured in options. This throttle will check the number of comments received within a certain period of time, and if the count exceeds a value that the user can specificy, will either moderate the comment, or deny it (again, something that can be configured). At Burningbird, the throttles are no more than ten comments in a minute (a WordPress option); and no more than 50 comments in a day (my option). These two values can be changed, and I’m also adding a maximum count for number of comments allowed in an hour. All of this will prevent ‘crapfloods’, which can overwhelm a site, and even a server.

Currently I’m using database queries for the comment throttle I have at Burningbird, but for Wordform, I’ll be using other caching methods to hold timestamps and comment counts. This should make the throttle lightweight and robust.

I’m also adding a configurable option to either close or moderate all comments over a certain number of days old. I use this with Burningbird, whereby the first comment to a post over so many days old gets moderated, and then the post gets closed. This has eliminated probably about 98% of my comment spams, while still giving me the option of determining (from this last comment), whether I want to keep the post open, but moderated.

A new functionality for Wordform not currently implemented at Burningbird is the ability to close a discussion. By closing a discussion, the post (or the web site) is temporarily put into a lock-down form, where only those people who have previously written published comments can add new comments. When they do, the comment is posted immediately. If a person hasn’t added a comment previously (based on the person’s email, which is a requirement for lock-down, though it’s not printed), their comment will be put into moderation.

Finally, I’m experimenting around with a new comment spam prevention method that I’m calling “Stealth Mode”. However, this is one item I am leaving for a “Ta Da!” moment when I release Wordform’s first alpha release.

(Most of these comment spam moderation techniques will also apply to trackbacks. I’m currently wavering on my support of pingback, which is really nothing more than recording a link, and this is accessible via the vanity sites.)

Between all of these–Throttle, Lock-down, individual and weblog moderation, better comment management, closing older posts, and Stealth Mode–the comment spam problem should end up being no more than a minor irritation in Wordform. Then if I can just get people to accept that comment spam is not an invasion of a person’s personal space, and that it’s a way of life and to not spend so much time fretting about it, we’ll have the comment spam problem managed.

Categories
Technology Weblogging

Why Wordform needs active users

Wordform is not being developed in isolation, specifically because I hope to capture input from people who could be considered the potential users of the product. It is more fun to go ‘Ta Da!’ and have the application all finished, to ooohs and ahhhs; but an inherent problem with this is that each of us brings our own interpretation of what is an oooh, and what is an ahhh.

A better approach, then, is to communicate as you develop (rather than after), keep your mind open, and solicit feedback as much as possible. And for this, I need active users — people who are willing to step up and say what they want, and how they want it.

For instance, when Marius points out the polished interface to the textarea within Blogger, saying that this is more meaningful than the Quicktags within WordPress, we can quickly show him a screenshot of the prototype for the Wordform edit page, currently in development. This is using the beta of HTMLArea, which is a very rich text editor currently being tested with Mozilla-based browsers, such as Firefox. It, as with Blogger, will work with IE and any of the Mozilla browsers. Unfortunately, it won’t work with Safari; but then, neither will Blogger.

The PHP program will test browser and insert quicktags, HTML tags, for browsers that can’t work with these rich text editors. However, Blogger’s switching back and forth between WYSIWYG and HTML tags, is a very nice feature. Luckily it’s already included as a feature within HTMLArea — just click the button labeled “<>” to toggle between HTML source and WYSIWYG.

As a sidenote, the new Comment Edit window in Wordform will also have a rich text editor, but I’m removing the HTML capability (HTMLArea is completely customizable). Why? So that I can ensure that tags are properly closed and that nothing harmful is added, while giving commenters a very rich editing experience.

Oh, and HTMLArea has plugins that will allow me to add in spellcheckers and various other nifty goodies. Don’t you just love open source?

Categories
Technology Weblogging

Adapting Admin for extensibility

Recovered from the Wayback Machine.

Many of the earlier changes I’m making to WordPress will be behind the scenes, in the administration pages. In fact, when I finish these changes, I probably will release a copy of the product as it will then be sufficiently different enough from WordPress to have earned status as a separate product.

One change I started coding a few weeks back was to make the administration pages more adaptable. For instance, rather than hard coding the post and comment status into the administration page, I’m adding these as database values and building the options list dynamically. With this developers who want to add new statuses for each can do so with an update to the database, leaving the code untouched for future upgrades.

(The post status can be passed to blog header, for processing for preview, display, etc. The comments files will also handle different statuses, as I already do so in my current comments pages.)

In addition, the menus and submenus of WordPress are built from a file, and this again makes it so that those who create extensions either have to modify the file or using some kind of DHTML to add options. A more adaptable approach, which I’m building into Wordform is to load the menu options from the database, rather than from a file.

A third area of adaptability is to modify the buttons below the text for a post to add options for what can be done with this post. With this, when I wanted to post a full page preview of a post (using the same stylesheet as the weblog), I wouldn’t have had to hack the page — I could have just added an option into the database and the functionality as a plugin.

All this cuts into the space in the page. What I’m thinking, and looking for feedback on, is to drop the in-page preview, since I’m providing a fullpage preview. I’m also thinking of making slug and trackback that display below the post into buttons that open small windows for each and doing away with separate simple and advanced edit pages. (See diagram of specific changes.)

I had also considered making the category into an option to open in another window, similar to how Movable Type handles it. The category hierarchies don’t display well in the page, and cut into text edit space.

However, is all of this too many window openings? Should I leave the categories as is, but open windows for some (or all) of the others?

Categories
Technology Weblogging

Start at the beginning

Wordform is a project to create a new weblogging tool that incorporates some ideas I’ve had for a tool for a couple of years now. It’s based on WordPress, an open source, GPL PHP/MySQL application; inheriting some functionality, while extending the product in new directions.

This site serves as the test site for Wordform development, as well as the beginnings of tool documentation. I will be documenting each change, before I make the change, describing the purpose and planned behavior; after with the code.

Stay tuned…