WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 5 months ago

#37330 new enhancement

Attachment pages do not always provide a link to the original article.

Reported by: webtechmailbag Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.5.3
Component: Media Keywords:
Focuses: Cc:
PR Number:

Description

I wasn't sure where to post this issue, as it seems to be a limitation in the WordPress code itself rather than a bug. But perhaps someone knows what's going on?

Individual attachment pages (which are created when inserting an image or gallery on a page or post) sometimes provide a link to the main article, BUT NOT ALWAYS.

This is noticeable in themes which take advantage of this capability, such as Twenty Thirteen and Twenty Fourteen, (for other themes that don't include a link back to the original article anyway this doesn't matter.)

For example, in Twenty Thirteen's image.php the following code checks to see if the article URL is available. If it is, the attachment page displays a "published in" link, but if not it just displays the date:

<div class="entry-meta">
<?php
$published_text = __( '<span class="attachment-meta">Published on <time class="entry-date" datetime="%1$s">%2$s</time> in <a href="%3$s" title="Return to %4$s" rel="gallery">%5$s</a></span>', 'twentythirteen' );

if ( empty( $post_title ) || 0 == $post->post_parent )
$published_text = '<span class="attachment-meta"><time class="entry-date" datetime="%1$s">%2$s</time></span>';

Obviously, WordPress expects that the article URL will not always be known, and this is observable. Some attachment pages link back to the article and some do not.

But why is this? It seems kind of random- I can't figure out which scenarios generate an attachment page without the link?

And in any case, why should WordPress not be able to figure out the article URL and always make it available for themes to use?

Change History (2)

#1 @SergeyBiryukov
3 years ago

Hi @webtechmailbag, thanks for the ticket!

If you've uploaded an image via the post editor, it's attached to that particular post, and its post_parent value contains the ID of that post.

If you've uploaded an image via Media Library, it's not attached to any post, unless you've attached it manually in the "Uploaded to" column in list view.

Hope that clarifies things a bit :)

#2 @webtechmailbag
3 years ago

Sergey,

Thanks for the explanation. You answer actually relates to another bug entry I had submitted:
https://core.trac.wordpress.org/ticket/37157

In that case certain galleries would cycle through *all* photos in the media library, and just couldn't figure out why. It turns out that when you create a gallery from already uploaded photos (so they don't register as being attached to any particular post) viewing that gallery will cycle through *all* unattached photos in the library.

Now I finally understand what's going on.

However, this WordPress behavior still seems almost like a bug. I would have expected that when a photo gallery is added to a page, the photos would automatically be "attached" to that page (if not already attached to another).

As it is, when uploading and/or adding photos to a page, WordPress provides no notification as to whether or not they are being "attached". Furthermore, when photos *are* automatically attached, there is no particular reason to assume that this is what the user wanted to do.

Since this causes several problems in WordPress, I'm thinking about re-submitting this as a bug or enhancement request. I'd like to hear your opinion on the matter, if you have one?

PROBLEM

Case 1: The user is editing a page and from there decides to upload a batch of photos. They pick out the ones to display on that page, and leave the others they've just uploaded to use at a later time. But these other photos have already been attached to the current page without their knowing, and they will be displayed inside photo galleries on that page!

Case 2: The user deletes a photo from a gallery and its thumbnail is removed. But unknown to the user, that photo is still displayed inside the gallery because it has not been"unattached" from that page.

Case 3: The user updates a gallery with photos that have already been attached to different pages. This will cause the gallery to break- not all of the photos will be viewable by clicking on a thumbnail and different galleries may open. But WordPress breaks the gallery without warning the user.

Case 4: The user updates a gallery with photos from the media library that have not be attached to any page. Unknown to the user, this will cause *all* unattached photos the user has uploaded to be displayed in the gallery. This would included photos that are still being edited, general site elements such as icon sets, logos, etc.

RECOMMEND SOLUTION

Allow photos in the medial library to be "attached" to multiple pages at the same time. (This is the way the Internet works! It is common practice to display the same images and videos on different pages.)

SECONDARY SOLUTION

When adding photos to a page, (whether a gallery or single photo) there should be a check-box option for "attach to this page". This both informs the user what is going to happen, and gives the user control of the attachment at the proper time and place.

If the user tries to attach a photo that has already been attached to a different page, a warning should be given that the action will "detach" the photo from its existing page.

If the user tries to update a gallery with a photo that has already been attached to a different page, the action should be prohibited as this effectively breaks galleries (unless a gallery plugin is being used).

ADDITIONAL CONSIDERATIONS

Use of words "attach" and "detach" in WordPress is confusing because it may be assumed that "attaching" a photo to a page and "adding" a photo to a page are one and the same thing, (like attaching or adding a photo to an email).

Perhaps a different term could be used, such as "associate/disassociate", or more accurately, "create media sub-page/ delete media sub-page" or "create attachment sub-page/ delete."

Regards,

Note: See TracTickets for help on using tickets.