Media attachment page interface options misleading

[alexdryden]

Prerequisites

• Can you reproduce the behavior you wish to address with all plugins except Pressbooks deactivated?
• Are you running the latest version of Pressbooks, the latest version of McLuhan, and the latest version of WordPress?
• Are you experiencing the issue while using this book theme?
• Did you perform a cursory search to see if your bug or enhancement is already listed?

Description

Media have the option to "link to attachment page" in the interface and in the user guide despite #611 suppressing media attachment pages for all but logged in users with the ability to upload media (see here).

Example of interface use of "attachment page"

In addition, this means that the media description is never discoverable by the public (as explained here).

The current, half-disabled state of the feature means that most authors and admins believe that this is a functioning feature and never discover that the public can't see the media attachment page or the media description because they are usually testing the book while logged in.

Steps to Reproduce

1. In a book that is set to public, add a media item to a chapter
2. Edit the media from the chapter level WYSIWYG
3. Under "Link To" select "Attachment Page"
4. Save and view the chapter.
5. Click on the image. Behaves as expected based on interface: opens the Attachment Page.
6. Log out.
7. Repeat step 5 (click on the image). Behaves as designed based on Remove/suppress Media Attachment pages #611: redirects to the chapter.

Expected behavior:
See 5 and 7 above

Actual behavior:
See 5 and 7 above

System Information

System Information

Book Info

Book ID: 10
Book URL: https://iopn-dev.library.illinois.edu/pressbooks/druguseandmisuse/
Book Privacy: Public

Browser

Platform: OS X
Browser Name: Firefox
Browser Version: 91.0
User Agent String: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Firefox/91.0

WordPress Configuration

Network URL: https://iopn-dev.library.illinois.edu/pressbooks/
Network Type: Subdirectory
Version: 5.9.3
Language: en_US
WP_ENV: Not set
WP_DEBUG: Enabled
Memory Limit: 64M

Pressbooks Configuration

Version: 5.32.0
Book Theme: McLuhan
Book Theme Version: 2.16.0
Root Theme: Aldine
Root Theme Version: 1.13.0

Pressbooks Dependencies

Epubcheck: Installed
xmllint: Installed
PrinceXML: Installed
Saxon-HE: Installed

Must-Use Plugins

hm-autoloader.php: n/a

Network Active Plugins

Pressbooks: 5.32.0

Book Active Plugins

Pressbooks: 5.32.0

Inactive Plugins

Akismet Anti-Spam: 4.2.2
Excalibur: 0.3.4
Hello Dolly: 1.7.2
Pressbooks: 5.32.0

Server Configuration

PHP Version: 7.4.19
MySQL Version: 5.5.5
Webserver Info: Apache/2.4.37 (rocky) OpenSSL/1.1.1k

PHP Configuration

Memory Limit: 256M
Upload Max Size: 2M
Post Max Size: 8M
Upload Max Filesize: 2M
Time Limit: 30
Max Input Vars: 1000
URL-aware fopen: On (1)
Display Errors: On (1)

PHP Extensions

OPcache: Zend
XDebug: Disabled
cURL: Supported
cURL Version: 7.61.1
imagick: Not Installed
xsl: Installed

[SteelWagstaff]

Thanks for filing @alexdryden . We'll take a look at this. My first thought would be that the ideal outcome would be removing 'attachment page' as a option, if possible. Does that sound like a good resolution to you?

[alexdryden]

If at all possible we would prefer a solution that kept that feature alive as a possibility.

Right now we are using the "Description" field that shows up on the attachment page for complex image descriptions (e.g. charts and diagrams in science textbooks) as an approximate implementation of the accessibility advice provided here for cases where it wouldn't make sense to have a detailed description as the caption. And I think a few other use cases that found the description field helpful. We didn't discover the issue till the textbook was published, and for the time being we're simply re-enabling the attachment page.

The solution that I proposed to my team on Monday was that we revisit the original issue (#611) and submit a pr that re-enables the attachment page for the public and then implements the other solution that was being entertained in the original issue, adding the appropriate attribution metadata to the attachment page (this note provides a roadmap). And I was given the green light to dedicate some development time to a pr.

If it is something you'd be interested in, I'd probably wait till after the other pr is finished so that I can incorporate any feedback from that here as well.