Last modified: 2010-01-17 14:00:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T24126, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 22126 - HTTP PUT method
HTTP PUT method
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-17 11:44 UTC by Liangent
Modified: 2010-01-17 14:00 UTC (History)
2 users (show)

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


Attachments

Description Liangent 2010-01-17 11:44:09 UTC
Can we accept PUT method to allow users to do editing in HTTP level?

For example:

PUT /w/index.php?title=Xxx&action=raw
 -> edit pages
PUT /w/index.php?title=Special%3AFilePath&file=Wiki.png
 -> upload (new) files
Comment 1 Max Semenik 2010-01-17 12:34:13 UTC
There's API that provides much richer features and allows to do that in a much more manageable way: http://www.mediawiki.org/wiki/API
Comment 2 Liangent 2010-01-17 12:45:12 UTC
Our external editor support currently exists together with API, then why not this?

I got this idea when I was editing an image on [[commons:]] with GIMP and had opened the image using "Open Location" command in GIMP but then I found it impossible to save my change to the server directly, and I think our current external editing implementation is ugly. This should be a replacement of the current external editing "protocol".
Comment 3 Max Semenik 2010-01-17 12:52:20 UTC
How is GIMP supposed to authenticate? How will it provide edit/upload summaries? Minor edit flags? How it will handle edit conflicts? When you realize that your way ofpage access should be able to accomplish all of that (and lots of other things), you'll realize that you'll have to reimplement our current API for a very little benefit, and that your GIMP will be unable to use it anyway.
Comment 4 Liangent 2010-01-17 12:56:27 UTC
Maybe not for GIMP, but I think our external editing solution is really ugly.
Comment 5 Chad H. 2010-01-17 12:58:57 UTC
(In reply to comment #4)
> Maybe not for GIMP, but I think our external editing solution is really ugly.
> 

Yes. The fact that we still support it is really ugly. External editors should be rewritten to use the API. If the API doesn't provide all features, open bugs to add the features. As far as I'm concerned, any sort of programmatic interface should NOT use index.php.
Comment 6 Sam Reed (reedy) 2010-01-17 13:54:48 UTC
Agreed.

With File uploads, and full editing capabilities (and no outstanding major bugs for the API), it's more than servicable for the functionality.

Granted, there are quite a few feature requests open, and a few bugs (non major) open, but still.

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


Navigation
Links