Open alexdryden opened 2 years ago
SteelWagstaff
commented
2 years ago 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
commented
2 years ago 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.
Prerequisites
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
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