Tag: php

New Cgiapp Site

I've been extremely busy at work, and will continue to be through the end of March. I realized this past week that I'd set a goal of having a SourceForge website up and running for Cgiapp by the end of January -- and it's now mid-February. Originally, I was going to backport some of my libraries from PHP5 to PHP4 so I could do so... and I think that was beginning to daunt me a little.

Fortunately, I ran across a quick-and-dirty content management solution yesterday called Gunther. It does templating in Smarty, and uses a wiki-esque syntax for markup -- though page editing is limited to admin users only (something I was looking for). I decided to try it out, and within an hour or so had a working site ready to upload.

Cgiapp's new site can be found at cgiapp.sourceforge.net.

UPDATE

Shortly after I wrote this original post, I figured out what the strength of Gunther was -- and why I no longer needed it. Gunther was basically taking content entered from a form and then inserting that content (after some processing for wiki-like syntax) into a Smarty template. Which meant that I could do the same thing with Cgiapp and Text_Wiki. Within an hour, I wrote an application module in Cgiapp that did just that, and am proud to say that the Cgiapp website is 100% Cgiapp.

Continue reading...

Cgiapp 1.5.3 released

1.5.3 fixes an issue introduced by 1.5.2 that creates a performance hit whenever the run mode is being determined by function name or CGI parameter. More details on the Cgiapp download page.

Continue reading...

Cgiapp 1.5.2 released

At work, we've been developing a new platform for our website, based entirely on Cgiapp. This week we released the first stage of it: garden.org and assoc.garden.org. These should stand as good testament to Cgiapp's robustness!

With all that development, and also with some communication from other Cgiapp users, I've made some changes to Cgiapp, and release version 1.5.2 this evening.

1.5.2 is mainly security and bugfixes. Error handling was somewhat broken in 1.5.1 -- it wouldn't restore the original error handler gracefully. This is now corrected. Additionally, I've made run() use the array returned by query() -- consisting of the $_GET and $_POST arrays -- in determining the run mode. Finally, I've modified the behaviour of how run() determines the current run mode: if the mode parameter is a method or function name, it cannot be a Cgiapp method or a PHP internal function. This allows more flexibility on the part of the programmer in determining the mode param -- words like 'run' and 'do' can now be used without causing massive problems (using 'run' would cause a race condition in the past).

As usual, Cgiapp is avaiable in the downloads area. Grab your tarball today!

Continue reading...

Smarty $_SERVER vars

I don't know why I never bothered to look this up, but I didn't. One thing I typically do in my parent Cgiapp classes is to pass $_SERVER['SCRIPT_NAME'] to the template. I just found out -- through the pear-general newsgroup -- that this is unnecessary: use $smarty.server.KEY_NAME to access any $_SERVER vars your template might need.

Continue reading...

Cgiapp mentioned in php|architect!

A new Cgiapp user reported they had stumbled across the project in php|architect! It's in the current, October 2004 issue, in the News section, prominently displayed in the upper right corner of the page. The announcement blurb is straight from my freshmeat project page for version 1.4. Cgiapp is carving a name for itself!

Continue reading...

Cgiapp 1.5.1 released

At work this week, I discovered a bug with how I was calling set_error_handler() in Cgiapp's run() method. Evidently passing a reference in a PHP callback causes issues! So, I corrected that.

I also made a minor, one-character change to query() to make it explicitly return a reference to the $_CGIAPP_REQUEST property array.

You can see full details at the Cgiapp download page.

Continue reading...

Cgiapp 1.5 released

Cgiapp 1.5 has been released; you may now download it.

This release fixes a subtle bug I hadn't encountered before; namely, when a method name or function name is passed as an argument to mode_param(), run() was receiving the requested run mode... and then attempting to process that as the mode param. The behaviour is now fixed, and is actually simpler than the previous (non-working) behaviour.

Also, on reading Chris Shiflet's paper on PHP security, I decided to reinstate the query() method. I had been using $_REQUEST to check for a run mode parameter; because this combines the GET, POST, and COOKIE arrays, it's considered a bit of a security risk. query() now creates a combined array of GET and POST variable (POST taking precedence over GET) and stores them in the property $_CGIAPP_REQUEST; it returns a reference to that property. run() uses that property to determine the run mode now.

Enjoy!

Continue reading...

When array_key_exists just doesn't work

I've been playing with parameter testing in my various Cgiapp classes, and one test that seemed pretty slick was the following:

    if (!array_key_exists('some_string', $_REQUEST)) {
        // some error
    }

Seems pretty straight-forward: $_REQUEST is an associative array, and I want to test for the existence of a key in it. Sure, I could use isset(), but it seemed... ugly, and verbose, and a waste of keystrokes, particularly when I'm using the param() method:

    if (!isset($_REQUEST[$this->param('some_param')])) {
        // some error
    }

However, I ran into a pitfall: when it comes to array_key_exists(), $_REQUEST isn't exactly an array. I think what's going on is that $_REQUEST is actually a superset of several other arrays -- $_POST, $_GET, and $_COOKIE -- and isset() has some logic to descend amongst the various keys, while array_key_exists() can only work on a single level.

Whatever the explanation, I ended up reverting a bunch of code. :-(

Continue reading...

PHP_SELF versus SCRIPT_NAME

I've standardized my PHP programming to use the environment variable SCRIPT_NAME when I want my script to refer to itself in links and form actions. I've known that PHP_SELF has the same information, but I was more familiar with the name 'SCRIPT_NAME' from using it in perl, and liked the feel of it more as it seems to describe the resource better ('PHP_SELF' could stand for the path to the PHP executable if I were to go by the name only).

However, I just noticed a post on the php.general newsgroup where somebody asked what the difference was between them. Semantically, there isn't any; they should contain the same information. However, historically and technically speaking, there is. SCRIPT_NAME is defined in the CGI 1.1 specification, and is thus a standard. However, not all web servers actually implement it, and thus it isn't necessarily portable. PHP_SELF, on the other hand, is implemented directly by PHP, and as long as you're programming in PHP, will always be present.

Guess I have some grep and sed in my future as I change a bunch of scripts...

Continue reading...

PHP: Continue processing after script aborts

Occasionally, I've needed to process a lot of information from a script, but I don't want to worry about PHP timing out or the user aborting the script (by clicking on another link or closing the window). Initially, I investigated register_shutdown_function() for this; it will fire off a process once the page finishes loading. Unfortunately, the process is still a part of the current connection, so it can be aborted in the same way as any other script (i.e., by hitting stop, closing the browser, going to a new link, etc.).

However, there's another setting initialized via a function that can override this behaviour -- i.e., let the script continue running after the abort. This is ignore_user_abort(). By setting this to true, your script will continue running after the fact.

This sort of thing would be especially good for bulk uploads where the upload needs to be processed -- say, for instance, a group of images or email addresses.

Continue reading...

<< First | < Previous | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | Next > | Last >>