iCalcreator library could not be found

Let's keep this discussion to one issue (#2070283: Caveat When loading iCalcreator library), since I'm pretty sure both of these stem from the same problem.

Wait, I'm an idiot. That other post is an old, closed issue. Lets stick to this one.

It looks like your webserver user doesn't have permissions to read the iCalcreator.class.php file. You'll need to make sure that Apache's user (on linux, it's usually "apache", on OSX it's usually "www", not sure about Windows) has permission to read the file and the folder it's inside.

You mentioned in the other thread that you "got rid of the warning". Which warning, specifically, is gone? All three of them? Is changing the directory to lowercase what did that? I ask because that should have made it worse. Libraries expects the directory to be "sites/all/libraries/iCalcreator", with the capital C.

Which version of iCalcreator do you have installed? You can check by opening iCalcreator.class.php and looking for a line like this:

define( 'ICALCREATOR_VERSION', 'iCalcreator 2.18' );

around line 48.

What message do you see below the words "Date iCal" on the admin status page (/admin/reports/status)? That will give me more information about what is specifically wrong.

Did you ever solve this?

I'm having the same problem here. Installed iCalcreator.class.php file in sites/all/libraries/iCalcreator and the status report is still saying "The version of the iCalcreator library could not be detected."

Please help.

Try this: go back to the status report page to see that error. Then go to the "Recent log messages" page (admin/reports/dblog) and look for errors related to the Libraries module.

If this is a permissions issue, you're likely to see several consecutive errors related to the functions fclose(), fopen(), and fgets(). If you see that, your iCalcreator.class.php file doesn't have permission to be read by your Apache server. You'll want to give that file full read permission for all users, or change its owner to the Apache user.

If you don't see errors related to those functions, please copy-paste the full error messages that you do see into this ticket.

I went to the Status Report page and saw the same error. It says:

Date iCal iCalcreator library could not be found, check the installation instructions for the Date iCal module.
The error message was: not detected
The version of the iCalcreator library could not be detected.

I cleared my browser cache and force loaded the page from the server on a reload to be sure. Then I went to the recent log messages page and there are no errors there. The only things in the recent log messages from today are a few user registrations indicated as being blocked by spam protection modules and the cron run completed message. Nothing else present to paste here.

I've installed another Drupal 7 on this same server and am having the same problem. Both of these sites will have events that I intend to feed to Google Calendar using this module. This functionality is currently working in Drupal 6 and is essential to have it working for me to upgrade them to Drupal 7, so I really hope I can get past this. No idea what I'm doing wrong. Thanks for your reply.

Well shoot. A complete lack of error messages is definitely not helpful. However, I did some more experimentation, and I think I might know what could cause that.

For one, is your server on a unix-based OS, or Windows?

If it's a *nix box, check the permissions for each of the folders on the path to iCalcreator.class.php ("sites", "all", "libraries", and "iCalcreator"). Every single one needs to have global read and global execute permission in order for the apache user to be able to read them. From my experiments, if one of those folders doesn't have those permissions, I get the same problem you have: the library is "not detected", and there are no error messages in the logs.

If your server is Windows-based, I imagine that this is also a permissions problem, but I have no clue how to fix that. I'm sure Google does, though.

It is a linux server, apache 2.2.27

The folder permissions all the way through are 755.

One other thing going on with this server that may or may not cause a lightbulb to come on over your head about this problem is I am unable to upgrade from Drupal 6 to Drupal 7. The step where I am supposed to run the update script after unpacking the Drupal 7 version into the root fails. The system automatically redirects from update.php to install.php no matter what I do with the permissions on settings.php. I've tried changing the $update_free_access setting to true and that changes nothing. I've tried copying Drupal 7's default settings file as the settings file (after adding the correct database information) and that fails as well. Nothing works. This doesn't happen when I build the site from scratch in Drupal 7. It's only at the point of updating the database when going from Drupal 6 to Drupal 7. Google has not yet provided me with the answer to that problem and I'm pretty much going to be stuck having to rebuild some very huge sites from scratch if I can't figure it out. I'm about to be a very unhappy camper that will likely have weeks or even months of largely unpaid work ahead of me as compared to days with a successful upgrade process.

