Because of a security problem, the Graph extension has been disabled with immediate effect. More information will follow as it becomes available. —TheDJ (talk • contribs) 09:03, 18 April 2023 (UTC)[reply]

Okay, that obviates my coming here to report that {{page views}} is broken everywhere. I'll subscribe here, but if you report elsewhere, please add a link here, and a {{tracked}} template, as appropriate so I can monitor. Thanks, Mathglot (talk) 09:47, 18 April 2023 (UTC)[reply]

It's in phabricator as Phab:T334895, but the task is restricted. 192.76.8.66 (talk) 10:42, 18 April 2023 (UTC)[reply]

Notes from T334940 — An update will go out later today, and in the meantime purging the pages cache should clear the raw wikitext — TheresNoTime (talk • they/them) 12:49, 18 April 2023 (UTC)[reply]

FYI An update will go out later today appears to mean "an announcement about the problem" and not a fix — TheresNoTime (talk • they/them) 13:13, 18 April 2023 (UTC)[reply]

An update has been posted on the wikitech-ambassadors mailing list, and it seems a MassMessage will go out tomorrow — TheresNoTime (talk • they/them) 23:41, 18 April 2023 (UTC)[reply]

Problem with { { Graph:Chart } } ?

Article/section Ittoqqortoormiit#Population contains a { { Graph:Chart } } construct that does not display in the Chrome or Firefox browsers.

Notes: I don't know how to suppress WP formatting inside editing panes. A Web search and a reading of the WP manual of style did not reveal how to do this. I don't know how to submit WP bug reports, nor do I wish to know. David Spector (talk) 12:37, 18 April 2023 (UTC)[reply]

@David spector: The Graph extension has been temporarily disabled, see above. —Kusma (talk) 12:39, 18 April 2023 (UTC)[reply]

Graphs disabled message

I have created {{Graphs disabled}} for use on significant documentation pages. It can just be blanked when graphs are working again but I suggest to not add it to numerous low profile pages when the problem is expected to be so brief. PrimeHunter (talk) 13:06, 18 April 2023 (UTC)[reply]

Sounds good: a temporary problem that is being fixed; thank you. I hope all the uses are on "low profile pages". David Spector (talk) 13:16, 18 April 2023 (UTC)[reply]

I misread the intent of the template, but what I just did still feels like it works. See WT:WPAFC I'm not sure if this is a good solution as for those who are just browsing Wikipedia might not know what a template documentation page is and might be confused as to why the graph isn't showing. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:27, 18 April 2023 (UTC)[reply]

It was intended for documentation pages about graphs. I have added an option |missing for places where a graph should have been displayed. That's a lot of places and I'm not sure how many temporary notices it's worth adding. It would be more practical if any use of <graph>...</graph> automatically displayed an interface message like MediaWiki:Graphs disabled. PrimeHunter (talk) 13:56, 18 April 2023 (UTC)[reply]

That would definitely help. And I realized that its intended for documentation pages after i Had already added it because I read it too quickly. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:58, 18 April 2023 (UTC)[reply]

