Page Updater Pro (Text) 2.1
|
|
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:
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:
- Except for the path to the script, copy this tag EXACTLY as you see it here.
- 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. - 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".
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:
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):
- You transferred the SSI script to the server in Binary mode instead of ASCII mode.
- You did not CHMOD the SSI script or you did not CHMOD it correctly. It must be 755.
- You do not have the correct path in the SSI tag (most likely cause).
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:
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
