Category: Technology

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…

Categories
Technology Weblogging

First change

The first changes being made to the initial snapshot of the WordPress 1.3a code is to incorporate the ‘floating cloud’ design currently being used at Burningbird into a 1.3 theme. While I’m at it, I’m also moving the default pages down into the themes directory, to minimize the number of files at the root directory of the installation.

While I’m making the changes, pages and links may break from time to time. When finished, this effort should also be usable as a template/theme for WordPress 1.3a, and will incorporate, among other things: live comment preview, post-comment editing, and comment spell checkings.

Categories
Technology Weblogging

Second change

A vulnerability was discovered with WordPress 1.2.1 and 1.3a, as detailed here and in a forum thread for WordPress, here. This was caused by the fact that an important system variable, siteurl is modified in wp-login.php if the application detects that the URI used to access wp-login.php has changed from what’s stored in the database.

As detailed in both of the above locations, there is usually more than one way to access a specific file, and accessing the file using different variations of URL results in a change to this value that could cause problems with the site. At a minimum, it could result in unnecessary updates to the database.

The current WordPress release was modified to lessen the amount of destructiveness of this vulnerability, but it hasn’t eliminated the problem completely. To fix the remaining vulnerability, I’ve removed the code that updates this value in the database from wp-login.php (though I’ve left the option in the database for now). Unfortunately, this leaves the original problem that served as reason for this code, which is to make it easier to move your WordPress weblog if you need to. Without this code, moving your weblog to another directory can make the administrative pages impossible to access. When I removed the vulnerability, I added back this problem.

To fix this original problem, I added SITEURL as a new parameter to the wp-config.php file, now renamed wf-config.php to differentiate it from the WordPress file. Now, when the WordPress weblog is moved, you can use a text editor to change this value:

define (’SITEURL’, ‘http://wordform.org’);

I also modified the code in the functions.php file that loads siteurl from the database, setting the cached values to that of SITEURL from the wf-config.php file.

if (’siteurl’ == $option->option_name) {
$option->option_value = preg_replace(’|/+$|’, ‘’, SITEURL);
}

This is an interim fix, while the rest of the code is adjusted not to depend on this as an option loaded from the database. Once I’m sure this is so, I’ll remove the option from the database.

Categories
Technology

When open source is like bad sex

Recovered from the Wayback Machine.

Earlier, in response to designer demands for programmers to be more responsive to users, I wrote a post titled Open Source is Like Sex. In it I said that the users need to think about being less passive–to meet the techs half way.

Of course, when the users say, “Come on honey, I’m ready to rock and roll”, it would help if the developers don’t respond with, “Not now, I’m not in the mood.”

This new writing is related to the earlier post about the vulnerability found in WordPress 1.2.1 and 1.3 that would allow anyone to change a person’s siteurl value just by entering a bad URL into a browser. This can render a site unreadable, and even unusable; luckily though, it was a relatively easy hole to plug.

That WordPress, like all software, has bugs is nothing new and no big deal. There is no such thing as ‘perfect’ software, and you can spend the next twenty years jumping from weblogging tool to weblogging tool and still manage to stub your nose or your toes hopping into bed with each new hope of the moment. Perfection isn’t going to happen and the most that you can hope for is reliability, and that the tool doesn’t actively get in your way when you’re trying to write.

In their relationship with developers, users can meet them half way by understanding that shit happens. They can help with testing, by reporting the bugs, and by maintaining a sense of humor when things don’t quite go right. And yes, being grateful for the software, especially when it’s ‘free’. However, the developers also have a responsibility back to the user: to fix bugs, as soon as possible; to let users know about potential problems; and above all, to be respectful of the application’s users and their concerns.

That’s why I am disappointed about the events surrounding the siteurl bug – not because of the bug, but because of what happened before and after. It was best summed up by what one of the WordPress support forum moderators, podz said, “When decisions are made, we will no doubt be told.”

And that about sums up the entire communication about this whole problem.

You know, if I had even a tiny fraction of the enthusiastic users that WordPress has, with any of my ideas and efforts, I’d damn near cry in delight. Ask any developer and they’ll tell you the same thing: sure you can write code for yourself, but its more fun when others want to use it.

If users shouldn’t take developers for granted, the reverse should also be true: we should never take those who use our software for granted. Sometimes ‘free’ software developers forget that they truly are being paid for their time and their efforts; users are paying them with interest, with gratitude, and with trust.

Categories
Technology

Code day

Maria could be describing my day when she writes:

I love days like today, when everything seems to be well padded in mist and torpor. The leaf blowers are silent, no one is out there improving their house or garden, and with the windows closed, for all I know, cars have ceased to flow on the roads.

However, our day was more a cold rain than a mist. Still, it was in ‘in’ day, spent catching up on coding projects. After a day of hiking, coding seems more fun somehow, as well as it giving my knees a chance to ‘rest’, poor dears.

I worked a bit with the OsCommerce store application and think I’ve managed to get the CSS layers and the HTML tables to play together for the layout. I am not a CSS purist, but I do strongly believe that templates are more adaptable and easier to work with when done as CSS rather than tables — tables add a lot of extra baggage, making the pages harder to read and customize. I’ve found this with the weblogging tools I’ve worked with, and I’ve been through enough weblogging tool templates by now to almost think this could be a truism.

I also worked on Tinfoil Project today, and have incorporated annotation as well as comments into the pages. I did have to use popup comments, but there’s a little ‘goodie’ included in most of the popup pages–similar to the sidebar ‘goodie’ that appears, from time to time, with these posts.

My busy fingers didn’t rest once today, and I also spent time contemplating migrating IT Kitchen weblog entries into wiki entries. After looking at the wiki database schema, I found that this isn’t as complicated as I thought it would be. However, I decided against doing a migration today, primarily because the weblog writing doesn’t translate well to a wiki environment. After all, weblog writing is fairly static and created by one author; while wiki writing is fluid and authorless. I don’t want to move people’s essays over into an environment that encourages editing.

What’s needed is the ability to ‘freeze’ pages in a wiki, and annotate with the author–a ‘essay category’ page. Better yet, the ability to pull data in from the WordPress/Wordform database and format it as a wiki page, sans the editing capability. The code is so nicely organized and documented in MediaWiki, it wouldn’t be an especially difficult task, and could be a fun exercise. The hard part would be to merge discussion between the two tools, weblog and wiki. That could be tetchy.

I’m finding out that I really enjoy ripping into open source code, blending bits and pieces of different products together. I was even eyeballing OsCommerce code today, thinking, “You know, this could be combined with a weblog for subscription based online publications…”

So many possibilities, so little time. Speaking of time, congratulations to Scott on his five year blog anniversary, and Karl for his almost five year mark. Reading both of your weblogs, I found your words are still fresh and youthful–like the words of young blogging babe instead of the old blogging codgers that you are.