extensions
extensions copied to clipboard
TurboWarp
Extension gallery enhancement: add search bar
This is a small pull request that adds a client-side JS search bar to the extension gallery. It searches by the contents of the titles and descriptions. It doesn't require that a result that starts with the search query, only that the results' strings contain the search query.
Potentially could also add sort/filter too
https://github.com/user-attachments/assets/69752cae-142b-4d35-a489-3467fe1c8a71
We definitely need a tags/sort-filter system
I can put it to the right of the search bar tomorrow, but it's getting a little late here
Tags would be interesting, but since this is client-side and relies on the page being already loaded we need a way to inject these and store them permanently when the page is loaded by EJS....
I can probably do a "filter by author" and "sort alphabetically" tomorrow as well, but sorting by release date would be tricky and would also need a similar solution to tags
@yuri-kiss Thanks so much for the help.
I'd still like to add some sort/filter features to this
Working on a sort system, but things are about to get tricky.
@CubesterYT We need to decide how we're going to go about assigning attributes (e.g., tags, release dates, etc.) to various extensions. we could do it in extensions.json but that would quickly clutter things. I might also need to modify the homepage renderer to include some data attributes in the <div> of each element.
Sorting alphabetically is relatively easy, sorting by release date is harder. Filtering by category is virtually impossible without extensions assigned to categories.
Added a simple sort system that can sort by the original order (the order in extensions.json), ABC, and ZXY order.
@CubesterYT the extension search bar in the add extension menu of the scratch-gui / TW editor doesn't have any sort/filter features..
It would really be a pain trying to tag all of the various extensions. Is there anyway that just a search bar and XYZ, ZXY, and default sorting is acceptable for production? of course, we could always add it later, but my tiny brain cells can't think up a way to reasonably do it without modifying extensions.json and that would be a pain for JavaScript trying to manage and for users trying to make new extensions...
We could put tags in a comma-delimited comment in the header metadata of individual extensions and iterate through the files in JS to get which tags are there:
// Name: Ammo Physics
// ID: masterMath_AmmoPhysics
// Description: Advanced three dimensional rigid body physics.
// By: -MasterMath- <https://scratch.mit.edu/users/-MasterMath-/>
// License: MPL-2.0 and MIT
// Tags: 3D, physics, rigid body
So for example even though neither the title or description contains "3D", the tag does, so Ammo Physics would show up with Simple3D. Searching by tags would be case insensitive, so "3d" would also work.
We could also possibly display tags on the website below the description as small Bootstrap badges.
The trickier part would be keeping track of release dates, as the user doesn't know beforehand when their extension will first be merged into the gallery. I could write a custom workflow / GitHub action that executes when a PR with a "pr: new extension" tag has been merged to automatically create a new comment at the bottom of the metadata, such as:
// Name: Ammo Physics
// ID: masterMath_AmmoPhysics
// Description: Advanced three dimensional rigid body physics.
// By: -MasterMath- <https://scratch.mit.edu/users/-MasterMath-/>
// License: MPL-2.0 and MIT
// Tags: 3D, physics, rigid body
// Released: 1/1/2026
and then the JS file for searching and sorting could read the released comment to sort extensions by the date they were released, but there could potentially be many security concerns with executing a workflow on a PR before it's completely merged.... Of course the workflow would only work on New Extension PRs so it wouldn't override the original release date when an extension is updated. Also don't really know how that would work but these are ideas and suggestions and I'm looking for feedback.
Filtering would also not be fun to integrate but it's definitely possible... There'd probably be a button or something that brings up a modal or tooltip or something with some check boxes that you can use to filter but I don't know what we would filter by
We could put tags in a comma-delimited comment in the header metadata of individual extensions and iterate through the files in JS to get which tags are there:
// Name: Ammo Physics // ID: masterMath_AmmoPhysics // Description: Advanced three dimensional rigid body physics. // By: -MasterMath- <https://scratch.mit.edu/users/-MasterMath-/> // License: MPL-2.0 and MIT // Tags: 3D, physics, rigid bodySo for example even though neither the title or description contains "3D", the tag does, so Ammo Physics would show up with Simple3D. Searching by tags would be case insensitive, so "3d" would also work.
We could also possibly display tags on the website below the description as small Bootstrap badges.
The trickier part would be keeping track of release dates, as the user doesn't know beforehand when their extension will first be merged into the gallery. I could write a custom workflow / GitHub action that executes when a PR with a "pr: new extension" tag has been merged to automatically create a new comment at the bottom of the metadata, such as:
// Name: Ammo Physics // ID: masterMath_AmmoPhysics // Description: Advanced three dimensional rigid body physics. // By: -MasterMath- <https://scratch.mit.edu/users/-MasterMath-/> // License: MPL-2.0 and MIT // Tags: 3D, physics, rigid body // Released: 1/1/2026and then the JS file for searching and sorting could read the released comment to sort extensions by the date they were released, but there could potentially be many security concerns with executing a workflow on a PR before it's completely merged.... Of course the workflow would only work on New Extension PRs so it wouldn't override the original release date when an extension is updated. Also don't really know how that would work but these are ideas and suggestions and I'm looking for feedback.
Filtering would also not be fun to integrate but it's definitely possible... There'd probably be a button or something that brings up a modal or tooltip or something with some check boxes that you can use to filter but I don't know what we would filter by
I feel like you could just make a separate extension search metadata json
I feel like you could just make a separate extension search metadata json
Then contributors have to find yet another file to add metadata too, even though there's already a place for metadata at the top of their .js files. Wouldn't it just make things more complicated?
Then contributors have to find yet another file to add metadata too, even though there's already a place for metadata at the top of their .js files. Wouldn't it just make things more complicated?
i think she means it would be auto-generated from the js file comments, LIKE IT IS ALREADY DONE for the gallery metadata used in the editor
Then contributors have to find yet another file to add metadata too, even though there's already a place for metadata at the top of their .js files. Wouldn't it just make things more complicated?
i think she means it would be auto-generated from the js file comments, LIKE IT IS ALREADY DONE for the gallery metadata used in the editor
the top of the extensions is going to be so bloated at this point
So did we want to add filter stuff or just merge this how it is
It'd just be a big mess to code and I don't see any reason that would justify adding it if filter functionality would be limited and not really that helpful
the extensions.turbowarp.org page is lower risk and easier to iterate on
I think it's fine to yolo merge and see what breaks
Okay, I'm prepared to fix anything that will break because it's probably a matter of what and when instead of if
I've opened this up for merging
Should this be merged or should I add some small enhancements first?
Alright I say we merge this since adding other features would require more in-depth changes to other frameworks
Sorry we've been busy
I have college now CST1229 is existing SharkPool doesn't do much And GarboMuffin works a 9-5
We'll get to things... eventually...
Sorry we've been busy
I have college now CST1229 is existing SharkPool doesn't do much And GarboMuffin works a 9-5
We'll get to things... eventually...
Totally understand, I knew a lot of you were busy I just wanted to clean some things up Good luck on college!