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.
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.
Decide where you want the PfP studio to reside and unpack it:
This should create a directory 'form' containing the PfP Studio and support files
colin@kermit:~$ cd public_html
colin@kermit:~/public_html$ tar -xzf ~/form20041104.tgz
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:
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').
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
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:
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 name as per $_SERVER['servername']
- filename and path
- widget name
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.