hashtag stripped out of wp-admin backend Dashboard URL's

[AITpro]

Not sure if this is new intended behavior or something that may be a bug.

WP Version: WordPress 4.2 Beta2
Test Example: /wp-admin/index.php#test
Result: #test is stripped from the URI
Other Example: div id created. hashtag on end of the URL pointing to that div id.
Result: hashtag is stripped from the URL resulting in the link not going to the intended div id.

[AITpro]

Argh never mind. The solution is to escape the hashtag. Sorry.

[AITpro]

Oops had 2 test sites open at the same time and thought escaping the hashtag worked, but it helps to be looking at the correct site.

So original issue is still occurring with hashtags being stripped out of all wp-admin URL's.

[AITpro]

The problem code is here: /wp-admin/includes/misc.php
Code Line: 854
Function name: wp_admin_canonical_url

Commenting out this action - hashtags are no longer stripped out of wp-admin URL's

add_action( 'admin_head', 'wp_admin_canonical_url' );

[AITpro]

And specifically with this js code:

if ( window.history.replaceState ) {
			window.history.replaceState( null, null, document.getElementById( 'wp-admin-canonical' ).href );
		}

[AITpro]

disregard/deleted. Invalid solution.

[AITpro]

I'm having one of those "special moments" days. Jeez how to not see something that is so freakin obvious.

The Solution:

window.history.replaceState( null, null, document.getElementById( 'wp-admin-canonical' ).href.location.hash );

Just some side notes for anyone else having a "special moment" like me: Since fragments are not something stored server-side and are client browser side only then you cannot do things like parse or use stored server variables. Yeah basic stuff, but I totally spaced out for a bit and forgot that basic stuff.

[dd32]

Shifting for review

[dd32]

In 31882:

When altering the admin URL to reflect the canonical location, keep the existing hash (if present) in the URL.
Fixes #31758. See #23367

[johnbillion]

Well spotted.

[AITpro]

Yup could have been a pain in the ass if it managed to get all the way through dev to prod. Not sure why I used hashtag and not hash anchor. I was having a very special day - even tying shoelaces was a challenge. :) Note to self: 2 margaritas == fun. 6 margaritas == fubar.

[AITpro]

@dd32 - good correction on concatenation (.) vs addition (+).
Correction: + is used for concatenation and addition in js. The dot was just a mistake on my part and + was intended.

[AITpro]

@johnbillion - didn't say thanks. So thanks. My pleasure to help in any small way that I can.

[dd32]

Replying to AITpro:

@dd32 - good correction on concatenation (.) vs addition (+).

Ah! I looked at your suggested code, but didn't catch the direction you were trying to go in (I thought you were trying to access the .href.location.hash property, which obviously doesn't exist!).

Glad to see we ended up at the same basic patch though, had I have realised the minor error, I'd have given you props in the commit, will have to manually add the props later :)

[AITpro]

Yeah for whatever reason in js (which should not be allowed) the dots work to "add" vars and other things - ie x.y.z, but it is a very bad coding practice to say the least. I just slapped that together to give the needed info and moved onto other problems without really refining anything. Tested it, it worked, moved on to other stuff.

Not concerned about props whatsoever. Just glad it is handled. Next...

[AITpro]

Correction: "...it is a very bad coding practice to say the least..."
It is completely invalid code,usage so it should throw an error instead of doing anything at all. ;) Very odd that this would work at all, but it does for whatever odd reason that may be. ;)

.href.location.hash

[AITpro]

Invalid disregard/deleted.

[AITpro]

Invalid disregard/deleted.

[AITpro]

Invalid disregard/deleted.

[AITpro]

Invalid disregard/deleted.

[AITpro]

Invalid disregard/deleted.