test weblog

If you have a CMS that has unfriendly URLs such as “/?id=6785″, or similar, you could use this little tip.

Add a .htaccess to trap 404s (missing pages). chmod it to 644. In it, place this: “ErrorDocument 404 /404.php”

Now, for the interesting part. The following script assumes your table is called ‘pages’, your database connection script is held in ‘.htDB.php’, and stuff. Read it to figure out more.

<?
$contact='kverens@contactjuggling.org';
include('.htDB.php');
$r=preg_replace('/^\//','',$_SERVER['REQUEST_URI']);
$r=preg_replace('/\?.*/','',$r);
$r=addslashes(urldecode($r));
$q=mysql_query('select id from pages where name="'.$r.'"');
if(!mysql_num_rows($q)||ereg('/',$r)){
 mail($contact,'[yoursitename.test] missing page',
  $_SERVER['HTTP_HOST'].' '.$_SERVER['REQUEST_URI']."\nfrom: ".$_SERVER['HTTP_REFERER']);
 header('Location: /');
 exit;
}
header('Status: 200 OK');
$r=mysql_fetch_array($q);
$id=$r['id'];
include('index.php');
?>

Note that this grabs the page’s ‘id’ from teh table. If you use a different scheme, then obviously, you’ll need to amend this.

After spending a fruitless few hours searching for an Open Source program which can draw out the relationships between various tables in a database, I’ve found nothing useful to me.

The one program which looked perfect for the task, Rekall, crashed when I tried to create a database with it. This was after hours and hours of compiling…

The one I’ve been pushed towards by most people is Dia, but that’s too general, and has too high a learning curve for the time which I can spend at it.

I’m thinking I might have to write one for future work. A pity I’m a web developer, and not a GUI developer. I have the wrong skillset.

quote from alt.html today:

Yep, my first thought was “how do you use a radio button on paper”?
[...]
My second thought was that in J.K. Rowling’s world, parchment with form controls and dynamic display is probably rather commonplace. This led to the third thought, which was to wonder if the _Daily Prophet_ and the _Quibbler_ have pop-up ads, and whether there are spells to block them. Which led to the fourth thought, which was to wonder if such publications ever tell their readers that they need to “upgrade” their wands in order to read them; “This scroll requires an Ollivander’s wand, but you don’t have one.”

Using a hybrid of Mike Hall’s hierarchical menus, I’ve come up with a rather nifty method to accessify them.

The problem was that each submenu was held in a layer of it’s own, with no visual clue to what the relationship was between each layer and it’s companions. This was a problem especially for non-coding web designers – it should not be necessary that a web designer have to learn JavaScript in order to create a funky menu. Also, any menu created should have it’s meaning, use, and relationships clear to even a non-JavaScript browser.

So, the method I’ve come up with is to create the menu using a tree of unordered lists, such as this:

• contactjuggling.org
  • moves
  • videos

I then add the below line at the head of the document, and add class="magicmenutop" or class="magicmenuleft" to the root <ul>:

<script type="text/javascript" src="magicmenu.js"></script>

That script searches for the <ul> containing the magicmenu (left|right) class, and does some cool stuff to it.

The menu traverses the tree, replacing each level of the tree with a layer, in the manner that Mike Hall’s script understands.

A difficulty arose when I wrote the traversal algorithm. I decided to use a depth-first recursive method, as it was simplest, but quickly realised something I had only been peripherally aware of – JavaScript’s variable scopes suck! Essentially, a variable created in a JavaScript is global, so a recursive instance of the same function will destroy any copies of itself.

That was, of course, very vexing.

The solution was to create an external array holding the variables. The index of the array was pretty handy – the index of the layer that the algorithm was writing to at the time.

Another difficulty arose when it was pointed out to me that the script fscked up in Opera and IE. I can’t test IE yet (don’t have it at home), but downloaded Opera and worked on that.

It turns out that Opera does not understand the document.styleSheets collection, and all efforts to dynamically create document-wide styles failed. (the styles I’m talking about are the all-important positioning directives – I don’t mess with colours – leave that to the designers)

I ended up having to write the styles directly into each layer and link as I wrote it.

Long story short – I’m happy with it, and think it will make a formidibale tool. Must contact Mike and mention it to him.

It really irks me when someone goes to the effort of creating a backwards-compatible whatever (menu, style thing, etc), yet bloats the HTML with javascript calls which will mean nothing to the non-javascript browsers.

For example, this month, ALA has an article on a JavaScript-based photo-gallery method, which is admittedly quite cool.

Now, at first glance, the idea is great – You simply create an unordered list of photo links, and dynamically load the image (overloading the ‘click’ method). Unfortunately, the method used introduces bloat that will slow down non-JavaScript browsers.

From the simple line <a href="images/bananas.jpg" title="A bunch of bananas on a table">some bananas</a>, we add code, creating <a onclick="return showPic(this)" href="images/bananas.jpg" title="A bunch of bananas on a table">some bananas</a>. Ideally, the use of JavaScript should introduce as minimal as possible a change to the page’s source.

How to solve it?

Simple – We know that the gallery images are all contained in a <ul>. So, in the external JavaScript which handles the gallery functions, we add an initialisation function which searches the document for <ul> elements that are given the class “gallery”. All links within that are then dynamically amended to include the event code onclick="return showPic(this)".

My philosophy with JavaScript is that it should affect the source code of the document as little as possible, leaving a very clean, easily readable source, free of clutter.

Like the new look? I’m using a method I developed a while back with collapsible lists to break the blog stories apart into tabs.

A simple example is here.

I won’t insult your intelligence by describing how to use it. It should be obvious from the source.

Nice engine in this thing. The backend is not as themeable as the front end, it seems, but I managed to copy my “other” site’s theme in a matter of minutes. Purty cool.

I’d still love to get my hands on the writer of that damned calendar, though

As mentioned by Donncha, I believe HTMLArea would be a useful tool for the backend.

Maybe I should stop chatting about revolution and just do it. I’m similar to the Judean People’s Front in that matter…

There comes a time when a man must scream and threaten bloody murder. One point of CSS is it’s ability to optimise the code needed to lever style into an element. This ideal is thrown out the window when the optimization looks like the following:

<tr class="b2calendarrow">
<td class="b2calendarcell">7</td>
<td class="b2calendarcell">8</td>
<td class="b2calendarcell">9</td>
<td class="b2calendarcell">10</td>
<td class="b2calendarcell">11</td>
<td class="b2calendarcell">12</td>
<td class="b2calendarcell">13</td>
</tr>

The above could be written a lot more efficiently by leaving out the b2calendarcell class, and instead addressing the cells as “.b2calendarrow td“. And don’t forget the indentation! In this case, it’s probably best to have all <td>s on one line. This would give the following:

<tr class="b2calendarrow">
 <td>7</td><td>8</td><td>9</td><td>10</td><td>11</td><td>12</td><td>13</td>
</tr>

Isn’t that much nicer?