The upload API call can sometimes return warnings based on the `watch` parameter, which has been deprecated in favor of `watchlist`. When it does, it returns two XML nodes named `<upload>`, and `check-api-response` was only looking at the first one. On my mediawiki (1.19.1), the XML comes back like: `<api><warnings><upload>...</upload></warnings><upload>...</upload></api>` We care about the data in the second `<upload>` node. This patch says if there are two `<upload>` nodes found, use the second one. I'm not sure what's the right thing to do here; I could amend cl-mediawiki to follow the mediawiki API, remove `:watch` and add `:watchlist`, but that drops support for older mediawiki versions, and it seems constraining to limit cl-mediawiki to recent mediawiki versions only.
Uses rvsection as returned by list-page-sections. One funky bit I'm not fond of: the new text must contain the markup for the section header. So if you use list-page-sections to figure out that "== foo ==" is rvsection 4, then when using set-section-content your text has to start with "== foo ==" or else the section will be lost. If the new text does not start with "== foo ==", the content will be saved as the end of rvsection 3, and rvsection 4 will now refer to a different section. Right now we throw an error if the text doesn't start with "==", which I think is the least surprising way to handle it.
Changed make-parameter to leave pathnames alone, which put drakma into a mode compatible with the upload API. Introduces `check-api-response` as a slightly more generalized form of `check-edit-response`, allowing checking the results of the upload response. Also made that pass back the XML results for other functions to interrogate. Example usage: (with-mediawiki ((make-instance 'mediawiki :url "https://wiki.example.com" :auth (list "user" "pass"))) (upload #P"/home/ryan/works.png")) re #1
Added comments reflecting that get-page-content cannot do this now, and why.