[wp-meta] [Making WordPress.org] #4701: Streamline access to the changelog content of plugin pages

[Making WordPress.org]

#4701: Streamline access to the changelog content of plugin pages
------------------------------+-----------------------------
 Reporter:  netpassprodsr     |       Owner:  SergeyBiryukov
     Type:  defect            |      Status:  closed
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:  fixed
 Keywords:  has-patch         |
------------------------------+-----------------------------

Comment (by netpassprodsr):

 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 [https://talk.plesk.com/threads/wordpress-
 toolkit.343831/page-8#post-864768 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!

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/4701#comment:12>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org