|
From: Wesley M. <we...@we...> - 2005-11-12 08:21:58
|
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...
|