In T420977#11768026, @egardner wrote:

Hi @dmaza – is this a new feature request for the 3D extension? Please provide a bit more context and we can triage appropriately.

@hnowlan who would be the right person to talk to about moving away from headless-gl and migrate to puppeteer considering that 3d2png runs on thumbor's image? Not sure if this is at all possible.

@donmccurdy @OpenDEM did you ever get https://github.com/OpenDEM/3D2PNG_GLB_Support to work?

In T419473#11694263, @thcipriani wrote:

Hrm. Seems like it's not rate limiting.

In fiddling with it in patchdemo a bit, I realize that
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/QuickInstantCommons/+/d24e4865b1747798d32fffefc33d29e0ac5cec58/src/Hooks.php#73

is coming back with an array of empty arrays on patchdemo, so when it tries to grab the image from commons, the image name is blank.

I wonder if this is related to T299953: Normalize imagelinks table since li_to is used in that query (c.f. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1248863).

In T416723#11684530, @OpenDEM wrote:

As far as testing the changes, unfortunately the only way is to install a local copy of mediawiki and the 3D extension with it's dependencies.

@Carsten_Steger That's exactly why we created a simple HTML/JS Testviewer. I've added the latest adjustments here: https://opendem.github.io/WikiMediaExtension3D_Test_GLB_Format/stl_test_3_2026.html

The code is available on Github: https://github.com/OpenDEM/WikiMediaExtension3D_Test_GLB_Format
No build is necessary, only a local web server due to CORS issues.
I have added another critical .stl model.

@dmaza If you have time, please take a look at the code to see if I have taken all changes into account correctly. Visually, it looks the same, as far as I can tell.

In T416723#11683067, @Carsten_Steger wrote:

@dmaza Thank you very much for your patch! I would love to test it, but don't know how I could do that. In any event, the code changes in your patch look very good to me. I have one suggestion that could be added to the patch because of your changes. Currently, mmv.3d.js contains the following call (line 45 with your patch applied):
this.camera = new THREE.PerspectiveCamera( 60, dimensions.ratio, 0.001, 500000 );
The huge z range of 0.001 to 500000 leads to a very inefficient use of the precision of the depth buffer. Since your patch scales the models to a much smaller depth range, at least the far value of 500000 of the frustum could be drastically reduced, which should result in better quality depth rendering.

This is a duplicate of T416723: STL files are rendered incorrectly by the media viewer 3D extension. There is a fix awaiting review on the other task

In T345953#11635136, @OpenDEM wrote:

In T345953#11634335, @dmaza wrote:

I agree. My goal is to follow up with updating to threejs 162, and then see what can be done to move GLB support forward.

@dmaza That sounds great! When it comes to .glb support, we should get together. A few things have already been tried here, which have been documented here: https://commons.wikimedia.org/wiki/Commons:Textured_3D

If I can help with the patch, please let me know.

In T345953#11633776, @OpenDEM wrote:

@dmaza The patch was released over a year ago, so there are bound to be more security vulnerabilities now.

I managed to go from 20 vulnerabilities (2 low, 6 moderate, 12 high) to 12 vulnerabilities (2 low, 3 moderate, 7 high)

npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated kad-memstore@0.0.1: This package is no longer maintained.
npm warn deprecated kad-fs@0.0.4: This package is no longer maintained.
npm warn deprecated rimraf@2.4.5: Rimraf versions prior to v4 are no longer supported
npm warn deprecated lodash.clone@4.5.0: This package is deprecated. Use structuredClone instead.
npm warn deprecated tar@6.2.1: Old versions of tar are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated glob@10.5.0: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated glob@6.0.4: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me

Tested and running with node v18.20.8 locally.

In T368423#11591410, @KSiebert wrote:

@dmaza Should I keep this in progress? Do you think we might go back to it in a future Wishathon?

AC2 issue is tracked here T415131: Votes should be visible on entities in "Under Review" status

In T366194#11553227, @KSiebert wrote:

@Aklapper Yes, the wishlist extension has replaced the gadget completely and tickets can be archived and codebase can be archived. @dmaza is there anything left in the codebase we might need?

I suggest we focus on editing .chart metadata, and only importing or referencing .tab files (at least initially), and then putting them together via API
A good reference for what I have in mind is this Figma plugin https://pavel-kuligin.gitbook.io/chart/getting-started

@GMikesell-WMF As I'm going thru the Acceptance criteria, I don't see the wording issue you are mentioning on each of the failing tests. Wish creation, Wish status change, Wish focus area change, Focus area creation, Focus area status change are the actions in the drop-down for the Community Requests log-type, it is not a requirement for those exact words to be part of the log text as far as I can see. Am I missing something?

ping @GMikesell-WMF

@GMikesell-WMF Let me know if this is working as expected now after our discussion a few days ago

I'll take over since MusikAnimal is on Sabbatical

I'll take a look at AC1.

Thank you @Samwilson

T409613 should be worked on first

❓ @dmaza Where should "Declined" be lowercase since the only time I see it lowercase is in "Edit", as seen in the video? Even clicking on the URL doesn't show any lowercase.

I can't reproduce it locally. We'll revisit later

❌ AC2: Confirm that only wishes with the status 'Declined' are shown.

"Declined" should be lowercase, all statuses values are lowercase. If you go to https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/Wishes?statuses=declined it works just fine

In T368423#11380266, @aude wrote:

For the overall wish from the community for improved pagination on the special pages, we are now not sure that a Pagination vue component would be what we need.

We might just need HTML elements with codex styles.

https://meta.wikimedia.org/wiki/Community_Wishlist/W186

We could try and do something similar to what was done for HTMLForm "displayFormat" and support the current navigation output and a "codex" looking one? Would that make sense?

Thank you @CCiufo-WMF. I wanted to make sure there weren't any known blockers or dependencies before this could be picked on.

@CCiufo-WMF We are considering this work as part of our next wishathon. Is there a particular reason why this was moved to the backlog? Is the proposed designs by @bmartinezcalvo good to go as is? Any help on how to move this forward is greatly appreciated. Thanks.

@GMikesell-WMF TIL The category is not showing because there is a preference to show/hide hidden categories. Preferences > Appearance > Advance Options > Show hidden categories.

❓ AC1: Confirm that an error message is displayed indicating that the type field is missing or invalid.

Double quotes are indicating empty. I think it's fine considering that this is only on preview mode

Acceptance criteria might be in conflicts with T406670: Automatically add a support vote on behalf of a wish proposer depending on how we solve it. I'll bring it up in other channels.

When a wish is created, make a request to action=wishlistvote on behalf of the user. Leave the comment blank – they'll be able to change it later if they want to.

To be clear, the comment can only be changed by editing the /Votes page or after the status is changed to one that allows voting.

Pretty sure this is related to T406669: Vote count isn't changed to zero when all votes are removed. All of the wishes I tried had already been voted on and the Votes pages exists.

I'm gonna give a shot at this but I'm not sure how to approach it. We count votes when we render them, so if there are not calls to the parser function the count is just ignored and thus this issue. I think we need special handling for votes pages on onLinksUpdateComplete perhaps? Open to ideas

In T406674#11264111, @Samwilson wrote:

The statuses are stored in configuration and have unique numerical IDs. This means "Accepted" will have to come last in the config

I might be missing something here. Can't we just store them out of numerical order, and they'll display in the order we want? (See the above patch.)