I for one oppose any need for a "Graphs disabled" message in mainspace; those in the know should just comment out graphs for the time being until this boondoggle gets fixed. (Hopefully this doesn't impugn on progress of inline SVG support.) – John M Wolfson (talk • contribs) 15:09, 18 April 2023 (UTC)[reply]

There is often associated content referring to the non-displayed graph. Commenting out the relevant parts may be non-trivial and it may not be uncommented quickly or at all when graphs return. The template can immediately be changed to display nothing when they return. If graphs were expected to be missing for a long time then a prettier but more work-demanding solution would be better but for a probably short term problem, I think it's good to have a simple option. PrimeHunter (talk) 15:24, 18 April 2023 (UTC)[reply]

Graphs are a very important part for illustration on Wikipedia. From "Demographics" section of geographical locations to "Polling" & "Results" section of elections to articles on geological periods to articles on a specific genus. I'd suggest that MediaWiki:Sitenotice be called with the text "Due to some technical issues, most Graphs on Wikipedia are not visible. Inconvenience caused is regretted." I said, "most graphs" because some graphs also exist as svg/png on commons with should be visible, and readers should not have to face technical jargon like "extensions", etc. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:15, 18 April 2023 (UTC)[reply]

If consensus exists for a notice, something simple and non-obtrusive, to the effect of "Graphs are currently unavailable due to technical issues", no template boxes or red error text, or anything too flashy, would probably be best while this is sorted. It's already embarrassing enough that stuff like this happens in the current year, we shouldn't bring too much flash or attention to it while the devs work to fix it. – John M Wolfson (talk • contribs) 16:20, 18 April 2023 (UTC)[reply]

Ahead of a proper communication that WMF is coming up with, I will say that it is now possible to display a custom message in place of the graphs, it is done by replacing MediaWiki:Graph-disabled content, empty by default, with a custom notice (such as an Ambox). There is also now a tracking category "Category:Pages with disabled graphs" showing the pages that used to contain graphs. The tracking category's name and description can be changed by editing MediaWiki:Graph-disabled-category and MediaWiki:Graph-disabled-category-desc interface messages. --Base (talk) 19:50, 18 April 2023 (UTC)[reply]

How about this? —CX Zoom[he/him] ^{(let's talk • {C•X})} 20:01, 18 April 2023 (UTC)[reply]

As source of inspiration, in Ukrainian Wikipedia we currently went with a standard Ambox icon and "There was supposed to be a graph or a diagram here, but its rendering is currently disabled for technical reasons. Please do not remove the code that is causing this message. Developers are already working on restoring the normal rendering of the graph or diagram." --Base (talk) 20:13, 18 April 2023 (UTC)[reply]

I find this one more precise and appropriate to be shown. Thanks for sharing. —CX Zoom[he/him] ^{(let's talk • {C•X})} 20:15, 18 April 2023 (UTC)[reply]

The missing graphs are probably confusing a lot of users so I have created MediaWiki:Graph-disabled with the suggested text. The text is still open for discussion but I wanted something out quickly. I guess there is no job queue to update affected pages so they have to be purged or edited to display it. See 4 Vesta#Physical characteristics for an example I purged. PrimeHunter (talk) 21:04, 18 April 2023 (UTC)[reply]

The ! in the red stop sign is quite alarming, while no action by reading user is required, not even by wikipedia editors.

Suggestion: use a 'information' sign, a white 'i' in a blue circle with the text:

"Sorry, we experience technical issues with this graph. It will reappear as soon as the developers have solved the problem." Uwappa (talk) 21:16, 18 April 2023 (UTC)[reply]

It looks a bit wonky for me because the notice has margins that squish it. It appears the notice has been propagated to all graphs on enwiki. SWinxy (talk) 21:21, 18 April 2023 (UTC)[reply]

I have toned it down to the default icon and no bold.[1] PrimeHunter (talk) 21:43, 18 April 2023 (UTC)[reply]

Thank you. Suggested text finetuning:

"Graphs are temporarily unavailable due to technical issues."

The temporarily will indicate that a solution is on its way. Uwappa (talk) 21:55, 18 April 2023 (UTC)[reply]

I may not be editing for a couple of hours but other admins are free to make changes. PrimeHunter (talk) 22:01, 18 April 2023 (UTC)[reply]

I think this one would be better as "i" is for information pages. I actually like the unbolded text. And Uwappa's suggestion is good too. —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:01, 18 April 2023 (UTC)[reply]

I don't think that image can be used since the file isn't protected. Galobtter (talk) 22:08, 18 April 2023 (UTC)[reply]

 Done seems reasonable. Galobtter (talk) 22:04, 18 April 2023 (UTC)[reply]

“The temporarily will indicate that a solution is on its way” lemme just do some expectation management here…. this extension is thoroughly unmaintained for over 6 years. I do not expect this to be quickly fixed. It should be noted that there were already discussions about potentially having to remove the entire extension even before the latest problem. I’m sure some ppl are looking into what is possible, but I’d be really surprised if this is fixed within a month. —TheDJ (talk • contribs) 22:40, 18 April 2023 (UTC)[reply]

TheDJ, thanks for that. Expectation management is always helpful. If you have any insight into how fixing a problem like this is prioritized, that might help us at VPT understand whether we should work on implementing any workarounds in the meantime. As far as I can tell, this outage has affected at least 60,000 pages here at en.WP. – Jonesey95 (talk) 23:22, 18 April 2023 (UTC)[reply]

I agree that the notice feels squished. I had tried to apply the style parameter to width:100% so that empty space on either side can be eliminated but that overflowed the notice box on the right side which is not good. I guess someone has a better idea for it. —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:05, 18 April 2023 (UTC)[reply]

Okay, this one unsquishes it: {{notice|style=width:100%;margin:0;|text=Graphs are temporarily unavailable due to technical issues.}} —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:07, 18 April 2023 (UTC)[reply]

I was trying just margin:0 but that didn't work. Thanks!  Done Galobtter (talk) 22:09, 18 April 2023 (UTC)[reply]

It looks good in the image frame and outside one. {{annual readership}} has been replaced with a custom notice by RedRose. SWinxy (talk) 22:18, 18 April 2023 (UTC)[reply]

The red icon is too disruptive and flashy. Text alone will do the job of explaining technical problems without calling undue attention to behind-the-scenes work. The current {{Annual readership}} notice is perfect. – John M Wolfson (talk • contribs) 16:10, 19 April 2023 (UTC)[reply]

Category:Pages with disabled graphs

There's a bunch of pages linked to Category:Pages with disabled graphs but that category has never existed and I don't know what to do with them. —Lights and freedom (talk ~ contribs) 19:40, 18 April 2023 (UTC)[reply]

The category has now been created with an explanation. PrimeHunter (talk) 20:54, 18 April 2023 (UTC)[reply]

Clarification

What is this "security problem", what does security have to do with little graphs and charts and things in Wikimedia articles? I wish we heard at least a little bit more of an explanation. ɱ (talk) 00:11, 19 April 2023 (UTC)[reply]

@Ɱ Code with vulnerabilities can ostensibly be "hacked" to use to run malicious code in places it otherwise couldn't. For WP:BEANS reasons, its best to not elaborate :) CaptainEek ^{Edits Ho Cap'n!}⚓ 01:19, 19 April 2023 (UTC)[reply]

What malicious code could be put in a graph box? 'Click here for a spam site'? Is it worth pulling it rather than fixing it quietly, if there's nobody actively misusing this code? ɱ (talk) 02:26, 19 April 2023 (UTC)[reply]

I don't know the security problem but mw:Extension:Graph uses JavaScript which means it intentionally runs code in the user's browser. See JavaScript#Security for some general problems. Some people disable JavaScript completely in their browsers for security reasons. PrimeHunter (talk) 02:46, 19 April 2023 (UTC)[reply]

Do graphs really need javascript? Can't graphs be just server side generated images? Is javascript only required just for mouseover effect? Will we avoid all javascript by deleting the mouseover effect? Uwappa (talk) 06:34, 19 April 2023 (UTC)[reply]

Graphs used to be server-side generated images, but that was removed because that was also showing its age, and in worse ways. I like the rollovers myself, as it happens, which were not possible before; the loss of course is that graph content isn't served to users who turn their JavaScript off. Izno (talk) 06:54, 19 April 2023 (UTC)[reply]

Moving away from graphs

TheDJ said it: this extension is thoroughly unmaintained for over 6 years. I do not expect this to be quickly fixed. Moving away from graphs is going to be tough, but not impossible. Some graphs are fully automated (e.g. {{annual readership}}) while others are partially automated (e.g. {{Television ratings graph}}). Would this be desired by the community? SWinxy (talk) 01:18, 19 April 2023 (UTC)[reply]

@SWinxy If by "this", you mean removing graphs altogether, no. Graphs are a fundamental aspect of conveying data, and this is an encyclopedia. Getting rid of coded in graphs would be a major headache, because they would need to be replaced by photos of graphs (photo-graphs :P), or other work arounds. CaptainEek ^{Edits Ho Cap'n!}⚓ 01:46, 19 April 2023 (UTC)[reply]

Yes, coded graphs! Ditching graphs altogether would be a bit of a challenge... SWinxy (talk) 01:51, 19 April 2023 (UTC)[reply]

Graphs are used on Wikisource to identify those works that are being read / accessed the most. The information helps drive our choices as to what publications we will put our efforts into next. We'd need a viable alternative before the extension is discontinued. --EncycloPetey (talk) 18:20, 19 April 2023 (UTC)[reply]

I think it's a bit premature to be worrying about removal/replacement. One of the suggestions on the public task is just to upgrade to a maintained version of the software package used and then do the remove/replaces necessary to fix the onwiki versions to the required standard. Izno (talk) 06:56, 19 April 2023 (UTC)[reply]

This. Don't jump the gun. This needs thorough analysis and then likely work. That can be between 3 days and 90 days or no further work at all. There really is no telling at this stage. Remember, everyone was working on their thing they are supposed to work on and now several people have been thrown into a big tumbling washing machines with work that is unscheduled and needs to happen next to other work they cannot let rest and delaying the rest, completely upending planning and scheduling. The only thing that might change anything at all, is expressing how much you appreciate and/or need graphs and how you use them. —TheDJ (talk • contribs) 08:13, 19 April 2023 (UTC)[reply]

@TheDJ: well said, thank you — you should be a technical spokesperson or something..! — TheresNoTime (talk • they/them) 08:43, 19 April 2023 (UTC)[reply]

Understood. I wanted to float the idea. SWinxy (talk) 16:55, 19 April 2023 (UTC)[reply]

Hell no, we should be doing more inline code, with inline SVG support and whatnot, not less. In any event, I don't think anything will come of this in the long-term except hopefully more proactive maintenance. – John M Wolfson (talk • contribs) 16:13, 19 April 2023 (UTC)[reply]

+1 —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:21, 19 April 2023 (UTC)[reply]

Preventing future issues

Any plans by the WMF or volunteers to check all other official extensions for use of outdated libraries? Any plans to implement new processes to make sure libraries don't get out-of-date in the future? DFlhb (talk) 12:13, 19 April 2023 (UTC)[reply]

They (un-maintained extensions) are documented and supposed to be handled at phab:project/profile/3144/. WMF's CTO (Chief Technical Officer), miss Deckelmann, is supposed to handle that, but she has not done so yet. There is also a list over who handles which extension and service at mw:Developers/Maintainers. Any further questions should be answered by WMF.--Snævar (talk) 16:04, 19 April 2023 (UTC)[reply]

Probably not in any systematic way. There doesn't appear to be enough software engineer time available to assign maintainers to all unmaintained software. Software gets created, then the software engineers / WMF teams move on to other projects. –Novem Linguae (talk) 19:37, 19 April 2023 (UTC)[reply]

There are some existing efforts here. libraryupgrader2.wmcloud.org is fairly prolific in updating outdated or vulnerable dependencies via gerrit change sets, see: https://gerrit.wikimedia.org/r/q/owner:tools.libraryupgrader%2540tools.wmflabs.org. But it has its limits and some changes must be manually reviewed. The Security Team also checks for outdated and vulnerable dependencies as part of any manual application security review request. And we are building out some SCA tooling for repos hosted at gitlab.wikimedia.org. These efforts could, of course, be expanded and accelerated. Though I would note that the way the Vega dependencies were "built" within the Graph extension was problematic, as they were not referenced within package.json and were therefore difficult to analyze, especially for an extension with no actual active maintainers. We're hoping to address this and several other issues in our current efforts to get the Graph extension reenabled on the projects. SBassett (WMF) (talk) 19:52, 19 April 2023 (UTC)[reply]

Community Wishlist item for 5 years

FWIW, I'd like to remind that the Graph extension we are were using is very outdated and the community has been asking for 5 years to upgrade it to the latest build. In 2023, it was the #49 request in CWS: m:Community Wishlist Survey 2023/Multimedia and Commons/Update Vega to the latest build. I suspect that the security issue could've been resolved if it were upgraded. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:40, 19 April 2023 (UTC)[reply]

Excellent link. This is yet another reason that I have given up on the CWS process. Regular editors, including myself, are not great at identifying which proposed improvements and projects are actually important for the continued operation of MediaWiki sites. Requests for shiny new features typically get a lot more support than boring stuff like "update the back-end software that drives a process that tens of thousands of pages depend on and for which there is no easy alternative". – Jonesey95 (talk) 18:48, 19 April 2023 (UTC)[reply]

It's outrageous how incompetent the WMF is. Everybody has known for years that the Graph extension was using outdated software and needed to be updated. This is critical software that is used in millions of pages. Nothing has been done for over 5 years! What were all the hundreds of paid developers doing in the meanwhile? Ita140188 (talk) 07:29, 20 April 2023 (UTC)[reply]

By that logic. Considering it is open source.... YOU also didn't do anything and thus you also are incompetent. There is too much code for the amount of developers, this is nothing new. Also it's not used by millions of pages. It's about 60 000 for en.wp, or just 16k articles. It's tiny compared to most extensions in use. —TheDJ (talk • contribs) 08:30, 20 April 2023 (UTC)[reply]

Sorry for the million hyperbole written out of frustration, it is still a lot of pages that get a lot of views every day. This problem has been known for years and reported several times, it was just waiting to happen. If doing basic maintenance of the underlying Mediawiki software also should be the editor's responsibility, it makes me wonder why are we paying millions of dollars every year to WMF developers? What exactly are they doing? Ita140188 (talk) 09:52, 20 April 2023 (UTC)[reply]

There are literally feeds of the 30000 tickets opened and closed each year and all the change sets in gerrit where you can find that out. Running a top 10 website for a couple hundred wikis each with their own configuration requires a lot of work. Also, not everyone codes, there is testing, releasing, datacenter operations, the couple thousand of software projects made by users/editors, fundraising infrastructure for dozens of countries in the world, etc etc etc. —TheDJ (talk • contribs) 10:50, 20 April 2023 (UTC)[reply]

Are they doing everything I want? Definitely not. Do they have the resources to do everything I want? Of course not. They have to set priorities, and disagreeing with your priorities is not evidence of incompetence.

Now, if you're in a position to fund the development you want, I'm sure that they would pay attention. Even then they would have the final say on what to do when. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:06, 20 April 2023 (UTC)[reply]

Graph extension disabled

Yesterday the Wikimedia Foundation noted that in the interests of the security of our users, the Graph extension was disabled. This means that pages that were formerly displaying graphs will now display a small blank area. To help readers understand this situation, communities can now define a brief message that can be displayed to readers in place of each graph until this is resolved. That message can be defined on each wiki at MediaWiki:Graph-disabled. Wikimedia Foundation staff are looking at options available and expected timelines. For updates, follow the public Phabricator task for this issue: T334940

--MediaWiki message delivery (talk) 17:36, 19 April 2023 (UTC)[reply]

Update on graphs: https://phabricator.wikimedia.org/T334940#8798354

Over the last few days engineers have been exploring an approach that will add Vega 5 support for the Graph Extension. The goal is restore as much graph rendering as possible in the shortest timeframe. This aim to address the vulnerabilities found but most importantly to restore as much of the extensions previous state. We will also be updating the D3.js library from version 3.5.17 -> 7.8.4. The Vega 1 and Vega 2 libraries will be removed from the graph extension.

In terms of expectations:

• Initially the graph extension with Vega5 may only be supported on modern browsers (approximately 2017 or newer). This is due to some issues with ES5 builds and MediaWiki in the most recent versions of Vega. It’s hoped this can be resolved with a build step to restore functionality to MediaWiki's full supported browser stack.
• A compatibility layer that maps Vega 2 community graphs to Vega aims to allow current Vega 2 syntax to work with Vega 5, but our expectation is that some <graph> syntax might need to be updated in some places.
• We are building in some more sustainable error handling code. They will load and display an error thumbnail if the graph cannot be displayed. The purpose of this is to allow us to turn some graphs on and get a better sense of which graphs need to be prioritized. When graphs fail to render they will also send an error to our client logs so we can track them and later fix them.

Security will be reviewing the updated Vega 5 and D3.js libraries and the threat model associated with this approach, and release of the update is gated on a successful security review. We want to be as confident as possible that the approach is secure and correct.

We are assembling a small group of engineers from across a number of teams to see how much additional progress we can make on Graph between now and May 5, and will be working iteratively on our approach. We will continue to share updates along the way here on Phabricator. If we hit major blockers (e.g., security or library complexities we can't quickly resolve in the order of days or a couple weeks), we will be sure to share this information whilst we establish next steps. Our hope is that we can avoid difficult tradeoffs where we would need to keep Graph disabled for a long time, but we also need to acknowledge that this is a distinct possibility.

Seddon (WMF) (talk) 14:59, 21 April 2023 (UTC)[reply]

@Seddon (WMF), maybe you missed it, but ES6 is now the minimum required version of JavaScript, plus one or two functions from ES2017ish timeframe that @TheDJ has mentioned elsewhere (Promise.finally I think was one). So not sure why ES5 is mentioned above as the source of an issue? Izno (talk) 16:19, 21 April 2023 (UTC)[reply]

@Izno The short answer is that Vega provides either a full or what they term an ES5 build. They don't do intermediate builds. Seddon (WMF) (talk) 17:40, 21 April 2023 (UTC)[reply]

lol Izno (talk) 22:25, 21 April 2023 (UTC)[reply]

April 28th update on graphs: https://phabricator.wikimedia.org/T334940#8813922

The short version

• The team has laid a bunch of groundwork to add vega5 support to the graph extension and improve the extensions security overall.
• Vega5 has been enabled on the beta.cluster for testing.
• We hope the start testing on production next Tuesday on test.wikipedia.org
• Vega5 breaks a lot of graphs. The team is trying to mitigate this, but communities will need to begin migrating from vega2 to vega5.

The long version

Over the last week we have:

• added Vega5 support
• dropped support for Vega1 and Vega2
• improved the error handling messaging within the graph extension
• add logging for graph errors
• ongoing work to improve url sanitisation
• added foreign-resources infrastructure for extensions
• started work on attempting to build a rudimentary vega2->vega5 translation layer to mitigate the disruption a move to vega5 may cause
• added some support for this migration for use to update raw graph definitions (not built via lua) via the GraphSandbox
• fixed an issue with graph overflow on mobile

The graph extension has been re-enabled on the beta cluster to aid engineers in being able to test in a more production like environment rather than relying on local development environment's. We had hoped that we would be able to re-enable the graph extension with vega5 at least on test.wikipedia.org however over the past week there have been a number of challenges. Recent builds of Vega meant it did not cleanly support ES6 browsers. This was also causing problems for our infrastructure. A recent patch to vega fixed this but also saw a big update to d3.js dependencies that vega relies on.

Whilst we could have used the last deployment window to backport a bunch of work to production wiki's, the scale of what needed backporting was beyond what is reasonable for the nature of backport windows. In addition to that, we were increasingly getting close to the golden rule of don't deploy on a friday. As such the team working on this took the decision that the majority of this week's work would go out on the deployment train next week and we will look to begin further testing on test.wikipedia.org next Tuesday.

In terms of expectation management:

• The graph extension is being upgraded from vega2->vega5 which means that the graph definitions that had been previously used on wiki either in a raw form or constructed via lua modules are not compatible. This means that none of the existing graph definitions would be in any way interoperable.
• Our engineers are attempting to build a rudimentary translation layer that may provide some small degree of backward compatibility but this cannot be relied upon and it is vital that communities look to migrate graph and templates from vega2->vega5.
• The english beta wikipedia serves as a good testing location and has the most recent version of vega5 and Module:Graph from enwiki/dewiki
• This guide] provides the most comprehensive detail on migration from Vega 2.

Seddon (WMF) (talk) 17:21, 28 April 2023 (UTC)[reply]

When will this be fixed?

It's getting kind of annoying that graphs have been disabled for this long. Is there an approximate time frame for when they will be working again? A day, a week, a month, a year, ever? Thiscouldbeauser (talk) 13:44, 23 April 2023 (UTC)[reply]

My hope is we can maybe restore some functionality in the next week or so. Seddon (WMF) (talk) 16:03, 23 April 2023 (UTC)[reply]

Cool, thanks! Thiscouldbeauser (talk) 11:58, 24 April 2023 (UTC)[reply]

Any updated forecast coming? Seddon (WMF) Tomastvivlaren (talk) 08:28, 8 May 2023 (UTC)[reply]

mediawiki.org is now running Graphs again. I think they are still working on some of the remote source usage and improvements to the automatic v2 to v5 transforms. —TheDJ (talk • contribs) 09:35, 8 May 2023 (UTC)[reply]

The hyperlink of Page view in Page information corrupts

Hi, about one month ago, there was a hyperlink for the value of "Page views in the past 30 days" in the "Page information" of each article that, after clicking on it, a diagram appeared for "Page view per day". But this hyperlink does not exist now.

For example, for the article "Telegram (software)", the associated Page information is Information for "Telegram (software)". In this page and in the section named "Basic information", the last item in the table is "Page views in the past 30 days", and its value is "271,603" today. This item, about one month ago, had a hyperlink that after clicking shows a "Page view per day" diagram for 1 month ago, but now this hyperlink does not exist.

So please do something to bring back this helpful hyperlink. Thanks, Hooman Mallahzadeh (talk) 10:51, 27 April 2023 (UTC)[reply]

@Hooman Mallahzadeh: The Graph extension - used in templates like Template:Annual readership - was disabled nine days ago. This was announced above, and also at Template talk:Annual readership#Currently disabled. --Redrose64 🌹 (talk) 11:21, 27 April 2023 (UTC)[reply]

Still, the hyperlink could still be there. Explain the unavailability of the graph on the linked page. As soon as the graph problem is solved, the graph will reappear. Uwappa (talk) 12:11, 27 April 2023 (UTC)[reply]

So far as I can tell, the link was not removed by English Wikipedia, but at a much more fundamental level - the MediaWiki software itself. --Redrose64 🌹 (talk) 12:35, 27 April 2023 (UTC)[reply]

Yes, the link was made and removed outside the English Wikipedia. It was also removed in other wikis. It's at https://en.wikipedia.beta.wmflabs.org/wiki/Example?action=info, but they have the Graph extension enabled at https://en.wikipedia.beta.wmflabs.org/wiki/Special:Version#mw-version-ext-parserhook-Graph. Considering graphs were disabled for security reasons, view them there at your own risk. If you have the default language "en - English" at Special:Preferences then you can click "Pageviews" in the page history or "Page view statistics" at the bottom of page information. It links another feature https://pageviews.wmcloud.org. You can also install User:PrimeHunter/Pageviews.js to get the link directly on pages regardless of your interface language. PrimeHunter (talk) 14:00, 27 April 2023 (UTC)[reply]

Short term solution for those private wikis affected please ?

Could you please tell us in simple to-do list what we can do to restore graph capabilities on our private wikis? (I assume it is not just on wikipedia as I have rendering problem on standard graph code on my private wiki. Shall we go back to a version earlier of Media Wiki as a short term solution for non-sensitive wikis?).

In my case (perhaps a large group of people), security is not an immediate issue as it is not a much developed private wiki and does not interest hackers, and I would appreciate solutions such as enabling previous functionality for some weeks, if there's the option, until the long term solution is ready.

To make it simpler, how can the following code be run in short term on private wikis? (it is showing as blank white now, when you try to edit in visual editor it shows a "rendering error" message)

{
  "$schema": "https://vega.github.io/schema/vega/v5.json",
  "description": "A basic pie chart example.",
  "width": 200,
  "height": 200,
  "autosize": "none",

  "signals": [
    {
      "name": "startAngle", "value": 0,
      "bind": {"input": "range", "min": 0, "max": 6.29, "step": 0.01}
    },
    {
      "name": "endAngle", "value": 6.29,
      "bind": {"input": "range", "min": 0, "max": 6.29, "step": 0.01}
    },
    {
      "name": "padAngle", "value": 0,
      "bind": {"input": "range", "min": 0, "max": 0.1}
    },
    {
      "name": "innerRadius", "value": 0,
      "bind": {"input": "range", "min": 0, "max": 90, "step": 1}
    },
    {
      "name": "cornerRadius", "value": 0,
      "bind": {"input": "range", "min": 0, "max": 10, "step": 0.5}
    },
    {
      "name": "sort", "value": false,
      "bind": {"input": "checkbox"}
    }
  ],

  "data": [
    {
      "name": "table",
      "values": [
        {"id": 1, "field": 4},
        {"id": 2, "field": 6},
        {"id": 3, "field": 10},
        {"id": 4, "field": 3},
        {"id": 5, "field": 7},
        {"id": 6, "field": 8}
      ],
      "transform": [
        {
          "type": "pie",
          "field": "field",
          "startAngle": {"signal": "startAngle"},
          "endAngle": {"signal": "endAngle"},
          "sort": {"signal": "sort"}
        }
      ]
    }
  ],

  "scales": [
    {
      "name": "color",
      "type": "ordinal",
      "domain": {"data": "table", "field": "id"},
      "range": {"scheme": "category20"}
    }
  ],

  "marks": [
    {
      "type": "arc",
      "from": {"data": "table"},
      "encode": {
        "enter": {
          "fill": {"scale": "color", "field": "id"},
          "x": {"signal": "width / 2"},
          "y": {"signal": "height / 2"}
        },
        "update": {
          "startAngle": {"field": "startAngle"},
          "endAngle": {"field": "endAngle"},
          "padAngle": {"signal": "padAngle"},
          "innerRadius": {"signal": "innerRadius"},
          "outerRadius": {"signal": "width / 2"},
          "cornerRadius": {"signal": "cornerRadius"}
        }
      }
    }
  ]
}

— Preceding unsigned comment added by 31.14.151.6 (talk) 10:39, 1 May 2023 (UTC)[reply]

Nothing has changed about the extension, other than it having been disabled. Well.. unless you are running the unreleased master branch. In that case, the solution seems pretty obvious to me... —TheDJ (talk • contribs) 11:05, 1 May 2023 (UTC)[reply]

The solution is not obvious to me, could you elaborate? How can we enable the graph extension? Any code? Shall we install an old version of Media Wiki (a month or two old)? 31.14.151.6 (talk) 11:16, 1 May 2023 (UTC)[reply]

The issue is not that a new version of MediaWiki broke Graph. The issue is that Graph has (and has had) major security flaws. Snowmanonahoe (talk) 11:22, 1 May 2023 (UTC)[reply]

I know the Graph has issues, I mean how has it been disabled on my private wiki and how can I enable it for myself? 31.14.151.6 (talk) 11:27, 1 May 2023 (UTC)[reply]

I am using Media Wiki 1.38.4, which means it is a version before the announced issue of Graph around mid April, so how can Graph be disabled on my private wiki? Does Media Wiki read some privileges and rights from a centralized server when it is run? 31.14.151.6 (talk) 11:26, 1 May 2023 (UTC)[reply]

It doesn't. Your issue has nothing to do with this security problem. From what I can see from above, you are using Vega 5, but Graph only used to support Vega 1 and Vega 2 up to last week. More importantly; this is not a support forum for 3rd party MediaWiki installation. —TheDJ (talk • contribs) 12:18, 1 May 2023 (UTC)[reply]

(The appropriate forum would be mw:Support.) Izno (talk) 17:09, 1 May 2023 (UTC)[reply]

Hi everyone,

In a few weeks, we'll be performing a test. Half of logged-in desktop users will see a version that shows the regions of the page separated more clearly. This version will include more borders and gray backgrounds (preview it here). After two weeks, everyone will see the current white interface again. We will analyze the usage data for both and make a decision on next steps in July.

Feedback about the white space

Currently, Vector 2022 uses whitespace to separate the various regions of the interface. It also has a white page background (outside of the content area). We have received a lot of feedback about this. There are two areas of concern:

1. Comments about adding more visual separation between regions of the interface. For example, a boundary around both the content area and the side menus. Volunteers have been wondering if this would improve the reading experience. Mainly by:
   • Drawing more focus/attention to the content when landing on the page (rather than taking in the interface as a whole first, then focusing on the content).
   • Making it easier to stay focused on the content while reading, because the content area would be more well defined.
2. Comments about adding a gray background outside of the content area. Volunteers have been wondering if this would reduce eye strain some people are experiencing from the large white area (i.e. “glare”) on larger screens.
   • Many of you have reported that the white space is too high in contrast and that adding a darker hue such as a gray decreases this strain.
   • This may also add further focus to the content area and the table of contents.

About the test itself

To verify these hypotheses, we have set up user testing with readers. Here you can read more about the test as well as learn about the outcomes.

We also want to ensure that the new layout does not negatively affect any high-level metrics for the project. This is why the A/B test will take place. We will be looking for no statistically significant decreases in the following: pageviews, opt-out rates, edit rate, Table of Contents usage, scrolling, and page tools usage. Due to privacy and technical restrictions, we are only able to run this test with logged-in users. We will filter the results by the number of edits a given user has. Then, we will proxy logged-out users via logged-in users with 0 edits.

This test will start within two weeks and will take two full weeks. It will be performed on Wikipedias in: English, Farsi, French, Hebrew, Korean, Portuguese, Serbian, Thai, Turkish, and Vietnamese.

After two weeks, everyone will see the basic (white) version again. Next, we will check if the new layout has negative effects on those metrics. If it doesn't, then we will enable it across all users and all wikis. It won't happen before July, though.

Thank you! SGrabarczuk (WMF) (talk) 09:43, 5 May 2023 (UTC)[reply]

Is this Vector2022 only or does it affect people using other skins? —Kusma (talk) 09:58, 5 May 2023 (UTC)[reply]

Hey, @Kusma. This is strictly part of the Desktop Improvements project (and its product, Vector 2022). We're actively working on one skin. This is to say, it's Vector 2022 only. SGrabarczuk (WMF) (talk) 10:02, 5 May 2023 (UTC)[reply]

After two weeks, everyone will see the current white interface again.: No, please. I would be more than happy to have this improvement, even if it requires me pulling some levers in my prefs after 2 weeks. Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:17, 5 May 2023 (UTC)[reply]

SGrabarczuk (WMF): Thanks for the detailed notice. I think that there will be many requests like the one above, i.e. "please tell us how to keep this new skin update!" You might think about how to answer those requests. – Jonesey95 (talk) 13:08, 5 May 2023 (UTC)[reply]

@CX Zoom: If it's only background colour changes in certain areas, I suspect that this will be done via CSS, so it should be fairly easy to copy the relevant rules to your CSS. --Redrose64 🌹 (talk) 11:21, 6 May 2023 (UTC)[reply]

Two grayed-out designs were proposed. What made you choose this rather boxy one that (to me) looks like a noob design attempt? Four white boxes on a gray background, plus white floating toolbar look too distracting (to me). 65.211.97.242 (talk) 16:15, 5 May 2023 (UTC)[reply]

@SGrabarczuk (WMF) is there a ?= parameter that can be passed to force this display for any troubleshooting? — xaosflux ^Talk 18:53, 5 May 2023 (UTC)[reply]

It is a somewhat odd choice. Adam Cuerden ^(talk)_{Has about 8.3% of all FPs. Currently celebrating his 600^th FP!} 11:40, 6 May 2023 (UTC)[reply]

Hi! Sorry if this is the wrong place to come—I did my best. (I don't think this is a bug.) Whenever I log in, the Table of Contents disappear. I'm not exactly sure when this started happening—I did enable Wikipedia:Twinkle at some point in the last couple days ... but now I've disabled it. I have no other beta or non-defaults enabled. For a minute there, the menu was showing up in the sidebar, but I hid that, thinking it might bring the TOCs back, so it's no longer there (though no such luck on the TOCs returning). Does anyone have any idea what I might've done to hide the TOCs?--Jerome Frank Disciple 16:36, 5 May 2023 (UTC)[reply]

Can you provide a screenshot? NW1223<Howl at me•My hunts> 16:55, 5 May 2023 (UTC)[reply]

Of course!

• Here's a screenshot in which the main menu is in the sidebar
• Here's a screenshot of what happens when I click "Hide" on the main menu

(If you meant provide a screenshot of my settings, I can do that too.) Sorry for all the trouble ... I'm actually surprised at how much extra convenience it is when you don't have a TOC ... --Jerome Frank Disciple 16:59, 5 May 2023 (UTC)[reply]

The table of contents is right next to "Badge Man." Does it appear when you click it? Nythar (💬-🍀) 17:03, 5 May 2023 (UTC)[reply]

(Annoyed grunt). And here I was almost having made it through the day without embarrassing myself. Sorry for all the trouble, last time I used Wikipedia consistently, the TOC was still featured in the body of the article—turns out, I'm old and I guess new buttons scare me? Found the "move to sidebar" button with in the TOC.--Jerome Frank Disciple 17:08, 5 May 2023 (UTC)[reply]

@Jerome Frank Disciple: The new TOC placement is one of the changes in a new skin Vector 2022. Logged in users can select the old skin Vector legacy at Special:Preferences#mw-prefsection-rendering. PrimeHunter (talk) 17:12, 5 May 2023 (UTC)[reply]

Thanks! I had seen that—I just must have ... Jesus I swear I'm not as old as this makes me sound ... accidentally clicked the "hide" button and then ... not seen the resulting pop-up notification? Listen, I'll be waiting at home for anyone who wants to go ahead and do the humane thing.--Jerome Frank Disciple 17:16, 5 May 2023 (UTC)[reply]

The same has just happened to me and this section has solved the problem for me. But I'll be far, far older than you – I remember watching Queen Elizabeth's coronation on Granny's TV. Thincat (talk) 10:41, 7 May 2023 (UTC)[reply]

I've recently been spending a lot of time trying to polish up Module:External links within its sandbox (although I haven't had the confidence to make any direct changes to the base module yet, even for slight bugfixes — in part because there are no testcases, so I have no reliable way to test my changes), and I just noticed that the function findSiteLinksOnWikidata has an issue: it attempts to read the property langcode from the first layer of the object that getSitelinksFromWikidata returns, but the property doesn't exist — getSitelinksFromWikidata never provides a langcode anywhere. I'm not certain how to fix this; my best guess is that maybe langcode should be requested_sitelink, but I can't verify this because a) I don't have a complete understanding of the module, b) there are no testcases (as mentioned before), and c) I can't even find a page that uses findSiteLinksOnWikidata in the first place.

Does anybody know how to solve this? {{Lemondoge|Talk|Contributions}} 17:45, 5 May 2023 (UTC) (note: if I'm asking this in the wrong place, sorry! I couldn't tell if this should go here, in WT:LUA, in WP:VPM, or somewhere else.)[reply]

I don't know but you could try asking Zyxw who wrote the module. The doc says it is based on no:Module:External links and any update of the code should start by examining the differences between the enwiki and nowiki (yes, that's what it is called!) versions. Also, there is probably somewhere at d:Wikidata:Community portal where people who love Wikidata answer questions. Johnuniq (talk) 00:47, 6 May 2023 (UTC)[reply]

I did not write Module:External links or Module:External links/conf or Module:External links/conf/Sports. As shown in the edit histories, I copied them from no:Modul:External links and no:Modul:External links/conf and no:Modul:External links/conf/Sport on 9 May 2017, with some edits to get them working on the English Wikipedia. no:User:Stigmj created no:Modul:External links on 10 March 2016‎ and according that edit history, it was based on and modified from no:Modul:Sportslenker. I did not know much about creating modules and taught myself what was needed to make it work. I will take a look when I can, but I am not the best person to figure this out. -- Zyxw (talk) 03:19, 6 May 2023 (UTC)[reply]

The reason you can't find a page that uses findSiteLinksOnWikidata is because there is no page that appears to be using it at all. fSLOW is triggered only when the code is given a sitelink prop (SLaaaa) to work with. the getLinks function (which is the only place fSLOW gets fired from) is used by just one template, which has no sitelink target set in its config. You'll probably need to make your own testing config if you want a testcase to work with. no:Modul:External links/conf/Arter#L-30 would probably be some good testing material, since it triggers fSLOW if tested using an article like Wildebeest. Aidan9382 _(talk) 06:55, 6 May 2023 (UTC)[reply]

[2], Here while searching for Yadav article, i got this website in search result. For few minutes, i confused it to be real Wikipedia. Even in search results for Yadav, it appears first in search results. What to do with such websites, which are almost identical and people here are editing with their own Pov, hence providing wrong information to the users.Admantine123 (talk) 08:07, 6 May 2023 (UTC)[reply]

@Admantine123: https://simple.wikipedia.org/wiki/Yadav is real Wikipedia like everything at wikipedia.org, a domain controlled by the Wikimedia Foundation. It's the Simple English Wikipedia. PrimeHunter (talk) 08:47, 6 May 2023 (UTC)[reply]

Ok, then i need to fix many caste related articles there, which are written with lack of WP:NPOV. Admantine123 (talk) 08:50, 6 May 2023 (UTC)[reply]

@Admantine123: Spend your time as you want. The Simple English Wikipedia has the same status as foreign language Wikipedias. It's not part of the English Wikipedia and some of their policies may be different – in particular about the used English. They do have an NPOV policy at simple:Wikipedia:Neutral point of view. Which search did you make where to get simple:Yadav as the first result? Our own search box only searches the English Wikipedia. I don't recall ever seeing the Simple English Wikipedia at top of a Google search. google:Yadav starts with our own Yadav and doesn't show simple:Yadav. PrimeHunter (talk) 12:58, 6 May 2023 (UTC)[reply]

On searching "Yadav caste", we get simple Wikipedia at the top. And below that, our Wikipedia. Admantine123 (talk) 17:38, 6 May 2023 (UTC)[reply]

OK, for that search Google chooses a featured snippet from simple:Yadav, maybe because it sounds more like an explanation of the seach term than something in Yadav. If the words are swapped then "caste Yadav" has Yadav at top without giving a featured snippet. PrimeHunter (talk) 19:21, 6 May 2023 (UTC)[reply]

simple: is not a mirror. Some of their pages (primarily modules and templates) are transwikid from English Wikipedia, but the articles, and the site in general, mostly are not. --Redrose64 🌹 (talk) 23:16, 6 May 2023 (UTC)[reply]

This is a generlization of a weird layout noted in Teahouse. When there are multiple right-hand images or floated items (infobox/navbox), they stack on the right side. If this is followed by a left-hand image, it vertically aligns with the last of the left-hand stack.

That seems like a reasonable effect: if I wanted the left-hand image to be higher, such as aligned with an earlier image in the right-hand stack, I would have placed it earlier in the wiki-source.

The problem is when the right-hand image-stack dangles down from an earlier section of an article. In that case, the left-hand image in the later section is pushed down by the right-hand stack. That is contrary to the purpose of using left/right to avoid images from getting pushed too far down due to stacking. It gives weird effects and is difficult to diagnose, let alone resolve easily:

foo

bar

bar bar bar bar bar

Before you say "well, stop stacking in the previous section", I'll point out that this is the standard situation in any article with more than one infobox/navbox in the lede. Is there any way to have I guess the opposite of {{clear}}? Or a template to put multiple infoboxes in a single container? DMacks (talk) 09:34, 6 May 2023 (UTC)[reply]

Is this a software "feature" (perhaps in the underlying CSS) to reduce sandwiching? The issue is reported here at the Teahouse. Esowteric + Talk + Breadcrumbs 09:42, 6 May 2023 (UTC)[reply]

{{Stack}} handles this. I have used it in the article reported at the Teahouse.[3] PrimeHunter (talk) 12:22, 6 May 2023 (UTC)[reply]

Thanks! DMacks (talk) 18:55, 6 May 2023 (UTC)[reply]

It is not a feature, just a reality of dealing with floating items that must clear themselves. Izno (talk) 16:18, 6 May 2023 (UTC)[reply]

This might be the only time in the history of ever that tk can do something better than other gui toolkits. DMacks (talk) 18:55, 6 May 2023 (UTC)[reply]

Why do I feel like this is something that is the result of any recent MW update, because this probably did not happen before. I clearly remember using |left in images to fix pushed images, and use {{clear}} when I need a content to begin after both left and right-aligned items are shown, instead of the current behavior which I independently discovered just now, see #Left-aligning image with lots of content on right section below. Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:31, 7 May 2023 (UTC)[reply]

Also, this behaviour is different from {{clear}} in the sense that the content after "clear" begins when all above content is finshed. In the case above, and the one I noted below, the top-alignment of left image and that of the last right image is at the same level, as if {{clear}} is being automatically applied just after the second-last right-aligned element, except that it affects only aligned items and not text content. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:37, 7 May 2023 (UTC)[reply]

@CX Zoom I don't know why you feel that way, but floating images have behaved this way almost since web browsers were invented. You can find one of many explanations at WP:MFOP.

If you're curious, this behavior is prescribed by the CSS1 spec (and unchanged in later specs):

5. A floating element's top may not be higher than the top of any earlier floating or block-level element.

https://www.w3.org/TR/CSS1/#floating-elements

I think the rule exists to allow text to be laid out on the page in a single pass. Otherwise, a left-floated image could push down the right-floated images that are placed before it, which in turn could push down the left-floated images further, which could push down the right-floated ones again, and so on. Matma Rex talk 19:46, 7 May 2023 (UTC)[reply]

Ahh, that makes sense. —CX Zoom[he/him] ^{(let's talk • {C•X})} 19:37, 8 May 2023 (UTC)[reply]

Is there any way to create a new portlet that doesn't involve just building the raw html? I've forked a script that does that, and it's a major PITA to ensure it works on every skin. It would be nice if there was a skin-agnostic way to add a custom portlet to a page (preferably using the MediaWiki api). Does anyone know of such a way? – MaterialWorks 11:59, 6 May 2023 (UTC)[reply]

phab:T303488. Izno (talk) 16:17, 6 May 2023 (UTC)[reply]

When I edit Daisy Bacon in VE using Vector 2022 I get this at the top of the screen instead of the toolbar -- it appears to be stuck halfway through the display sequence for a VE session. When I edit Pachysentis it works fine and I get the toolbar at the top. The problem doesn't occur in legacy Vector. In fact the VE session appears to be fully initialized because I can use the keyboard shortcuts ctrl-shift-K and ctrl-shift-S to add citations and save the article, so it's only a problem when I want to do something that I haven't memorized the keystroke for. Any idea why this might be happening? Mike Christie (talk - contribs - library) 13:15, 7 May 2023 (UTC)[reply]

... and it's now happening only intermittently. This has been happening for a while, though, so if anyone has an idea what might cause this that would be good to know. Mike Christie (talk - contribs - library) 13:44, 7 May 2023 (UTC)[reply]

Hi there. I have a log of all my recent PRODs at User:Magnolia677/PROD log. Is there a way to see my AFD log too? Thank you! Magnolia677 (talk) 15:33, 7 May 2023 (UTC)[reply]

Found it! Thanks. Magnolia677 (talk) 15:37, 7 May 2023 (UTC)[reply]

Resolved

 – This particular issue fixed. Discussion on same issue at #Left-image after multiple right-images in preceding section above. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:33, 7 May 2023 (UTC)[reply]

I've done this in the past, when the content on the right is too much, adding |left to the image aligns it to the left and displays it where the image is invoked. But Special:Diff/1153659695 did not do that, the image continues to be displayed at the end of the page. Commenting out the sidebars fixes it, but I fail to understand what difference in alignment does the infobox and sidebar have, that the infobox won't displace the image to the end, but even a single sidebar would. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:42, 7 May 2023 (UTC)[reply]

The 'thumb' right aligns the image. Alternative: replace thumb by x150px. Uwappa (talk) 15:55, 7 May 2023 (UTC)[reply]

That does not appear to be true, and that option removes the caption and disregards editors' thumb size preferences, which is probably not desirable. I see it on the left, but after all of the infobox and sidebar content. See the above section re {{stack}}, which worked in this case as well. There is a bit of a sandwich effect for me, since I have my thumb size set high, but it looks fine to me when I am logged out. – Jonesey95 (talk) 16:03, 7 May 2023 (UTC)[reply]

@Uwappa: See WP:EIS, |thumb and |left may be used together. The former puts a caption below the image and a frame around both, it defaults to floating right but this last may be overridden with |left. The problem here is nothing to do with left or right alignment though, it is that floated box-type objects (whether they be images (framed or otherwise), sidebars, infoboxes, portal boxes or anything else that isn't headings or inline text) are always displayed in the same vertical order that they occur in the page source. When the page source has a long sequence of right-floated objects (in this case there are five: {{Infobox country|...}} {{Contains special characters|Tibetan}} {{Contains special characters|Uncommon Unicode}} {{Princely states topics}} {{History of South Asia}}) that are followed by a left-floated object (the image in question here), the upper edge of that image cannot be drawn any higher than the upper edge of the last sidebar preceding it, i.e. {{History of South Asia}}. There are three fixes: (i) use {{stack}}; (ii) cut down the number of sidebars; (iii) (best) add plenty of content, particularly to the Nepalese-Bhutanese domination section (because it preceded the image concerned), perhaps to the lead section as well. --Redrose64 🌹 (talk) 20:26, 7 May 2023 (UTC)[reply]

Hello Technical supporters I used to use this excel to wiki converter up to 20 days ago when it stopped working, who can repair it? or guide me to an easy similar converter? [4]. Abu aamir (talk) 15:53, 7 May 2023 (UTC)[reply]

See Wikipedia:Village pump (technical)/Archive 204 § Excel to Wikipedia tables for a discussion of options, including using copy and paste within the Visual Editor, and a link to a page that points to different tools. isaacl (talk) 16:10, 7 May 2023 (UTC)[reply]

See Help:Table#Tables and the visual editor (VE). The sections that follow provide much help. There are a couple converters linked too. Copying and pasting to and from tables to the Visual Editor, LibreOffice Calc, web pages, etc. is covered too. --Timeshifter (talk) 20:46, 7 May 2023 (UTC)[reply]

@Abu aamir I maintain that tool and was not aware that it wasn't working. I am trying to debug it now. --Ahecht (TALK
PAGE) 22:06, 8 May 2023 (UTC)[reply]

@Abu aamir I restarted the webserver and it is now working. Not sure what caused it to fail before. --Ahecht (TALK
PAGE) 22:10, 8 May 2023 (UTC)[reply]

• @Ahecht thanks for your effort, it is very good tool.--Abu aamir (talk) 06:55, 10 May 2023 (UTC)[reply]

Does there exist an established way to add a preview image to an article? By preview image, I mean an image that shows up in search results/suggestions on mobile Wikipedia, or when you link to a Wikipedia article from a social platform (i.e. Twitter, Discord, etc).

Usually, the first image of the article is used automatically, but sometimes this is a bad default. For example, when you link to Carolina–Duke rivalry, the preview image is the Duke logo, which is not ideal. We have File:Duke v Carolina logos.svg which would make for a much better preview image; however, I don't know the best way to make it become the preview image. I suppose I could put something like <div style="display:none">[[:File:Duke v Carolina logos.svg]]</div> at the top of the article, but that seems a bit janky and I was wondering if there's a template or something. Cheers, IagoQnsi (talk) 23:05, 7 May 2023 (UTC)[reply]

@IagoQnsi: The image in search results/suggestions must be displayed in the lead and selected by mw:Extension:PageImages#Image choice. I don't know whether Twitter and Discord use the page image. PrimeHunter (talk) 23:52, 7 May 2023 (UTC)[reply]

@IagoQnsi You can exclude images from being the page image by adding the "notpageimage" class, e.g. [[File:Example.png|class=notpageimage]]. --Ahecht (TALK
PAGE) 21:55, 8 May 2023 (UTC)[reply]

Please can someone advise how to update e.g. Category:Fully protected redirects to Category:Wikipedia fully protected redirects, following a valid request at WP:CFDS? This is part of a set now listed at WP:CFDWM#Other, but the old category still contains members that do not depend on {{R fully protected}}. – Fayenatic London 11:11, 8 May 2023 (UTC)[reply]

By looking through the remaining redirects and finding out where the category comes from? Spot checking a few, I see several that are directly categorized, and I also see that other redirect protection level templates like {{R semi-protected}} can apply the category if the article is fully move-protected. You might start with those. Anomie⚔ 11:42, 8 May 2023 (UTC)[reply]

This search finds three templates. When you think the template cases are done, remove "NO BOTS" from WP:CFDWM#Other and see if the bot does the rest. It has admin rights. PrimeHunter (talk) 12:05, 8 May 2023 (UTC)[reply]

Thank you, those templates seem to cover all cases. I had thought the categories were being populated by some hidden cascade system.

The bot won't work where it can't find a category to replace. It is either a matter of waiting or doing dummy edits to force the template updates to propagate. – Fayenatic London 15:12, 8 May 2023 (UTC)[reply]

Ah, yes I see, there were some residual pages coded directly as members of Category:Fully protected redirects, so I fed them to the bot. I missed a trick there – I could have asked someone to replace the category code with {{R fully protected}}, and have now requested help with this at Wikipedia:AutoWikiBrowser/Tasks#Replace_category_with_template. – Fayenatic London 19:14, 8 May 2023 (UTC)[reply]

I'm making a template (Template:User friends) and I want to be able to put a link in the text in the "name of friend" parameter, but I can't figure out how. Any ideas?

Sincerely, --AugustusAudax (talk|contribs) P.S: Aliens exist 14:11, 8 May 2023 (UTC)[reply]

Something like this: This user is [[real life]] friends with [[User:{{{1}}}]]? —  Jts1882 | talk  14:21, 8 May 2023 (UTC)[reply]

Or [[User:{{{1}}}|{{{1}}}]] to not display "User:". PrimeHunter (talk) 14:28, 8 May 2023 (UTC)[reply]

Thanks! Sincerely, --AugustusAudax (talk|contribs) P.S: Aliens exist 15:33, 8 May 2023 (UTC)[reply]

As copy-pasting an article's subsection for wikilinking transforms spaces into redundant underscores, is there a way to wikilink without manually removing underscores in every instance (particularly to simplify syntax and to limit character count)? E.g. [[Wikipedia#Policies and laws|Wikipedia's policies and laws]] instead of [[Wikipedia#Policies_and_laws|Wikipedia's policies and laws]]. Brandmeister^talk 21:05, 8 May 2023 (UTC)[reply]

{{slink}} exists. Izno (talk) 21:18, 8 May 2023 (UTC)[reply]

User:Nardog/CopySectLink might help you. Nthep (talk) 21:27, 8 May 2023 (UTC)[reply]

If you use the reply tool or the new topic tool in visual mode (you can turn them on at Special:Preferences#mw-prefsection-editing-discussion), you can just copy-paste the full link like "https://en.wikipedia.org/wiki/Wikipedia#Policies_and_laws" and it will be automatically prettified to become an internal link like "Wikipedia#Policies and laws". Matma Rex talk 23:08, 8 May 2023 (UTC)[reply]

Thanks, set the CopySectLink tool. Brandmeister^talk 09:16, 9 May 2023 (UTC)[reply]

MediaWiki message delivery 00:34, 9 May 2023 (UTC)[reply]

The tipsy removal looks to impact these 35ish scripts. Izno (talk) 01:04, 9 May 2023 (UTC)[reply]

For scripts that use jQuery UI (which is most of the above), it's more sensible and easier to migrate to jquery.ui.toolip – which is what Twinkle did 3 years ago. Tipsy is a jQuery plugin after all. – SD0001 (talk) 06:09, 9 May 2023 (UTC)[reply]

Pedantic correction: Half of logged-in desktop users who are using Vector 2022 will see an interface... I haven't yet found anything to explain why (if it's indeed the case, as implied) logged-out desktop users will see no change. — JohnFromPinckney (talk / edits) 07:39, 9 May 2023 (UTC)[reply]

The note above from WMF staff says Due to privacy and technical restrictions, we are only able to run this test with logged-in users. I looked through half a dozen phab tickets and found mention of the "logged in only" restriction, but no explanation about why it was put in place. This A/B test appears to be the reason for the new ".vector-feature-zebra-design-disabled" CSS class that has been stuck to all sorts of other classes like gum to the bottom of a shoe, interfering with custom CSS. If you are one of the lucky 50% to see the Zebra design during the A/B test, or if you figure out how to script your way into the test, you will get a ".vector-feature-zebra-design-enable" CSS class instead, AFAICT. – Jonesey95 (talk) 13:57, 9 May 2023 (UTC)[reply]

Probably caution around that even a cookie that just assigns the user to the A or B bucket might be seen as a "tracking" cookie under various laws, and lack of any other good way to do the bucketing. Anomie⚔ 12:07, 10 May 2023 (UTC)[reply]

Well, heck. I didn't actually look on this same page; I just followed the links provided in the News item. (And it's probably there on the mw pages, too, and I just didn't see it.) Thanks for the tip, Jonesey. — JohnFromPinckney (talk / edits) 13:21, 10 May 2023 (UTC)[reply]

I recently came across a WP:PEIS in ATP 1000, that I was able to resolve by replacing flag with flagg|cxxlo. ATP 1000 and WTA 1000 have each 30+ transcluded sections with a list of singles and doubles tennis winners per season (1990–present). At what point will the page size limit be exceeded and how does one prevent it?

I experimented in my sandbox and replaced #if:1 with P1|1=, and flag(icon) with flagg|cxxlo, but that didn't resolve the issue. By replacing flag(icon) with flagg in the source sections pages before transclusion ([14], [15], [16]) I was able to reduce the page size limit after transclusion but only to a degree.

Is there a way to further reduce the page size template expansion being exceeded and where can I calculate how much template data in kB has been expanded? Qwerty284651 (talk) 15:54, 9 May 2023 (UTC)[reply]

You can delete the {{P1|1= wrapper entirely; the only result will be a little bit of excess whitespace, and the PEIS will be about half. See Wikipedia:Template limits#How can you find out? to find out how much room you have left. * Pppery * _{it has begun...} 16:24, 9 May 2023 (UTC)[reply]

You can avoid the whitespace by removing the newlines before and after the section transclusion. PrimeHunter (talk) 17:41, 9 May 2023 (UTC)[reply]

I realized what's the problem. It's the 54 (6 players x 9 events) flagicons that are section transcluded. Replacing them with flagg|cxxlo reduces the PEIS by 28kB (from 44.000 bytes [17] --> 16.000 bytes [18] (that is 520 bytes per flagicon) in all 35 articles (1990-present) will drastically reduce the current PEIS of ATP 1000, which sits just below the page size limit [19]. Removing whitespace is barely noticeable. Removal of the {{P1|1= wrapper significantly reduces PEIS at the cost of excess whitespace. Qwerty284651 (talk) 23:44, 9 May 2023 (UTC)[reply]

Given both sister articles ATP– and WTA 1000 expand yearly, that PEIS will be reached eventually. I will defer from removing P1 until PEIS limit is reached again (in 10+ years). After P1 removed the articles are still over PEIS, then we are left with 2 choices: split article (usually because of rebranding) or substitute 2–5 transcluded sections as a last ditch effort at the cost of longer page loading time (server workload)... Qwerty284651 (talk) 23:59, 9 May 2023 (UTC)[reply]

Final result: with all 35 articles flagicons replaced with flagg|cxxlo (size reduced by a 1/3) [20]. Qwerty284651 (talk) 00:42, 10 May 2023 (UTC)[reply]

And I went and removed the flag icons representing countries, since it is against wikipedia MOS and Tennis Project consensus to use them for locations anyway. Only for player sports nationality. Fyunck(click) (talk) 03:50, 10 May 2023 (UTC)[reply]

@Fyunck(click), thank you for that. Duly noted for next time: Flag icons only sport athletes nationality. Qwerty284651 (talk) 07:15, 10 May 2023 (UTC)[reply]

More templates needed...e.g.: Chasing Amy : Box Office Mojo: Template:Mojo title - [21]

• The Numbers (website): https://www.the-numbers.com/movie/Chasing-Amy
• Lumiere (database): https://lumiere.obs.coe.int/movie/4223

.... 0mtwb9gd5wx (talk) 01:44, 10 May 2023 (UTC)[reply]

Hey all. It's been a while. This is an FYI as I'm aware that when things break, this is among the first places that many Wikimedians would check, hoping to find relevant information.

We have recently learned that we're currently unable to access the WorldCat API, which provided the ability to add citations using ISBN numbers. This affects citations made with the VisualEditor Automatic tab, and the use of the citoid API in gadgets and user scripts, such as the autofill button on refToolbar. The Editing team is investigating options.

I would like to gather a bit more information before sending out a Mass Message to other wikis; in the meantime, interested folks can keep tabs on the situation via Phabricator, or by reading the next issues of Tech News. If you know of any users or groups who rely heavily on this feature (for instance, someone who has an upcoming editathon), I'd appreciate it if you shared this update with them.

On behalf of the Editing team, Elitre (WMF) (talk) 08:24, 10 May 2023 (UTC)[reply]

Thanks for the notification. I have suggested to inform users at Wikipedia talk:RefToolbar#ISBN autofill broken. PrimeHunter (talk) 14:32, 10 May 2023 (UTC)[reply]

When attempting to access link from the reference desk, regarding a "community survey", the following error occurred:

Erreur interne du serveur

CDbConnection failed to open the DB connection.

Une erreur interne est apparue lorsque le serveur web traitait votre requete. Veuillez contacter the webmaster pour signaler ce problème.

Merci.

Link = https://questionnaires.marsouin.org/index.php/978939 --136.56.52.157 (talk) 09:03, 10 May 2023 (UTC)[reply]

I get a different error, I get

Internal Server Error / The server encountered an internal error or misconfiguration and was unable to complete your request. / Please contact the server administrator at postmaster@questionnaires.marsouin.org to inform them of the time this error occurred, and the actions you performed just before this error. / More information about this error may be available in the server error log.

Stuartyeates (talk) 09:22, 10 May 2023 (UTC)[reply]

I have filed phab:T336353. —TheDJ (talk • contribs) 09:23, 10 May 2023 (UTC)[reply]

Hello,

thanks for the feedback

there is a problem with OVH. We are on it

I've asked to unplug the banner (and to replug it once solved)

Sorry! Jullienn (talk) 09:29, 10 May 2023 (UTC)[reply]

I have disabled the banner until the survey can be fixed. Peter Coombe (WMF) (talk) 09:30, 10 May 2023 (UTC)[reply]

Thank you! Jullienn (talk) 09:34, 10 May 2023 (UTC)[reply]

quick question @Pcoombe (WMF) : also in the French/Spanish / Turc language versions? Jullienn (talk) 09:35, 10 May 2023 (UTC)[reply]

Yes, they are all part of the same CentralNotice "campaign" so are all disabled. Peter Coombe (WMF) (talk) 09:41, 10 May 2023 (UTC)[reply]

@Pcoombe (WMF): a duplicate discussion at WP:Village pump (miscellaneous)#Marsouin survey error. So is VPT the right forum for any future banner issues as well? Jay 💬 10:51, 10 May 2023 (UTC)[reply]

No, see meta:CentralNotice/Report_an_issue —TheDJ (talk • contribs) 11:02, 10 May 2023 (UTC)[reply]

Volunteer me happened to see this VPT discussion on his watchlist so that is how I became aware of it. But generally the quickest way to get CentralNotice admin attention is as described at m:CentralNotice/Report an issue. Peter Coombe (WMF) (talk) 11:17, 10 May 2023 (UTC)[reply]

The survey links are working again. The banner is planned to go back up on English Wikipedia (at a reduced traffic level) at 12 UTC i.e. in approximately 40 minutes. Peter Coombe (WMF) (talk) 11:22, 10 May 2023 (UTC)[reply]

The banner is back, and from the questionnaire server's side, everything is working fine this time. Sorry for the inconveniences! Jullienn (talk) 12:29, 10 May 2023 (UTC)[reply]

• Got this banner failing again. Please note, this is not managed by the English Wikipedia, I've reported it at meta:User_talk:Pcoombe_(WMF)#More_banner_problems, as this is being managed by WMF. — xaosflux ^Talk 13:07, 10 May 2023 (UTC)[reply]

A week ago I initiated Wikipedia:Help desk/Archives/2023 May 3#Losing login. A few minutes ago, for the first time in a week, I experienced the same problem. Is this a known problem?--Bbb23 (talk) 15:31, 10 May 2023 (UTC)[reply]

I don't know if it's known in the Phab ticket sense, but along with the other responses that you got in the last thread, I have that issue from time to time as well. ScottishFinnishRadish (talk) 15:44, 10 May 2023 (UTC)[reply]

I'm not getting what you're getting, but related: in 2023 I've been strangely getting logged out a lot from my devices. Unlikely to be actually related though. SWinxy (talk) 07:01, 11 May 2023 (UTC)[reply]

This might be phab:T326281 or one of the related issues. Browsers have lately become more strict about accessing cookies for privacy and security reasons, which breaks logins, especially crosswiki. Check if you have any tracking protection/privacy extensions enabled; they might be breaking the logins. Galobtter (talk) 08:41, 11 May 2023 (UTC)[reply]