requinix

Given that Ubuntu Focal (20.04) uses PHP 7.4, installing it through apt will be easiest. That's the sort of thing you could probably have figured out yourself.

And to be clear about potential confusion, the word "timestamp" has two meanings. The one I was using is a Unix timestamp, which is the number of seconds since January 1st 1970. So it's a number. The one gizmola is using is the TIMESTAMP type in the database, which converts easily between the numeric Unix timestamp and date strings.

Then you would use the proc_* functions. They're complicated to understand and use (much more than this SSH thing I'm telling you about), but that is the best way to start up a process and send input to it (if you don't have any better alternatives).

Yes, and I'm telling you that's not the right answer. The right answer is to set up a private key and modify your SSH configuration so the whole prompting problem completely goes away. Unfortunately if you search for stuff like "git ssh" you'll find a number of places that don't give the best answer. Generate your private key (that you can search for), associate it with the Git account, then follow this article on how to set it up with SSH. But like I said, make sure you do this for the correct user account on the machine. Which is probably not your personal account. When done right, you (and by "you" I mean whatever the correct user account was) can tell git to clone from github.com, or pull from it, or push to it, or whatever else, and the authentication will be completely handled for you. No prompts.

There are a number of migration guides available to take you from 5.5 to 7.2. You should look through them for this upgrade process regardless of the encoding issue. Spoiler: you need to care about the default_charset at a minimum. The input/output/internal_encodings probably won't matter.

Part of the way there. array_push could be useful except for one rather important limitation: you can't choose the array keys it uses. And since the keys are important here, array_push won't cut it. Also note that array_push is basically just a function version of the [] operator. As in array_push($array, $value) is the same as $array[] = $value. It does allow pushing multiple values at once, though, and sometimes that is useful.

What is the "lampstack" thing you seem to have installed? Ubuntu has a perfectly good LAMP stack available for installation through apt, and it takes care of all this cli-vs-webserver configuration stuff for you.

Entering a username and password is not the right approach. Set up the SSH settings on the machine to use proper authentication with a private key. This can happen automatically without any prompting. Note that this is a general git/SSH issue. Nothing to do with PHP. Just make sure that you're applying these settings to the same user that is running PHP - which is probably not the usual user you're used to but instead "apache" or "nginx" or "www-data" or something else.

1. You don't "get around" it. You fix it. Likely by updating some php.ini settings to match how 5.5 worked. Note that there were a lot of changes to how character encoding works in PHP so you cannot simply copy and paste settings. 2. This could be an encoding problem. Fix that first.

That will add the $newArray array into the users array under a "0" key. As in $_SESSION[users] will be an array with an "id", "fname", "lname", and "0". The answer is array_merge/replace or careful use of the +/+= operator.

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.