Re: [PHPiCalendar-DEV] calendar_functions.php

[Wesley M. <we...@we...>]

Hi Jim,

Yeah, I was afraid I'd broken stuff. Placing a .ics at the end seems  
like the correct approach, since the "// Process files." block  
expects the files to be the full path to a real file. I don't think  
it's a kludge, since under normal operation, that's how a calendar  
name would be mapped onto a file, right?

I think then this needs to be combined with a modification to line 70:

		// Build the list of files we need to check.
		if ($find_all || $recursive_path == 'yes' || $support_ical == 'yes') {
			// Open the directory.

This will force it to check other .ics files, such as  
corestorage.ics, in the $search_path for the name pulled out of  
Info.plist, if $support_ical == 'yes' but you still specify the  
calendar name in the request. I imagine that if $recursive_path ==  
'no', at this point you would use $cpath to identify the directory  
containing your iCal directory with the corestorage.ics and  
Info.plist contents.

This seems to work for me in my very brief test. Without your change,  
and the change to line 70, selecting a specific calendar doesn't work  
unless $recursive_path == 'yes'. What do you think?

Later,
Wes

On Nov 10, 2005, at 10:47 PM, Jim Hu wrote:

> I've seen a problem where calendars aren't showing up when a  
> specific calendar is selected, as opposed to  
> all_calendars_combined...this is using what's in the CVS and not  
> using recursive searching.
> As far as I can tell, availableCalendars() never pushes the  
> calendar onto the cal_filelist array.  I patched my install by  
> forcing a .ics extension onto $filename.
>
> 		} else {
> 			foreach ($cal_filename_local as $filename) {
> 				array_push($files, "$search_path/$filename".'.ics');
> 			}
> 		}
> ...but that seems very much like a kludge.  Any thoughts?
>
> =====================================
> Jim Hu

--
Wesley Miaw
we...@we...