All Scripts backed by 10 years in business, free support, free updates and a 30 day money back guarantee.
Download Purchase Programming F.A.Q. Support Contact
Commercial Perl Scripts
All Form Pro Updated
Count It
Form Mailer + Attachments
Client File Manager
Da Godfaddah
Dropbox Updated
FAQ Builder
HT Manager Updated
Mailing List Server
Page Updater - Text
Page Updater Pro Updated
PS Guestbook Updated
PS Lightning Search Updated
Quick File Mailer
Quick MySQL
Upload Center
Free Perl Scripts
Access Log Viewer
All Form
Epoch Converter
Error Log Viewer
Invoice Center
PS Upload
Question Manager
Site File Finder
Site File Lister
SSI Tag Maker
Perl Modules
Monger Calendar
Monger File
Monger Mail
Monger Persist
JavaScript Generators
PopUp Windows
Meta Gen
RGB / Hex Converter
Page Colors
Tutorials and FAQs
Using CuteFTP
Using WS_FTP
Installing Scripts
Free Services
Epoch Converter
TLD Registries
RGB/Hex FInder
Colour Checker
Terms and Conditions
Privacy Policy
Refund Policy
Site Map

Form Processor with no SPAM from robots.

Anti-spam, anti-robot, anti-flame, Guestbook for your website.

Manage Remote websites from your website. Allow clients to update sections of their own web pages.

Secure file manager with upload progress meter. A printer's best friend. Find out more.

Page Updater Pro (WYSIWYG) 2.2

Supported Servers : Unix, Linux, FreeBSD, Sun, BSDOS, Mac
Price : USD $99.00
Requires : Perl / cgi-bin (LWP Module on Remote Servers for Remote SSI)
Version : 2.2
Original Release Date : March 2005
Latest Release Date : June 2009
F.A.Q : Click here for F.A.Q.
Users Guide : Admin Guide Client Guide
Online Demo : Admin Demo

Quality Perl Script Guarantee This Perl Script has been quality guarantee stamped by our customers. If this script does not perform for you on your server as advertised, we'll issue you with a full refund plus a 10% credit voucher.

  1. Beginning
    1. Disclaimer
    2. Introduction
    3. Requirements
    4. Configuration
    5. Installation

  2. Owner/Administrator Functions
    1. Admin Login
    2. Admin Logout
    3. Working with content files
      1. Listing available content profiles
      2. Adding content file profiles
      3. Editing content file profiles
      4. Updating the content of a content file
      5. Emptying a content file
      6. Deleting a content file
      7. Specifying where a content file is used
      8. Setting permitted display documents
      9. Setting permitted display servers
      10. Creating Local CGI SSI Application executable file
      11. Creating CGI SSI Application for remote content file
      12. Generating SSI Tag Syntax for local SSI scripts

    4. Working with user profiles
      1. Listing current user profiles
      2. Adding a new user
      3. Editing a user profile
      4. Changing a users login information
      5. Setting which content file they are
        permitted to update
      6. Deleting the user profile

  3. Displaying Content On Your Server
    1. Using a .php page
    2. Using a .shtml page
    3. What is SSI?
    4. How to create an SSI script for the program
    5. How to create an SSI tag on a web page
    6. Loading and CHMODing an SSI script.
    7. Viewing the content

  4. Displaying Content On A Remote Server
    1. Differences between a local and remote SSI
    2. Requirements for a remote SSI script
    3. How to configure a remote SSI script for
      the program
    4. Using a remote SSI script
    5. Security considerations for a remote SSI
    6. Viewing the content remotely

  5. Setting Up Multiple Updateable Zones On A Single Page
    1. What is a zone
    2. Creating SSI scripts for each zone
    3. Creating the SSI tags for each zone
    4. Updating content for multiple zones
    5. Viewing content from multiple zones

  6. Client Users Guide

  7. Security

  8. Support

Using a .php page

You can have the content called from a remote server and displayed on any local server within a PHP file using the following PHP statement.

<?php virtual("/cgi-bin/whateveryoulike.cgi"); ?>

