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:
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
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.
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.