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
RegisterHT
Mailing List Server
Page Updater - Text
Page Updater Pro Updated
PS Guestbook Updated
PS Lightning Search Updated
Quick File Mailer
Quick MySQL
Select-A-File
Upload Center
Free Perl Scripts
Access Log Viewer
All Form
Epoch Converter
Error Log Viewer
Invoice Center
PS Upload
Question Manager
Quick CHMOD
QuickHT
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
Sudoku
Tutorials and FAQs
Cookies
Using CuteFTP
Using WS_FTP
Installing Scripts
Debugging
Utilities
env_vars.pl
backup.pl
restore.pl
check_email.pl
date.pl
dayname.pl
fileage.pl
format_length.pl
format_url.pl
getfile.pl
parse.pl
redirect_html.pl
Free Services
Epoch Converter
TLD Registries
RGB/Hex FInder
Colour Checker
ASCII Codes
Policies
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 (Text) 2.1

Supported Servers : Unix, Linux, FreeBSD, Sun, BSDOS
Price : USD $50.00
Requires : Perl / cgi-bin
Version : 2.1
Original Release Date : April 2004
Latest Release Date : April 2009
F.A.Q : Click here for F.A.Q.
Users Guide : Admin Guide Client Guide

  1. Beginning
    1. Disclaimer
    2. Introduction
    3. Requirements
    4. Configuration
    5. Installation
    6. Un-Install


  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 .shtml page
    2. What is an SSI?
    3. How to create an SSI script for the program
    4. How to create an SSI tag on a web page
    5. Loading and CHMODing an SSI script.
    6. 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
      script
    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 .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 an SSI?
An SSI is a "Server Side Include". SSI's are generally effective only in .shtml documents, however, a server can be configured to run them in any HTML document.

How a SSI works is that you put a special tag in a .shtml document that points to a Perl program on the server. This is what the standard Apache SSI looks like for executing a Perl script:

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


When you enter the URL (or click a link) to a .shtml document in your browser, the server receives the request, see's that it's a .shtml document and then steps through the document, line by line. Wherever the server finds one of these SSI tags, it executes the script and takes the data returned by the script (text and HTML tags) and then prints that information out to the browser.

Because of this, the end person who is looking at the page in their browser never see's the SSI tag. This is because the server replaces the SSI tag with the information that the program gave it to print out.

Some people say there are security issues involved with SSI's. This is not the case with Page Updater Pro. The content that is being delivered is entered by you, the user. You would not want to damage your own server would you? Also, Page Updater Pro creates Flat Text Files. It does not create a file that is recognized as executable by the server. Finally, the SSI does not permit any input. The SSI's with this program only output information.

There are many more types of SSI commands that you can use on your web page. Check the FAQ section of www.apache.org for more information on Server Side Includes.

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 "schedule.pl".
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 pup_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]

...it 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 "env_vars.pl" 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". V3.1 of this program now 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 page_update.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




Security
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




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

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 1Page 2




  ©2009 All rights reserved, PerlServices.net. Website hosting by LinuxHostingPlans.com