The steps involved in displaying content on a remote server are as follows :

  1. Log into PUP and Create Content File

  2. While logged into PUP, from : List Content Files click Remote SSI to generate the script you need to upload to remote server.

  3. Save the generated file in Notepad or any plain text editor, you may name it whateveryoulike.cgi

  4. Upload whateveryoulike.cgi in ACII mode to the remote server in any cgi executable folder such as your cgi-bin, and CHMOD it to 755

  5. Use this tag in the PHP files that you want to display the PUP content:

    <?php virtual("/cgi-bin/whateveryoulike.cgi"); ?>

To Top

Using a .shtml page

A .shtml page is simply, an HTML document. It is identical to .html and .htm documents. You create it with a normal text editor or WYSIWYG program like any other HTML document.

The difference with .shtml documents is that when the server receives a request for it, instead of automatically delivering it back to the browser, the server first has to parse the document (go through it line by line) looking for SSI (Server Side Includes). Some servers are set so that all HTML documents can handle SSI's but most servers reserve SSI's for .shtml documents.

All pages ending with .shtml are uploaded to the server with FTP just like any other HTML document. You do not have to CHMOD a .shtml document.

To Top

What is SSI?

SSI is an accronym that stands for Server Side Include. First developed by Apache, SSI is now also implemented (with differing rules) on Windows IIS servers. In short, SSI tags are coded in to regular HTML documents. When a request is made to your server for a HTML document, the server replaces the SSI tags with the content found in the file that the SSI tag points to.

In more detail, servers can be configured to parse documents. By default, most servers only parse .shtm and .shtml documents. However they can also be configured to parse regular .htm and .html documents. See the PUPW FAQ for information on How to Configure Linux servers to parse .htm and .html files. Parsing means a document is acted upon before being served as opposed to just being served as is. Apache will determine the structure of a document to be parsed and execute any commands found within it before serving it to the requester (you).

SSI tags look a lot like regular HTML tags. SSI tags are coded in to your HTML Documents, just like any other HTML tag. Two examples follow. The first asks Apache to execute a CGI script, the second asks Apache to simply fetch the contents of a file.

<!--#exec cgi="/path/to/" -->

<!--#include virtual="/path/to/main_menu.txt" -->

As far as Apache is concerned, what the above SSI tags are saying is

<!--replace me with the output produced by /path/to/ -->

<!--replace me with the content found in /path/to/main_menu.txt -->

The files you point to in the SSI tags can be any type of files. They can even be Regular HTML files with HTML code. If not for SSI, most website would still be using Frames. Because when one needs to update a link on a website that has 2,000 pages, SSI lets them update all 2,000 pages by editing just the one file. If all 2,000 pages have an SSI tag that point to main_menu.txt, when main_menu.txt is updated, the changes are instantly reflected on all 2,000 pages.

To Top

How to create an SSI script for the program

Please see the section on "Creating Local CGI SSI Application executable file" or the section on "Creating CGI SSI Application for remote content file"

To Top

How to create an SSI tag on a web page

The standardized format for an SSI tag on an Apache server is:

<!--#exec cgi="/cgi-bin/path/to/schedule.cgi"-->

There are a few things to note about this tag:
  1. Except for the path to the script, copy this tag EXACTLY as you see it here.
  2. The path to the script is relative from your cgi-bin (might be called just "cgi" or "cgi-local") OR if you are running the SSI outside the cgi-bin, it is relative from your main web document directory.

    NOTE: You do NOT put a full URL in the SSI tag. You do NOT use the servers absolute path to the script.
  3. Most servers require that SSI scripts have a .cgi extension. However, some servers will permit a .pl extension. Even fewer still are servers that will only permit files with a .pl extension to run as SSI's. If your server is configured for .pl scripts to be mandatory for SSI's, then you can simply rename your SSI script with a .pl extension. Therefore, "schedule.cgi" would become "".
Now, go to your .shtml document and put the tag in the above format into it. Having done that, FTP your .shtml document onto your server. Voila. Faite accomplis.

Please note that this program takes the headache out of creating the SSI tags. Now you simply generate the SSI file according to whether it is a Local Content File or a Remote Content File. Once that SSI CGI script is loaded and CHMODed, you just enter the full URL to the script in your browser address bar and add "?showtag" to the end of it. The SSI script will print out to your browser the the correct SSI tag syntax for itself.

To Top

Loading and CHMODing an SSI script

An SSI is a Perl script. Therefore you must load and CHMOD it exactly the same way. FTP it to the server in ASCII mode and then CHMOD 755.

To Top

Viewing the content.

To view the content of the file, call the .shtml document containing the SSI tag in your web browser by entering the full URL to it. Note that you must call the document that resides on the server and NOT the document that resides on your hard drive.

When the browser prints out the page, where you had placed the SSI tag in the document is where you will see the content displayed that you added through the pupw_admin.cgi program.

What? No content?

Invariably, if this is the first time you've used an SSI you will find you have to play around with them a bit to get comfortable with them and make them work properly. If the content doesn't display the first time you call the .shtml document, here is a checklist of things to go over:
Did you get the admin program up and running? If not, go back and do that first.

Did you actually add any content for this content file through the admin program? Maybe log into admin and have a look just to make sure.

Did you transfer the SSI script in ASCII mode?

Did you CHMOD the SSI script to 755?

Is the path to Perl correct at the top of the SSI script?

Did you type the SSI tag exactly as in the demo? Maybe check your virtual hosts support/FAQ pages to see if they require a different syntax for the SSI call.

This is a weird one, did you FTP the file onto the right server? I've got a couple hundred FTP addresses in my FTP client and I have to admit I've done that a couple times.

Is the relative path correct?

If you web page displays instead of the expected content, this:

[An error occurred processing this directive] indicates one of these three errors (usually):
  1. You transferred the SSI script to the server in Binary mode instead of ASCII mode.
  2. You did not CHMOD the SSI script or you did not CHMOD it correctly. It must be 755.
  3. You do not have the correct path in the SSI tag (most likely cause).
If you do not get the above error message and the content does still not display and you have gone through the checklist above, look at the source code of the page being displayed in your browser. If you look at the source code and can still see the SSI tag, then your server is not configured to support SSI'. In this case, contact us with the URL to the page. Once we confirm your server won't support the program, we will issue you a full refund.

To Top

Differences between a local and remote SSI

There is no difference, basically, between a local SSI and a remote SSI. They are the same thing. The difference is in how our program handles them. In the case of a remote SSI script for our program, instead of drawing the content from the remote server, the SSI on the remote server "talks" to your main program via the HTTP protocol. The remote SSI and the main program pass information back and forth. This is what permits your remote page to display the content.

To Top

Requirements for a remote SSI script

For your remote server to make use of the remote SSI script, it must be a UNIX server running Perl 5 or higher and it must have the LWP::Simple Perl module installed on it. If you don't know if this module is installed, go to our utilities area and download the "" utility. Place it on your remote server, CHMOD 755 and run it. It will, at the bottom of the page, list all the Perl modules installed on your server.

To Top

How to configure a remote SSI script for the program

Please read the section on "Creating CGI SSI Application for remote content file". This program takes all the fuss out of creating the remote SSI CGI script and you don't have to manually set any variables. The program will do it all for you.

To Top

Using a remote SSI script

The SSI that is running on your remote server works EXACTLY the same as the one on your local server. All of the rules and considerations for loading the script. Additionally, all the rules and instructions for creating an SSI tag and using it in a .shtml document are exactly the same as for the local server. Please refer to the directions above for these two items.

To Top

Security considerations for a remote SSI script

Since we are very concerned about server security and security within our programs, there is one final consideration for SSI scripts on remote servers.

For a content file to be displayed on a remote server, WE STRONGLY RECOMMEND that you set a valid server name in the content file profile. If you don't then you open up the content to a Content Jacker.

To Top

Viewing the content remotely

Viewing the content remotely is exactly the same as viewing it in a local page. Also, the same checklist applies if it doesn't work with one addition:

Is the URL to the main admin program complete and correct?

To Top

What is a zone

For many users, there is a whole bunch of new terms flying around. To avoid confusion and help clarify things, we refer to the updateable portion of a page that is being updated by the program, we call that area a "Zone".

If there is only one SSI tag on a page, that page has ONE updateable zone. If a .shtml page has three areas that are updated by three separate SSI scripts pulling in information from three different content profiles, that page has THREE "Zones".

A zone is simply the area of a page that is updated via an SSI script.

To Top

Creating SSI scripts for each zone

Reading the preceding section, you can see there is no trick to creating an SSI script for each zone. Simply follow the directions for creating an SSI script and an SSI tag for each updateable zone on your web page. The only thing that is different is that the web page will now have three SSI tags (all pointing to different SSI scripts) in the .shtml document.

To Top

Creating the SSI tag for each zone
Creating the SSI tag for each zone is exactly the same as described above. All you have to remember is that each SSI tag must point to a different SSI script.

To Top

Updating content for multiple zones

Updating the content is exactly the same us updating the content for a page with a single zone on it. You or a user logs in, then selects the content file to update and updates it. You can only update one content file at a time. You must update each zone individually. Remember, as soon as you update a content file, that content is immediately available for display.

To Top

Viewing the content for multiple zones
Again, simply call the .shtml document in your browser. The server will parse ALL the SSI tags in the page and display the content in the appropriate page.

If one or more of the tags does not display it's content, then go through the checklist we provided earlier, applying each question to each SSI tag that is not displaying the content.

To Top

Client Users Guide

The wysiwyg.cgi program has a link to the Client Users Guide. This guide explains only those elements that are necessary for your client/employee/associate to update the content of a content file. You can view that guide from this link.

You are not permitted to download this page and place it on your own server, it must remain on the Perl Services server. However, if you request the customization package, we will send you a remote SSI script to display the body of the Client Users Guide from your own website.

To Top


There are a few important security aspects to keep in mind. Some are good practice in general, some are specific to this program only.

1. WE STRONGLY RECOMMEND that you specify a valid document name for each content file profile you create.

2. WE STRONGLY RECOMMEND that you specify a valid server for each content file profile you create.

3. Make sure your $DataKey variable is a completely random sequence of characters. Do not make it a real word and do not make your Postal Code/ZIP Code or phone number part of it.

4. This program only supports one main administrative user. Do not give out your administrative User Name and Password unless absolutely necessary. If you do have to give it out to someone, change these as soon as that person is finished working with it.

5. Change your User Name and Password every four to six months. Encourage your registered users to do the same thing. If they don't, do it for them.

6. Select a User Name and Password that is easy for you to remember but hard for someone else to guess. User Names and Passwords that are longer, are harder to guess. We recommend ten characters for User Names and Password.

7. Whenever this program creates a sub-directory, it creates and index.html document that displays an un-authorized access message. This is utilized in case someone stumbles across the directory name. This way your server will not be able to list the contents of that directory. If your main directory document is named something other than index.html, you will have to FTP into the data directories and manually rename these documents.

8. Your programs administrative password is encrypted. Therefore you can not retrieve it. If you forget the administrative password you will have to run the set-up routine again. Running the set-up routine again will let you set-up a new password.

9. Unlike most CGI programs available on the web, this program utilizes a back-up and restoration set of utility on all data files. This reduces the likely hood of files being erased by a large number of hits at the same time. In the very unlikely event that this does occur, please contact us

To Top


If you are unable to set-up this program or are uncomfortable setting up the program then please contact our support department.

If you have the program setup, then log into admin and click the support link on the footer bar of the admin interface.

We offer an installation service for a small fee, details of which are available at the support centre. Note that due to the unpredictable nature of NT and Mac servers, we do not offer support or installation services for programs being installed on these types of servers. This program was written for a UNIX server.

If your program is up and running and then you need to contact our support department, please utilize the built in support form as it passes us the necessary information to properly handle your request. You access the built in support form by clicking on the "support" link at the bottom of the screen of the admin program.

If you do not receive a response from our support centre within 24 hours, please contact us

To Top

Page 1   Page 2   Page 3

  ©2009 All rights reserved, Website hosting by