Extension gallery enhancement: add search bar

[Brackets-Coder]

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

video.mp4

[CubesterYT]

We definitely need a tags/sort-filter system

[Brackets-Coder]

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

[Brackets-Coder]

Todo:

• Sort
• Filter

[yuri-kiss]

just some minor nitpicks and changes

[Brackets-Coder]

@yuri-kiss
Thanks so much for the help.

I'd still like to add some sort/filter features to this

[Brackets-Coder]

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.

[Brackets-Coder]

Added a simple sort system that can sort by the original order (the order in extensions.json), ABC, and ZXY order.

[Brackets-Coder]

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

[Brackets-Coder]

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

[yuri-kiss]

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

I feel like you could just make a separate extension search metadata json

[Brackets-Coder]

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?

[CST1229]

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

[yuri-kiss]

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

[Brackets-Coder]

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