Oct 1 2018
Sep 7 2018
Jul 9 2018
May 2 2018
Apr 25 2018
Dec 28 2017
Works for me! Thanks so much, @Seb35!!
Dec 24 2017
Dec 2 2017
Nov 4 2017
Still a problem in MediaWiki 1.29.1.
Oct 11 2017
Sep 8 2017
Jun 30 2017
@zhuyifei1999 Yes, the current code successfully logs into a private wiki. There are some warnings, but the same warnings were already present before the changes.
Jun 26 2017
The error behavior has changed in the current version of pywikibot. The error is now RuntimeError: Unable to determine articlepath.
Jun 8 2017
@Anomie - thanks for the info. Would the following be a correct fix within Pywikibot?
@zhuyifei1999 - Thanks for the suggestion. This wiki is inside of a corporation that uses another authentication method.
Any estimate on when you might address this issue? Pywikibot is completely unusable on all wikis that require logins to read.
May 24 2017
@matmarex - Thanks so much for your extremely clear and detailed explanation. Thanks to you, I have updated the affected extension on our wiki, and it's now working perfectly. I also appreciate very much that the docs will be updated.
Apr 4 2017
Is there any kind of workaround for this issue? Our wiki hasn't been able to use Pywikibot for 4 months....
Feb 28 2017
You sure that T153346 is the same onBeforeUnload issue as this ticket?
Feb 16 2017
Feb 3 2017
Suggestion: Allow the user to provide the missing site information, either on the command line (using options), in a configuration file, or during script execution if the script can prompt the user interactively.
Jan 10 2017
This problem no longer occurs in MediaWiki 1.28.0, with the Linker class (deprecated) replaced by calls to LinkRenderer.
Jan 9 2017
Jan 5 2017
Jan 4 2017
This can be closed.
Looks like someone already patched this for bug T151973:
Jan 3 2017
Thank you for making the patch. Interestingly, I filed this bug report against a different extension that's also named DynamicPageList. I found the bug in the third-party extension known as DynamicPageList2, Your patch is against the original DynamicPageList from Wikimedia.
Finally managed to have time to get developer access, and submitted the patch above. This bug has been around for 3 releases, so hopefully this will eliminate it.
Dec 30 2016
Thank you, TTO!
Dec 27 2016
Why not just apply the one-line patch? The change is simple & obvious.
I just encountered this error during an upgrade from 1.26.4 to 1.28.0:
Dec 24 2016
Dec 22 2016
Dec 21 2016
Looks like the tip doesn't work for logging into private wikis either. I'll file a bug report.
Here's the output of generate_family_file.py on a private wiki using your primary repository:
@Magul - Thanks, I was not aware that I was using an outdated branch. I just followed the instructions in your official docs at https://www.mediawiki.org/wiki/Manual:Pywikibot/Installation.
Dec 12 2016
Nov 22 2016
A-ha. Got it. If the link's query string contains "http", the VisualEditor code hangs. My link's query string includes:
If I use the same PHP code but keep the querystring empty ($query = array()), VisualEditor loads without any errors.
Nov 16 2016
Thank you very much. Is it possible to install ICU on our old version of elasticsearch (1.7.4)? From looking at the docs, I see ICU only for versions 2.0 and up.
Nov 15 2016
Here you go:
@dcausse - Thank you so much for that information! We'll try it out.
@dcausse - In this ticket, you wrote about crossnamespace redirects support in CirrusSearch:
Oct 24 2016
Thank you, Brion!
Oct 21 2016
Suggested patch attached.
Sep 27 2016
Solved it! The cause is indeed the TitleKey extension. When it's installed, auto-suggest works for cross-namespace redirects in the wiki search box.
Thinking outside the box: maybe our wiki search box was somehow using the default MediaWiki search engine (mySQL full-text search) for auto-suggest, even though CirrusSearch was working for actual submitted searches. Is that possible? If so, do you know how we might re-configure our wiki to make it happen again?
@dcausse - Also to answer your question, if I look at User:Jsmith with ?action=cirrusDump, then yes, the redirect "John Smith" is listed in the JSON:
@dcausse - Thanks for your reply. If cross-namespace redirects are not supported for autocompletion in the search box, then I'm baffled because these redirects were working for years in our wiki search box... for 7,000+ users.
Sep 26 2016
Thanks for your quick response!
Here's another oddity. Create an article "Foo Bar Blat" in the main namespace that's a redirect to a User page, say:
Aug 29 2016
I filed this ticket. In Firefox 48.0.1 on Windows, I can now select the ticket number easily. A double-click works fine, and dragging is a little finicky but works well enough. I'm satisfied.
Aug 4 2016
Aug 3 2016
Thank you so much for trying to reproduce the issue. With your results in hand, I think I have narrowed down the cause. Would you mind repeating your test, but with the TitleKey extension installed (the 1.27 branch version)? When I remove this extension, I can no longer reproduce the issue.
Aug 2 2016
I notice that the LinkCache class (the subject of the error message) was reimplemented in 1.27 to use HashBagOStuff instead of MapCacheLRU.
Jul 28 2016
Florian introduced this typo in https://phabricator.wikimedia.org/rEYAK7252ccf3d34a81f51d4961a6cd89229bc5763c12 -- would you please fix it? Thanks.
May 17 2016
If you have the TemplateData extension installed, and you have docs on page Template:Foo/doc, and you edit Template:Foo, you'll see a note near the button for editing template data, saying that the doc subpage already has templatedata on it.
May 9 2016
The problem does not occur in the latest Firefox or in Internet Explorer 11.
This is in Chrome 50.0.2661.94 m and whatever version of MediaWiki is running on Wikipedia today [1.27.0-wmf.22 (1a1a79c)]
Apr 4 2016
Mar 1 2016
Interesting. Will there be a migration script of some kind to move templatedata from its current format into the new one?
Feb 11 2016
Feb 2 2016
Suggestion: allow the wiki administrator to designate a particular subpage string, such as doc, as the official place to keep TemplateData. Then VisualEditor can intelligently and unambiguously filter these pages out. See T125222.
I can't reproduce it on Wikipedia, but I can on our 1.26.2 internal wiki at work. Attached is a screenshot after:
In Windows 7 Professional, I can reproduce this 100% of the time in Firefox 44.0, Chrome 48.0.2564.97 m, and Internet Explorer 11.
This is MediaWiki 1.26.2 with the appropriate VE version for 1.26.
This also happens in Chrome 48.0.2564.97 m.