[wp-trac] [WordPress Trac] #63953: Improving the Permalink Structure for `?attachment_id=123`

Wed Sep 10 12:17:12 UTC 2025

#63953: Improving the Permalink Structure for `?attachment_id=123`
-------------------------+-----------------------------
 Reporter:  kimjiwoon    |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Media        |    Version:
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 Since I’m not very fluent in English, I prepared two AI-generated versions
 of this proposal. To keep things simple, let me start with the conclusion.

 Currently, the permalink of an **Attachment Post Type** is placed under
 the *uploaded-to* parent post.
 I propose changing the structure so that the permalink is placed under the
 **author** instead.

 For taxonomy, I suggest using **categories**. Multiple categories should
 not be allowed; instead, a **hierarchical directory-style structure**
 should be supported.

 ### Summary

 This ticket proposes a follow-up idea to the concepts discussed in
 [#47839](https://core.trac.wordpress.org/ticket/47839 "null") (Extended
 file management in Media Library). While that ticket focused on general
 media management, this proposal takes a different direction. It
 prioritizes the scalability of WordPress in multisite and multi-user
 environments and aims to improve compatibility with external systems like
 ActivityPub (Fediverse) and Openverse. I believe that adopting these
 broader goals will lead to fundamental improvements that benefit all
 users.

 The design is inspired by the user experience of platforms like Pinterest,
 Misskey Drive, and FileBird Pro. Users familiar with these systems will
 find the core concept of this proposal easy to grasp.

 ### The Problem: The Current Media File Structure

 A WordPress media file currently has two distinct levels, which are not
 cleanly connected:

 1. **The Physical File**: This is the file's URL on the server, e.g.,
 `/wp-content/uploads/2025/08/myimage.jpg`.
 2. **The Attachment Post Type** (`post_type = 'attachment'`): This is a
 separate entry in the `wp_posts` table that provides the media item with
 its own dedicated post page, e.g., `?attachment_id=123`.

 In the current Media Library, the "Uploaded to" field only displays the
 first Post/Page a media item is attached to, even if it is used in
 multiple locations. This contrasts with platforms like **Misskey Drive**,
 which allow viewing *all notes* where a media file has been attached,
 providing a much clearer and more organized user experience.

 ### Proposal: A Canonical and Semantic Permalink Structure

 I propose a unified and semantic permalink structure for federated media.
 This would resolve the current inconsistencies and make the system more
 robust for both human and machine readability.

 A proposed structure could be:

 - `/%author%/%media%/%_boards%/%filename%?w=300/` for a "drive feed" or
 media gallery view.
 - `/%author%/%media%/%_pins%/%filename%?w=1024/` for an individual media
 object page.

 ### Design Principles & Inspiration

 This design is informed by key principles from existing WordPress features
 and external systems.

 **From Core Trac Ticket #47839:**I have adopted the key principle of
 implementing a **virtual folder structure using hierarchical taxonomies
 rather than actually moving files.** This is crucial for avoiding
 backwards compatibility issues.

 - **Folders vs. Categories**: A virtual **Folders** approach is preferred,
 where an image can be placed into a single folder. This simplifies the
 user experience and reduces the complexity that can come with a multiple-
 category approach.
 - **Virtual vs. On-Disk**: The virtual folder structure must be
 implemented without altering the physical location of files on the
 server's hard drive.

 Furthermore, this virtual structure should be seamlessly integrated into
 the "Add Image" interface and allow for the creation of galleries based on
 these virtual folders.

 **From FileBird Pro:**My concept is also inspired by a FileBird Pro-like
 design, incorporating the following features:

 - Folders are unique to each user.
 - The API allows for searching by folder names.
 - Breadcrumbs are displayed for navigation.
 - The design supports folders for various post types.
 - It provides a function to track attachment size for storage limits.

 **From the Jetpack Carousel:**Drawing from this concept, I identify three
 distinct ways to link to a piece of media:

 - **Image gallery view (block)**: A federated view of a media collection.
 - **Upload target (page)**: A dedicated page for a single media object.
 - **Direct file link**: The canonical URL to the raw file.

 My proposal is to position the **Upload target (page)** as the **federated
 `Object`** that resides under the user's actor profile. The `attachments`
 field in the federated post should link to this `Object` URL, not the
 direct file link. This distinction is crucial for optimization and for
 maintaining a clean, scalable Fediverse profile.

 ### Centralized Media Storage

 For WordPress multisite networks, which typically have separate media
 libraries for each subsite, a **centralized media storage solution**
 should be considered.

 This could involve a system like the **Network Media Library** plugin to
 consolidate all media files into a single location on the main site. This
 would allow each media file to have a **single, canonical URL** (e.g.,
 `https://example.com/uploads/2025/08/image.jpg`), preventing URL conflicts
 and redundant data in the Fediverse. This is also essential for
 implementing user-specific storage limits.

 I had initially dismissed the Network Media Library plugin because of its
 age and lack of recent updates on WordPress.org. However, based on recent
 reports, it appears to function well with modern WordPress versions.

 - [https://github.com/humanmade/network-media-
 library](https://github.com/humanmade/network-media-library "null")
 -
 [https://www.thewordcracker.com/basic/%EC%9B%8C%EB%93%9C%ED%94%84%EB%A0%88%EC%8A%A4-%EB%A9%80%ED%8B%B0%EC%82%AC%EC%9D%B4%ED%8A%B8-%EA%B3%B5%EC%9C%A0-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC/](https://www.thewordcracker.com/basic/%EC%9B%8C%EB%93%9C%ED%94%84%EB%A0%88%EC%8A%A4-%EB%A9%80%ED%8B%B0%EC%82%AC%EC%9D%B4%ED%8A%B8-%EA%B3%B5%EC%9C%A0-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC/
 "null")
 - [https://docs.ipfs.tech/concepts/content-addressing/#what-
 is-a-cid](https://docs.ipfs.tech/concepts/content-addressing/#what-
 is-a-cid "null")

 `eof`

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63953>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform