We Keep Coding

Changing where the back button leads to

I am developing a web app and want to make the back button in the browser more app like.
A user goes through these steps to post a message:
List all messages -> read one message -> write reply -> gets back to message after reply
If the user then clicks the back button he will get back to the page were he wrote the reply. The prefered action would be to get back to the list of all the messages.
I've tried to use the HTML5 History API to remove the history of "write reply" and "read one message" after posting, but it doesn't seem to be possible to do that.
Are there any other way make it behave like I want, or should I just leave it as it is? I know you shouldn't mess with the back button, but I really think this would make it more logical.

you can try to do in this way:
After the user wrote the reply you can execute this js
// 1) push a fake state in the history
history.pushState({ foo: "test" }, "test", "test.html");
// 2) add a listener when the user press the back button
window.addEventListener('popstate', function(event) {
//redirect user where you want
window.location.href = '...';
}, false);
Keep in mind that the code #point1 will change your URL in the address bar, so if you're using the URL with some fragments or other info in the query string you must deal with them.
For the code #point2, if you're in a single page web app, you must remove the listener once finished this operation.
However this is a possible solution but without know the environment I don't know if can suit your request.
Hope this can help!

How to login and enter into a different html page

I am new to backbone.js , I have a login page made in bootstrap and I also have a small validation done in a js file where it checks if the username and password is test when clicked on signin button, what I am trying to achieve now using backbone.js is once signin button is clicked with valid data it should take me to xyz.html file

when you receive your success message, in the callback just type
window.location='xyz.html'
It will forward there. Be aware that any javascript objects will be lost, so if you need to pass data to the next page, you can do it through cookies, or url parameters (window.location='xyz.html?data=cool,stuff,to,know' ) or by having xyz.html make a request to "the server" when it starts, and get some data.
if you want to do it the backbone way, you can do:
myRouter.navigate("/xyz.html", true)
but that will not actually forward you, it will just change the url and then call the handler for that "route" because what you are then supposed to do is to do an ajax call for an html template, or otherwise rebuild the current page differently. If you do actually want to end up on a different page then you SHOULD use window.location

How to append to form "Thanks for the email!" after submit button is pressed?

I'm building a contact form for my website and I would like users to enter their information, click submit, have the information process with php and to just have a message display on the bottom of the form. Originally, I was redirecting to another page and the form was working properly, but now I just want to append a small message and can't get it to work.
This is what I have currently in my contactengine.php file for it to process all the variables and send the email.
if ($success){
THIS IS WHAT I DID BEFORE THAT WORKED BUT HAS TO REDIRECT
// print "<meta http-equiv=\"refresh\" content=\"0;URL=index_thanks.html\">"; //
//BELOW IS WHAT I WANT TO OCCUR
<script type="text/javascript">
$("#contact-area").append("Thanks for your message!")
</script>
}

You don't need JavaScript for this. JavaScript is great, but it should only be used where necessary, since it can add some brittleness to the user experience.
Here's a possible design approach:
Set up a POST form
Process the form, set a session variable to thank the user, and redirect to the form again. This switches the browser from POST to GET mode†, and is usually as simple as this:
header('Location: http://yourdomain.com/form.php');
exit();
Render the form as usual. If a session variable is set to thank the user, render the thank you message, and unset the session variable‡
I wouldn't use a <meta /> refresh here - it needs to load more data to work, and is more fiddly to implement.
† The POST-redirect approach is a common design pattern in web development. There are plenty of resources about this on the web, if you are unfamiliar with it. It fixes problems associated with rendering web content inside a POST method, particularly in relation to page refreshing and using the back/forward buttons.
‡ These temporary session variables are sometimes known as flash variables. They exist from one HTTP operation to the next, and are erased at the end of the second operation.

You cannot put JavaScript inside of your PHP code. However, I will give you an explanation of what you need to do.
On the client side, bind an event for the click, then
$('form button').click(function() {
$.post('file.php', {'object': 'property'}, function(success) {
if(success) {
$("#contact-area").append("Thanks for your message!")
}
});
});
On the server side, you will process this:
//file.php
$sentByAJAX = $_POST['object'];
return true;

Remove POST data when using custom javascript back button

