Unable to Connect to Google (Calendar API v2 is deprecated)

I think this is due to Google shutting down v2 of the API -- the full projection is no longer supported. This comes into play in line 7 of agenda.module.

This is also a problem in Drupal 6.

Same issue here on Drupal 6. Is this a simple matter of updating the line 7 of the agenda.module to point to a new feed? I tried this, and while it finds the XML, it is not parsing the data correctly.

Looks like just updating the feed reference won't work. The XML is generated using a new v3 format. The current agenda.module can't parse it correctly. I think this will require a fairly extensive reworking of the parsing code.

I am running 7.32 and have the same issue - how long does it normally take to have a patch or newer version developed ?

Does anybody know of an alternative module that can replicate what agenda does or similar ?

We are having the same issue, errors started around 11:09am EST.

Same issue here. Any indication how long before a fix is prepared?

As a stop-gap measure, try changing AGENDA_SOURCEPATTERN in agenda.module, from-
define('AGENDA_SOURCEPATTERN', 'http://www.google.com/calendar/feeds/%s/%s/full? ...

to-
define('AGENDA_SOURCEPATTERN', 'https://www.google.com/calendar/feeds/%s/%s/basic? ...

that should resurrect your calendar feed in some form, though the data is a bit mangled (uses 'now' as the start date & time, crams extra info into the description field), but depending on your application, it might be better than nothing.

Sorry, but suggestion #9 has no effect whatsoever.
Still the message: "No activities scheduled"

The new XML feed is:

https://www.google.com/calendar/feeds/%s/public/basic

However, the data is formatted differently, so Agenda cannot not parse it. I'm working on trying to update agenda.module using the migration guide that Google has made:

https://developers.google.com/google-apps/calendar/migration

Thanks to Seanatki for working on the code.
Meanwhile a quick and dirty alternative is to embed the google calendar(s) in a drupal block (or page) using the google calendar agenda view. You can find instructions on the lower part of this page. http://www.timeatlas.com/web_sites/general/use_google_calendars_to_displ...
Remember to set the width to fit your block or page. This works well for the site I manage.
This will work with multiple calendars.

Great, just as i'm launching a new site that is using this module as a prominent frontpage feature.
@seanatki Let me know if you need any help !

It seems to me that the https://www.google.com/calendar/feeds/%s/public/basic url that seanatki references in #12 is not useful, since it is pushing all data into an HTML formatted description.

It looks a lot like you will have to use something like oauth authentication before being able to get to 'the good stuff'.

I have succeeded by accessing the Google Agenda through some code, but it requires the help of a few other modules (f.i. the gauth module for easy authentication)
It's not returning XML anymore , so that part might need to be rewritten. However, leveraging the gauth module, you're getting objects for Google Calendar Events, that you could pretty easily parse into the array that is used in the Agenda module right now.

If you're only accessing public calendars, it would suffice to generate an API key for your server on the https://console.developers.google.com.

(This switch feels a bit like the Google Calendar API might turn into a paying API ... let's hope it won't come to that in the very near future)

I Have the same Problem.. seems to bee an Googe Calender APK-Problem they changed it from v2 to v3

Is there a solution yet ??

I experienced the same problem with the GCal Events module and attached a patch for its 6.x-1.4 release in #2376917: Use Google Calendar API v3 to construct Calendar address (v2 is deprecated). A patch here may need to follow a similar approach. Let me know if others think that is the way to go and would like my help patching this module.

@guschilds: i came across your patch already. It looks like the same thing i'm trying to do.
The Agenda module will need to switch from an XML feed to using the gauth module then.
Quite some remodelling that might need to be talked about with the module maintainer i would assume.
I'm up for helping out as i'm in need of the module working for my new site :)

Here is my first attempt at converting Agenda to use google API v3.
Thanks guschilds for making the patch to GCal Events and writing some quick instructions.

1. Navigate to https://code.google.com/apis/console.
2. Create a project and turn on the Calendar API (agree to the TOS).
3. Navigate to "Credentials" in the left menu under "APIs & auth".
4. Create a new key (server key) if you don't already have one.
5. Once it's created, it'll display on that page. Copy the "API KEY" and save it for later.
6. Get the Google API Client Library for PHP.
7. Navigate to https://github.com/google/google-api-php-client and clone the master branch.
8. Rename that cloned directory "google-api-php-client" and move it to sites/all/libraries.

After getting that set up apply the patch to the dev version of the agenda module and enter the google api on admin/config/services/agenda/googleapi

I have not had time to do a lot of testing yet, but I figured I would get this out there so others can try it out.
The debug option is all commented out. I did not have time to change that over.

Please do not apply this to a live website until it has been tested and reviewed by others.

@gooddesignusa : Looking good, it seems to work for me ...

Some comments on the patch:
- There's a few instances of needless whitespaces.
- I would move the Google API setting to a separate tab, looks cleaner than the two links we now have on the single settings page

I've done just that, new patch & interdiff attached.

Feel free to comment more if needed :)

Thanks oenie, I appreciate someone else taking a look. I worked some more today and got the debugging function to work and added a couple more fields. I want to test a bunch of events and make sure all day and multi-day events are rendering correctly. I will apply your changes and release another patch later tonight.

how to use the patch???
will there be a new vers. ??

So, this patch is only for the dev version?

Thank you so much!

I assume this patch is for the Drupal 7 version of the module. How hard would it be to make this work in the Drupal 6 version?

@Frief: https://www.drupal.org/patch/apply , links to your OS at the bottom
@stinky : it seems to apply on the 7.x-1.4 version as well.
@seanatki : that would be something to check with guschilds, i have no real D6 experience, sorry ...

Thanks oenie for your work on this! I'll apply the patch immediately.

oenie: Thanks for reworking the Google API settings page. It works much better now.

Spruitje: don't run the patch on a live website until we test it a little more. My first patch did not have everything set up yet. Some things were hard coded. I was just trying to get the ball rolling ASAP. If you applied the patch from oenie it will also have the same hard coded options since he just cleaned white spaces and moved the Google API settings page. This new patch now uses the settings from the block.

This new patch applies to the latest dev. It includes my first patch and the changes from oenie.
Additional things I've added in this patch:

• Debug function is now working with the new Google API.
• Added more debug text that will display settings used in API call.
• Added more fields that can be used when rendering the event. (Event ID, Hangout URL, Hangout Link, iCalUID, recurrence & Recurring Event ID)
• All the new fields will show up in the table on the debug page.
• Added edit link on debug page to edit the agenda block you are currently debugging.
• Set up google api override for agenda block - This could be used if you needed to use a different key to access a private calendar.
• Use agenda block timezone, start date, end date and max events when requesting events through Google API.
• Added drupal_set_message to show exception error message when request fails.

My next step is to try and see what is needed to get private calendars working. I have not fully tested that all the dates are rendering correctly yet. I quickly looked through the events I was pulling in and the dates were matching but please test that all different kinds of events are working correctly.

More information about event information can be found here:
https://developers.google.com/google-apps/calendar/v3/reference/events
https://developers.google.com/google-apps/calendar/concepts

Looks like private calendars need OAuth. I quickly looked around for an example but was unable to find one.
I think OAuth support should be a separate issue after we get this patch RTBC.

All day events are ending 1 day later. It seems to be on googles side.
Here is a response for an all day event for today.
https://gist.github.com/gooddesignusa/3af82b836960ea4e995e

I should have a fix later tonight.

@gooddesignusa
Thank you

First, thanks to everybody working on solving the problem.

I am using agenda on a shared host and having applied the last patch from gooddesignusa I got an open_basedir restriction message. This occurs because Google tries to store data in the server roots tmp directory, which will most propably not be accessible in most shared host environments. Solution to this: Find Config.php in your API library (in my case: /sites/all/libraries/google-api-php-client/src/Google) and change the Google_Cache_File path on line 94 (I hardcoded it to my temporary Drupal path).

