Develop Reference

How can I run a block of PHP code every so often?

I am creating a website where the goal is to have only one session per user, I managed to do this with some validations and adding fields to my DB, then suppose that if the user enters with his username and password in Chrome he can navigate without problem, if the The same user in another browser either Firefox enters with his username and password, in the Chrome session when reloading the page or going to another page directly the session is closed, but what I want to do is log out instantly the moment the other session is started or if it is not possible then that this be done in a certain time so as not to wait for the page to reload or change to another.
This is my PHP code where I have the validation, I investigated that I can do it with ajax, but I don't understand how to do it, someone could guide me on this please. I thank you in advance.
$userById = $connection_s->getUsers($_SESSION["id_user"]);
if ($userById["fecha_acceso"] <> $_SESSION["fecha_acceso"]) {
echo"<script>location.href='logout.php';</script>";
}
I don't know what else I could put in code, this is my validation.

How to stop esc key from stopping redirect

Using AJAX to submit an order:
user fills out form and clicks submit
disable submit button to keep from multiple clicks
pop up modal informing that order is being submitted
submits form via ajax
if successful, redirects to order confirmation page
if not successful, explains why, hides modal, reactivates submit...etc.
The problem is, when they click submit, if they then click escape key, it can stop the redirect, and then the page is just stuck on pending even though the order technically already went through.
Question:
How can I keep the user from using the escape key to stopping my redirect?
I don't think the user would even know that's what they're doing, but in my case, the order has already been processed. Hitting escape simply keeps them from seeing their confirmation page, likely making them assume the order didn't go through.
Is there another/better way to handle this situation?

I don't know what you are trying to do exactly but I'm assuming staying in the page after success destroys your site logic and I'm going to give you some tips
But be aware there is no ultimate solution to this problem,the user can click the stop button on the browser, or he can close the tab all together !
so I'm assuming this is only to prevent user mistakes only
First Way: when the success call back triggers, make a Boolean variable as flag to preserve the success state, now when the user submits again if it's true you can redirect again, or maybe even put a timer that tries to redirect every x seconds for example based on this flag
Second Way:(I'M NOT SURE IF THIS WORKS!) Register a keyboard event for the escape button, and consume the event using event.stopPropagation this might be even browser dependent

Your original submit sends the Ajax request to some web service for fulfilling the order e.g. /ordersubmit. The logic in the web service returns the redirect response after a successful order. The response may take some time and the user can cancel the request before the response is received.
Create a new web service e.g /orderstatus that checks the order and if it has been successful returns the same redirect response as /ordersubmit would. If the order is still pending or has an error return a suitable message body.
The web order page has a timer started after the initial Ajax request to /ordersubmit. When the timer expires the page sends a new Ajax request to /orderstatus and acts on the response.
If the response isn't the redirect start a new timer and check again. If after three tries the order still isn't complete show a suitable message asking them to contact support.

Facebook Flex and feedback from Actions

I'm playing around with Facebook Flux (I'm using Fluxxor, but I don't think that's really important) with ReactJS, and so far I think they its a great way of working with the data flow in an application. However, there's one thing that I'm really struggling to get my head around. It might be that this is simply something that shouldn't be done with Flex, or that I'm missing something obvious, but hence why I'm asking...
For example, I'm building a system to log in with. Very simple - there's a Login dialog that pops up, and you enter your username and password and press the button. This calls the LoginAction.login(username, password) Action Creator, which sends the LOGIN Event to the Dispatcher and then triggers the API call to authenticate the user and make sure the credentials are correct. If we get a success back from the API then we trigger the LOGIN_SUCCESS Event to the Dispatcher, the SessionStore handles this and stores the fact that we have successfully logged in, and the details of who we are. This then triggers bits of the UI to update - for example the "Log In" button changes to a "Hello Graham" bit of text, and a "Log Out" button instead. That's all really easy and just works and makes sense.
What I'm getting stuck with is when the login fails. If I enter an invalid username/password then I want the Login Dialog to tell the user this, so that they can correct what they entered and try again. The only way that I can think of to achieve this is to send a LOGIN_FAILED Event to the Dispatcher, which is then handled by some Store that stores the last Login errors for the Dialog to display. This just feels weird though, because these errors are not application state but are instead a transitive piece of information about this one request that failed, that the user will then correct and retry.
It feels to me that this transitive state is going to be very common around API calls that might fail because of user input, and so don't belong as part of the application state but instead belong somewhere else. However, I can't work out how Flux allows this transitive state to get back to the UI to be displayed to the user...

