requinix

Print out the value of the DOCUMENT_ROOT and see what happens when you try to add "../includes/db.php" to it.

RDP servers are notoriously risk-prone. It's almost always a bad idea to have them open to the internet for anyone to connect to. By "tunneling" through the VPN, the RDP server remains disconnected from the internet, but you can still access it by connecting to the VPN (which is going to be much more secure). Ditto for the remote server. In your case apparently you need two hops, presumably because it's not accessible over the VPN directly, but the point is the same. It's very common to have a database server not connected to the internet, to minimize risk, so to allow access you can VPN or SSH into the network and then tunnel to get a direct database connection.

If we're still talking about the original issue, my reply was trying to point out that you were rewriting everything when you should be rewriting only the things that don't exist. Also, followed by is funny.

Preview? They might not have a name per se...

It's rather unlikely that GoDaddy is running a PHP that isn't using mysqlnd. And I'm not sure that existed in the time of PHP 5.2. So this situation you're describing seems backwards. First things first, though: PHP 5.2 is extremely out of date. You need an version of XAMPP that has PHP 7.4 - to match what your real website is running. Frankly, I'm amazed XAMPP even provides PHP 5.2...

If you're looking to hire somebody, try the Job Offerings forum. If you need some help doing the work yourself, we have a few forums according to the topic, such as PHP Coding Help and MySQL Help.

Basically no. The query optimizer will rearrange the query as it sees fit according to heuristics that are probably better informed than you are. Generally, you want to write the query in the most logical way and let MySQL execute it however it wants. Post your query and an EXPLAIN for it.

get_result is only available if you're using mysqlnd, the exact details of that being mostly irrelevant as virtually everyone should be using it by now. What version of PHP are you using locally, and what version is on your server?

I don't see anything in our regular logs... Are you sure the message didn't get dumped into a spam folder? Ever had problems with signups (or just emails in general) from other sites? And a fun fact: the last person to sign up with an sbcglobal.net email was back in 2015...

Once again: the "latest version" of Webalizer, this 2.23-08 that you found, is ten years old. https://webalizer.net/news.html Webalizer is dead, and the longer you insist on using it the worse things will be for you. No updates. No features. You're going to fall further and further behind on the sorts of things everybody else is using because they're using modern tools. Changing software sucks, I know, but it's very much worth the temporary discomfort.

I can't think of a reason this code should be in place: it modifies where PHP stores session files, which PHP is quite capable of handling by itself. Why do you think you need this code?

Has it always been slow/occasionally not returning, or did that change recently?

Webalizer? You mean this one? Whose homepage dates to 2014, and tells you to download it over FTP?

Sounds like a query failed.

I don't see anything in this code that has to do with your PHPSESSID.

Sure it does. I can't tell why you attached a sig.txt file to your post though.

I don't know what you're asking or how to answer it either, but I can definitely confirm that the code you posted doesn't make any sense whatsoever and there is no reason it needs to exist.

Okay. And?

Basically anything that has "await" and/or "async" keywords works the same way.

800 isn't enough to run into the one or two PHP bugs I know of (which also have their own specific circumstances) but you should avoid putting everything into one directory on principle. Typically one partitions into ~a hundred or so per directory "tier". Though really, you shouldn't be storing stuff in files like this to begin with.

And how many files are in this directory?

You know, I'm not actually sure how to "professionally" solve this. The issue being, to be clear, that with a certain viewport height there is a certain range where scrolling into it causes the bar to hide, thus decreasing the height of the document, and if the viewport is also close enough to the bottom, the decreased height causes the document to scroll "up" and triggering the bar to display, and that can cause a scroll event again where it's re-calculated that the bar should be hidden... And narrowing the viewport width enough causes wrapping which increases the element's height and thus also the size of the problematic range, making it easier to trigger. Barring more specific advice, my suggestion would be to toss out what you've come up with and see if Google can suggest a different implementation to use. eg. https://www.google.com/search?q=css+disappearing+nav+scroll+down I'm betting that a successful solution will involve the scrollTop property.

So you do understand why it's doing that, right? Exactly what is the goal? Which menu is it you want to hide under what conditions?

317000 GET (ahem) To emphasize what mac_gyver said earlier: you're not running specific logic on specific days. What you should be doing is looking at the current state of things (like the date) and comparing with the previous state of things (like when The Thing last happened) and figuring out what to do. If you want to give the user the option to do something "on the first of the month" then the current state is the date, the previous state is the last time the user exercised the option, and the comparison is whether it's now a new month since then. If the current month is June 2023 and the user did the thing in May, or April, or March, then you let them do the thing; if they did the thing in June (ie. this month) then you don't let them do the thing. If you wanted to give them the option every month with rollover, you do the exact same thing except the comparison is "how many months have lapsed since they did the thing". If they did the thing in March then you would grant them 3 (April, May, June) options.

Try it and find out. Seriously. That would have been the easiest option this whole time. All you had to do is manually find a setuid executable, such as sudo, and run different find commands to see what happens.