Late Night PC

The Views module in Drupal is both useful and confusing. The basic idea is that Views will allow you to provide a styled list of some content. This content can be pages, stories, blog posts, comments, users, RSS feeds items, nodes and even some other kinds of data. You can think of it kind of like those generic examples of PHP and MySQL that pull out a bunch of records from a table and just give you a list. Except that it doesn't rely on just MySQL. And it doesn't just give you a list. And it does validation. And you don't really have to write any code.

The Views interface in Drupal 6 (under Administer >> Site Building >> Views) is pretty complicated. I don't understand all of it yet, so I decided to work through an example of something that I needed here on Late Night PC. There's a view included called "archive" which shows up at example.com/archive/yyyymm. This is pretty close to the way I was doing my archives under Wordpress. My archives page URLs had the form latenightpc.com/blog/archives/yyyy/mm. So I basically wanted the archive view with these changes:

1. Move the URL from archive to blog/archives
2. Change the parameter from yyyymm to yyyy/mm
3. Filter the view to show only blog posts instead of all content

I have a website that I use for stuff but not stuff on the public web. I use it for serving my calendars and private web applications. I use Apache's built in authentication to keep it from being crawled and to keep casual visitors from wandering in. I have a domain name assigned to it from dyndns.org for convenience. The ddclient script runs on one of my boxes and updates the ip address over there whenever mine changes. The system works very well. Most of the time. Somehow one weekend the domain name was left pointing at my old ip address for a while when I was out of town. Who ever had that IP address sure was serving up a lot of nasty stuff. Now Google thinks all that nasty stuff is on my private domain.

I'm going to fix it. I use Google Webmaster Tools for other stuff and I see there's a URL removal tool in there. To use the tool you have to verify that you own the domain - a reasonable request. The thing is the URLs I want to remove are on a domain that I don't want Google to crawl and the way Google verifies that you own the domain is by retrieving a specific URL from the domain. What a dilemma.

CakePHP uses the Prototype Javascript library for its ajax helper class but I've come to prefer jQuery. Prototype is a fine library too but I've just gotten used to jQuery.

A web application I'm working on needed a ttw html editor so I grabbed TinyMCE and copied in some of the example code and everything seemed to work fine at first glance. Unfortunately TinyMCE has an issue with jQuery's $(document).ready function and it also has an issue with saving via ajax in CakePHP.

There's a helpful page on the Bakery that outlines some issues you'll run into trying to get CakePHP & Prototype working with TinyMCE but it's a little out of date now (I'm using CakePHP 1.2RC1, TinyMCE 3.09 and jQuery 1.2.6 at the moment). I'll go through examples that illustrate how I solved the two problems I ran in to but I'm not going to explain everything you need to do ajax submissions with CakePHP.

CakePHP is a really nice MVC framework I've been using for a project I'm working on. I've been using one of the 1.2 betas for what seems like forever but I just now saw they've got a Release Candidate out as of a couple days ago. The MVC pattern fits a whole lot of applications or acts as glue for a lot of web apps where the main goals don't fit MVC. I find that CakePHP is fantastic for getting a lot of the monotonous code out of your way so you can focus your efforts on the important stuff. Here's the release note. You can download it from the main page at CakePHP.org. This framework has a few warts and like any young software, it will see API changes that break code. Don't expect it to solve every problem for you but it will give you a huge boost to start-up speed on building new applications. In the long run you have to remember it's a tool for you to build an application, not an application in and of itself. It's time for me to dive in now and start my upgrade, I hear some of the conditions on my find() calls will have to be fixed...

The SVG Open is shaping up fast. The call for papers has been out there for a while now but if you're quick you can still present a paper or run a workshop but the deadline to submit for papers and courses is April 18 and that'll be here before you know it. The SVG Open is the conference for people doing SVG. The SVG Open has been running since at least 2002 and seems to get a little broader appeal every year it runs. Look at the broad areas to cover: client-side Javascript toolkits, map overlays like Google's, widgets in Opera, cell phones and other embedded applications, UI elements in Gnome and KDE, desktop tools like Inkscape. Those are just off the top of my head, that kind of a list just didn't exist 5 years ago - not for mainstream applications like these. SVG is growing in adoption and I don't see that slowing down anytime soon. I've been out of the scene for a while but things have really come a long way all of a sudden. There's some great support across the latest browsers - compare that half-green Firefox 3 to the qualified "about half of the tests passed that test features supported by Firefox" from a few years ago. There are solid, supported tools that make SVG creation accessible to anyone. Inkscape may only consider their release 0.46 less than a 1.0 but it's a real practical tool that's adding features in leaps and bounds. Want some graphics to work with? The Open Clip Art Library has piles of subjects covered. There are more and more compelling reasons to choose SVG every day. If you're someone who's been applying SVG already then share what you know and go present it at the Open.

