Re: [PHPiCalendar-DEV] ics extensions

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

Hi Jim,

I don't think there's anything to read with $support_ical, but the  
issue is that with one of the newer versions of iCal, Apple changed  
their repository structure. It used to just be a single directory  
with a list of Calendar.ics files in it. Now it has become more  
database-like (no doubt to support a richer feature set) so there is  
a base directory, containing multiple subdirectories of some hashed  
name. Inside each of those subdirectories is the corestorage.ics  
file, a binary index, and an Info.plist file that contains meta  
information.

So that's what led me to include the two new config globals to  
support iCal and recursively search directories.

I remember seeing that $calendar_path .= "/$cpath" line. It works if  
$calendar_path is not empty, but becomes a problem if $calendar_path  
= '' in config.inc.php. What's $tmp_dir used for? I'd propose the  
following for $cpath:

if ($_REQUEST['cpath']) {
	$cpath 	= $_REQUEST['cpath'];
	if (empty $calendar_path) {
		$calendar_path 	= ".";
	}
	$calendar_path .= "/$cpath";
	$tmp_dir 	.= "/$cpath";
}

I just checked in the changes we discussed below. Hopefully this will  
fix the issues people have run into from my bad checkin earlier.

Later,
Wes

On Nov 11, 2005, at 8:42 PM, Jim Hu wrote:

> Wes,
>
> Hard for me to evaluate...I confess that I'm lost on what's going  
> on in the $support_ical setup.  Is there a place where I can read  
> up on that?
> What I did on my end to take care of $cpath is to move the code  
> setting $calendar_path using $cpath in init.inc.php to before
>
> 	if($_REQUEST['cpath']){
> 		$cpath 	= $_REQUEST['cpath'];				
> 		$calendar_path 	.= "/$cpath";				
> 		$tmp_dir 	.= "/$cpath";				
> 	}
> 	include_once(BASE.'functions/calendar_functions.php');
>
> This sets the $calendar path in function available_calendars  
> correctly...at least as far as I've been able to  check in the past  
> couple of days.  Anyway, I think that the .ics extension problem  
> may account for some of the other bugs being reported on the bbs,  
> so if it's OK to append the .ics where I did I'll use it.  I could  
> put that on the CVS but maybe you should just include it when you  
> make the other changes.
>
> I've been working on fixing some bugs with rss.php.  More on this  
> later.
>
> Jim Hu
>
>
> On Nov 11, 2005, at 10:16 PM, phpicalendar-devel- 
> re...@li... wrote:
>> <snip>
>> --__--__--
>>
>> Message: 3
>> From: Wesley Miaw <we...@we...>
>> Subject: Re: [PHPiCalendar-DEV] calendar_functions.php
>> Date: Thu, 10 Nov 2005 23:11:30 -0800
>> To: php...@li...
>> Reply-To: php...@li...
>>
>> 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...

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