Is Mutisite extension incompatible with 4.3.3?

[Eileen]

Hmm - I made that other extension publicly available the other day & installed it fine (it makes name fields read only for logged in users to prevent people renaming themselves when registering someone else).

But, that installed fine for me. Does your web user have write permission to the extensions dir? Does curl work fine?

[Eileen]

I took a look at this site for bcobin & the problem was with all extensions & caused by the following

1) the call to CRM_Core_Invoke::rebuildMenuAndCaches(TRUE); after the install completed was over-flowing some time limit or packet setting. I suspect that making some setting or other more generous may have helped as I have seen extension installations succeed despite having the following issues

2) There were some flaws in the civicrm_navigation table with entries having a parent_id from an incorrect domain. This bug has been fixed but multidomain sites who upgraded prior to the fix had the incorrect entries still. Fixing this & running the cacheclear before running the extension install was sufficient

3) because the above was failing to finish in time the api was trying (& failing) to rollback the transaction

4) drupal watchdog debugging was turned on - but some sql setting (perhaps max_packet_size but I think not) was caused logging the backtraces (when turned on) to watchdog to make mysql server 'go away'. I'll check with Chris B because we recently tweaked a few settings where this error was hitting us and one of them (not sure which) made the problem go away. I can't see what they were.

5) as an aside this is the sql I use to put missing entries for non domain-1 domains into the navigation tables since the upgrade script fails to look after the other domains
http://pastebin.com/GxD5gA7s
.
totten - I feel like the extension installation shouldn't fail if the clearcaches fails. In fact it actually does seem to do the install - or at least partially. I was going to suggest a try/catch - not sure if that works when the problem is an overload of server settings.

[Chris Burgess]

We were hitting SQL timeouts during upgrade, and used these settings to permit it to complete.

One of the issues I think is that CiviCRM maintains, but doesn't use, a DB connection to the CMS DB while it's running a long-running query to the CiviCRM DB. When it tries to connect to Drupal ten minutes later, the whole upgrader fails. This could be handled better.

Anyway - a big factor that permitted upgrade to succeed was some simple MySQL/PHP tweaks (prob not values you'd use in production, though).

In my.cnf,

Code: [Select]

max_allowed_packet = 64M
innodb_lock_wait_timeout = 600 # These two, I just multiplied by ten. YMMV.
wait_timeout = 1800

In php.info,

Code: [Select]

mysqli.reconnect = On

The other was to identify the long-running queries, and make those happen outside of the CiviCRM upgrader.

[bcobin]

Oh, silly me... now why didn't I think of that?

(Eileen - you simply amaze me.)

Thank you so much for looking into this, Eileen - I see that the extension is now happily enabled - and my gratitude knows no bounds. Hopefully all this will help - thanks SO much!