Last modified: 2010-01-17 14:00:20 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 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