I have a funny feeling that whatever is causing that problem may also be why it doesn't see your library. I don't think I'll get any help from the ISP on this because they'll likely call it a Drupal problem.

The iCalcreator.class.php file itself has permissions set to 644 though.

... same problem here - suddenly the error message came up as reported above.
I set all listed directories/files (see #11) to 755 and no change - the error message keeps coming.
All Caches flushed - still no joy ...

... well - just found the answer for my case:
On the last update of the library I read the advice and changed the library name to all lower case = icalcreator. Prior to then it was iCalcreator.
Changing it back to iCalcreator solved my error message .....

Yeah, if your site isn't actually Drupal 7, I can't even begin to imagine the kinds of odd things that would happen with Date iCal. I really can't help with that.

But to debug the issues you're having with the upgrade, I'd suggest hooking your Drupal site up to a debugger. Eclipse with xDebug is what I use, and it lets me watch the code as it executes, one line at a time. Doing that should help you figure out why that redirect is happening, and maybe shed some light on how to fix it.

The site I am working on now is Drupal 7. The situation I explained about the D6 to D7 upgrade is for another site on this same server. I thought the server behavior might shed light on this problem. It turns out that was happening due to settings added to the settings.php file on instructions from the Domain Access module. I took that out and that problem stopped happening. I'm having all sorts of other problems migrating that site from D6 to D7, but that's not related to this module situation.

I'm having this problem on a D7 site and the files have the letter C capitalized, so that isn't a solution for me.

OK, I've got two final ideas to try:

1) Edit the date_ical.module file, and replace the following function:

function date_ical_libraries_info() {
  $libraries['iCalcreator'] = array(
    'name' => 'iCalcreator',
    'vendor url' => 'http://github.com/iCalcreator/iCalcreator',
    'download url' => 'http://github.com/iCalcreator/iCalcreator',
    'version arguments' => array(
      'file' => 'iCalcreator.class.php',
      'pattern' => "/define.*?ICALCREATOR_VERSION.*?([\d\.]+)/",
      'lines' => 100,
    ),
    'files' => array(
      'php' => array('iCalcreator.class.php'),
    ),
  );
  
  return $libraries;
}

With this:

function date_ical_libraries_info() {
  $libraries['iCalcreator'] = array(
    'name' => 'iCalcreator',
    'vendor url' => 'http://github.com/iCalcreator/iCalcreator',
    'download url' => 'http://github.com/iCalcreator/iCalcreator',
    'version' => '2.20',
    'files' => array(
      'php' => array('iCalcreator.class.php'),
    ),
  );
  
  return $libraries;
}

That will hardcode the version number, rather than attempting to detect it from the file. It's possible that this will bypass whatever weird problem is breaking the detection, though that same problem may prevent the library from actually being used. If you can successfully export or import iCal feeds with that edit, then we know there's something wrong with only the version detection process, but everything else is fine.

2) Instead of making that edit to date_ical.module, apply the attached patch to the Libraries module. It adds a bunch of debug statements to the detection process, which I'm hoping will shed some light on why the detection is failing for you. You'll also need to install and enable the Devel module, since it's what defines the debug functions the patch added.

With Devel installed and that patch applied, go to the Status Report page again, and you should see a bunch of new messages appear at the top of the screen. Please expand all the arrays, then screenshot them so I can see what the messages say.

OK, I tried option 1 from your post. After uploading the edited file, the status report did say it detected the library.

I went into a View to see if I could add an iCal Feed. On one site I'm having all sorts of issues with the migration of the Date field into Drupal 7 from a Drupal 6 site. I tried it in there first because that's the one I was working on at the time I decided to start working on your post above. The View said it was missing a style plugin, so I re-added that as calendar. That seemed to work. I then hit the iCal feed display button and the entire view has now become unaccessible. All it does when I click Edit on the main views page for this view is it takes me to a page showing this:

Auto preview
Preview with contextual filters:
Separate contextual filter values with a "/". For example, 40/12/10.

When I click the Update Preview button present, it says

Invalid display id calendar_1

And that's it. My view is no longer accessible or editable. That's the page it took me to when I hit the iCal feed display button.

