Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Let the server name the Media screen's "Used in" sources

Open
  • Is something wrong?
#187 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
56/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript
Domain
backend, frontend

Research direction

Start with Media.jsx and mediaUsageDisplay.js to trace how the Media screen labels usage, then read mediaUsageService.js and the usageId handling in contentAddress.js. Check how the server exposes project media data and how the client makes the current requests. Done means usage labels match today while coming from one request, or the task is closed as not needed.

Written by the indexing model from the issue text.

Description

enhancement

The Media screen makes many requests to name where each file is used; on big multilingual sites one request from the server would be better.

To label its "Used in" lists, Media.jsx (loadUsageTitles) fetches every page, the collection schemas, and each collection's items once per language: 2 + schemas × languages requests on every visit, all concurrent, and a fetch that fails just leaves raw ids. Fine for current themes; on a large site with many collections and languages it grows. The server already resolves these ids (mediaUsageService.js, usageId in contentAddress.js), so one endpoint returning { usageId: { kind, title, language } } for the project's media would replace the fan-out, and the client would keep only the formatting (mediaUsageDisplay.js).

Done when: The Media screen labels its usage from one request, with the same labels as today, or the task is closed as not needed.

Start: Media.jsx, mediaUsageDisplay.js, mediaUsageService.js. Source: 2026-10-18 Codex review of the media usage label fix.

Dominant language
JavaScript
Stars
162
Forks
6
Avg merge
12h 55m
Merged PRs (30d)
2

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from tsiger/widgetizer

All issues in tsiger/widgetizer

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.