Did you know the upcoming WordPress 6.4 release, expected on November 7, is likely to have attachment pages disabled for new installations?
Until recently, WordPress used to automatically create attachment pages where users would upload files from the media upload system. So far, this was regarded as a unique post type that contains information on each file and its attachment, accessible under its own URL. In this aspect, SEO plugins were redirecting the attachment pages correctly, as that was the primary purpose intended.
Read on to delve into how the upcoming WordPress 6.4 release will impact the existing functionalities or websites.
“Until WordPress 6.4 was released, WordPress created attachment pages by default for every attachment uploaded,” WordPress contributor Joost de Valk said in the dev note for this change. “On the vast majority of sites, these attachment pages don’t add any meaningful information. They do, however, exist, get indexed by search engines, and sometimes even rank in search results, leading to bad results for users and site owners.”
WordPress contributors like Joost de Valk speak of the functional aspects concerning the attachment page feature. In Valk’s view, these pages are not useful when it comes to including some meaningful stuff. Nevertheless, from an SEO perspective, the attachment pages come in posing a problem for the website owners.
So, the million-dollar question hovering over the minds of developers, website owners, users, and everyone else is – What will be the impact of the upcoming release 6.4?
Well, the answer is it will not change the existing websites in any manner. You can take a deep breath. The older or existing websites will continue to function in the way they have been. On the other hand, the new websites will have their attachment pages redirected to the attachment URL. The good news for website administrators is that they can enable or disable the attachment pages. All they need to do is use the latest wp_attachment_pages_enabled database alternative that would help in controlling the behavior of the attachment pages.
Contrary to what was mentioned in the Trac ticket and Dev Note, there will be no interface to determine if a site disables the attachment pages.
“In light of the WordPress mantra ‘decisions, not options,’ we’ve decided against making a setting for this,” de Valk said.
Working around the development of the upcoming release, WordPress plugin developer Sybre Waaijer suggested an option in the interface that could be toggled on or off. This could offer a newer alternative to users, despite disabling the attachments page feature.
“The problem with filtering options is that when another plugin provides the option toggle, the option filter will go against user expectations. This is where “decisions, not options” becomes paradoxical because we’re now deciding to set an option while also not giving the option.
So, as plugins fill in this gap, then A) where will plugins put the option (likely on their custom page instead of options-media.php), and B) of the dozens of types of plugins that are in the market to juggle this, who will ultimately be in control of the option?
If it’s a filter, each plugin promises to set a toggle via a simple condition. But since it’s an option, plugins can add an option to filter an option and add an option to toggle the option. It’ll become a source of bugs because of the logical biconditionals (XNOR).”
It looks like an interface is not and will never be under consideration in WordPress, however, the contributors are discussing on considering the option of inserting this as a core plugin.
“Should we not have a core plugin for re-enabling attachment pages on new sites?” Automattic-sponsored contributor Justin Tadlock said. “If there’s not going to be a UI for this, then a plugin that’s not buried in a Trac ticket would be ideal.”
De Valk consented to this suggestion to have a plugin that just adds a setting to the Options – Media Page. He believes that users will truly understand the purpose of attachment pages only when they use it with reference to a unique or specific use case. As described in the Dev note, this kind of plugin would best serve the interests of those who are not in a position to write code to modify the attachment pages’ behavior.