#4701 closed defect (bug) (fixed)
Streamline access to the changelog content of plugin pages
Reported by: | netpassprodsr | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | has-patch |
Cc: |
Description
The quick:
The following snippet of code is in the wrong place. It should ideally be the final element just before the closing <article>
tag on the page, not above the content it references.
<script type="text/javascript">if ( '#changelog' == window.location.hash ) { window.location.hash = '#developers'; }</script>
(this snippet immediately precedes the following group of tags, and because of which it does not produce the desired result:)
<span id="description"></span> <span id="reviews"></span> <span id="installation"></span> <span id="developers"></span>
The details:
The WP Toolkit for Plesk presents links to the plugin pages of those with an updated version available. The link has a reference to changelog, as in this example:
https://wordpress.org/plugins/akismet/changelog/
An automatic reformat of the URL occurs resulting in this link:
https://wordpress.org/plugins/akismet/#changelog
Prior to mid-July 2019, the behavior of the WordPress.org plugins directory would be to simply present the first tab (description) content, so the user then needed to click the Development tab to see the changelog details.
Since then, the script snippet above was inserted to attempt making the Development tab content appear when arriving at the page via a changelog URL.
While the URL in the browser does change, that change is ineffective because the new URL refers to elements not existing when it changes.
(Interestingly, if the page is immediately refreshed in the browser, the Development tab content does indeed appear.)
I propose 1 of 2 resolves to this issue:
- Move the script snippet to be the last element before the close of the article html block,
OR
- Wrap the script content in some deferred logic structure (e.g., window.onload() or similar) so it runs after the page is loaded.
Attachments (1)
Change History (14)
#2
@
5 years ago
My platform configuration: (this should have been part of the original ticket submission.)
OS: Windows 10 Pro, 1903 Edition
Browser: Firefox Quantum 68.0.2 (64-bit)
I can reliably reproduce the experience accessing different plugin pages.
This ticket was mentioned in Slack in #meta by sergey. View the logs.
5 years ago
#4
@
5 years ago
Hi @netpassprodsr, welcome to WordPress Meta Trac!
Thanks for the ticket, I was able to reproduce the issue. The current snippet shows the correct tab in Chrome, but not in Firefox (until a page refresh).
This ticket was mentioned in Slack in #meta by netpassprodsr. View the logs.
5 years ago
This ticket was mentioned in Slack in #meta by netpassprodsr. View the logs.
5 years ago
This ticket was mentioned in Slack in #meta by netpassprodsr. View the logs.
5 years ago
#9
@
5 years ago
- Owner set to SergeyBiryukov
- Resolution set to fixed
- Status changed from new to closed
In 9151:
#10
@
5 years ago
Given the recent conversation in #meta, I checked this out. I am able to reproduce this in Firefox(69.0.1) on Windows 10 Pro.
As for a suggestion on a fix, what about wrapping the hash update in an IIFE?
Edit: Per continued discussion in Slack, a simple jQuery $( document ).ready(...
was suggested.
#12
@
5 years ago
Thank you Otto42 for your contribution in this case.
Here's what I was thinking
I offer you my theory and reasoning for what I considered the root problem to be (being as you asked for as much in #meta):
As the browser receives data from the web server, it gets (among other things) HTML markup code and JavaScript snippets to process.
I theorized that the browser engine will act on (e.g. render) as much data as it has received, reasonably adhering to W3 standards, and the user experience reflects that over the course of the page loading.
In my case study, Firefox receives a <script>
snippet followed by a series of span
tags in the stream. The snippet directs the browser to check for a specific property of the URI and modify the location hash to point the focus at one of the anchor-like IDs of the span group.
Brief Aside
I should point out there's already been a lot of funky business going on before getting this far in the page load. The original link started out being a plain, slash-delimited value
https://wordpress.org/plugins/akismet/changelog/
which WordPress converts via redirect (here's an excerpt of the headers of the 302 redirect)
HTTP/2.0 302 Found server: nginx ... content-type: text/html; charset=UTF-8 strict-transport-security: max-age=360 ... x-redirect-by: WordPress location: https://wordpress.org/plugins/akismet/#changelog x-frame-options: SAMEORIGIN x-nc: BYPASS ord 1 X-Firefox-Spdy: h2
So, the browser then requests the https://wordpress.org/plugins/akismet/
page data from the server (including the trailing hash suffix #changelog).
And Now Back
As the browser encounters the <script>
snippet, it performs the hash adjustment right away, since it has enough info to act upon it. The browser URL now looks like https://wordpress.org/plugins/akismet/#developers
The browser hasn't yet processed the HTML <span>
tags containing the anchor-IDs so it doesn't know where to give focus so it dismisses the hash and carries on receiving stream data.
Next the HTML <span>
tags arrive followed by the <ul>
content containers corresponding to each of the <span>
elements. The browser simply renders these since, as far as it's concerned, the script processing is done and over with.
This behavior, as I understand it (and I could be wrong), is intrinsic of the rendering engine of a given browser, how it prioritizes data received and execution of any script code along the way. Clearly, different browsers on different platforms perform differently (... the bane of web developers). We do what we can to help provide a reasonably consistent experience to the general user pool.
I was WRONG when I expected the relocation of script code below the referenced anchor-ID element to correct the issue across all browsers on all platforms, since it didn't work. It was just one of my proposed resolutions of the issue, as I allowed for the possibility it might not work.
The Latest Revision
I invite others who encountered the experience I initially and more recently reported to test the latest revision (commit r9152) intended to fix this issue on their systems, namely Joyously, ipstenu, macmanx. I, for one, can see the changed code loading in my browser: the wrapped hash-change statement in a window.setTimeout() function call, but my experience remains that the detail tab holds focus after page load.
With grace, the deliberation on next steps to treat this is left to the more experienced coders* in this group.
(*those more familiar with this code base)
And That's Not All!! (A little more background)
My initial effort (7/19/2019) was to address the ACTUAL ROOT PROBLEM at the ACTUAL SOURCE: the WordPress Toolkit build maintained by the community of developers who build extensions to the Plesk server management platform.
I've already made my case and asked them to revise the link reference output by the plugins near plugins which have updates available to point to the correct URL on the WordPress Meta site. (You can see how far that went.)
So now I'm here attempting to get this resolved at another fault point in the sequence.
In Summary
I have expended a significant effort to address this issue on multiple fronts and am encouraged to at least see some progress made in this arena. Thank you very much!
#13
@
5 years ago
If this fix didn't work, then my proposal would be to remove the changelog link entirely, and redirect to the root plugin instead, and ditch it. Because at this point, without an understanding of the underlying problem, it's not worth the effort to fix.
We do not have /changelog or #changelog links anymore, it's been years, and it's time to move on, I think.
The development tab appears for me regardless of the location of the script on the page.
This "fix" appears to work correctly.