courtly
courtly
courtly
courtly

Upcoming Events

San Francisco CiviCRM Meetup - February 8th, 2012
February 8th, 2012
Come meet others from the Bay Area who are interested in, using or developing (more...)

UK usergroup - London meetup
February 8th, 2012
Come and meet others from the UK that are using CiviCRM or are interested in (more...)

London user and administrator training
February 23rd, 2012
A comprehensive two day hands on training course covering the configuration, (more...)

CiviCRM London sprint Feb 2012
February 27th, 2012
Following the CiviCRM training here in London, we will have a CiviCRM code (more...)

Philadelphia - CiviCRM Meetup for Q1 2012
March 13th, 2012

UK South West - CiviCRM Meetup
March 20th, 2012
Come meet others from the Area who are interested in, using or developing for (more...)

[Bristol, UK] user and administrator training
March 21st, 2012
A comprehensive hands on training course covering the configuration, (more...)

San Francisco user and administrator training
March 29th, 2012
A comprehensive two day hands on training course covering the configuration, (more...)

CiviCRM Usability, Test and Code Sprint - San Francisco (March 2012)
March 29th, 2012
This usability, code and test sprint is targeted at CiviCRM users and (more...)

CiviCon 2012 San Francisco Bay Area - April 2nd 2012
April 2nd, 2012
CiviCon is THE annual event bringing together the people who use, develop, (more...)

CiviCRM Documentation, Test and Code Sprint - after CiviCon San Francisco (April 2012)
April 4th, 2012
This sprint is targeted at CiviCRM users and developers who want to work on (more...)

CiviCRM Components

Tools for engaging your supporters...

CiviContribute


CiviEvent


CiviMail


CiviMember


CiviReport


Attempt to reduce support issues ...

Not Just a Contact Database

These optional components give you more power to connect and engage your supporters.

  • civiCASE

  • Case management for clients and constituents.

  • civiEVENT

  • Online event registration and participant tracking.

  • civiMEMBER

  • Online signup and membership management.

  • civiMAIL

  • Personalized email blasts and newsletters.

  • civiREPORT

  • Report generation and template management.

March 25, 2008 - 17:20 — lobo

We monitor the forums quite a bit and are always trying to figure out how to reduce / minimize the repeated requests. Many a time my strong stance on refusing to fix something obvious delays a few fixes (yes, i'm learning all the time and hopefully improving and becoming a wee bit wiser). I got a bit tired and fed up of seeing the same requests over and over again, so earlier today I went on a spree and fixed (or attempted to fix) a few of the most common support requests or mistakes. Without further ado, here are the ones we fixed today:

  • Ensure that CiviCRM lets the user know that PHP5 is a requirement for CiviCRM. We need to detect this early enough and abort. Depending on the number of issues that arise with 5.0.x and 5.1.x we might make 5.2.x a requirement in v2.1.
  • Ensure that the MySQL version has InnoDB support. CiviCRM running under MyISAM is pretty much guaranteed to result in data integrity issues after a few days/weeks/months. However this check is quite expensive and we'd like to avoid it on every page load. As a compromise we've added it to the admin page section and abort out there. In good conscience, we cannot allow folks to run CiviCRM in a non-InnoDB environment
  • Joomla front end session support. This is a semi-hack, but hopefully it catches most cases. On any POST operation in the frontend, we ensure that the session is a decent size, if not, we abort and give a nice error message, with a link to the relevant documentation page.
  • SMTP problems. Another frequent occurence on the forums. Folks dont seem to understand the incredibly cryptic error message. So we've trapped most of the smtp errors and display a nice error message instead.

One thing which we have not yet addressed is the "invalid key" error message. We hope some of the above fixes addresses that, along with us suppressing the drupal cache automatically in v2.0. This also breaks our rule of not adding a lot of new code after the code freeze. Hopefully these error checks dont introduce a lot more bugs (though the software engineering laws do dictate that a few bugs will be introduced because of this).

To some extent, I do feel stupid and bad that we did not implement all of the above traps in a earlier release. We do hope to learn, be more aggressive, trap and display more understandable error messages. Not being the owner of a package is not an excuse anymore. Feel free to call us out on other things we can do a better job with.

( categories: )

Comments

V 2.01 ?

What code freeze ?
Is there already a code freeze on the next version ?

As for the no InnoDB rule. That's one thing to display a message on the admin "You are going to have problem, go upgrade/convert ASAP" and another to abort altogether. On the second, you introduce a regression on an existing install (not quite the same as not installing as for the PHP constraint)

From an admin point of view, In one case you're the solution on the other you're the problem. I'd suggest to go a softer road and not shoot at the poor admin guy, but warn him strongly that his going to shoot himself if he doesn't stop using myISAM

I was talking about v2.0 ..

We are making a fair amount of changes in v2.0 after a release. We tend to avoid doing any changes (to avoid the new code => new bugs => more changes cycle)

For 2.0, i've taken your advice and switched the error to a warning. We need to make it into a fatal error in 2.1 onwards and just avoid the whole mess of folks thinking they will get by with MyISAM (which many people have done)

lobo

not every site is live

I know that I am replying to an old posting, but I have another angle you might want to consider.

I was reviewing 2.0.5 for an existing Drupal installation. The LAMP server I use on my desktop (XAMPP) apparently does not has INNODB disabled. I am more interested in seeing how it works and before I put it online I would verify INNODB was available.

I am willing to take the risk of losing my data on this test site and I'm insulted by attempts to nanny me.

stopping Drupal cache pre CiviCRM 2.x

For people who haven't upgraded to 2.x and therefore don't have the build-in blocking of Drupal's cache. They might want to checkout http://drupal.org/project/cacheexclude which disables the cache on specified pages. I haven't used it myself, but it sounds like a match.

Testing SMTP settings

It'd be wonderful if there were a "send a test email now" button in the SMTP setup screen. (Not the one for CiviMail, but the regular one.) That would make it much easy to check that you got the settings right, simpler than say making a test contribution.