So I gave up on that site with this. I then went back to the straight Drupal 7 site (not an upgrade from Drupal 6). That site did not have the initial calendar View set up by the Date Wizard. So I tried to run the Date Wizard. After choosing all my settings, I ran that and got the following error:

FieldException: Attempt to create field name field_date which already exists and is active. in field_create_field() (line 85 of [path]/modules/field/field.crud.inc).

I feel like I'm nearly ready to give up as nothing I'm doing seems to work at all. But I have to get this functionality working for these Drupal 7 sites.

As for your option #2, I've never installed a patch. The things I have seen that explain this process have been beyond my comprehension thusfar. I'm good enough with Drupal to build a nice site when things work as they are supposed to, and I have some debugging ability, but I'm not nearly at the level you developers are. So please be patient with me. I'd like to learn patching, but I feel like I have to have someone in the room at the machine with me to show me the process COMPLETELY. I'm usually a quick learner once I see something done once. But even the videos I've watched on the patching process have left me feeling like I'm over my head. I know once I do one successfully, I'll wonder why it seemed so difficult.

I can give you temporary admin access to either of these sites if that would help. These sites are in development, not production.

Hmmm, that second error you described makes me think that the Calendar stuff may be getting in the way of setting up an iCal feed. You don't need to create a Calendar view to export an iCal feed; you can just create a new basic View, then follow the instructions in the README.txt file.

The problem you had on the migrated site sounds really strange, though. Have you checked the error log at /admin/reports/dblog on your site, to see what errors get thrown when you attempt to edit that View? PHP and Drupal have a bad habit of hiding error messages in that log, rather than showing them to you immediately.

As for applying a patch, you're on a *nix system, so you can use the unix patch tool, rather than having to involve the git system:

1) Copy the libraries_debug.patch file I attached to this issue into your /tmp folder.
2) cd to the sites/all/modules/libraries folder of your drupal site.
3) Type this command (without the quotes) "patch -p1 < /tmp/libraries_debug.patch".

You should see this output, and only this output:

patching file libraries.module

If that's what you saw, then you're all set. Just make sure you installed and enabled the Devel module before you apply the patch, or you're likely to get a bunch of errors.

Once you've gathered what you can from the new debug messages being printed by the patch (instructions at the bottom of comment #18), you can remove the patch by following steps 1-2, then using this command "patch -p1 -R < /tmp/libraries_debug.patch". Or just reinstall the Libraries module.

Nothing in the error log relating to the inability to edit the view on the migrated site. I can recreate the view if need be.

If at all possible, I'd like to create that Calendar view with this because that is the way I've been using the iCal feature in the past. I'm trying to rebuild already existing functionality in the upgrade from Drupal 6 to Drupal 7.

I have two sites I need this on. On one of the sites, I couldn't get the Drupal 6 to 7 upgrade process to work iniitially (which I later determined was due to the domain access module stuff in settings.php). That site has minimal content, so I decided that rebuilding the site from scratch in Drupal 7 would be faster than debugging the upgrade process. But then on the other site, there is a huge amount of content and functionality. So on that site I'm doing everything I can to get through all the 6 to 7 upgrade errors I'm encountering because that will hopefully be faster than rebuilding the site from scratch. It was on that site that I learned that domain access caused my previous upgrade problem. I got past that step the second time because I was much more determined to diagnose it.

Both of these sites are having the same problem with your module though and they are on the same server. I'll stick to the exclusively D7 version of the site from now on in attempting your recommended fixes.

OK, back to creating the view.

I uninstalled the Date and Calendar modules completely, deleted fields already created through them. I then reinstalled and successfully ran the Date Wizard to create the view. So that worked. When I clicked on the iCal display button, I got the following error:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /admin/structure/views/view/event_calendar/preview/feed_1/ajax
StatusText: Internal Server Error
ResponseText:
iCalcreator/iCalcreator.class.php at master · iCalcreator/iCalcreator · GitHub
Skip to content
Sign up
Sign in
Explore
Features
Enterprise
Blog
This repository
This repository
All repositories
Star
41
Fork
12
public
iCalcreator/iCalcreator
Code
Issues
3
Pull Requests
2
Wiki
Pulse
Graphs
Network
HTTPS clone URL
Subversion checkout URL
You can clone with
HTTPS
or Subversion.
Clone in Desktop
Download ZIP
Permalink
Show File Finder
branch:
master
Switch branches/tags
Branches
Tags
master
Nothing to show
Nothing to show
iCalcreator / iCalcreator.class.php
Fetching contributors…
Cannot retrieve contributors at this time
file
10544 lines (10511 sloc)
440.691 kb
Open
Edit
Raw
Blame
History
Delete

