requinix

Do not delete data. It's really, really good to have data, and you cannot magically restore the data when you realize that it was actually useful after all. There's a much simpler answer here: the users online are the ones who've been active in the last X minutes. That's all there is to it. You don't have to delete anything.

According to the documentation, oci_fetch_assoc() returns one row of data.

Keep in mind that the + operator (and +=) for arrays may not work the way you think it does.

What's your current code? And just in case, what's an exact example of one of the date strings?

$output .= ' <img src="banner/'.$row["banner_image"].'" alt="'.$row["banner_title"].'" /> <div class="carousel-caption"> <h3>'.$row["banner_title"].'</h3> </div> </div> '; Obviously you need to change that, right? Figure out what HTML markup you need to show a video, then change your code so that it (a) knows whether the item to display is an image or video, then (b) puts the appropriate markup into $output.

It's not just a matter of a checkbox. How you use reCAPTCHA has nothing to do with PHPMailer or really anything else. Completely irrelevant. So what you need to do is look into how to incorporate reCAPTCHA into your script in general.

It can be whichever. Some people prefer date strings, some people prefer timestamps. It doesn't matter very much which you use. ...as long as you use it consistently. If lastaction is a date string then you need to work with other dates as strings as well. Or if you made it a timestamp then you'd need to work with other date as timestamps. That's what your problem is right now: lastaction is a date string but $Online is a timestamp. You can't compare the two directly like that. Either you convert $CheckOnline[lastaction] into a timestamp if (strtotime($CheckOnline['lastaction']) < $Online){ (which you could instead do in your query with a slightly different method) or you convert $Online into a date string using the same format as lastaction if ($CheckOnline['lastaction'] < date('Y-m-d H:i:s', $Online)){ (which you could instead do when you first calculate $Online). Decide whether strings or timestamps make more sense to you, then adjust accordingly.

Is lastaction a date string or a integer timestamp?

Don't use it. I'll ask again: every single page you visit, do they all have exactly the same domain name? I mean everything between those two slashes, not just the last two parts of it. So www.pereia.net and pereia.net are not the same thing. Instead of using Javascript and going through the history, use absolute URLs: echo "<a href='/Dev/mail/view/inbox'>Back to Inbox</a>"; In fact all your links should look like that: no http:// or domain name, and the path relative to the root of your website.

output_buffering is the setting I was talking about. Basically, enabling it lets you pick up some bad habits regarding code and application design. That helps narrow it down. If you have two session cookies then you have two things that are trying to create session cookies. There should only ever be one. Decide whether you want the .sitename.net or www.sitename.net domain for the cookie (it doesn't really matter which, but you might as well go with the .sitename.net one), then investigate what could be causing the other cookie to be set. PHP will not create two unless your URLs are changing domain - and that includes adding or removing a www subdomain - which you said isn't happening, so there's something going on with your setup. Maybe there's different settings, maybe something is manually creating session cookies, it's hard to say.

... These pages, do they ever work? I asked because you have a session_start() immediately followed by an echo that doesn't include any HTML. That should mean there was some HTML being outputted before the code you posted, and if there weren't any warnings from PHP then you must be using some discouraged php.ini settings. What is the value of the output_buffering setting? Variety of possible causes. What sorts of URL paths do you have for the working and non-working pages. Do all pages under a certain "directory" work while pages under another one do not? What does your browser say about the session cookie settings? It should include a domain, expiration, and path. The cookie will only be sent for pages with that path prefix.

Also, is it always the same page(s)? And if you refresh (specifically refresh, not re-browse to) the broken page, does its behavior change? Does it show you as logged in? The code you posted, I don't imagine it's your real code. What is the real code? To find the session identifier, use your browser's developer tools to find the session cookie. It should be quite noticeable. Remember the random ID you see, then (with the tools still open) load pages until you end up getting logged out. The tool should also be able to show you the HTTP request sent to retrieve that page. In its request headers should be a Cookie header with the session ID. Check other pages that worked for an example. Is the Cookie header present and with the correct session ID? For your error log, are you sure it's logging everything? Do you have it set to log all messages from PHP - warnings and notices and all that, not just errors?

If you refresh working pages, do they eventually think you're logged out? Can you watch request headers in your browser to make sure the correct session identifier is being sent every time? Any errors or warnings in your PHP or server error log?

Do your URLs ever change domain name or HTTP/HTTPS?

Oh wait, is this one of those things where someone bookmarks Javascript code? Then it's sounding like you need throttling. Whatever is happening, don't allow it more than once every X seconds.

Then either (a) what I said about cookies/sessions, or (b) the whole thing doesn't make sense. How could having a bookmark possibly give someone an unfair advantage? It's ridiculous. If you don't want direct access to the page then what you want is to require indirect access through some particular flow. So what you do is enforce the flow.

No. No no no. Do not do that. It is pretty much always a bad idea to make it harder for people to browse your website. I don't know what this "advantage" is, but someone typing something into an address bar should not be sufficient to give it to them. If there are other pages that must be visited then you should enforce that with cookies or session data. ...which may be what you're thinking about. If you want people to hit page A before page B then you make sure that (1) page A sets some data, like a cookie or session variable, to indicate the page was visited, and (2) page B reacts in some appropriate way if that data is missing or invalid or expired or whatever.

Caching isn't bad, you know. As long as you're not using Expires, it's totally okay to tell clients that they can cache stuff. Mostly assets like CSS and Javascript and images - things that don't change often. In fact you should do that to help reduce stress on your server and your wallet.

You cannot really control how people arrive at your page, no. A bookmark or clicking a link or typing it in the address bar are all essentially the same thing. If you have a problem when a script runs that much then have you tried addressing that?

I doubt it's broken. More like Edge updated something between versions 38 and 44 to work better.

Unless someone at Doctrine did something wrong, a patch version update like 8.5.2 -> 8.5.4 or 2.7.2 -> 2.7.3 should not break anything. I would first look at the two minor version upgrades: doctrine/inflector (1.3 -> 1.4) and doctrine/common (2.12 -> 2.13). But is that really the problem that needs to be solved? Did you look into the foreign key constraint error first?

That data shows an array containing an object. Decide whether it should be returning an array at all (tip: only do it if you need to support returning multiple objects) and adjust either the PHP or the Javascript accordingly.

Use the correct domain name for the URL. I don't know what it is. You might not even know what it is. But one of those two should be the "proper" domain. If your tool thing complains about preloading then add preloading. Which you do by preloading the actual URL that your page wants to load. Not that it makes sense to preload something that's being embedded right into the page...

Spaces are common and a + is a lot easier to skim over than %20.

1. Because + is also allowed for a space. 2. An actual plus will be encoded as %2B.