Thanks. I upgraded to 1.31.5 a few hours ago. :-)

Works for me! Thanks so much, @Seb35!!

Still a problem in MediaWiki 1.29.1.

@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.

The error behavior has changed in the current version of pywikibot. The error is now RuntimeError: Unable to determine articlepath.

@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.

@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.

Is there any kind of workaround for this issue? Our wiki hasn't been able to use Pywikibot for 4 months....

You sure that T153346 is the same onBeforeUnload issue as this ticket?

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.

This problem no longer occurs in MediaWiki 1.28.0, with the Linker class (deprecated) replaced by calls to LinkRenderer.

This can be closed.

Looks like someone already patched this for bug T151973:

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.

Thank you, TTO!

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:

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.

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.

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.

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:

Thank you, Brion!

Suggested patch attached.

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.

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:

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.

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.

I notice that the LinkCache class (the subject of the error message) was reimplemented in 1.27 to use HashBagOStuff instead of MapCacheLRU.

Florian introduced this typo in https://phabricator.wikimedia.org/rEYAK7252ccf3d34a81f51d4961a6cd89229bc5763c12 -- would you please fix it? Thanks.

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.

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 (rMW1a1a79c56899)]

Interesting. Will there be a migration script of some kind to move templatedata from its current format into the new one?

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.