https://bugzilla.wikimedia.org/show_bug.cgi?id=55158
Web browser: ---
Bug ID: 55158
Summary: getFileVersionHistory doesn't work if information is
hidden
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1550/
Reported by: stefan2wiki
Created on: 2012-12-14 01:38:42
Subject: getFileVersionHistory doesn't work if information is hidden
Original description:
Take a file where some information is hidden, for example this one:
https://commons.wikimedia.org/wiki/File:Catania\_Piazza\_Quattro\_Canti.jpg
In this case, the edit summary for the first revision is missing.
Try this code:
import wikipedia
site = wikipedia.getSite\(u'commons', u'commons'\)
page = wikipedia.ImagePage\(site, u'File:Catania Piazza Quattro Canti.jpg'\)
history = page.getFileVersionHistory\(\)
I get an error message:
Traceback \(most recent call last\):
File "<stdin>", line 1, in <module>
File "wikipedia.py", line 4194, in getFileVersionHistory
result.append\(\(i\['timestamp'\], i\['user'\], u"%s×%s" % \(i\['width'\],
i\['height'\]\), i\['size'\], i\['comment'\]\)\)
KeyError: 'comment'
There is no i\['comment'\] because the comment is hidden \(deleted\).
Result: The script crashes when running getFileVersionHistory. It would be
better if getFileVersionHistory at least returns what's available, instead of
returning nothing at all. For example, if you use i.get\('comment'\) instead of
i\['comment'\], then getFileVersionHistory returns None if there is no comment.
That seems much better than crashing.
Some version information:
Pywikipedia \(r10715 \(wikipedia.py\), 2012/11/13, 20:56:05\)
Python 2.7.3 \(default, Aug 1 2012, 05:16:07\)
\[GCC 4.6.3\]
config-settings:
use\_api = True
use\_api\_login = True
unicode test: ok
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=64358
Bug ID: 64358
Summary: Incorrect EditConflict Exception
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: zhuyifei1999(a)gmail.com
CC: info(a)gno.de
Web browser: ---
Mobile Platform: ---
Site.upload may trigger EditConflict when using Page.save if page is loaded
before the upload.
EditConflict is raised in site.py line 2796-2798:
if lastrev is not None and page.latestRevision() != lastrev:
raise EditConflict(
"editpage: Edit conflict detected; saving aborted.")
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=59678
Web browser: ---
Bug ID: 59678
Summary: Implement badtoken detection and recovery
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: maarten(a)mdammers.nl
Classification: Unclassified
Mobile Platform: ---
Every once in a while I get a badtoken exception. This is probably because I
have multiple bots running on the same site at the same time (race condition).
* Bot A requests token -> 123
* Bot B requests token -> 123
* Bot A edits with token 123 -> ok
* Bot B edits with token 123 -> poof
We could of course implement very difficult synchronization, but it doesn't
happen very often so it's probably better handle it like a collision in
ethernet.
* Detect the badtoken
* Back off for a random number of seconds
* Get a new token
* Do the edit
Max tries should be respected so the bot can't get into a infinite retry loop.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=59973
Web browser: ---
Bug ID: 59973
Summary: Pywikibot should have a
wikibase-error-sitelink-already-used exception
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Wikidata
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: maarten(a)mdammers.nl
Classification: Unclassified
Mobile Platform: ---
At the moment when you try to add a sitelink to an item at Wikidata that's
already used, you'll get a pywikibot.data.api.APIError.
Sitelink to Commons Category:Mormonism based on P373
failed-save
Site link [//commons.wikimedia.org/wiki/Category:Mormonism Category:Mormonism]
is already used by item [[Q8808767]]. Perhaps the items should be
[[Help:Merge|merged]] and one of them [[Wikidata:Deletion policy|deleted]]?
Request deletion of one of the items at [[Wikidata:Requests for deletion]], or
ask at [[Wikidata:Interwiki conflicts]] if you believe that they should not be
merged.
{u'messages': {u'0': {u'type': u'error', u'name':
u'wikibase-error-sitelink-already-used', u'parameters':
[u'//commons.wikimedia.org/wiki/Category:Mormonism', u'Category:Mormonism',
u'Q8808767', u'commonswiki']}, u'html': {u'*': u'<p>Site link <a
class="external text"
href="//commons.wikimedia.org/wiki/Category:Mormonism">Category:Mormonism</a>
is already used by item <a href="/wiki/Q8808767" title="Q8808767">Q8808767</a>.
Perhaps the items should be <a href="/wiki/Help:Merge"
title="Help:Merge">merged</a> and one of them <a
href="/wiki/Wikidata:Deletion_policy" title="Wikidata:Deletion
policy">deleted</a>? Request deletion of one of the items at <a
href="/wiki/Wikidata:Requests_for_deletion" title="Wikidata:Requests for
deletion" class="mw-redirect">Wikidata:Requests for deletion</a>, or ask at <a
href="/wiki/Wikidata:Interwiki_conflicts" title="Wikidata:Interwiki
conflicts">Wikidata:Interwiki conflicts</a> if you believe that they should not
be merged.\n</p>'}}}
This is a bit too low level for me. This should be caught by either site or
page and a WikiBase exception should be thrown.
The behavior should probably be modeled after the IsRedirectPage exception. We
might want to create some more Wikibase exceptions while we're at it, but I
haven't looked into that.
PageRelatedError
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=59227
Web browser: ---
Bug ID: 59227
Summary: pywikibot.data.api.APIError:
internal_api_error_ReadOnlyError when the database is
locked
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: maarten(a)mdammers.nl
Classification: Unclassified
Mobile Platform: ---
Database is locked at the moment. Makes the pywikibot crash with this error:
Adding new Commons category claim to [[Commons:Category:Green Party of British
Columbia]] based on [[en:Category:Green Party of British Columbia]]
Traceback (most recent call last):
File "C:\pywikibot\core\commonscat_to_wikidata.py", line 238, in <module>
main()
File "C:\pywikibot\core\commonscat_to_wikidata.py", line 235, in main
bot.run()
File "C:\pywikibot\core\commonscat_to_wikidata.py", line 94, in run
newclaim.addSource(source, bot=True)
File "C:\pywikibot\core\pywikibot\page.py", line 2957, in addSource
self.addSources([claim], **kwargs)
File "C:\pywikibot\core\pywikibot\page.py", line 2965, in addSources
data = self.repo.editSource(self, claims, new=True, **kwargs)
File "C:\pywikibot\core\pywikibot\site.py", line 720, in callee
return fn(self, *args, **kwargs)
File "C:\pywikibot\core\pywikibot\site.py", line 3797, in editSource
data = req.submit()
File "C:\pywikibot\core\pywikibot\data\api.py", line 401, in submit
raise APIError(code, info, **result["error"])
pywikibot.data.api.APIError: internal_api_error_ReadOnlyError: Exception
Caught:
The database is currently locked to new entries and other modifications,
probably for routine database maintenance, after which it will be back to
normal.
The administrator who locked it offered this explanation: The database has been
automatically locked while the slave database servers catch up to the master
Should be caught like any other api error, back off, wait some time. Try again
until we reach max tries.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=56321
Web browser: ---
Bug ID: 56321
Summary: Locked database makes bot crash with
"pywikibot.data.api.APIError"
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Wikidata
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: maarten(a)mdammers.nl
Classification: Unclassified
Mobile Platform: ---
" File "C:\pywikibot\core\pywikibot\page.py", line 2692, in addClaim
self.repo.addClaim(self, claim, bot=bot, **kwargs)
File "C:\pywikibot\core\pywikibot\site.py", line 709, in callee
return fn(self, *args, **kwargs)
File "C:\pywikibot\core\pywikibot\site.py", line 3581, in addClaim
data = req.submit()
File "C:\pywikibot\core\pywikibot\data\api.py", line 394, in submit
raise APIError(code, info, **result["error"])
pywikibot.data.api.APIError: internal_api_error_ReadOnlyError: Exception
Caught:
The database is currently locked to new entries and other modifications,
probab
ly for routine database maintenance, after which it will be back to normal.
The administrator who locked it offered this explanation: The database has been
automatically locked while the slave database servers catch up to the master
"
Should back off and retry
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=61312
Bug ID: 61312
Summary: protect.py should have different messages for
protect/unprotect pages
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: info(a)gno.de
Web browser: ---
Mobile Platform: ---
Now we have the same edit summary for both operations
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=64489
Bug ID: 64489
Summary: Clean up limit handling (data/api.py)
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: valhallasw(a)arctus.nl
Blocks: 56190
Web browser: ---
Mobile Platform: ---
QueryGenerator has a very complicated structure to handle request limit
handling; some of it is currently working by accident, e.g.:
new_limit = None
(...)
new_limit = min(new_limit, self.api_limit // 10, 250)
Now, new_limit is what? None!
(at least, on python 2 -- this returns an error in python 3)
Which is actually required as some requests don't allow limits, such as
https://en.wikipedia.org/w/api.php?maxlag=5&pageids=1969218|225758|38275275…
adding &rvlimit=50 returns
error: {
code: "rvmultpages",
info: "titles, pageids or a generator was used to supply multiple pages, but
the limit, startid, endid, dirNewer, user, excludeuser, start and end
parameters may only be used on a single page."
}
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=62261
Bug ID: 62261
Summary: Throw specific error instead of generic APIError if
claim target is deleted
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: Unprioritized
Component: Wikidata
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: felix(a)fex-it.de
Web browser: ---
Mobile Platform: ---
If adding a claim, two types of errors are thrown in case of a deleted item:
item = pywikibot.ItemPage(repo, "Q726")
target = pywikibot.ItemPage(repo, "Q14854094")
c = pywikibot.Claim(repo, u'P171')
c.addTarget(target)
item.addClaim(c) # Error if item or target were deleted
At the last line, you get either
pywikibot.exceptions.NoPage: Page [[wikidata:-1]] doesn't exist.
if item (Q726) has been deleted or
pywikibot.data.api.APIError: invalid-snak-value: Q14854094 not found
if the target (Q14854094) has been deleted.
It would be great, if for the latter a specific "InvalidValueError" or similar
would be thrown. Then, the error could be caught and handled specifically
without the need to parse the (possibly changing) API error message itself.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55011
Web browser: ---
Bug ID: 55011
Summary: Support for Wikimedia Labs and Toolserver
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/feature-requests/335/
Reported by: cdpark
Created on: 2013-04-08 01:52:09
Subject: Support for Wikimedia Labs and Toolserver
Original description:
1\. Source directory repositiory
Split pywikipedia source and user config/script. See also
https://wikitech.wikimedia.org/wiki/Nova\_Resource\_Talk:Bots\#Pywikipediab…
Currently, pywikipedia imports\(or includes\) other file from \(1\) source code
directory \(2\) current working directory \(3\) pywikipedia environment,
depends on code. How about to support PYWIKIPEDIA\_HOME or similar environment
for source code repository.
2\. Local mysql mirror support.
In WMLabs and toolserver, access of wikipedia mirror is available. Page.get\(\)
and pagegenerators can be use this information. \(BTW, Page.put\(\) should work
to original site, not mirrors\). It can be also useful for other mediawiki
installs if admin runs some pywikipedia-based script \(e.g. replace.py\) for
his own database.
--
You are receiving this mail because:
You are the assignee for the bug.