Having done this I still get a Google Service Exception saying: (403) Access Not Configured. The API is not enabled for your project, or there is a per-IP or per-Referer restriction configured on your API key and the request does not match these restrictions. So the question is, do I really just have to turn on the Calendar API or is there anything else to do beyond, e.g. enter my site adress or the calendar ID which will access/use the API somewhere (I'm using a public calendar, not private).

Thanks for any advice.

Re-rolled patch with everything from before and the following changes / updates:

• Fixed all day events rendering 1 day later. I guess this is how google treats all day events. Start date is inclusive and end date is exclusive.
• Removed $event['recurrence']. Google does not return anything since we are using singleEvents & orderBy: startTime.
• Added $event['allday'] to _agenda_parse_event().
• Added new fields "creator email", "creator_displayName", "organizer email" & "organizer displayName"
• Fixed issue on debug page only showing edit link when loading calendar failed. Also added destination to link to redirect back to debug page after editing agenda block.
• Changed styling of debug table to not use overflow:auto and enabled sticky headers.

I did some more tests and all the event dates seem to be rendering on the correct days using the correct times.

Thank you for the good work so far gooddesignusa! And thanks for the concern, but fortunately I am using this module now only in a project in developing stage.

First I's like to say thank you to gooddesignusa for his good work!

After running the patches I allways get the error-message "Agenda: The google-api-php-client library was not found."

Searching on google I found a page, how to install the api-php-client, but none of the shown ways worked.

First I tried to put a php.ini into the drupal root-directory which contained the line

include_path = ".:/path/to/my/htdocs/google-api-php-client/src"

but it seems that my host does not parse the php.ini (phpinfo() did not mention it).

The second try was putting the line

set_include_path(get_include_path() . PATH_SEPARATOR . '/path/to/my/htdocs/google-api-php-client/src');

into each .php file in sites/all/modules/agenda an into agenda.module.

Does anyone have an idea, what I am doing wrong?

Before the update to API V3 I didn't need to install the google api php client.

@Mattin: You need the Libraries module installed.
The libraries module is used to determine the path to the google api php client.
If you put the folder in sites/all/libraries (the default folder where the Libraries module is looking) it should work.
The reason why you need it now, is it helps us with a bunch of the Boilerplate code for accessing the V3 API.
Otherwise, we would be writing extra code, that other modules wanting to access the Google API, had to write as well.
You needing to write extra include statements is hacking modules, which you shouldn't be doing unless you found a bug.

@brody1962:
In this screenshot you can see that the configuration for your Google API key specifies the IP your key is valid from.

You need this setting to include (or be set to) the IP of the server where your website is hosted. That's the IP that will be used to retrieve the data from Google, and thus the IP that will be used to do the authentication. I can imagine that, when you're debugging your site on your local machine, you will need to change the IP to that of your current IP address. Which, in the case of an Internet provider with dynamic IP address assignment, might switch every time you reboot your computer and the likes.
Can you see if the problem lies there ?

@gooddesignusa: My first critique on the first patch was going to be about the private calendars, but i started thinking and from what i can remember is that the Agenda module didn't allow private calendars in the first place. So that would actually be a new feature request. It's not so good practice to add that to a patch/bugfix IMHO.
When dealing with the oauth, i have done a few tests with that, that seem to be working. Leveraging the gauth module might come in handy (although that would include another dependency, which is not really needed) We could come back to it if you want.

Thanks everyone for testing the patch.

@oenie: I think it did support private calendars but I never actually used it. If you look on the agenda block settings page under the Google Calendar ID's field, the description reads "The IDs of each google calendar you want to display, each on a new line. For private calendars, include the access token after the email with a forward slash." Also check out http://cgit.drupalcode.org/agenda/tree/agenda.module?h=7.x-1.x#n437

I also agree that OAuth support should be a different issue. I just included the google api override field because I thought it would be needed later. I don't think it hurts to include it in this patch since it could be used to have different APIs for different calendars. Not sure why you would need that but it would work.

@Mattin: check out the instructions in comment #22 for how to set up the API.

Big thanks to gooddesignusa and oenie!!! My last problem was, that I didn't read #22 and so didn't create an API-key. Now everything works fine and I can continue to set up the site.

@oenie: Thanks for your hint. I've seen that settings page (your screenshot), but there it reads that all IPs are allowed. Therefore I thought that everything would work fine. So, what Google tries to tell me is: no IP allowed unless a specific IP is defined here ? As I am running my development site on the same shared host as the live website the problem is definitely not caused by a dynamically assigned IP adress. I'll give it a try and post the result. Thanks.

@brody1962 : I've started reading your message, and i've thought of something.
In the left menu at the Google Developers Console, there's the item Api & auths > APIs
There you specify for which of the Google APIs you want to be able to use your key.
You have to make sure that the Calendar API there is set to ON. (Step 2 in comment #22)
I got your error-message when i turned my Calendar API off , so i think that's where your problem lies.

@oenie: Do you think we should be adding hook_libraries_info for google-api-php-client like gauth does?

http://cgit.drupalcode.org/gauth/tree/gauth.module
http://cgit.drupalcode.org/gauth/tree/google-api-php-client.libraries.info

I'm also wondering if there are any security concerns with having the full Google API library. Should we at least delete the examples folder or is there a way to only have the server access those files and maybe block them to the public by using htaccess?

@oenie: The Calendar API has already been turned on, that was not the reason. But defining a certain IP adress solved the problem. So you really made my day, thanks a lot, especially as this is not a Google user forum.

If somebody intends to write more fine-grained instructions at the end of the whole process: After generating the server key (step 4 of comment #22) Google displays a settings page stating that all IPs are allowed to access the API using the key. This is misleading, obviously you must define dedicated IP(s), normally the host IP your website is running on.

I've just given maintainer access to guschilds, so hopefully we will have a resolution ASAP.

The work in this issue thus far has been committed into the 7.x-2.0-beta1 release.

Thanks to gooddesignusa, oenie, and everyone else who has provided feedback in this issue thus far. After #20, I asked aidanlis to be added as a maintainer so we could solve this problem. I was pleased to see gooddesignusa and others step up and use my effort in GCal Events to create a series of patches. Tonight I created a 7.x-2.x branch and committed the changes of each patch. From that branch I've created a 7.x-2.x-dev snapshot release, as well as the 7.x-2.0-beta1 release. Please note that after the first couple patches, I had to apply the changes manually so please test my work and verify that everything made it.

I've also added a note to the project page about all of this. As the note mentions, there is now a README with installation and configuration instructions. Using this module has gotten a lot more complicated with this API and we need to make sure these instructions are as clear as possible.

That being said, there is definitely more work to be done before the stable 7.x-2.0 release can be created and recommended. From what I can tell (let me know if I miss anything), that includes:

• Adding a hook_libraries_info() implementation, as mentioned in #43.
• A decision on how to handle private calendars. If that will be another issue (as hinted at in #39), please create that issue.
• Ensure all code has been converted and any unnecessary code gets removed.
• Finish updating all module documentation, including code comments.
• Thorough testing and feedback.

We also need to port the fix to the Drupal 6 version with a 6.x-2.x branch and release.

Please continue to contribute feedback and fixes while testing the progress of this issue. All patches are greatly appreciated!

Also, please create all new patches against the 7.x-2.x branch.

Updated the issue description with the current status of this thread using the issue summary template.

Thanks a lot guschilds, i was just writing a quick response, but you addressed almost all my questions in your long post.
I'll look into creating that issue on accessing the private calendars.
That will however introduce either a dependency on the gauth module, or extra settings in the Settings tab of our new configuration. (because of OAuth)
I've succeeded in accessing a private calendar already, so i could take a stab at solving that.

Your comment in #49 is for all future patches i assume ? Which means we will need a 7.x-1.4 version & a 7.x-2.x version of those patches ?

Let's get this show on the road :)

oenie,

Thanks for taking command of the private calendars. Maybe it becomes a submodule within the Agenda module so all users won't have to install the gauth module when most won't need it. I suppose that can be discussed in the new issue.

Please don't create future patches against 7.x-1.4. That will remain frozen and won't have any API v3 code. Once the 7.x-2.0 release is created, 7.x-1.4 will be deprecated. All future patches should be made against the current state of the 7.x-2.x branch. Does that make sense?

Thanks again!

OK, that makes perfect sense. I interpreted your #49 comment the wrong way. One of those rare moments that I'm reminded that English is not my native language :)

I've created #2380761: Accessing private calendars with the Calendar API v3 for a follow-up task on introducing access to private calendars in the 7.x-2.x branch.

Thanks to all the contributors to this issue so far; hope you can manage access to a private calendar in the near future because that is what we really need!

I submitted another patch in a different issue and SimpleTest was failing due to $event['published'] missing.
Published date is no longer available in v3 so I removed it from the test file.

Superb work by this community - many thanks. Now working again after updating to the 7.x-2.x-dev version of 2014-Nov-23.
http://dartingtonmorrismen.org.uk/

I ran into the test problem gooddesignusa mentions in #57 in #2386029: Undefined property: stdClass::$hangoutlinktext in _agenda_parse_event(). I've committed the patch to the 7.x-2.x branch (#59) and tests are no longer failing for that reason. Thanks, gooddesignusa.

Spruitje, please follow #2380761: Accessing private calendars with the Calendar API v3 for updates on private calendars (thanks to oenie for creating it). Any help is appreciated!

maranjo, Thanks for sharing your success and the link! Always cool to see our efforts in action.

(Updated issue summary to link to the private calendar issue.)

Since the API v2 was deprecated, the 7.x-2.0-beta1 release was made, and the instructions were written, releases for the google-api-php-client have been made that will allow us to specify a specific version of the API rather than instructing to clone master. The version (likely 1.1.2 seen here) should be specified in an implementation of hook_libraries_info() and the instructions in the README will need to be updated.

Soon after that hook is added we should get this issue wrapped up and closed, creating new issues for any individual bugs that arise.

Any progress on a solution for Drupal 6 ?

I am using Drupal 7 on one of my first sites I ever created. The Agenda module (which I love) was to be featured prominently. I had it working for a couple days before it crashed. I have read through this thread and have tried everything to get it working - including creating a Google Developer account, obtaining a API key, etc. Also, I have tried to implement other similar modules such as Gcal with no luck. Can anyone please help me?

I also am waiting to hear of progress on a solution for Drupal 6. I have a client website that uses this module prominently. Any progress for Drupal 6 fix?

libraryweb23,

Were you using the 7.x-2.0-beta1 release? Did you follow all of the steps in the README for Installation and Configuration? Could you provide information as to how far you've gotten and what results you have/haven't seen?

hsoubry and kriscarp,

The code of the Drupal 6 version of this module seems relatively similar to the Drupal 7 version. This should make it a bit easier to backport the work that has been done for the 7.x-2.x version. That being said, I have not had the need or time to do so since the API was deprecated. I'd be more than happy to help review/test patches and to give commit authorship to whoever creates them, but I can't make any promises on a timeline until someone takes the first step. Any chance you can help?

#34 references the error (403) Access Not Configured. The API is not enabled for your project, or there is a per-IP or per-Referer restriction configured on your API key and the request does not match these restrictions. I also get this error, even though I've created a new Google API project, enabled Calendar API, and created a public key enabling my server's IP address. And I'm referencing a public calendar. In the Google API usage, I see corresponding 40x errors.

I duplicated the same request on my browser, first adding my local computer's IP address to use the same public key and entered the same URL that the module used. Got the same access not configured response back.

So it's obviously not a module issue, assuming the URL it creates is valid. But I've followed all the instructions for enabling Google APIs. I've seen a few comments about allowing access to a server tmp directory, I don't know if that has anything to do with this. Wondering if anyone has had these issues.

UPDATE: Resolved! I don't know if I missed this, but to me the module directions were flawed (and the error from Google non-instructive). The module README.txt states: "Create a new key (server key) if you don't already have one." So under Public API access, I clicked "Create new Key" and then "Server". Using the generated key failed as described above. But if instead of "Server" I clicked "Browser", that generated a key that worked.

Bottom line, create a public "Browser" key, not a "Server" key.

Hi! Here is the patch for the drupal 6 last dev version(2013-Sep-30). I've made it based on 7.x-2.x-dev and made some own modifications according to drupal 6. Don't forget install module Libraries and Google API Client Library as described in README.txt

I have committed hook_requirements() and hook_libraries_info() to the module, as well as updating the README.txt. This should make it clearer on how install the Google API PHP Client library. It was also updated to use the 1.1.2 version rather than cloning the master branch.

The next step here will be to review, test, and commit khiminrm's 6.x patch from #68 (thanks, khiminrm!) and create a 6.x-2.x branch/release with it. Once that is done, we can get these out of beta and this transition will be over.

Thanks interesting, brian-paperfish. I've always used a server key and I think others have had success with it as well. I made a note in the Troubleshoot portion of the README that mentions browser keys working as well. I wonder what makes the difference...

I created the 6.x-2.x branch and applied khiminrm's patch in #68 to the 6.x-1.x branch. This is now working just the same as the 7.x-2.x branch. The only difference between the two are the commits made to 7.x-2.x after the patch. I've created #2430625: Add hook_requirements() and hook_libraries_info() to 6.x-2.x to address this difference.

The 7.x-2.x and 6.x-2.x beta releases are now working. Follow installation instructions in the README for help when using them. I will now be closing this issue as Fixed. Thanks to everyone who helped keep the module alive. Any additional issues or requests that come out of this work should be created as new, separate issues.