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?

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.

:?

Edit: See here!

Agree

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.

Thanks Derek, will let you know how I get on. Any chance that a future point release might see the default behavior (use of JavaScript) revised?

Yes, though not likely right away.

Thanks. It’s enough to know that you understand where I’m coming from with this.

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 there are no referrers? You can turn them off, and some servers do (or it gets stripped by firewalls or other network equipment or similar).

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:

Problem solved.

Edit, JS got stripped out…, there was a ‘onClick’ after the href with a value of ‘history.go(-1); return false’.

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.

What a great post..!

Paul Cripps (Nine Four) - 25 July 2008 04:05 AM

What a great post..!

You would say that!

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.

Nathan, you can use an extension and eliminate a hack here.  Use the System Offline extension as a template.

Huh? Sorry.. confused… :?

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.

Ah, sorry I see what you are suggesting now. Thanks for the prod in the right direction Derek, let me know if this works for you…

http://nathanpitman.com/journal/551/expressionengine-extension-noscript-messages

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.