I think it would be preferable if the ‘User Message’ templates worked without JavaScript enabled.
At present the ‘Return to Previous Page’ link is written as a JavaScript history back-1, is there any reason for this? Could EE not get the referring URL instead, or at least use JavaScript in an unobtrusive manner?
<a href="http://www.referringurl.com">Return to Previous Page</a>
The href of the link could be returned as the ref URL and then the JavaScript could be applied as an onClick meaning that with JavaScript disabled the link would still function as expected.
Glad someone does! I’m a bit of an advocate for maintaining an ‘acceptable’ experience for users with JavaScript disabled. We’ve been working really hard on a current project using EE to do this. We’re using Thickbox to display ‘modal’ log-in and registration dialogs and this is the only thorn in our side, something we have no control over.
I’d be interested to hear from the EllisLab guys if this is something which could possibly be hacked. Even a pointer as to where to locate the code that generates that link would be useful.
While we can’t support hacks, I can understand the desire here. /system/core/core.output.php, show_user_error(). Take care with how you choose to implement this, as show_message() will sanitize any links intended for the href= attribute of the link since this information can come from external sources.
Ok, unless I have missed anything, this seems dead easy to implement as a proper link. Here’s what I’ve done. At about line 536 in core.output.php I’ve added a var called ‘$ref_url’ which is the referring URL, I then add that to the data array in place of the nastyness that was the JavaScript history-1.
Now try a search or whatever on your site and you’ll see your new ‘Return to Previous Page’ link except now it’s linked to a actual URL rather than using “[removed]history.go(-1)”. I’ve also tested this with login, logout and forgotton password to name a few and it all works as expected.
Obviously if anyone else tries this and discovers a problem please let me know.
What if the user has JavaScript disabled or it is not available? A server side solution is surely more robust isn’t it? At the end of the day there are always “what if’s”. The scenario you describe could easily be catered for by making the ‘default’ a JavaScript history-1 ‘onClick’ and the ref url in the href as the fall back? Just change line 471 in core.output.php to:
I did not mean to imply that a JS-based solution was preferrable, just that—using PHP as we do—it would be possible, and in fact easy, to allow for a case where “HTTP_REFERER” was empty. Either by providing a JS-based fallback, a default link or something like that.
Sure I know you were just playing devils advocate.
You’re right that there should be some validation of the ref_url value also in case there is no value so that the href is never empty. I think I’ll add that here.
Here I am re-applying my hacks after an upgrade from 1.6.3 to 1.6.4! Something worth noting, I’ve started adding a file to the root of my EE sites called ‘hacks.txt’ which contains a plain text list of hacks and the related forum entries so that when I come back to perform an upgrade, I have a definitive list of what hacks I need to be wary of.
Instead of hacking core.output.php, you can override the global $OUT object with an extended version of the class, so your extension will basically just rewrite the show_message() method to do whatever you want. And you’ll be able to keep core.output.php intact and in step with the release.
I don’t have time at the moment to try it out, Nathan, but at a glance it looks good, i.e. you’re using the hook correctly. The only issue of course is that this extension and the System Offline extension cannot be installed at the same time, as they each overwrite the global $OUT object with their own version of the class, though it’s a trivial matter for someone to merge the methods that they wish overwritten into a single extension.