On Pavlov.net talking about some improvements in memory handling on Firefox 3:

It isn’t reasonable to expect all those authors to write code to manually break the cycles themselves.

This reminded me immediately of an MSDN article that took a decidedly different stance on pretty much the same problem in Internet Explorer:

The good news is that memory leak patterns can be easily spotted if you know what to look for.

The fact that the MSDN article is from 2005 really drives home just how stunned I was when I first read it. The page goes on to describe how web developers should analyze their Javascript and write their code to work around bugs in garbage collection. I understand the idea that sometimes users have to work around bugs in a program but that's definitely not the message I got looking at the MSDN article. It read a lot more to me like "we sent out IE 6 SP2 about a year ago and we have no intentions on fixing this any time soon." Then look at the audiences that these two very different standpoints are aimed at. The Mozilla post is about extension developers, a relatively small and advanced group compared to the number of web developers - the ones most likely to understand the issue if anyone does. The MSDN post talks to "every web developer" and says to "Use defensive coding practices and assume that you'll need to clean up all your own memory." While this may be practical advice for advanced coders, in this context it says to me that there's no intention from Microsoft to really fix this problem. Kudos to Mozilla for working to improve efficiency and close leaks instead of blaming web developers.

Here's a quick tip for PHP error reporting and display in development.

When a project is in the early stages of development you want to see all the error information you can. You probably want E_STRICT on especially when you're starting from scratch, to help avoid relying on deprecated behaviour. The E_STRICT flag is only available as of PHP 5 and is not included in E_ALL until PHP 5.2 (there's a little disagreement on php.net between the definition of E_ALL in this table and the earlier note about error_reporting on the same page).

In an early development project you also don't want to have to keep tailing log files to see the error messages. That's a pretty sure way to miss errors. So you want to set the display_errors flag on. You also want to control this on a per-project basis, since some projects will have legacy bugs that you're not fixing right now and those can be left spouting errors to logs until someday in the future when you decide to fix them.

At the risk of turning this into an Apache fan blog, I have to mention the handy directive I found today. Many webmasters run in to mod_rewrite at one time or another and every one of them will have at least a little trouble with it. I just came across the RewriteLog Directive and corresponding RewriteLogLevel Directive. You're not going to be able to turn these on with shared hosting, they can't be used in .htaccess. To set up a debugging log for mod_rewrite, you need to add them to your httpd.conf somewhere. In my case I'm working on a server at home so I added

Motivation

Now that I've got an LDAP server up and running I'm trying to get my personal web server set up so it has a blanket authentication for my personal applications, static content and development stuff. The web applications I'm talking about aren't meant to be exposed to the public at large, they're not what you find here on Late Night PC Service or any of my other sites. These are things like PHP Calendar, Task Freak, SugarCRM, a bunch of development versions of apps I'm working on and some static content that might be a single html file or an image. I currently have a server that's accessible through DynDNS and I use basic HTTP authentication on it. The server runs Apache HTTPD 2.2 and has whatever modules I want on it. My next server is roughly the same but I want to make things a little more secure and a little simpler (at the same time no less). So my idea was to move to LDAP as the Authentication Provider and Digest as the Authentication Type.

• Rob's blog
• 5 comments
• Read more
• Buy Rob a coffee

I can think of three things I really want from my email: it should be easy to use, fast, and private. SquirrelMail gets me pretty close to those goals. It just got better today with the release of version 1.4.10. Somewhere between the last version I last installed and this one they've added support for multiple identities - that is to say that you can have more than one return address. If you want to set it up on a site you host at 1and1, there's an FAQ at 1and1 on how to do exactly that. Unfortunately they haven't updated it since they changed their outgoing (SMTP) mailservers to require authentication. I got the hint because it's mentioned for other email clients. Since SquirrelMail is really just an IMAP email client written in PHP, the same rules apply. What worked for me was this change in SquirrelMail's config/config.php: $smtp_auth_mech = 'login'; The default was none. So overall all you need to change in the default config file to make SquirrelMail work with mail at 1and1 are the $domain, $smtpServerAddress (smtp.1and1.com) and $imapServerAddress (imap.1and1.com). The other interesting thing is that since SquirrelMail is just an email client, you don't have to run it on your 1and1 web server to get your 1and1 mail. If you have a home server or one hosted somewhere else, you could use the same configuration file and SquirrelMail will go get your mail just like any other client would. Depending on how you use your mail you might find this a little more convenient and possibly faster than using your web server.