bits and peecees

It's been a bit here and there this last month. I don't seem to get many large "blocks" of time to get really stuck in. Priorities.

The xhtml upgrade continues slowly, and lots of corz.org back-end code has been tweaked and improved along the way. The comments facility is starting to look pretty damned cool, with only two major features to add, it may yet see the light of day in source form.

No mysql1, the comments themselves are lovely xhtml-in-a-file, like these blogs are, and the comment script itself has proved to be very robust, that "bloody voyager page" has something like two thousand, seven hundred comments on it, and up they come, like shit off a stick.

I have a funky idea for comment subscriptions, too. I'm not keen on adding rss to comments, imagine a thousand people subscribed to every comment page? That could drain some serious bandwidth. Instead, I thought I might use email, but with a twist..

When a user posts, their name is stored, and if they choose to subscribe, their email address is linked to that name. If someone else posts after that, and uses their name in the post, they get a notification email! This list of subscribers could also be used to disallow duplicate user names in comment threads. I might get time to code this over the week-end, though I've already said that about a dozen tasks, so, we'll see.

cbparser, that fun-luvvin bbcode parser for the masses had a minor upgrade the other day (v1.0.3b). I expanded the tag balance checking. Certain imbalances will be automatically corrected. Try a basic unfinished tag on any of the comment pages onsite for a wee demo. The test page is good.

l*rz

;o)

cbparser X

With pride and some jubilation, I am overly pleased to announce the release of cbparser 1.0, the all-new, 100% xhtml compliant, css styled bbcode parser for the masses.

cbparser still does bbcode to html and back to bbcode translation, but now the html has a nice X in front of it, that is, XHTML 1.0 Strict, to be precise, which it is.

Features..

Producing 100% strict xhtml compliant code was the motivation, but I didn't stop there. There's loads more tags, support for a wide range of email bbcode, improved anti-spam capabilities, XSS and CSRF attack prevention, InfiniTag™ support, and much much more.

What are InfiniTags™, you ask. Simply put, you can enter any and all regular html tags as bbcode, essentially replacing the akward <angle brackets> with handy [square brackets]. So although there are no actual table tags in cbparser, you could easily create tables using [table], [tr], [td], etc, or indeed any tag you like, like this strike tag, which doesn't actually exist (now deprecated in HTML5 -ed).

The parser comes with its own GUI (front-end) which you can see in operation in all the comment facilities and blog pages here at corz.org, or just click "edit blog" in the sidebar. You simply call the function from your page, and TADA! instant bbcode entry form, with javascript buttons and dials included. If that wasn't cool enough, cbparser will also automatically recognise and convert any legacy bbcode you might happen to edit, and all you php hackers out there can do your stuff most elegantly with the Cool Colored Code™ tag performing automatic coloured syntax highlighting! Very cute.

Feel free to check out cbparser's built-in demo page, right here. (yup, you get that, too, along with stylesheet, ul images, the neat cbguide -with javascript buttons, menus, smileys and even an undo facility! - as well as the lovely, totally portable javascript functions that drive the guide) and MUCH MORE! I had to add that

The updated bbtags page will keep you and your users on the right track, and I aim to keep it in sync with cbparsers new tags and features at all times, feel free to link to it from wherever you like; it's a permanent feature.

Okay, I've had enough of this blog, download and see for yourself!

for now..

;o)

phpsuexec

Yesterday night, my host switched over to phpsuexec.

For those that don't know, phpsuexec allows a hosting company to detatch php from the Apache server (usually php is installed as an Apache "module") and run it like a regular cgi inside the user's own account. This has many advantages for the host, chiefly, that they can track which user is eating up all the resources. As I've learned, it also has many advantages for the webmaster, too.

Firstly, of course, nothing works. Your pages will likely not load, and you will probably be greeted with a nice 500 error page instead of your beloved website. If you are still reading this, I'll assume phpsuexec is something that interests you, so here's what you need to know..

File permissions. Under phpsuexec, php scripts can no longer have their persmissions set to 777, or live in folders with those permissions, either. Folders should be set to 755, and php scripts to 644. If some script you downloaded says it needs to be set to 777 (world-writable), ignore it, and set it to 644. Your scripts are no longer run as user "nobody", but as YOU, so as long as the owner (you) can write to the file (the first 6) then all is well. Same story for log files, comment files, etc. Where they used to need to be 777, now they don't. With phpsuexec, 644 is just fine, even 600 if they are private things.

If you have shell access to your site, you can fix the whole lot in one go, like this..

for i in $( find . -name "*.php" ); do chmod 644 $i; done
for i in $( find . -type d ); do chmod 755 $i; done

and that's all your file and folder permissions fixed. But you still get 500 errors, right?

php directives. Becasue with phpsuexec, php has been disconnected from Apache, those php directives inside your .htaccess files are now completely meaningless to Apache. Hence the error. You need to remove all those php directives from your .htaccess files. Again, this is easy to do in one fell swoop..

