See https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/skins/SkinTemplate.php$1294 for the current logic.

There is probably a bad work around, but if the url contains # (meaning that a section is linked to) copy that from the current url and append it to the permalink. I can make that as an on-wiki script in the meanwhile if there is a better way to do it in PHP

@MZMcBride on-wiki script:

$(document).ready( function () {
    $('#t-permalink > a').each( 
        function() {
            this.href = 'javascript:window.permaLinkSection("' + this.href + '")';
        }
    );
} );
window.permaLinkSection= function( href ){
    var section = window.location.href.match(/#.*$/);
    if ( section && section[0] ) {
    	href = href + section[0];
    }
    location.href = href;
};

if (understandably) this ticket isn't actioned soon, I may propose this as a gadget

Coming back to this:
Per https://stackoverflow.com/questions/2317508/get-fragment-value-after-hash-from-a-url-in-php this doesn't seem possible in php
In javascript, a much simpler implementation:

$(document).ready( function () {
    $('#t-permalink > a').on( 'click', function ( e ) {
        e.target.href += window.location.hash;
    } );
} );

Is there a good place to put this code? It should be

• loaded for all article views (i.e. not special pages, specifically whenever the permalink is included, so views that pass OutputPage::isArticle)
• Not in its own resource loader module (should be bundled with an existing one)

My initial thought was to add it to mediawiki.toc, but it should be loaded even when there is no table of contents, since it works for user-provided anchors as well. @Krinkle any ideas?

Indeed, this will have to be a client-side solution. I recommend against on-load DOM manipulation. Both because it adds unconditional cost for something that is rarely used (doesn't scale well, there are goingn to be hundreds of little features like that otherwise all adding cost, "tragedy of the commons" scenario), but also for usability reasons because it means it stays behind if you use the TOC after initial page load.

Adding it on-click seems like a good balance and also means we are transparent to the user at all times. If they long-press and copy the link, they probably don't expect it to disclose the section they last clicked on in their personal browsing session. When clicking on it, they might observe it brought them to the same section and can choose what to do with that. Not ideal, but it's something.

I'm CC-ing Reading-Web to help further. This is not merely about how and where to ship. It's also about understanding the end-user need and how to best support that. This idea is, in my opinion, not an "obviously good" or "universally harmless" idea. think it's worth thinking through the implications for end-users from a UX and product perspective and decide what we want to do for everyone based on that.

Permanent link feature is not part of Vector. It's in core. Web team doesn't have capacity to work on this.

Change 825423 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Include URL hash/fragment/anchor in permanent links

https://gerrit.wikimedia.org/r/825423

Change 825423 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.page.ready: Add current hash fragment to sidebar permalink URL

https://gerrit.wikimedia.org/r/825423

@matmarex did editing team want to QA or should I resolve?