It's sort of pitiful, actually.

So, between drowning in mucous and going to work... not much has been happening. I set up another one of my domains so that I can begin work on my content management system - right now I haven't had time to just sit down and hack, so it's taking shape slowly.

One thing I have done, though? I've determined that the PHP4 documentation sucks; in particular, session management.

I can hear it now - "if you don't like it, volunteer to do some of the documentation yourself." Yeah, I would, except I could spend all my time writing the PHP4 documentation or I could do things that I like to do. (I hate doing documentation at work - why would I do it at home?)

Or maybe you'll say, "it's free, it's one of the 'hidden costs' of using free software." Well, maybe, but ever seen Microsoft's documentation for products? In a lot of cases, it's far worse. If the PHP team is really serious about moving people over to it from the alternatives, we have to not only beef up the language in capabilities, which they have done in spades (and it's marvelous - I love PHP), but they also have to document it properly.

What's this mystical problem I had?

Well, recently PHP moved to turn off register_globals and give us a large number of superglobal arrays to hold the information passed via various methods in a secure manner. I applaud them for doing a lot to clean up security. Unfortunately, my webhost turned globals back on so none of their customers would have their code suddenly broken, which is also understandable.

Being one to embrace this new standard, I went to my .htaccess file and added the following lines:

<IfModule mod_php4.c>
    php_flag register_globals off
</IfModule>

And voila! My globals are turned off. (Let's hear it for Apache!)

Then I begin to wonder how I will authenticate users against the site, so I turn to investigate session management in more detail. Of course, session_register() won't work. At all. Sure, it'll put a value in the session, but the value never changes. If I use $_SESSION['some_variable'], it works fine, but when I rewrite the script using all session_register() instead, I get screwed to the wall.

I spent the next hour plus searching Google and php.net for answers, and discovered that worse than being an undocumented issue, it's poorly documented. It says:

If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), session_is_registered() and session_unregister().

That doesn't tell me that session_register() doesn't work, just not to mix-and-match my references.

Waaaay down in the user-contributed notes, some guy who is one of my heros now posted:

In PHP 4.0.6 when the register_globals configuration option is turned off you must use the $HTTP_SESSION_VARS array to get and set session variables. session_register will not work!

I imagine he went through something similar to what I did to figure this out.

To test, I turned global variables back on, and sure enough, session_register() works as advertised. Chalk it up to crappy documentation.

I have to give it to the PHP group for having (largely) great code, though. Also, I have to also mention that it's great that they have the manual where users can contribute issues and commentary, and the people attaching notes to the documentation are really great and helpful in their comments.

I think part of what is getting to me is that I spend too much time building things actually experimenting rather than outputting developed lines of code. Sure, I learned a bit, and I understand more issues than I did before, but that was time I wanted to be building some authentication code against a skeletal user database.

Well, I guess experience is what you get when you don't get what you want.

restlessmind