Attempt to reduce support issues ...

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.

Comments

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.

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.

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

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

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.