Last modified: 2009-08-13 20:45:29 UTC
At translatewiki.net $wgEnableJS2system = true; $wgEnableScriptLoader = true; $wgAllowCopyUploads = true; 1. Go to Special:Upload 1b. notice how none of the fogg, messages work, showing like <fogg-use_latest_fox><fogg-for_improved_uplods><fogg-please_install> 2. Input a valid url 3. the dialog pops out 4. wait, nothing happens, progress stays at zero 5. click the close icon 6. confirmation dialog with ok and cancel: ok -> nothing happens; cancel: the blue dialog disappears (button actions switched?)
Posssibly related from the error log: [13:02:18] -rakkaus:#mediawiki-i18n- [06-Aug-2009 10:02:19] PHP Notice: Undefined variable: options in /var/www/w/maintenance/http_session_download.php on line 44
Which could indicate possible regression in r54426.
FIXED in r54514
The warnings are gone, but all the other problems remain.
Michael, can you check this out? Thanks!
in r54790 copy by url is working for me locally. Is $wgPhpCli set the correct path? Is something tricky being done with the language file? <fogg-use_latest_fox><fogg-for_improved_uplods><fogg-please_install> are in mwEmbed.i18n.php , does /w/mwScriptLoader.php?class=mvFirefogg&debug=true list the language messages?
So there does appear to be a problem with memcahced... anyone have any idea why php sessions would work while memcached sessions don't. (this is when running php in a background shell exec passing the session_id as a command line argument)
Is translatewiki using memcached or the APC local cache? The latter may not be accessible to the spawned command-line process...
just running $wgSessionsInMemcached = true; locally and its not working either. Any ideas on this one? ... saving state to a db table does not sound fun ... but I don't see much other options yet... is there any tricky way to get the command line version to get access to the memchached session?
Well, this is suspicious to me... in Setup.php: if( !$wgCommandLineMode && ( $wgRequest->checkSessionCookie() || isset( $_COOKIE[$wgCookiePrefix.'Token'] ) ) ) { wfIncrStats( 'request_with_session' ); wfSetupSession(); $wgSessionStarted = true; } else { wfIncrStats( 'request_without_session' ); $wgSessionStarted = false; } Is the session stuff getting set up properly when we're on the command line?
so it appears to have been a combination of not using wfSetupSession to setup memchahed handler and the use of session_start and session_write_close that where incompatible with memchached non-blocking session handling (but without them php session handling blocks and does not work for background updates)....This was a bit tricky to track-down in the background php process but "should work" with r54965 Tested with both php based handler and memcached handler.
