I tend to create my own directory heirarchies when I set up new websites. 

I recently switched to the Fedora Core 12 desktop linux distribution for my development environment. When attempting to install formVista using the setup program I wrote, I kept running into weird permission denied errors. 

It turned out to be an SELinux policy violation. I had not set the required SELinux "type" on my custom "html" directory.

Instead of just disabling SELinux, I did some searching around and determined I needed to add the "httpd_sys_content_t" type to my directory.

chcon -Rt httpd_sys_content_t html

which basically says add the "http_sys_content_t" type to everything in the html directory.

There's a nice SELinux administration tool available for Fedora Core 12 which lists out all the various settings available and it was intrumental in helping me find the correct setting. It's called system-config-selinux and is part of the policycoreutils-gui package.

This is one of the liabilities of using a language long term that's in a high state of flux. As you continue to build larger and larger codebases, the work required to change that codebase as the language changes increases linearly.

The formVista codebase started in 2001 and has been growing ever since. During that time the PHP language has changed significantly. In many of these cases these changes address fundamental design flaws in the language such as the whole way objects were done in PHP 4. (A change which will in the near future force me to evaluate each and every object assignment in the entire codebase. ouch.)

So today I was looking at the PHP documentation for the split(). I'm endless forgetting if the string or the delimiter comes first. To my shock and horror split() is now deprecated.

Of course you can use explode() or preg_split(), but it's another case of having to crawl through a codebase and change things. IMHO, in this case it's completely needless and arbitrary. If the underlying code that implements the split() function needs to be changed, then a wrapper function should be included so that legacy code does not break.

Firebug absolutely rocks. When tracking down the effects of errant CSS cascades, html quirks, DHTML side effects, etc, nothing beats Firebug. 

However, today I ran into a little gotcha that consumed a few hours of my life. I wanted to align some drop downs and input fields nicely for the admin side of a new microblogging twitter/facebook/digg type component for formVista.

The backend of formVista has a bunch of legacy code. Parts of it were written close to 10 years ago. Slowly as we develop out the new moderinzed FVML tag set, we're going through and updated the very dated looking backend components.

I figured it was some style that was cascading down. Some margin, padding or alignment. Firebug showed nothing. I edited the styles inline. No joy. No matter what styles I applied the form fields displayed in the center of the form. I started to believe maybe I had run into a CSS bug in Firefox. 

Then I realized the culprit. In formVista, components are hosted on pages but are completely separate. As a result, I don't spent alot of time actually looking at the HTML pages themselves. I focus on the component FVML files where all the work happens. The hosting HTML pages are just wrappers.

Legacy wrappers.

The page in question, where my newly styled component was living, used an ancient table based layout.

<table width="100%">
<tr>
<td valign="top" align="center">
...etc...

And therein lies the problem. The align="center" was cascading down and overriding my styling. My guess is that firebug doesn't have a way to handle this case, or that I'm missing something in it's use.

Re-arrange the hosting page to use a CSS layout and problem solved.

What appears to be a compelling resource for javascript, jQuery, HTML, PHP and CSS info: http://net.tutsplus.com/

So I just spent some time tracking down a little bug which turned out to be my own stupid fault. 

formVista uses HTMLPurifier to sanitize HTML that's submitted by end users. HTMLPurifier rocks. 

However, Ryan over at Nuts and Bolts Interactive discovered <br /> tags submitted using the WYSIWYG html editor are changed to <br>. This is not correct for the XHTML 1.0 Transitional doctype that we're using on the front end.

After some digging, I realized that I had set the doctype correctly on the frontend but had set it to HTML 4.01 Transitional on the backend. (We still have a lot of work to do bringing the backend out of the stone-age).

Since HTMLPurifier was being loaded on the backend it was getting the backend's doctype and doing exactly what it was supposed to do.

So the takeway is, if HTMLPurifier is not doing what you expect it to be doing, make sure to check that you are in fact passing it the correct doctype.