The calendar itself is still there and displays just fine, alas, I can't get into it and it shows wrong information now.
Thanks for any help!!!The site is on an apache server, I use netcaptor (but also tried IE and others), I get no error message and the calendar worked fine for years. My webhost is also looking into this...
Thanks!
Oliver
There were problems detected with the files or directories needed by CalendarScript. These problems may be caused by one of the following: "The file does not exist" problems are usually caused by the $BASE_DIR path being incorrect. "No READ access" and "No WRITE access" problems are usually caused by forgetting to CHMOD the files or directories after transfer, or not giving the correct permissions in Windows. "The file was not transferred in ASCII mode" problems are caused by not explicitly transferring files in ASCII mode in your FTP program. Some FTP programs make it appear like you're transferring in ASCII mode, when in fact you're in "Auto" mode or something similar, and this can cause problems. The files with problems are listed below.
Problem File/Dir The file does not exist /home/nineteen/public_html/cgi-bin/calendarscript/session/junk.txt Once this problem is fixed, please re-run this debugger to check for any further errors!
------------------
I just looked into the session directory, there's no file called junk, just files with numbers as name, such as 1011197140.txt for example.
Last post for now, I hope somebody can help me.
Click the button on the message you want to edit.
I'm afraid I don't know what is causing your problem besides maybe incorrect permissions. It is not unheard of for server maintenance to change permissions unexpectedly (or for host's support to deny any changes took place which may be responsible).
Dan O.
[This message has been edited by DanO (edited June 27, 2004).]
thanks for the info, I'll forward that to my host. There were other problems with the site that they're currently looking into, maybe I just have to change permissions back to what they have to be. If I find any other info and can't fix the thing I'll post again, and I'll also let you know if I was able to fix things with the above info!!
Thanks again!
Admin screen comes up, but after log in and selecting the default calendar it just goes back to the log in.
I don't know perl and am not familiar with the database structure behind the calendar. My host said that i might have to re-crate some MySQL databases that might not have gotten restored with the backup. But since the calendar itself works and displays just fine, I'm not sure that's an issue.
I searched around here for similar problems and found different sollutions people used, I sent them all to my host. As for $base_dir, I just looked at my calendar_admin.pl file and here's what it says:
#!/usr/bin/perl## CalendarScript# Version: 3.1## Copyright 2001 Scott# http://www.CalendarScript.com/ #
BEGIN { # CHANGE THE LINE BELOW IF NECESSARY # Be sure to remove the # before $BASE_DIR, and change the path between the quotes #$BASE_DIR = "/...change.to.full.file.path.of.dir.../calendarscript/"; # DO NOT CHANGE ANYTHING BELOW HERE!
Now, if I read that correctly, there's no base directory set? But how could that be, the calendar worked for a long time just fine. It has the same line in calendar.pl too. But the calendar itself displays just fine.. :-(
Any other ideas?
Thanks,
------------------edited 6-28 7:38am
[This message has been edited by Oliver (edited June 28, 2004).]
In the users.txt file in the /calendarscript directory.
** there's no base directory set? But how could that be **
Normally the BASE_DIR is derived from enviromental variables on the system it is running on. If those variables are not set on the particular server or you want the data files to reside in a directory other than the default (/calendarscript), then the $BASE_DIR variable must be set manually.
Might a file be corrupted? Should I upload my local copy of the admin file (or maybe an other file?) Or do a new installation? If so, whould that overwrite my events and settings? Which files would I need to backup to make sure everything looks as it's supposed to later on.
I'm at a complete loss here, I don't understand why it suddenly won't work anymore. Unfortunately I don't know Perl so I can't really poke around. Nothing changed with the directories, and since the calendar itself displays just fine I'm sure that's not the issue.
I noticed that the files permissions.txt and users.txt are set to 644, everything else is set to 755 (777 is not allowed on my host). Only the session files in the sessions folder are also at 644. Should I change any of those? I tried with the two files I mention, but it did not seem to help.
I really need to get this up and running again, there's outdated information on the calendar.
Thanks for any additional ideas! I searched the forums here but found no applicable sollutions, though I might have overlooked something.
Data files and their directories should usually be chmod to 666 (read and write permissions) or 766 depending on the server set up.
I don't know what else to suggest, sorry.
[This message has been edited by DanO (edited June 28, 2004).]
You say 666 or 766, is that for ALL files under the calendar folder (including the calendar folder)? The instructions I printed when I installed this say 777 for everything and my host requires 755. Which worked just fine for a while...
Any idea what else could be wrong? I'd rather not have to install a different calendar, this one worked just fine for a while now. I'd be happy to give you url and log in info via e-mail if that might help, I don't want to post it here of course :-)
I'm still getting the loop around: sign in, select calendar, sign in, select calendar, .....
Are there some instructions on doing a new installation without deleting all the entered events? Or, which files would I have to backup and replace after a new install, to make sure all my events and calendar settings remain?
Maybe you know somebody else that might have an idea? There must be somebody that can figure this out? I'm at a loss, but I'm also not a perl person - sadly~~
Just the files and directories which get written to by the script.
** my host requires 755. Which worked just fine for a while... **
755 is usually just for scripts and their directories but depends on the way the server was set up.
** Are there some instructions on doing a new installation without deleting all the entered events? **
Not that I know of.
How about trying to install it from scratch but in a different directory? That way you can see if you can get it to work without loosing any of the original data?
My server requries such files to be set to 755, not 777 as the manual says. But that worked just fine so far.
How does the log in process work? I'd guess once I enter name and pw the program checks to make sure it's correct. I can log in (get the logged in message), but when I then select the default calendar I just get back to the log in screen. What proess(es) would run after the calendar selection? Maybe the calendar can't find the file or can't write to the sessions folder? Would that explain the loop back to the log in? I'm just trying to trace this step by step to find what the issue is.
Thanks for all the help!
Correct, then it sets a cookie. If the cookies aren't set or the session can't be written, then the script doesn't know you're logged in and will likely ask you to (again).
Any addtl info would be great, and help me and the server admins to figure out what is going on.
Thanks!!