At some point I hope to have a more automated installer included in the package. In the meantime you'll have to edit some files.

Installation

The simplest way to install the package currently is to unzip it into it's own directory within the webserver's document tree. After you've done this you may need to move some files around, and you will need to edit some files. If it's a public webserver, you should also restrict access to the PfP Studio.

1. unpack

   Decide where you want the PfP studio to reside and unpack it:

   
   colin@kermit:~$ cd public_html
   colin@kermit:~/public_html$ tar -xzf ~/form20041104.tgz
   

   This should create a directory 'form' containing the PfP Studio and support files

2. configure

   The key dependency is the pfp_env.inc.php file. This should be in one of the directories listed in your include path (not a subdirectory). If your include path has '.' in it, you can leave it where it is for the time being. The other .inc.php files should be accessible via the include path, but you can put these in a subdirectory - provided you update the 'require_once' statements in the first 3 lines of pfp_env.inc.php
   Within the form directory are the following directories:
   • css
   • jslib
   • images
   • pfp_saved
   The first three directories can be anywhere within the webserver's document tree. The last one is used for storing/retrieving the forms/widgets and can be anywhere PHP can read from (and write to if you want to save the files. The reason for not leaving the former three in the same directory should be obvious when you get to the next section.
   Next you need to tell PfP where to find these directories; edit the file pfp_env.inc.php to set the paths and prefixes for each directory. These are set in the constructor of the pfp_env object (from about line 137). For the css, jslib and images directory there is a path (where the file is in the filesystem) and a prefix (the URL without the preceding 'protocol://host' part). Saved PfP files are never accessed directly by HTTP therefore there is no prefix. You also need to specify a location for temporary files. Finally, you may need to tell setup the php_lint variable to refer to another program for PHP syntax checking (e.g. 'php -q -l' or 'C:\PHP\php-cgi.exe -q -l').

3. Secure it

   If your webserver is accessible from the network (most are) you should implement some sort of access control on the form directory (e.g. for apache see this article - but note that digest authentication is a much better idea and now widely supported).

4. Set up your browser

   PfP Studio is intended to be as portable as possible and require zero configuration of the client (by zero I mean nothing more than typing in the URL or clicking on a link to get there). However web-based code editing has a long way to come before it even remotely compares with a dedicated editor. For that reason, PfP uses a mime type application/x-pfo with a file extension .pfo to allow fragments of code to be sent to the client for editing (and back again).
   The file is ascii text. Currently is a single line of text (more may be added later) containing three fields, seperated by ':' characters. These are:
   • server name as per $_SERVER['servername']
   • filename and path
   • widget name
   It is up to the helper application you associate with this mimetype to retrieve the file (if appropriate), start up the editor with the local copy, then when finished (and if appropriate) copy the file back to the same location on the server.
   I've included a sample script (editwidget.sh) which runs on a Unix/Linux client which exects the PfP Studio to be running locally (doesn't copy files).

More documentation on installing and using PfP Studio will be available when someone (maybe you!) gets round to writing it. In the meantime, look at the sample files for some clues.