Hi,
As you may know there are currently two entry points in MediaWiki for javascript that wants to perform certain actions, action=ajax and api.php. Only the following features still use action=ajax: ajax watch, upload license preview and upload warnings check. I don't really see much point for two entry points where one would suffice. These could all be readily migrated to the API. However, this would mean that they will become unavailable if the API is disabled. Would that considered to be a problem?
Bryan
Bryan Tong Minh schrieb:
Hi,
As you may know there are currently two entry points in MediaWiki for javascript that wants to perform certain actions, action=ajax and api.php. Only the following features still use action=ajax: ajax watch, upload license preview and upload warnings check.
Don't forget extensions, like categorytree
-- daniel
On Sat, Jan 9, 2010 at 5:03 PM, Daniel Kinzler daniel@brightbyte.de wrote:
Bryan Tong Minh schrieb:
Hi,
As you may know there are currently two entry points in MediaWiki for javascript that wants to perform certain actions, action=ajax and api.php. Only the following features still use action=ajax: ajax watch, upload license preview and upload warnings check.
Don't forget extensions, like categorytree
I was not yet planning to kill action=ajax itself, just all functions that use. There is really no reason to break backwards compatibility here.
Bryan
2010/1/9 Daniel Kinzler daniel@brightbyte.de:
Oh, also: action=ajax supports http cache control. can this be done with the api yet?
Yes, with the maxage and smaxage parameters. AFAIK those are currently broken on Wikimedia, however, because Squid overrides the caching headers set by the API.
Roan Kattouw (Catrope)
Hi! I have an extension, which submits and renders polls defined with parser tag hooks. To have the article view properly re-generate dymanical content of tag, the typical approach is to use $parser->disableCache() in hook's function. However, in my case, the dynamically generated content is changed only when the poll was successfully submitted. When a user just views the page and makes no vote, the content doesn't change, thus, should be cached to improve the performance.
When I comment out $parser->disableCache() line, the content of page is not being updated, until one purges the page manually, which is very unhandy. So I used to have this call unconditionally, which is inefficient.
But, I am (with my limited knowledge of core) cannot find out, which calls should I make to invalidate parser cache and article cache in the extension's code on demand (conditionally). In the point of code, where the user had successfully POSTed voting data and the results of vote were stored in the DB, I try to execute the following methods:
$wgArticle->doPurge(); $wgTitle->invalidateCache();
then perform a a 302 redirect to show the same title with updated poll results.
However, when I comment out the $parser->disableCache() line, tag function output content is not being displayed at all. Like if there were no tags at the page.
What would you suggest? My only idea to implement GET action which will conditionally purge the page. I don't like such approach.
Thanks, Dmitriy
* Dmitriy Sintsov questpc@rambler.ru [Sat, 09 Jan 2010 23:12:30 +0300]: I've managed to do this by clearing "internal" memc key for the selected article and user object in ParserCache. Also, by setting a cookie before sending the redirect headers, so the next GET would know the data were posted. Still unsure how well would it work with every version / setup of MediaWiki out there. Let's hope the future changes of core won't interfere. Once, a long time ago, I've had a horrible issue with my security extension, when new "optimisation of userCan for readonly wikis" was introduced, I think in 1.12.. Dmitriy
On Sat, Jan 9, 2010 at 7:54 AM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
These could all be readily migrated to the API. However, this would mean that they will become unavailable if the API is disabled. Would that considered to be a problem?
No. At this point we should remove $wgEnableAPI and set it to true unconditionally. Other things already randomly depend on it, like watchlist RSS feeds.
On Sun, Jan 10, 2010 at 3:15 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
No. At this point we should remove $wgEnableAPI and set it to true unconditionally. Other things already randomly depend on it, like watchlist RSS feeds.
Enabling it has caused data to be leaked from private wikis in the past. Has that been fixed?
Angela
It seems to be fixed. I got the following message when I tried to get data from a private wiki via API.
<error code="readapidenied" info="You need read permission to use this module" xml:space="preserve">
On 1/10/10, Angela beesley@gmail.com wrote:
On Sun, Jan 10, 2010 at 3:15 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
No. At this point we should remove $wgEnableAPI and set it to true unconditionally. Other things already randomly depend on it, like watchlist RSS feeds.
Enabling it has caused data to be leaked from private wikis in the past. Has that been fixed?
Angela
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sun, Jan 10, 2010 at 3:52 AM, Angela beesley@gmail.com wrote:
Enabling it has caused data to be leaked from private wikis in the past. Has that been fixed?
I'd sure hope so. If not, I'm pretty sure the right thing to do is fix it, not just disable the feature. We could leave the option but say it's unsupported, but either way, it doesn't make much sense to me at this point to care what happens to people who disable the API. It's no longer just for bots.
2010/1/10 Angela beesley@gmail.com:
On Sun, Jan 10, 2010 at 3:15 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
No. At this point we should remove $wgEnableAPI and set it to true unconditionally. Other things already randomly depend on it, like watchlist RSS feeds.
Enabling it has caused data to be leaked from private wikis in the past. Has that been fixed?
Actually, the API is now overly restrictive on private wikis, disallowing all actions except login from users without read rights. This means they can't get certain data that they could get through the UI (like the content of whitelisted pages such as the main page, the /name/ of the main page, the wiki's name and content language, etc.). For most users this is annoying and should be fixed, but for operators of private wikis it's probably a comforting thought that, for now, even the most innocent requests to do anything but log in will be denied to users without read rights.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org