SessionStore handles this and stores the fact that we have successfully logged in
In your case you keep information about successful auths. Why not to keep info about unsuccessful once also at store (the same store or independent once which keeps auth state or permissions state for user)?
It's another side of your state. In this case you've just have to dispatch special event on failure (like in you case about successful login) to store(s), save new state and send changes to the UI.
Here is the example which is similar to what i mean. You send a request to the server ant can dispatch an action if login fails.

Is an AJAX request killed when a link gets clicked?

I have a website with an AJAX cart. The concept is pretty simple: you end up on a page with a product and can click the Buy Now button. When you do so, the JavaScript code adds the product to the cart, changes the cart visual with the new count, and sends an AJAX request to the server to report the change.
What I'm wondering about, since the client and the server may take a while to process the AJAX request, is... will the client clicking a link to move to another page (i.e. "next product") before the AJAX is reported as successful stop the AJAX request at all?
// prepare request...
...snip...
// send request (usually a POST)
jQuery.ajax(uri, ajax_options);
// return to user
// will a click on a link cancel the AJAX call after this point?
Further, I have timed AJAX requests. If the user clicks on a link before those timed requests happen, they will be lost for sure. Assuming that the click does not cancel an AJAX request, would starting one in the unload event work? Would using a cookie be better/safer than attempting another AJAX request? (although if the user clicks an external link, the unload is really the only solution I can think of to save that data...)
As a side note: I do not want to darken the screen when the user adds an item to the cart so that way the user can continue to do things... but if the AJAX needs to be confirmed before a link can be clicked, I'd have to make sure clicks cannot be used until then.
Update:
I thinks that some of you are missing the point. I do not care about the done() or completed() functions getting called on the client side. What I do care about is making sure that in the end I get all the data on the server.
I understand that's asynchronous, but what I want to make sure of is avoiding loss of data, especially if the link goes to another website (to the same website, I am really thinking to make use of a cookie to make sure that the data of delayed AJAX requests get to the server no matter what.)
Also, the idea of timed data requests is to avoid heavy loads on the server. With a properly timed set of AJAX requests, the client and server both work a lot better!

#meagar summed this up pretty well in the comments
Any pending AJAX requests will be aborted when the browser navigates away from the page.
So depending on how you define "killing" an AJAX request, that means the request may be started, but it also might not have finished. If it's a short request, most likely it won't be aborted by the time it finishes. But if it's a long request (lots of data processing, takes a second or two to complete), then most likely it's going to be aborted somewhere in the middle.
Of course, this all depends on the browser. The issue typically is that the request makes it to the server, but the browser aborts the request before the response comes through. This all depends on the server and how it processes the data.
Some servers will interrupt the execution of your view, where the requests data is being processed and the response is being generated. Many servers will just let the code run and trigger an error when you try to write output to the response. This is because there is nobody on the other end, so you're writing the response to a closed connection.
although if the user clicks an external link, the unload is really the only solution I can think of to save that data
From my own experience, most browsers will allow you to send out a request during the beforeunload event. This is not always true for unload though, as by that time the page change cannot typically be stopped.
One way to get around this, especially when the response matters, is to halt the page change after the user clicks the link. This can be as simple as calling evt.preventDefault() on the click event for the link, and then later redirecting the user to where they wanted to go when the request is finished. You should make sure to indicate to the user that their request has not just been ignored, but that they're waiting on something to finish first. Users don't want to be left in the dark, so make sure to give them some feedback (like changing the button text, disabling it, etc.).

Javascript OnPageUnload - on "leave page" must call additional method

This is the problem: my web application (php) has a wizard feature which gathers customer's data page by page, and stores it in session. If customer tries to navigate away from the page before they have completed the wizard, I would like to display a massage to the effect of "You will lose your data". If the customer chooses to navigate away, the session data should be wiped.
I know that I can intercept this action by binding onpageunload event, but is there a way to then make another call, e.g. ajaxClearWizard() if the customer says "yes"?
PS I can see that, perhaps session shouldn't be used here, but I'm using an existing library, and although this wizard-data-persistence used to be a required feature the business now requires it to be removed :(
Any ideas, alternatives?
Thanks in advance!

window.onbeforeunload = function () {
return 'Your content has not been properly saved yet!';
};
This will make the browser display a confirmation box in middle with above content.