Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#4701 closed defect (bug) (fixed)

Streamline access to the changelog content of plugin pages

Reported by: netpassprodsr's profile netpassprodsr Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: Priority: normal
Component: Plugin Directory Keywords: has-patch


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:

An automatic reformat of the URL occurs resulting in this link:

Prior to mid-July 2019, the behavior of the 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:

  1. Move the script snippet to be the last element before the close of the article html block,


  1. 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)

4701.diff (1.2 KB) - added by netpassprodsr 5 years ago.
single line relocation to accomplish the fix

Download all attachments as: .zip

Change History (14)

#1 @Otto42
5 years ago

The development tab appears for me regardless of the location of the script on the page.

This "fix" appears to work correctly.

#2 @netpassprodsr
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 @SergeyBiryukov
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).

5 years ago

single line relocation to accomplish the fix

#5 @netpassprodsr
5 years ago

  • Keywords has-patch added

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 @SergeyBiryukov
5 years ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 9151:

Plugin Directory Theme: Move the JS for redirecting #changelog to #developers for back-compat after the #developers element.

This ensures that the Development tab is opened automatically upon the redirect. Previously, the code used to work in Chrome, but not in Firefox.

Props netpassprodsr.
Fixes #4701. See #2771.

#10 @davidbaumwald
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?

Version 0, edited 5 years ago by davidbaumwald (next)

#11 @Otto42
5 years ago

In 9152:

Plugins: Add a settimeout on the #changelog switch, to force firefox to behave in unusual circumstances. Fixes #4701.

#12 @netpassprodsr
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
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
x-frame-options: SAMEORIGIN
x-nc: BYPASS ord 1
X-Firefox-Spdy: h2

So, the browser then requests the 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
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 @Otto42
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.

Note: See TracTickets for help on using tickets.