- Special:Preferences on repo1 is currently broken.
- client2 main page fails with "1054: Unknown column 'rev_sha1' in 'field list' (localhost)", presumably due to out of date schema.
- The behavior of the autocompletion in the gadget editor is confusing. When you manually type a valid script name, it is not accepted. Only the autocompleted script name is accepted. There are no clear success/failure indicators and invalid entry is quietly ignored.
- I've created a new gadget on repo1 and enabled sharing, but it does not appear in client1 shared gadget prefs.
- When viewing a gadget definition page, I would suggest making the default "edit" tab utilize the Special:Gadgets form editor, and stashing the raw JSON edit mode into the "additional actions" dropdown in Vector.
Topic on Talk:ResourceLoader/Version 2 Design Specification
Thanks for your bug reports :)
- The error on the preferences page was caused by a gadget name containing a space ("Invalid name 'wpgadget-Quick Recent Changes' passed to HTMLFormField::__construct"). I superficially fixed this case in r102409 but now the display name is weird (contains underscores). This is easily fixed by editing the title in the gadget manager, though.
- client2 main page is fixed now, had to run update.php on all DBs
- The new gadget not appearing in "Shared gadgets" is probably a cache invalidation bug, I'll look into that. I know that ForeignAPIGadgetRepo doesn't have any proper cache invalidation at all at this time
- That's an interesting suggestion. Timo?
I was right about cache invalidation:
- client1 uses ForeignDBGadgetRepo, so hasSharedCache should have been set to true, but it was set to false. I set it to true so it now exploits the fact that repo1 and client1 use the same memcached server (and can therefore access each other's cache entries; this is also the case for WMF wikis and ForeignDBFileRepo exploits this as well) instead of maintaining its own cache of what repo1 has
- client2 uses ForeignAPIGadgetRepo, which does not offer shared cache usage. So this one still relies on using a mirror cache, which never expires (!!!), and so client2 doesn't see any of the new gadgets on repo1. I'll fix the never-expires bug in the code
Cache expiry bugs are fixed now. Changes should show up immediately on wikis pulling through the DB (like client1) and with a delay of no more than 10 minutes on wikis pulling through the API (like client2).
\o/ Shared gadget setup confirmed working now.
As an aside, the localization cache on the prototype wikis is borked right now, leading to message values randomly not being loaded ("Some UI text" becomes "<somemessagekey>" every now and then). NeilK ran into this with commons.prototype, and it's affecting your test wikis as well. He took a shortcut and just set, I think, $wgLocalisationCacheConf['forceRecache']=true;
which seemed to at least suppress the issue.
I discovered and fixed this issue independently, using $wgLocalisationCacheConf['store'] = 'files';
. The default backend for LC in trunk is APC, which doesn't seem to be working very well for us.