next »

[TDPSS]

I've just UPLINKed our CalenScript based page for the first time and I'm having a lot of difficulty getting the Perl scripts to function correctly. I've done all the requirements outlined for a typical Unix Host Server. All files where xfer in ASCII mode, and ALL files set to 775.
All, the CalendarScript files on the site are straight from the CalendarScript321.tar.gz file. NO hacks or mods on my part, other than setting $BASE_DIR.

When I execute debug.pl I get a whole list of:
"The File does not exist".  Pretty much the whole calendarscript tree. The "file/Dir" syntax listing looks correct.
i.e. /cgi-bin/calendarscript/yada-yada-yada.ext

I've tried making the $BASE_DIR an absolute i.e.
$BASE_DIR = www.PowellButteCommunityCenter.com/cgi-bin/calendarscript;

And still the issue exists. The Host Server Support team says they support Perl 5 version 8 something.

Any more suggestions on what I can do?

-Dennis

[TDPSS]

CORRECTION:  all file permissions from calendarscript directory on down the whole tree are 777.
-Dennis

[DanO]

 

quote:I've tried making the $BASE_DIR an absolute i.e.
$BASE_DIR = ht tp://www.PowellButteCommunityCenter.com/cgi-bin/calendarscript

The script says:
 

quote:# Be sure to remove the # before $BASE_DIR, and change the path between the quotes

No directory path contains ht tp://...  That is only found in URLs. Also, the file directory path on the server is unlikely to be the same as what is seen in the script URL.

If you don't know what the absolute path to your script files on the server is, check your host's CGI FAQs or ask their support.

JMO

Dan O.

------------------

[TDPSS]

I realize the misconceptions on $BASE_DIR and URL's and that such a test was doomed. I was only experimenting, not fully understanding it's true nature and use. I have done more experiments in putting the calendarscript tree in the htdocs area, and setting $BASE_DIR accordingly. Yes the # was removed from the get-go. As expected, those tests failed. I then added a text file of my own to debug.pl's list of files to check and set $BASE_DIR to a non-calendarscript directory containing that file, like htdocs and cgi-bin. Even that file test fails.

Clearly there is a fundamental issue with the PATH variables! Something is really amiss between what standard rules Host Providers operate under and what stardard perl scripts should expect to operate under. The Host Provider is "Net Solutions" and I see other entry's to this same vendor, same problem - with no apparent resolution in this site's blogs. I also see other Host providers listed with simular issues. I checked Network Solutions Technical support page for CGI FAQs and nano-nano.  

I have absolutely no clue what's next. The folks at Net Solutions are looking into this and hopefully if they've dealt with this issue before, a fix may be forth-coming. This has certainly pop the balloon on this project. I think it's a great Application, when things are setup and working. It's late, I'm tired and I'm starting to rant!
Certainly any further info would be greatly appreciated.
-Dennis

[musicvid]

There is a little script called perldigger.cgi that will give you more information on your server paths and perl installation than you'll ever use. It's free and you will be able to find it with a simple Google.

------------------

[TDPSS]

The problem has been solved. I'll post details when I fully confirm everything is working. The guys at NetWork Solutions were extremely helpful in solving this issue. Mucho Thanks to them ! By the way they claim that HTML files in the cgi-bin area aren't allowed - even though they are template files for   the perl scripts. I will confirm this and report back.  I'm currently running the "calendarscript" directory under the htdocs area. Also, Network Solutions provided a perl script to show what the full path is for your cgi-bin and htdocs area. This certainly solved the DIR_BASE issue.
-Dennis

[DanO]

** By the way they claim that HTML files in the cgi-bin area aren't allowed - even though they are template files for the perl scripts. **

That is quite possible, it depends on how the server is set up. That information should be covered in the specific host's CGI FAQ's.

That is the main reason for the $BASE_DIR variable, so you can point the script files (which could be in the cgi-bin directory) to the data files which may be elsewhere on the server.

JFYI

Dan O.

------------------

[TDPSS]

I haven't had a chance to test the plugins feature. I was planning on using the ClickOne. In moving the calendarscript directory tree to htdocs, will the perl scripts for plug-ins still work?
Or due they need to be relocated back cgi-bin?

-Dennis

[DanO]

All supporting files have to be in their proper place in the /calendarscript/ directory tree regardless of where the actual script files are located.

Dan O.

------------------

[TDPSS]

I have been testing the my setup with CalendarScript installed in the htdocs area on my DomainName Site. I've made a simular change to the local Host machine that I originally used for initial development of our Community Center web site. The new configuration of CalendarScript is working well on the local Host machine, but has a problem on the Domain Host with the "Login" button on main page. It appears the DomainName HOST system is looking for my local system and is trying to launch calendar_admin there. I've look at the Web Source page and the HTML script generated for the Main Calendar has http::"...my.local.hosts.ip:8080/" reference all over the place. How is CalendarScript getting this address and still trying to use it? My DomainName Host knows nothing of my local host machine. I've cleared all local data in my Browser, that doesn't solve anything.
-Dennis

[TDPSS]

Sorry, forgot to add that debug.pl reported no errors with both the Local and DomainName systems.
-Dennis

[TDPSS]

OK, I found it in config.txt !

------------------

[DanO]

** the Main Calendar has http::"...my.local.hosts.ip:8080/" reference all over the place. How is CalendarScript getting this address and still trying to use it? **

You must have installed the script on one server and then moved those files to a different server where it will actually be used. The script should be installed and run for the first time on the server it is going to be used on as some variable are set the first time it is run.

** I found it in config.txt **

Yes. If you're moving the script files from one server to another, some variable valves will likely have to be manually altered as discussed in the previous forum message, "Saved, Moved & Restored".

Dan O.

------------------

[TDPSS]

The fixup changes to config.txt corrected the login issue, but now logging in as Administrator and selecting "Admin" button
I get a Calendar Admin : Main Menu that's virtually broken for every selection but "View Calendar". The error is Page Not Found.

** The script should be installed and run for the first time on the server it is going to be used on as some variable are set the first time it is run.**

What scripts are available in the .tar.gz distribution for installing on a Unix plateform. All I saw was a DOS .bat file.

-Dennis

------------------

[DanO]

** What scripts are available in the .tar.gz distribution for installing on a Unix platform. **

It shouldn't need to be "installed", just unzipped on the server once uploaded (in binary form BTW). Any manual changes necessary would have to be performed after that.

I myself however, usually just extract the files locally (either .zip or .tar.gz) and then FTP those files in ascii mode to the server, preserving their directory structure. Once there i chmod the three .pl files if necessary (it often isn't).

JFYI

Dan O.

------------------