Calendar/Date Update

Posted by trista13 on May 4, 2011 at 7:42pm

Ok... So I posted the things that I attempted this morning here: http://groups.drupal.org/node/137409#comment-486629. Andy pointed out that having them as a comment on our meet-up will probably make it hard for other people to find. So, I tried with a fresh Drupal install (with absolutely only those four modules running) and ran into the SQL syntax error which I found was an issue here: http://drupal.org/node/1137538. There is a comment there about updating a line in the calendar module code that I did do, but it did not fix the error. I'm also getting this error that seems to be helpful, but I don't understand it:
* Debug:

  'Exception: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near \'AS field_data_field_date_
  FROM 
  node node
  LEFT JOIN field_data_field_date field_\' at line 1'

  in views_plugin_query_default->execute() (line 1362 of /home/clients/websites/w_tcal/public_html/tcal/sites/all/modules/views/plugins/views_plugin_query_default.inc).
* Debug:

  'Exception: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near \'AS field_data_field_date_
  FROM 
  node node
  LEFT JOIN field_data_field_date field_\' at line 1'

  in views_plugin_query_default->execute() (line 1362 of /home/clients/websites/w_tcal/public_html/tcal/sites/all/modules/views/plugins/views_plugin_query_default.inc).

It's all in green...

But, my conclusion... there are still lots of bugs with calendar and date. I was wondering, could it be possible that some of the issues are being caused by the servers where my site is hosted? I haven't tried it locally or on another server, so I was thinking that could be a problem too. (I'm desperate and willing to try anything!!)

Again, thanks for all the help! I'm really blown away by the willingness of everyone within this community to help each other succeed.

Comments

Do you know your server versions?

Posted by hajush on May 4, 2011 at 8:27pm

It was great hearing of your travails and I'm very hopeful you'll be a super Drupal calendar expert we can direct questions to later. About the SQL issues, it could possibly be a db problem. Will you post all the specific db versions. Wouldn't hurt to know the PHP version too. The whole phpinfo() result maybe even.

Thanks Harold for your kind

Posted by trista13 on May 9, 2011 at 2:32pm

Thanks Harold for your kind words... if I can answer one question about Drupal, I will be very proud of myself! So, the info from Bluehost is: Apache 2.2.17, PHP 5.2.17 and MySQL 5.1.56-community-log. I'm not sure what the phpinfo result is... Definitely a newb with database stuff.

Somebody holler when Calendar and Date are fixed!

Posted by opegasus on May 8, 2011 at 12:24am