I've coded some custom navigation buttons into the project I'm working on, via javascript - they essentially copy the browser button functionality (brief wasn't initially clear on why separate buttons were required, but they asked for them):
function goBack() { window.history.back(); }
function goForward() { window.history.forward(); }
However, as the functionality is the same as the browser back button, the website asks if I want to resubmit POST data if I go back to a page with said POST data, which is undesirable. Ideally, to fit with the current site setup (all POSTs submit to the originating page, which checks for POST data and performs the relevant submissions to the database), I want to clear the POST data so there is no request to resubmit.
I'm not familiar with the Post/Redirect/Get (PRG) that people might recommend, and it doesn't seem to cover the concept of continually pressing "back"; if you submit a form, you post to a page which handles the post action, then redirects to a GET page - but the redirect is still in the history, meaning if you go back, surely you would hit the redirect page and just be sent "forward"? Plus, PRG seems mostly centred on page refreshing, which is not what I'm looking for at the moment.
The concept of PRG also seems to be due to the browser back button not allowing for additional code to control POST data, so coders have to make the best of what they can access.
With my relative freedom of having a custom back button which could allow for manipulation of POST/session/cookie data, I'd consider there should be some method of calling a global session variable or cookie on back button press, which then gets picked up on the previous page load to unset the POST data and the global session variable/cookie, but my attempts to implement something like this have not succeeded - they've been simple single-line setcookie('back', true) or set($_SESSION['back']=true) PHP snippets within goBack(), with PHP earlier in the page:
<?php if (isset([either set cookie or set session variable]) {
unset([either set cookie or set session variable]); // also tried changing 'true' to 'false' here
unset($_POST);
}?>
Is this kind of behaviour possible and I'm just looking at this from the wrong angle, or is the only way to do a successful back action while suppressing POST to re-engineer the site to use PRG, which will be comparatively significant legwork? Is there some other point in a page load/POST submit that would allow for clearing the POST data, to allow for the back button functionality I'm looking for?
EDIT
I, as an example, navigate to site.com/stuff/edit/[an ID], to edit an item of stuff. The first time I visit, there is no POST data, so the PHP check of isset($_POST) returns false and the page is simply rendered with a form which is populated by a GET.
I amend in the form and press submit. The submit sends the POST data to the target page; this is STILL site.com/stuff/edit/[an ID]! However, because there is now POST data, the PHP picks this up, validates it on the page (you'll see why later) and performs backend model and controller functions to update the item to the database serving the site.
Depending on whether the update was successful, the page then renders the form again, with the information which is retrieved from a GET, which pulls the information from the server (amended or otherwise) and either a success or fail message.
If I want to add a new item, I navigate to site.com/stuff/new; this navigates to the same page as site.com/stuff/edit, but PHP code determines the masking URL and renders different aspects of the code to look like a different page with a different POST action - it also notes there is no ID passed in.
I add an item, and the POST redirects back to the same page; this time, though, there is no Id from the server, meaning the code behind picks up the fact it is a new entry, and performs an insert. It then either displays a success message with a link to view/edit the new item, or a failure message with a prepopulated form to reduce retyping the new item into the form.
I hope this has helped show how this page works; its not necessarily how I would have written the site, but I've inherited the work from an ongoing situation and work with others who code in this way, so I need to be consistent or make unobtrusive changes rather than radical redesigns of in-use code.

I think this should do the job:
function goBack() {
var referrer = document.referrer;
if(referrer != '') {
window.location = referrer;
} else {
window.history.back();
}
}

How to log out showing the proper status?

I have a members site. Every web page's header bar will have the following 2 options depending the user is logged in or not:
Option 1) if the user is logged in, it will have the following 2 links:
"user12345"
"logout"
Option 2) if the user is log out, above 2 links will become:
"login"
"register"
The page has some Javascript code which will check a user cookie. If the user cookie exists, if will display option 1), otherwise option 2). There is no problem with the Javascript. It shows above options correctly.
Here's the problem. I use a server side script (perl) to do the "logout" function. The script will delete the cookie and re-direct back to the original page. I am hoping the page will show option 2), but it doesn't. It still shows option 1). The page needs to be refreshed to show option 2). This is confusing because users have clicked the logout link, yet when they return to the page, they still see their usernames there. They need to refresh the web browser in order to see that they have logged out.
Option 2) should show on the page upon clicking the "logout" link. But I simply have no idea how to get this done successfully.
Please provide your expertise to fix this problem.

First, I would suggest breaking the problem down so that you can test the logout functionality separate from the page redirect.
Modify your Perl script so logout doesn't redirect.
Login and then click logout.
Use a Chrome or Firefox extension that lets you view cookies. Verify that the cookie has been deleted.
If everything checks out here, I would suggest that you then reconnect the redirect and repeat the above steps:
When your page redirects and you don't see the login | register buttons, check to see if the cookie was deleted, if the cookie appears, then there may be something being cached in the code after the redirect.
As an alternative, you could use the document.referrer to capture your logout URL in your JavaScript code and also use this to determine if you should show the login | register buttons. For instance:
if(document.referrer = "/logout" || /* existing check of cookie goes here */) {
// show login | register
} else {
// show username, etc.
}
If possible, the best solution usability-wise would be to turn your logout url into an AJAX call so you don't need to reload the page. This would be better than the above solution because you could check the response object to determine if the logout operation was a success. If so, you could then dynamically replace the header bar with the correct text.
An AJAX example, using jQuery.ajax, is as follows:
$.ajax({
url: '/logout',
success: function(data) {
if(data.logout == true) {
// user is logged out
}
},
error: function(jqXHR, textStatus, errorThrown) {
/* problem with logout */
}
});
Your perl logout script will need to return a JSON object as a String, if successful:
{"logout":true}
There are other ways of making AJAX calls and transferring data to/from the server, and you can find those examples doing a search on Stackoverflow for "AJAX".

BlockquoteFirst, I would suggest breaking the problem down so that you can test the logout functionality separate from the page redirect...
I've fixed the problem without the use of AJAX call.