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.