I would love to use these puppies but I get the same errors as Trista13 does. I tired the line fix ($this->view->query->add_field($table, $delta_field); as suggested in one error forum but to no avail.

So if there is a place to set and get notifications when these modules actually work, please let me know about it.

P.S. I am on a different server than Trista13 is. Not saying it isn't a DB issue but...

Thank you so much for posting

Posted by trista13 on May 8, 2011 at 2:45am

Thank you so much for posting this! So glad to know it's not just me!! I'll post right away if I get anything to work.

Ditto!

Posted by opegasus on May 8, 2011 at 3:04am

No worries, we are among many who have bitten their nails to the quick on this per the threads I found. I too will post a solution if it presents it's self to me first. Hang in there!

SQL error fix from forums

Posted by Wendell Holmes on May 9, 2011 at 5:48pm

Christopher, the correct fix seems to be listed as:
$this->view->query->add_field($table, 'delta');

Not ..($table,$delta_field);

Also in the posted Query, there seems to be an out of place "." before the second AS on the second line.

Query

SELECT node.title AS node_title, node.nid AS nid, field_data_field_date.field_date_value AS field_data_field_date_field_date_value, field_data_field_date.field_date_value2 AS field_data_field_date_field_date_value2, field_data_field_date. AS field_data_field_date_, 'node' AS field_data_field_date_node_entity_type
FROM
{node} node
...

"Probably one of the most powerful laws in the Universe is the Law of Unintended Consequences"
Superfreakonomics by Leavitt & Dubner

Thanks Wendell...

Posted by opegasus on May 10, 2011 at 11:18pm

I haven't tried that yet. Hopefully soon...........

Getting closer!

Posted by opegasus on May 10, 2011 at 11:28pm

If you are subscribed to the issues Q's for Date and Calendar, then you already know.

Apparently Views may have been the culprit here? I just updated to the latest views (dev) and now at least my view (Calendar) shows the correct 'type'. Still yet to conquer is the display as it only shows the top navigation and will not show the calendar view (current month) unless the actual month is passed in to the URL.

Ergo: if I type http://coworkingmontana.org/calendar/

I only get the Nav bar. (Year | Month | Week | Day

If I type in: http://coworkingmontana.org/calendar/2011-05

At least I get the Content type (Events) created. Still get to loose the updated printing...

Anyone having luck with this?

Patch

Posted by scottrouse on May 11, 2011 at 9:18pm

Have you tried the patch I submitted here: http://drupal.org/node/1137538#comment-4446838

-Scott

Scott Rouse
http://about.me/scott.rouse

The issue of patches..

Posted by opegasus on May 12, 2011 at 1:37pm

...eludes me frankly. I have searched for how and where to apply patches to no avail. So out of 6,555 files (approx) I would have no clue where or how to apply it?

Does one add it to the core files (which one) or the module files (which one) and where in the code does one do this?

OR is there a special module for applying patches...

As you can see, without any starter knowledge on this subject the possibilities are near endless.

If there is a link on how-where, would you please share it?

~Christopher

Let me see if I can help...

Posted by scottrouse on May 12, 2011 at 3:21pm

The official Drupal docs on applying a patch are located here: http://drupal.org/patch/apply

Let me see if I can explain it, though. A "patch" file is simply a set of machine-readable instructions (somewhat human-readable, also) that tell a computer which changes to make to which files. That's really all there is to that. There are commands we can run (usually at the command line) that will "apply" that patch to the desired files. That's what the http://drupal.org/patch/apply page talks about.

Sometimes, however, it's just as easy to look at the patch file ourselves (it's just a text file) and make the necessary changes manually. Let's look at the patch file I submitted at http://drupal.org/node/1137538#comment-4446838.

If you download the patch file and look at it in a text editor (or just in your browser, for that matter), you'll see that it looks like this:

diff --git a/includes/calendar_plugin_style.inc b/includes/calendar_plugin_style.inc
index d7b33ac..929d6f3 100644
--- a/includes/calendar_plugin_style.inc
+++ b/includes/calendar_plugin_style.inc
@@ -184,7 +184,7 @@ class calendar_plugin_style extends views_plugin_style {
               $this->view->query->add_field($table, $base_field . 'value2');
             }
             if (!empty($info['delta_field']) && !array_key_exists($table . '' . $info['delta_field'], $this->view->query->fields)) {
-              $this->view->query->add_field($table, $delta_field);
+              $this->view->query->add_field($table, 'delta');
             }
           }  
         }

I'm going to add line numbers in this one for easier reference. Keep in mind the line numbers aren't part of the original patch file. I've just added them for clarity.

1 diff --git a/includes/calendar_plugin_style.inc b/includes/calendar_plugin_style.inc
2 index d7b33ac..929d6f3 100644
3 --- a/includes/calendar_plugin_style.inc
4 +++ b/includes/calendar_plugin_style.inc
5 @@ -184,7 +184,7 @@ class calendar_plugin_style extends views_plugin_style {
6                $this->view->query->add_field($table, $base_field . 'value2');
7              }
8             if (!empty($info['delta_field']) && !array_key_exists($table . '' . $info['delta_field'], $this->view->query->fields)) {
9 -              $this->view->query->add_field($table, $delta_field);
10 +              $this->view->query->add_field($table, 'delta');
11              }
12            }  
13          }

Breaking it down line-by-line...

Line 1 basically shows the command I ran to generate the patch file. I'm using the version control system Git. (More on patches with Git at http://drupal.org/patch.) We can ignore that line.

Line 2 just shows the "commit numbers" for the two Git commits I'm comparing. We can safely ignore that line.

Line 3 shows the name and location (relative to the root of this module) of the old (original) version of the file and line 4 shows the same info for the new (changed) version of the file. In most cases (as in this one), they are the same file. My patch was submitted as an issue for the Calendar module. One could then (correctly) assume that the file paths in the patch are relative to the root of the Calendar module. So, the file we're patching is in the Calendar module files at calendar/includes/calendar_plugin_style.inc. Back up a copy of your Calendar module, then go find that file (calendar/includes/calendar_plugin_style.inc) and open it in your favorite IDE or text editor.

Line 5 starts with some line numbers of the calendar/includes/calendar_plugin_style.inc file. It's telling us that we're going to be looking at lines 184-187. The -184,7 +184,7 indicates that the line numbers are staying the same from the old version to the new version (we're actually only changing one "word" in the code). Line 5 then continues with some of the code from the file to give us context for our changes.

Lines 6, 7, and 8 continue to give us context. There's no - or + in front of those lines to indicate that we should be changing something.

That change, however, comes on lines 9 and 10. The - tells us to remove that line of code in the file and replace it with line 10 (indicated by the +).

Lines 11, 12, and 13 just finish with some context of unchanged code.

So, basically this patch is telling us we can open up calendar/includes/calendar_plugin_style.inc and replace line 187 of that file ($this->view->query->add_field($table, $delta_field);) with $this->view->query->add_field($table, 'delta');. That's it. Save it, clear your cache, and the module has been patched.

A few caveats... This was a very simple patch file. The reason we have patch files rather than just saying "replace line 184 with xxx code" is that the process would be very time consuming and complicated for humans when many lines of code are changing. Computers, however, can do it almost instantly. Learning to read a patch file to understand the changes is important, but it's also important to learn how to apply the patch automatically.

On another note, you have to remember that now you're dealing with a custom/hacked/patched version of a contributed module. It is no longer in sync with the Drupal.org repository. If there's an update to the module, your patch work will be overwritten unless, of course, the patch is "committed" to the main code repository by one of the module's maintainers. That's why I set the status of that issue to "needs review." In indicates to the maintainers, and the Drupal community at large, that the patch should be tested thoroughly. Once the patch has been tested, the status can be changed to "reviewed & tested by the community" (sometimes abbreviated "RTBC"). If the maintainer accepts the patch, he or she will commit to the latest dev release of the module and, eventually, include it in the next stable release. They'll also usually set the issue status to "fixed".

Scott Rouse
http://about.me/scott.rouse

AWESOME!

Posted by trista13 on May 12, 2011 at 6:28pm

Thanks so much Scott for this detailed post. I haven't attempted a patch and I was unsure of exactly what is it is/does. Again, I'm blown away by this group's shared knowledge and how willing you all are to share what you know to help those of us who aren't sure!

Agreed!

Posted by opegasus on May 12, 2011 at 6:52pm

Totally awesome how Scott and Andy watch over the flock!

Precision explenation.

Posted by opegasus on May 13, 2011 at 3:27pm

Thanks Scott for the line X line explanation of how a patch is created, the ways to implement and how to read a patch file. You made it almost painless.

Scott, Thanks so much for

Posted by Wendell Holmes on May 13, 2011 at 8:05pm

Scott,

Thanks so much for taking the time to give such a thorough answer to Christoper's question. I'm quite sure there are lots of us out here watching and learning besides just him. And thanks, Christopher, for being the one to step up and ask the questions

"Probably one of the most powerful laws in the Universe is the Law of Unintended Consequences"
Superfreakonomics by Leavitt & Dubner

Of course

Posted by scottrouse on May 13, 2011 at 8:08pm

You're very welcome, Wendell. I hope it's helpful to many people.

-Scott

Scott Rouse
http://about.me/scott.rouse

Thanks Wendell...

Posted by opegasus on May 13, 2011 at 8:29pm

...a lot of self debate on whether to put it out there...newbie fears, all unfounded of course but there, none the less.

Hopefully I have learned two invaluable lessons here today. :-D

Calendar Dev Updated

Posted by scottrouse on May 25, 2011 at 8:27pm

FYI:

The patch for Issue #1137538 has been committed to the dev release of Calendar by KarenS. That should solve many of the errors we discussed in this thread.

Scott Rouse
http://about.me/scott.rouse

w00t!

Posted by laken on May 25, 2011 at 8:55pm

Yup, way to go Scott for not only helping our local group solve these problems, but helping get it fixed for the whole Drupal community! Module maintainers like KarenS are very busy and seemingly little things like what you did can make all the difference in getting stuff done. So thanks!

Yay!

Posted by trista13 on May 25, 2011 at 8:37pm

Thanks Scott for putting the patch out there so it could be incorporated!

Echo that!

Posted by opegasus on May 25, 2011 at 9:29pm

Thanks Scott from all of us WORLD WIDE!

You get and EXTRA burrito this week!

Happy to Help

Posted by scottrouse on May 25, 2011 at 9:37pm

Happy to help. Now time to update all my core installs: http://drupal.org/node/1168756

Ugh.

Scott Rouse
http://about.me/scott.rouse

Yep update night last night..

Posted by opegasus on May 26, 2011 at 3:46pm

2 out of three updated and so far, no issues. Of course I haven't delved deeply into the sites but figured safety first, issues later.

It always concerns me to see that long list of errors when updating sites or modules but I am learning to not freak out and just ignore them, move on.

Core Update

Posted by scottrouse on May 26, 2011 at 3:51pm

Good to hear. I've not encountered any issues with these core updates. The core itself is well tested and should update without a hitch. Sometimes, however, there will be an errant contributed module or two that seems to react strangely.

Everyone here feeling ok about the process, or should I put together a quick article on updating core?

Scott Rouse
http://about.me/scott.rouse

Clarification:

Posted by opegasus on May 26, 2011 at 4:27pm

I didn't communicate that last part (above) well. Meaning that I get errors right after running PHP updates ( haven't tried upgrades ie: D6 to D7) on Core and Modules as a return after the script(s) run. The errors usually point to modules, true.

