Page Updater Pro (WYSIWYG) 2.2
|
 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.
|
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 :
- Log into PUP and Create Content File
- While logged into PUP, from : List Content Files click Remote SSI to generate the script you need to upload to remote server.
- Save the generated file in Notepad or any plain text editor, you may name it whateveryoulike.cgi
- 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
- 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/some_script.pl" -->
<!--#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/some_script.pl -->
<!--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:
- 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 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:
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". 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:
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
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.
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
