"Attachment Page" is still listed as a link to option for Image Block when Attachment Pages are disabled

[MadtownLems]

Description

6.4 brought us the ability to disable Attachment Pages (and new sites are created without them).

However, even when Attachment Pages are disabled, I am shown "Attachment Page" as an option when setting the link of an Image Block.

Step-by-step reproduction instructions

1. Disable Attachment pages (set wp_options.wp_attachment_pages_enabled = 0)
2. Add an Image Block to a Post
3. Open the link setting option for the Image Block
4. See that Attachment Page is still listed.

Screenshots, screen recording, code snippet

Environment info

WordPress 6.4.1, no Gutenberg plugin

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[carolinan]

I may be wrong but it seems this option is not exposed to the block editor. I have not created custom REST API end points in a few years so I will remove my assignment.

[Mamaduka]

Exposing the wp_attachment_pages_enabled option via the /settings endpoint won't work; it requires access via the manage_options capability, and the Image block is available to non-Administrator users.

Maybe the media endpoint should respect this setting and omit the link from the response when attachment pages are disabled.

I reposted my question in the original Trac ticket: https://core.trac.wordpress.org/ticket/57913#comment:76.

[peterwilsoncc]

@Mamaduka I think removing the link items could cause problems for consumers of the rest api. Could the option be exposed via get_block_editor_settings() instead?

[Mamaduka]

@peterwilsoncc, that's one possibility, but I don't want to introduce yet another block editor setting if that's possible.

One alternative I can think of is adding a new link via WP_REST_Controller::get_available_actions, which the editor also uses to limit post-type-related actions. However, I'm not 100% sure if it belongs there.

@TimothyBJacobs, do you think I should give up on REST API modifications and just go with global block editor settings? 😄

[TimothyBJacobs]

My gut would be to remove the link from the response as well. I think it's unexpected that we link to the attachment page via the REST API, if that page won't actually work.

Maybe instead of completely removing the prop, we set it to an empty string?

[peterwilsoncc]

@TimothyBJacobs @Mamaduka What about setting the link to the image URL for sites with attachments disabled (I thought this was already the case, sorry). That will allow systems that are using it to safely continue to do so.

The block editor could then determine whether to show the attachment page link by comparinglink to source_url and if they match then only show the media file option.

My testing shows that a REST request is made for the media prior to the dropdown being displayed, please correct me if that is not always the case.

[carolinan]

I think this is the key

The block editor could then determine whether to show the attachment page link by comparinglink to source_url and if >they match then only show the media file option.

[TimothyBJacobs]

What about setting the link to the image URL for sites with attachments disabled (I thought this was already the case, sorry). That will allow systems that are using it to safely continue to do so.

This makes sense to me. Looking at the attachment_link filter, it says it can return an empty url to disable the view attachment page link on the media modal. So we'd probably also need to disable the option if link is empty.

[Mamaduka]

The block editor could then determine whether to show the attachment page link by comparing link to source_url and if they match then only show the media file option.

I was just testing this logic. Unfortunately, it won't work. The link still returns the attachment page URL, which then gets redirected to the file URL, while the source always returns the file URL.

Example returned values:

link: https://gutenberg.test/2024/04/attachement-pages/image-1/
source_url: https://gutenberg.test/wp-content/uploads/2024/04/image-1.jpeg

It also looks like the component responsible for rendering Link URL options for images already accounted for empty link and prevented rendering the attachment page option.

It seems to me that @TimothyBJacobs suggestion is the right way to handle this.

[TimothyBJacobs]

I was chatting with @peterwilsoncc some, and we're wondering if the correct place we should be patching is the get_attachment_link function instead. Because it seems strange to us that get_permalink is returning a URL that doesn't "exist".

[Mamaduka]

@TimothyBJacobs, @peterwilsoncc, sounds good to me. Once there's a working patch for the core, I can update the Gutenberg code.

[peterwilsoncc]

I've created WP#61133 to update the return value for get_attachment_link().