Unless the error duplicates along the way I 'typically' ignore them. Just like we did in class. Plus nearly all the video tutorials I watch/watched showed those folks with errors and they ignored them. I am referring to the errors right after updates/upgrades, not the persistent errors one gets.

I am cool with updates/upgrades. Issue I have is to remember to read the TXT README files before I do any updates/upgrades because they are quite helpful and sometimes the Developer has a twist in the process that would definitely screw up the site or module(s) function. As an example: 'You must disable the module before updating'. I have been tripped up in the past, luckily it wasn't a huge deal other than my ego getting a slap and time to correct the faulty (by me) update.

D6 -> D7

Posted by scottrouse on May 26, 2011 at 4:57pm

I've not upgraded a production site from Drupal 6 to Drupal 7 either. I was talking about updating core code from 7.0 to 7.2 or 6.20 to 6.22.

Scott Rouse
http://about.me/scott.rouse

Yes I was/am aware that

Posted by opegasus on May 26, 2011 at 5:37pm

you were discussing the same versions. I wanted to be clear that I was discussing inside one development and not a full porting from one full branch (ie: Drupal 6) to another full branch (Drupal 7).

Especially early on I used to read threads like these (not these) and it wasn't clear by the posting person what the delineation was and I left those forums almost more confused than when I entered. So I promised my self to ensure I specified exactly what I was referring to and even what I am not referring to so that someone new to Drupal would be closer to an understanding. I don't always succeed but I nearly always re-read my post (preview) before I submit/commit it to see if someone new would get lost reading my descriptions and adjust accordingly.

Some tips for updating core

Posted by trista13 on May 28, 2011 at 9:19pm

Hi Scott,

I made the assumption (you know what they say about assuming!!) that updating Drupal core worked the same way as updating modules. This afternoon I decided to get ready to do the update tomorrow and realized that is not how it works. I've looked through drupal.org for an explanation of updating core and I haven't found anything that makes sense (except if you're using drush). Would you mind going over the process briefly?

Thanks!

Trista a place to start...

Posted by opegasus on May 28, 2011 at 9:40pm

..is opening up a copy of the Drupal core files from the latest update. Next in that top directory

(see attached jpeg/screenshot) in this level you will see a README file (highlighted in the screenshot). Open that in Notepad ++ (regular Notepad just wraps all the text together) and read there on where to get help on various possible actions.

All the upgrades (core and most module developers) have a README or an UPGRADE txt file and that is where we read about upgrades, any issues we need to be concerned about, etc. I say most of the time and most issues as not all developers take the time to create these files or update them all the time with items we may encounter.

Cheers,

~Christopher

Darn Reply section doesn't have a file attach so I am including the file contents below.

(UPGRADE.txt)

INTRODUCTION

This document describes how to:

Update your Drupal site from one minor 7.x version to another minor 7.x
version; for example, from 7.8 to 7.9, or from 7.6 to 7.10.
Upgrade your Drupal site's major version from 6.x to 7.x.

First steps and definitions:

If you are upgrading to Drupal version x.y, then x is known as the major
version number, and y is known as the minor version number. The download
file will be named drupal-x.y.tar.gz (or drupal-x.y.zip).
All directories mentioned in this document are relative to the directory of
your Drupal installation.
Make a full backup of all files, directories, and your database(s) before
starting, and save it outside your Drupal installation directory.
Instructions may be found at http://drupal.org/upgrade/backing-up-the-db
It is wise to try an update or upgrade on a test copy of your site before
applying it to your live site. Even minor updates can cause your site's
behavior to change.

UPGRADE PROBLEMS

If you encounter errors during this process,

Note any error messages you see.
Restore your site to its previous state, using the file and database backups
you created before you started the upgrade process. Do not attempt to do
further upgrades on a site that had update problems.
Consult one of the support options listed on http://drupal.org/support

More in-depth information on upgrading can be found at http://drupal.org/upgrade

MINOR VERSION UPDATES

To update from one minor 7.x version of Drupal to any later 7.x version, after
following the instructions in the INTRODUCTION section at the top of this file:

Log in as a user with the permission "Administer software updates".
Go to Administration > Configuration > Development > Maintenance mode.
Enable the "Put site into maintenance mode" checkbox and save the
configuration.
Remove all old core files and directories, except for the 'sites' directory
and any custom files you added elsewhere.

If you made modifications to files like .htaccess or robots.txt, you will
need to re-apply them from your backup, after the new files are in place.

Sometimes an update includes changes to settings.php (this will be noted in
the release announcement). If that's the case, replace your old settings.php
with the new one, and copy the site-specific entries (especially the lines
giving the database name, user, and password) from the old settings.php to
the new settings.php.
Download the latest Drupal 7.x release from http://drupal.org to a
directory outside of your web root. Extract the archive and copy the files
into your Drupal directory.

On a typical Unix/Linux command line, use the following commands to download
and extract:

wget http://drupal.org/files/projects/drupal-x.y.tar.gz
tar -zxvf drupal-x.y.tar.gz

This creates a new directory drupal-x.y/ containing all Drupal files and
directories. Copy the files into your Drupal installation directory:

cp -R drupal-x.y/* drupal-x.y/.htaccess /path/to/your/installation

If you do not have command line access to your server, download the archive
from http://drupal.org using your web browser, extract it, and then use an
FTP client to upload the files to your web root.
Re-apply any modifications to files such as .htaccess or robots.txt.
Run update.php by visiting http://www.example.com/update.php (replace
www.example.com with your domain name). This will update the core database
tables.

If you are unable to access update.php do the following:

Open settings.php with a text editor.
Find the line that says:
$update_free_access = FALSE;
Change it into:
$update_free_access = TRUE;
Once the upgrade is done, $update_free_access must be reverted to FALSE.

Go to Administration > Reports > Status report. Verify that everything is
working as expected.
Ensure that $update_free_access is FALSE in settings.php.
Go to Administration > Configuration > Development > Maintenance mode.
Disable the "Put site into maintenance mode" checkbox and save the
configuration.

MAJOR VERSION UPGRADE

To upgrade from a previous major version of Drupal to Drupal 7.x, after
following the instructions in the INTRODUCTION section at the top of this file:

Check on the Drupal 7 status of your contributed and custom modules and
themes. See http://drupal.org/node/948216 for information on upgrading
contributed modules and themes. See http://drupal.org/node/895314 for a list
of modules that have been moved into core for Drupal 7, and instructions on
how to update them. See http://drupal.org/update/modules for information on
how to update your custom modules, and http://drupal.org/update/theme for
custom themes.

You may decide at this point that you cannot upgrade your site, because
needed modules or themes are not ready for Drupal 7.
Update to the latest available version of Drupal 6.x (if your current version
is Drupal 5.x, you have to upgrade to 6.x first). If you need to update,
download Drupal 6.x and follow the instructions in its UPGRADE.txt. This
document only applies for upgrades from 6.x to 7.x.
Log in as user ID 1 (the site maintenance user).
Go to Administer > Site configuration > Site maintenance. Select
"Off-line" and save the configuration.
Go to Administer > Site building > Themes. Enable "Garland" and select it as
the default theme.
Go to Administer > Site building > Modules. Disable all modules that are not
listed under "Core - required" or "Core - optional". It is possible that some
modules cannot be disabled, because others depend on them. Repeat this step
until all non-core modules are disabled.

If you know that you will not re-enable some modules for Drupal 7.x and you
no longer need their data, then you can uninstall them under the Uninstall
tab after disabling them.
On the command line or in your FTP client, remove the file

sites/default/default.settings.php
Remove all old core files and directories, except for the 'sites' directory
and any custom files you added elsewhere.

If you made modifications to files like .htaccess or robots.txt, you will
need to re-apply them from your backup, after the new files are in place.
If you uninstalled any modules, remove them from the sites/all/modules and
other sites/*/modules directories. Leave other modules in place, even though
they are incompatible with Drupal 7.x.
Download the latest Drupal 7.x release from http://drupal.org to a
directory outside of your web root. Extract the archive and copy the files
into your Drupal directory.

On a typical Unix/Linux command line, use the following commands to download
and extract:

wget http://drupal.org/files/projects/drupal-x.y.tar.gz
tar -zxvf drupal-x.y.tar.gz

This creates a new directory drupal-x.y/ containing all Drupal files and
directories. Copy the files into your Drupal installation directory:

cp -R drupal-x.y/* drupal-x.y/.htaccess /path/to/your/installation

If you do not have command line access to your server, download the archive
from http://drupal.org using your web browser, extract it, and then use an
FTP client to upload the files to your web root.
Re-apply any modifications to files such as .htaccess or robots.txt.
Make your settings.php file writeable, so that the update process can
convert it to the format of Drupal 7.x. settings.php is usually located in

sites/default/settings.php
Run update.php by visiting http://www.example.com/update.php (replace
www.example.com with your domain name). This will update the core database
tables.

If you are unable to access update.php do the following:

Open settings.php with a text editor.
Find the line that says:
$update_free_access = FALSE;
Change it into:
$update_free_access = TRUE;
Once the upgrade is done, $update_free_access must be reverted to FALSE.

Backup your database after the core upgrade has run.
Replace and update your non-core modules and themes, following the
procedures at http://drupal.org/node/948216
Go to Administration > Reports > Status report. Verify that everything is
working as expected.
Ensure that $update_free_access is FALSE in settings.php.
Go to Administration > Configuration > Development > Maintenance mode.
Disable the "Put site into maintenance mode" checkbox and save the
configuration.

To get started with Drupal 7 administration, visit
http://drupal.org/getting-started/7/admin

Updating core via FTP (no command-line)

Posted by eporama on May 29, 2011 at 1:36am

The key to updating core is that if you've avoided hacking core then everything that makes your site unique is in the /sites folder. Keep that folder in tact and uploading a new version of Drupal with your /sites directory should be all you need to do (plus visiting update.php).

I wrote up another blog post about this with some more detail. Hopefully it might help.

http://eporama.com/ramblings/updating-drupal-core-without-command-line-t...

Erik's Got It

Posted by scottrouse on May 29, 2011 at 4:56pm

I couldn't have said it much better than Erik. Check out his helpful post. The only thing I'd add is to make sure and copy over any other files you may have customized. One of the most common is the .htaccess file. It frequently gets changed for various hosting configurations.

I'd elaborate, but I'm in the middle of the woods this weekend.

Scott Rouse
http://about.me/scott.rouse

Upcoming Block being weird

Posted by trista13 on May 31, 2011 at 3:06pm

So, I did finally get the calendar working, but for some reason my upcoming block is only showing one event (a repeating event) five times (and there are other events that fall between the repeating dates of this event). I know that a few of you have had success with calendar/date and I was wondering if this included the upcoming block.

Thanks!

Views Configuration

Posted by scottrouse on May 31, 2011 at 3:13pm

I'd have to take a look at your Views configuration for that block. The issues you're having with the upcoming block are fairly unrelated to any issues on the full Calendar page. The "Upcoming" View is a straightforward list of nodes filtered and sorted by a date field.

If you need to resolve it soon, hit me up on Skype (scott_rouse) or Jabber (scottwrouse@gmail.com), and I'll see if I can talk you through it.

Scott Rouse
http://about.me/scott.rouse

Comments

INTRODUCTION

UPGRADE PROBLEMS

MINOR VERSION UPDATES

MAJOR VERSION UPGRADE

Group organizers

New groups

Group notifications