Last modified: 2011-01-10 18:10:01 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 26650 - Remove $wgAPICacheHelp in favour of $wgAPICacheHelpTimeout
Remove $wgAPICacheHelp in favour of $wgAPICacheHelpTimeout
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.17.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks: global-vars
  Show dependency treegraph
 
Reported: 2011-01-10 04:56 UTC by Sam Reed (reedy)
Modified: 2011-01-10 18:10 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sam Reed (reedy) 2011-01-10 04:56:48 UTC
Setting $wgAPICacheHelpTimeout = 0 should have the same effect as toggling $wgAPICacheHelp (boolean). i.e. if we set the timeout to 0, it won't be cached at all, if we set it to > 0, it will be cached.

No real need for the boolean to do this, per Niklas on http://www.mediawiki.org/wiki/Special:Code/MediaWiki/56559#c4072

Added in r56559, r56091

Not quite sure what the process of disabling globals is...

Do we stop listening to the on/off in the main code, but only make it have any effect in the setup phases...

ie if $wgApiCacheHelp = false, $wgApiCacheHelpTimeout = 0...
Comment 1 Roan Kattouw 2011-01-10 13:57:51 UTC
Or just don't rename the global, just change its purpose? We can detect whether it's set to a boolean or a number and act accordingly.
Comment 2 Roan Kattouw 2011-01-10 14:00:30 UTC
(In reply to comment #1)
> Or just don't rename the global, just change its purpose? We can detect whether
> it's set to a boolean or a number and act accordingly.
Or wait, I'm sorry, I misunderstood. I missed the fact that $wgApiCacheHelpTimeout was already there.

Due to register_globals considerations we have to either keep the old var around in DefaultSettings or stop listening for it. Neither sounds particularly nice, so I think the best solution is to phase it out gradually (mark as deprecated now, but still define it in DS and listen to it for a while longer, then kill it in a later release).
Comment 3 Sam Reed (reedy) 2011-01-10 17:44:37 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Or just don't rename the global, just change its purpose? We can detect whether
> > it's set to a boolean or a number and act accordingly.
> Or wait, I'm sorry, I misunderstood. I missed the fact that
> $wgApiCacheHelpTimeout was already there.
> 
> Due to register_globals considerations we have to either keep the old var
> around in DefaultSettings or stop listening for it. Neither sounds particularly
> nice, so I think the best solution is to phase it out gradually (mark as
> deprecated now, but still define it in DS and listen to it for a while longer,
> then kill it in a later release).


Yeah, exactly. I'll put a rough patch together for a proposal for this, and see what you think...
Comment 4 Chad H. 2011-01-10 17:48:10 UTC
Methods used in extensions need to be phased out
Really old or widely-used globals need to be phased out.

This doesn't need to be phased out. Just remove the boolean, repurpose the value of 0 for $wgApiCacheHelpTimeout and note it in RELEASE-NOTES config changes. I doubt this is getting massive use outside of WMF.
Comment 5 Sam Reed (reedy) 2011-01-10 17:51:11 UTC
Hmm, probably true, WMF/MW developers. And of that, there's probably only a minority of us that do anything.

Is it worth backporting to 1.17 to kill it earlier? It was only introduced in 1.16...
Comment 6 Sam Reed (reedy) 2011-01-10 18:10:01 UTC
Removed in r79942

Re: 1.17

<^demon> Reedy: If it applies cleanly to 1.17, I say go for it.

I'll leave the call of whether to backport this upto Roan

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links