Then it listed the numbers 1-2041 or so in succession, one number per line.

Also note that on the main Views list page, it shows the paths for this View as:

/calendar-node-field-date/month, /calendar-node-field-date/week, /calendar-node-field-date/day, /calendar-node-field-date/year, /calendar-node-field-date/ical/%/calendar.ics

All of them are clickable links except for the ical one, which is in plain black text.

I hope this provides you/us with helpful information.

I'll try the patch next.

Regarding the patch. Note that the server I have these two development sites on also has three production sites on it. I want to make sure I'm only applying this to the libraries module on the one development site. There is one tmp directory in the root of the account on the server (totally private) and there is another tmp directory in the public_html directory one level below the root. Within public_html, we have a production site. The other two production sites are in their own subdirectories with add-on domains assigned to them. Then there is another subdirectory within public_html. In that subdirectory is this development site, which then has an add-on domain assigned to it. So I'm not sure where I should have the /tmp directory you're referencing for purposes of this test. There is no /tmp directory within the subdirectory where this site is stored. Where should the /tmp directory be in relation to this site and the server structure detailed here in order to follow your instructions? Or does it not matter?

I'm just worried that if I apply this patch in either the tmp directory in the root or the tmp directory in public_html, it will apply the patch to all instances of the libraries module present anywhere within public_html, which would mean it would apply it to the three production sites as well as the two development sites.

Please confirm that I'll only apply this to the one development site by following your instructions before I attempt this.

This would be great if I can successfully do this as I'm sure this will greatly expand my debugging capabilities, so thanks for trying to walk me through it.

Ack, sorry I didn't get back to you on this sooner! My browser crashed and I lost the tab where I was writing my reply, and then forgot about it.

However, in the intervening time period, I've run into an extremely similar problem as you were having with iCalcreator, and I may have found a solution.

First, thoroughly double check that the folder permissions from every folder in the entire chain to your iCalcreator folder in "libraries" (whether that be sites/all/libraries/iCalcreator or some other path) are actually 755 permissions. I ran into the "no error message, library version undetected" problem when I had one folder half way up the chain that was somehow set to 700.

Then, using either "drush cc all" or the "Clear all caches" button on the admin/config/development/performance page of your site, clear your site's entire cache. The key bit of info that I learned while debugging my own problem is that libraries caches the results of the libraries_load() function even when it fails to load the library. This seems like such a bad idea that I've posted an issue on their queue, asking them to change that.

Here's hoping that this works for you!

755 permissions on folders all the way through. The iCalcreator.class.php file is permission 644.

I restored the original date_ical.module file and then cleared the cache on the Performance page. No change. I was hoping it would be that easy, but no luck.

I can still try the patch if you can walk me through things with post #23 above.

I have a sinking feeling that this is going to be something where I've done something very stupid and I'm going to feel bad about wasting your time. Let's first make sure I've downloaded the correct file(s). The iCalcreator.class.php file I have is 3,218,114 in size. Is that correct? Do I need anything else?

The relevant thing regarding your iCalcreator.class.php file is if it has a line near the top that looks like this:

define( 'ICALCREATOR_VERSION', 'iCalcreator 2.20' );

The version detection code looks for that line (using a regex) in order to determine what version the file is. Considering that the patch to date_ical.module which hard-coded the version number didn't actually fix this, I'm sure you'll find that line just fine. The problem really seems to be that your apache user can't read the file at all, for some non-permissions-related reason.

As for your multi-server situation, I'm not entirely certain what you mean by "add-on domain". Could you describe what the direct children of the Drupal "sites" folders are in your setup? I'm going to guess that they look something like this:

/public_html
  sites
    production1
    production2
    production3
    all
    default
  drupal2
    sites
      dev1
      dev2
      all
      default

Is that right?

Sorry for taking awhile to respond. I'm juggling lots of issues with this Drupal 6 to Drupal 7 migration I'm attempting to do.

