requinix

Make sure PHP is being run with the correct locale, then retrieve it. Note that's not a complete answer. You'll need to investigate and test a little.

The temp dir really ought to be writable by PHP. You and/or your client should complain to the "ISP" or whoever manages their PHP setup to allow for that. Worst case: write to someplace other than /tmp. Like a dedicated log directory for your application. Oh. And this is something that should be configurable.

How about you try describing what you want with a few more words? Maybe even an example or two?

Look at the documentation for session_destroy() to see how to destroy a session.

Extensions are not freebies. Most of them come with particular requirements that you must have installed. So you tell me, does it make sense to install Oracle database support on your server if your application has nothing to do with it? And all that software comes with additional risks of vulnerabilities and such. And some of them do come with some overhead even when not in use. And every time you want to update an extension you have to restart PHP. Installing and enabling extensions is easy. Don't be lazy. Get what you need, don't get what you don't need.

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.