User Details
- User Since
- Apr 5 2016, 6:06 PM (399 w, 2 d)
- Availability
- Available
- LDAP User
- Jack who built the house
- MediaWiki User
- Jack who built the house [ Global Accounts ]
Wed, Nov 8
Yeah, this works, thanks:
// jshint esnext: false // jshint esversion: 11
Too bad JSHint doesn't support esversion > 11, so I can't use e.g. ||= without triggering a linter error.
Fri, Nov 3
Wed, Nov 1
Oct 31 2023
OK, thanks.
Oct 26 2023
Oh, that's great news. (Currently a fragment with random characters gives a notification "This comment could not be found. It might have been deleted or moved." – is that expected? Also maybe unsuccessful lookup should be reflected in the notification text as well.)
Oct 22 2023
Oct 18 2023
That's an interesting question, because I stumbled upon this when I was testing a script of mine that is not in production yet. And even there the button should be outside of #mw-content-text which the link selector requires.
Oct 13 2023
...Because in a later commit making mw.widgets.CopyTextLayout.js based on an OOUI widget this change has been erased.
So why UrlShortener still uses the articles icon?
Oct 11 2023
Oct 7 2023
Oct 6 2023
@Krinkle Thank you for caring enough to look into old copies of my script, haha. The majority of the results are not used by anyone. Those in my userspace are kept for historical purposes. I already requested removal of some of them. If they interfere with your cleaning up routines, I can remove all or most versions that are not in use.
Oct 5 2023
Oct 4 2023
@Jdlrobson Convenient-Discussions now uses the hook, thank you for implementing it.
So, if "the hook wikipage.tableOfContents.vector does not seem to have been adopted by any gadgets or code" that basically means that either
- there are no user scripts in nature that modify the TOC
- or their maintainers are unaware of the creation of the hook => their user scripts work unreliably in Vector 2022.
The second seems more realistic to me, so I would look for such user scripts and inform their maintainers.
I completely missed the moment when this was implemented, so my code still uses a hack. I'll check out the hook shortly.
Oct 3 2023
The workaround advised to me by @AntiCompositeNumber is to open a URL with some tag instead of the master branch. You can take any from https://phabricator.wikimedia.org/source/mediawiki/tags/master/, e.g. https://doc.wikimedia.org/mediawiki-core/1.40.1/js/. P.S. I see he already said that, well I'll keep it as an instruction anyway.
It happens on a regular basis. Like the third time I run into it in the last week. The docs go down for a few hours, then resurface. Feels like when something is doing rm -rf, then reuploading the data.
Oct 1 2023
The easiest possible improvement:
Sep 29 2023
Sep 26 2023
Sep 24 2023
Sep 23 2023
Right, and wikis often use H1 headings for days/weeks/months in such cases as a workaround.
Sep 15 2023
Please attach restricted files
Sep 14 2023
Sep 10 2023
Sep 8 2023
Sep 7 2023
Sep 5 2023
I think this is a classic "developer logic vs user logic" problem. From the user's (gadget developer's) POV, "Please update call to mw.util.addPortletLink with ID p-namespaces. Use p-associated-pages instead." means exactly that: replace all usages of p-namespaces with p-associated-pages. The user likely won't even notice that this warning comes from the Vector 2022 skin, assuming the instruction to be universal.
Sep 4 2023
The local solution is simple – choose the first findable portlet like document.getElementById('p-associated-pages') || document.getElementById('p-namespaces') || document.getElementById('p-cactions'), see https://en.wiktionary.org/wiki/Project:Grease_pit/2023/September#Fix_MediaWiki:Gadget-DocTabs.js. So I close this. But the very need to use such a tricky way hints a poor architecture IMO, see T345490#9138919.
It turned out there's not only a race condition; on pages like https://en.wiktionary.org/wiki/Citations:house the execution of the script stops with error
and links to the entry and its discussion aren't added. Instead ofusers see this:
This is because on this line the script expects that the #p-namespace element is real and not a dummy and traverses its subtree. If there were no #p-namespace at all, the code would have fallen back to using #p-cactions. But because there is #p-namespace, the script terminates with an error. So, as a matter of fact, this dummy-adding code broke how tabs work in the "Citations" namespace of English Wiktionary.
It says: "Please update call to mw.util.addPortletLink with ID p-namespaces. Use p-associatedPages instead."
- The new element has ID p-associated-pages (with a dash, not camelCase); using p-associatedPages doesn't have any effect.
- If you follow this advice, your item won't be added on Vector and Timeless which still have p-namespaces.
- The code mapping #p-namespaces to #p-associated-pages may cause a race condition if the script is smart enough to specifically look for the existence of #p-namespaces before adding its item (see T345491). (Update: and even break some things completely, see T345491#9138953.)
Why not just make sure all skins use the same IDs and do backwards compatibility by centralized means (in mw.util.addPortletLink() itself perhaps) instead of having pieces of code all around struggling to make sense of each other? (Otherwise, how is the update to p-associated-pages T316908 supposed to carry on? Will each skin have this mapping code that fixes one thing, breaks another?)
Sep 3 2023
I'm lazy to create another task, but OOUI in general doesn't seem to account for the sticky header. The same with $floatableContainer of OO.ui.PopupWidget:
(The widget's floatableOutOfView property should've turned to false and the popup should've disappeared, as the $floatableContainer element came out of view.)
Sep 2 2023
At least the class vector-tab-noicon should be added to the <li>, I assume.