The server situation is now irrelevant. I moved one of the two sites I'm working on to another server altogether and isolated it from all other sites. I'm still getting the same problem with the library on that server. I can try the patch here now, but I think the problem lies with the file itself....

I just did a search in the iCalcreator.class.php file for the code you said should be there. It is not present within the file. There is not even anything when I search on

<?php

The entire file looks like it is coded in HTML. The vast majority of the lines in the file are like this:

<span id="L1" rel="#L1">1</span>
<span id="L2" rel="#L2">2</span>
<span id="L3" rel="#L3">3</span>
<span id="L4" rel="#L4">4</span>
<span id="L5" rel="#L5">5</span>
<span id="L6" rel="#L6">6</span>
<span id="L7" rel="#L7">7</span>
<span id="L8" rel="#L8">8</span>
<span id="L9" rel="#L9">9</span>

It continues like this for over 10000 lines of code all the way to

<span id="L10543" rel="#L10543">10543</span>

So I'm thinking we've found the problem here. Is there any way I can send you the file I have for you to determine if I have the wrong file? .php is not an allowed file type for attaching a file here. Should I put it in a zip file?

My goodness, that is very much the wrong file content. That is extremely bizarre... there's not even any file in the iCalcreator distribution package that looks like that. How did you download the library in the first place? It's possible that the instructions in Date iCal's README have become stale.

You'll need to re-download the library. You can get it directly from the author's GitHub repo here. Extract that zip, copy the iCalcreator.class.php file to the sites/all/libraries/iCalcreator folder, and you should stop seeing that error.

Ah HA! I think I figured out what you did wrong. I'm going to guess that you originally downloaded iCalcreator.class.php directly from the https://github.com/iCalcreator/iCalcreator page, using right-click and "Save As" (or your browser's equivalent). Unfortunately, while Github appears to make that file available for direct download like that, that link does not, in fact, lead directly to the file. It leads to a landing page for the repository's history of that file.

Honestly, though, this is my fault. I went back and looked at Date iCal's README.txt file, and the instructions were very unclear. I can totally see how someone unfamiliar with GutHub would make this mistake based on those instructions. I've completely re-written the instructions to prevent this problem from occurring again.

That was it. Problem solved on both sites now.

Yeah, now that you mention it, I did get confused with what to download. I remember that now. I downloaded a .zip file named iCalcreatorusing-2.20.zip at one point. After unzipping it, I didn't think that was what I needed and then downloaded the PHP file and probably did exactly what you said here. I now also remember thinking there was something different between the README.txt file and the instructions on the main module page here too, so you might want to cross-reference those. I decided to just put both things in the iCalcreator libraries directory (the php file and the unzipped .zip file contents), figuring one of them would be the right thing.

I haven't done anything at github.com before. I'm not at that level, but I hope to eventually learn.

Thanks a bunch for the effort to figure this out. I'm glad it turned out to be something very simple even though we took a bit to get to the destination. I just had that feeling that I didn't have the right file. Thanks too for your generosity in making sure I don't feel totally stupid. ;)

Glad to hear that everything's settled!

Ran into this problem as well, but immediately found the class file's name has been changed from "iCalcreator.class.php" to "iCalcreator.php"

You're the second user who's run into this problem since I fixed it in the dev release, so I clearly need to push this fix out to a new recommended release.

The problem is that iCalcreator's most recent version has been significantly refactored, and it is no longer compatible with Date iCal. You need to use iCalcreator v2.20.2 or earlier. I'll put out Date iCal 7.x-3.4 momentarily, which will have an updated makefile and README that explains how to get that version.

#33 worked for me.

In case anybody else gets here with similar problem, I downloaded v2.20.2 from github as zip, and had to rename icalcreator.class.php to iCalcreator.class.php. Seems the unzip command on my linux host was aliased to unzip -L, which changes all filenames to lowercase.

Wow, that seems like an incredibly bad idea for a Linux host to do, since most *nix OSes actually enforce case sensitivity in filenames.

NOTE TO ALL FUTURE GOOGLERS:
Date iCal 3.6 fixes the incompatibility with iCalcreator v2.22 and up. So if you're getting this error, it's probably not because of #33.