for i in $( find . -name ".htaccess" ); do mv $i $i.old; sed 's/php_value/#php_value/g' $i.old > $i;rm -f $i.old; done

(all commmands are entered on a single line, even if it may appear split into two in your web browser) Now all php directives will be commented out in every .htaccess file, and you can at least see your page. (if you have "php_flag" directives, use a similar command for those, too). Still not working?

AddType directives. If you parse non *.php files as php, for instance generated CSS (like corz.org) then statements like this..

AddType application/x-httpd-php .css .style

will now fail dramatically. The solution is simple, use SetHandler instead, like this..

# for suexec..
<FilesMatch ".(css|style)$">
  SetHandler application/x-httpd-php
</FilesMatch>

And now all *.css and *.style files covered by that particular .htaccess will be parsed by the php machine. Excellent!

Options -ExecCGI will also prevent your php script from running, of course. While we're at it, here's some other stuff you need to know..

• The user executing the wrapper must be a valid user on this system.
• The command that the request wishes to execute must not contain a /.
• The command being executed must reside under your web document root.
• The current working directory must be a directory.
• The current working directory must not be writable by group or other.
• The command being executed cannot be a symbolic link.
• The command being executed cannot be writable by group or other.
• The command being executed cannot be a setuid or setgid program.
• The target UID and GID must be a valid user and group on the system.
• The target UID and GID to execute as, must match the UID and GID of the directory the script is located within.
• The target execution UID and GID must not be the privledged ID 0 (root)
• Group access list is set to NOGROUP and the command is executed.

Only a couple of these things will likely have any impact on your site. Other things of note:

• PHP-based HTTP Authentication no longer works (good, it was crap)
• The $PATH_INFO variable within PHP does not function (good, it's a security hole)
• The PHP function getallheaders() does not work. (damn! gonna have to rewrite PDA!)

what about my php directives!?

Okay, so far so good. But what about all those php directives you deleted? How are you supposed to enable zlib compression? or change the upload size and what-not? Worry not! This is where the fun begins.

Rather than mix php directives in with apache directives, you can now create local php.ini files. In much the same way that it's smart to split code structures and content, content and style in your web pages, this enables you alter your php environment in almost any way. The more I think about this, the more I think it's a great idea.

You don't have to recreate a complete php.ini for your site, you simply specify the values you wish to override, just like you do with Apache directives in .htaccess files. Perhaps something like this..

; php directives
[php]
register_globals = Off
zlib.output_compression = 16386
zlib.output_compression_level = 7
zlib.output_handler = zlib.output_compression
default_charset = utf-8
display_errors = off
log_errors = on
error_log = /www/cor/public_html/err/php_error.log
upload_max_filesize = 10M
post_max_size = 10M

[session]
session.use_trans_sid = 0
session.save_path = /www/cor/tmp/sessions

note: you MUST use proper [sections], just like the master php.ini file. You can override any php directive in this manner, though sensible web hosts will have disabled the dangerous ones. Currently, at least on my host, the php.ini values don't cascade down through the tree, though I'm assured they are looking for a fix. placing php.in files in EVERY directory seems a daunting task, indeed, we'll see.

Now everything's setup, your site should function exactly as before. Better, in fact..

The first thing I noticed is that because my session files now live inside my user space, as opposed to the system /tmp folder, they are exempt from the server's garbage collection process. Think about it.

This has been a continual nuisance for years, at every web hosts I've been with. Now, if I specify that a session should last twenty four hours, it does exactly that! As opposed to fifteen minutes or thereabouts, as before. This alone has made the switch to phpsuexec worthwhile.

It's tempting to think that this whole phpsuexec business is some Gestapo effort by your host to clamp down on "bad" users, it's not. It's simply a means to managing better, more robust web servers. If I have some script that is out of control and eating server resources, I WANT TO KNOW ABOUT IT! With php running as an Apache module, there is simply no way to do this.

More importantly, if some other website on my shared server has a script that is out of control, I WANT IT FIXED! There's no reason why a hundred web sites should have to suffer for one user's wonky code. In our case, it turns out that one of the hosts' server tools was eating up most of the extra resources, and this change has enabled them to locate and crucially, FIX the source of the trouble. There were a couple of users with dodgy scripts too, by the way. phpsuexec gives us all control.

There are other advantages, too. Mail now comes from my user account as opposed to "nobody@..", which is nice, and this fine-grained control over php directives that couldn't previously be manipulated has opened up a whole lot of possibilities. And of course, other users on my shared server can no longer read my raw files. Not a small consideration.

It's all good. Sure, it takes a wee bit of effort to get your site working again (and if only you'd used proper <ifModule> conditions, nothing would have broken, but then, who does? they don't work on Windows servers anyway, afaik, not that mine is) but it's effort well spent.

for now..

;o)