After spending about a week on the fone with them, suffering multiple hang-ups and nonsense comments from technical supoort, I finally got them to call me by writing nastygrams to the President of the place.
The guy who responded finally admitted that all Perl include modules are now hidden and generally unavailable to websites. They hadn't bothered to tell me this. If I want CalendarScript to work, I have to upload the modules to their servers.
I tried finding them on CPAN... the first one is called "asp.inc" and a search on that name gave >2,000 returns. Clearly, that won't work. If I had a *nix server I could get the files from that -- but I don't.
So here's the problem: Can somebody please just send the all Perl modules which CalendarScript requires.
Please?
Here's a list of them to make things easier:
"asp.inc" "DBFile.pm" "DBFileUtil.inc" "TimeLocal.inc" "Date.inc" "ConfigFile.pm" "Event.inc" "HTML.pm" "CGISession.inc" "User.pm" "SimpleDateFormat.pm" "calendars.inc"
netcraft.com reports the OS as Linux running Apache/1.3.29 (Unix) FrontPage/5.0.2.2634
I'm contributing my time to maintaining this sit for a non-profit organization concerned with senior issues.
It's OK to contact me directly.
Thanks for any all help !!!!!
quote:Here's a list of them to make things easier:"asp.inc""DBFile.pm"...
"asp.inc""DBFile.pm"...
Dan O.
------------------
goDaddy.com had killed CalendarScript, so the first appearance/guess was that they had removed some required modules... and it took a week of pulling teeth, hangups, and finally president abuse to get them to admint that they had done so. Stupid me for believing them.
It appears what they have really done is to remove from their initiation script the suggestion to search subdirectories of the program's current directory for include modules.
I'm downloading the current CalendarScript version, and I'll post my final results after I test that at the goDaddy.com hosting site.
Thanks for giving me at ticket on right cluetrain!
That's Dumbass.
** what they have really done is to remove from their initiation script the suggestion to search subdirectories of the program's current directory for include modules. **
I'm afraid I'm not sure what you mean by that. The calendar.pl and calendar_admin.pl files add the specific subdirectory to @INC with the line:
unshift(@INC,$BASE_DIR."lib");
As long as the $BASE_DIR variable is being set (namely using the $ENV{'PATH_TRANSLATED'} or $ENV{'SCRIPT_FILENAME'} environment variables), the path to those files should be available to the script.
JMO
[This message has been edited by DanO (edited August 03, 2004).]
First off, $ENV{'PATH_TRANSLATED'} & $ENV{'SCRIPT_FILENAME'} are not available -- that seems to be one of their really useful changes. OK, so all I have to is set $BASE_DIR, huh? (BTW, a bug exists in calendarscript.pl that if these $ENV things can't be found, the error message emitted is not HTML formatted, and so is not sent by the server. If it had been, I would have saved about a week with the goDaddy freezebrains)
NO.
Running debug.pl reveals that it can't see any of the needed modules, no matter what I set $BASE_DIR to.
Fact of the matter is, they've so screwed up things so much that it seems impassable detect any files at all (good trick, that
Since they didn't trust that debug.pl was doing the right thing, I wrote the simplest possable test program for them:
------cut here--------cut here----
$file = "/cgi/calendars.txt";
print <HTML preamble>
if (-e $file){ print "saw the file";}else{ print "didn't see the file";
print <HTML postamble>
I've placed copies of calendars.txt in all directories, yet this code never sees it.
(It sure looks like a server problem to me, but of course I'm the only guy out of thousands who has this problem -- yeah, sure)
What do you think is going on?
Any suggestions?
I wrote a script called peek.pl to tell me that: PATH_TRANSLATED = null SCRIPT_FILENAME = /html/cgi/<scriptName> this does not start high enough in the direcrtory tree
But $0 (name of the script being executed) gave:
/home/content/w/e/n/wendyPeterson/html/cgi/
(Wendy Peterson is the name of the account holder)
so the currect setting is:
$BASE_DIR = "/home/content/w/e/n/wendyPeterson/html/cgi/calendarscript";
It only took me two weeks not to find this out from goDaddy's little kiddies....
Here's a suggestion: debug.pl might display what it senses as its location to given something of a clue for the proper setting of $BASE_DIR
Hope this helps someone... like convincing them not to use goDaddy.
After sending numerous emails, suffering a series of hang-ups, and phone calls from customer misservice representatives, I finally go in touch goDaddy's VP of Straighting-out-the-Mess.
He got whoever set up the server the last time around to admit they had messed up, and to correct the sanfu so that now CalendarScript works perfectly without and changes. (It seemed to be something about thier hiding/rewriting the virtual directory structure but neglecting to make SRIPT_FILENAME match whatever fiction they had constructed).
I've been assured that based on my experiences some improvements will be made at goDaddy beyond keeping thier servers straight. I guess we'd all like that, and we'll all watch and see.
This time, it seems the server is inserting a segment into the URL when you are in the admin function (I see "cgi-bin/sbox" being inserted).
I've sent a detailed description of the problem to GoDaddy tech support and am awaiting their response.
Is your script still working?
After some more searching on this board I'm pleased to announce that at least I have managed to find a work around. I think the GoDaddy virtual structure still needs to be corrected, but for the Calendar Script administrative functions, you need to change line 322 in the 'calendar.pl' script to read:
$Template::CGI_URL = $AdminConfig->get("calendar_admin_url") | | $ENV{'SCRIPT_NAME'} | | $ENV{'REQUEST_URI'};
This way, when the URL for the admin config file is requested it won't end up with the incorrect "cgi-bin/sbox/" directory structure tha tthe GoDaddy server was providing.
One more thing -- I have two SSI calls on my home page that stopped working. Do you (or any other posters here) have SSI? I formerly used #INCLUDE VIRTUAL but that was giving an "error occurred while processing directive" or something like that.
I've had to change the call to #EXEC CMD, but now I'm not getting any calendar entries back. Any thoughts?
Kent
Go Daddy Sucks!
** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
Step 1:
run the install.bat file that comes with the download from a c: prompt.
c:> install.bat www.yourdomain.com hostingusername hostingpassword cgi/
Step 2:
Modify calendar_admin.pl.
The base dir line should be as follows:
$BASE_DIR = "/home/content/u/s/e/username/html/cgi/calendarscript";
In this example, your path goes /home, /content, /u/s/e, /username/html/cgi/calendarscript
The /u/s/e refers to the first three letters of your hosting username. If your username is 'example', then your three letters would be /e/x/a .
Step 3:
Modify calendar.pl
$BASE_DIR = "cgi/calendarscript/";
Additional Information:
If you need to debug the script, modify debug.pl to use this base dir:
The three letter rule applies here in the same way as in Step 2.
If you are having trouble getting a script to run on a Go Daddy hosting account, please feel free to contact technical support and we will do our best to assist you with it.
president@godaddy.com
Douglas Preston Jr.Office of the PresidentGODADDY.COM14455 N. Hayden Road, Suite #226Scottsdale, AZ 85260480-505-8828480-505-8844
Also what if you have 1 account with different URL's on it?
This is the script I am trying to edit - maybe some of you could help me?
<?php$webroot="gal/"; // relative path from admin script to picturesdefine("BASE_DIR","/home/content/......../gallery/gal"); // absolute path to galleries for spgmdefine("MAX_THUMB_WIDTH",100); // max width for thumbnailsdefine("MAX_THUMB_HEIGHT",100); // max height for thumbnailsdefine("MAX_IMAGE_WIDTH",640); // max width for displaying image for croppingdefine("MAX_IMAGE_HEIGHT",480); // max height for displaying image for croppingdefine("GAL_FILE","gal-desc.txt"); // where the gallery descriptions are, default to spgmdefine("PIC_FILE","pic-desc.txt"); // where the picture descriptions are, default to spgmdefine("THUMB_PREFIX","thb/"); // thumbnail prefix, _thb_ default to spgmdefine("COLUMNS",4); // the number of thumbs to display per rowdefine("JPG_QUALITY",75); // 1-100, typically 75, bigger number = better quality, larger filesdefine("LANG",'en'); // defines the language to use, default is english (en)
// the image types allowed, "type"=>true (1), all lowercase$pic_extensions=array("png"=>1,"jpg"=>1,"gif"=>1);?>
the guy who supplied this PHP script advises the following:
"BASE_DIR" - This is the absolute path to the gallery on the host filesystem. For example: "C:/wwwroot/photos/gal/" or "/var/html/wwwroot/photos/gal/"
I just don't get!!!
taken from: http://www.bluepalmtrees.com/spgm/
Setup and InstallationInstallation and Setup (Moderators: scott, DanO, Marty)HELP! GoDaddy killed my Script -- need modules
