requinix

In my very first post here I questioned why you were even having it redirect at all. I haven't changed my mind since then. You know how br-storage goes to your server? The server that has the website and all that? mullins-storage needs to do exactly the same thing. No redirects.

It's on the right server but it's redirecting to br-storage.com now. The web server needs to handle both domains going to the same site.

Must be a really old book. What you should do is actually learn how to program with PHP instead of throwing code into files and tweaking it until it works.

If it needs to have access to all the requests and responses at once then you kinda have to go the RequestResponsePair route (though I'd pick a different name). But first I would try to see if maybe it could be refactored so that it can do a sort of "set up" step, process each request/response in turn, then "tear down" after. Depends why and how it's processing as a group.

Here's a really simple reason that you should be able to understand: If your code doesn't do what you want it do then you need to recode things. We're talking about removing a couple lines and changing a couple lines. It's not rocket surgery. Read the other thread where we told you why you should use glob() until you figure out why. Because you don't understand what the problem is. No.

Didn't we tell you to use glob()?

Whatever is on lines 6029, 1252, and 9 of those files, that cannot happen if there has been any output. You can't put that <link> where it is. And it probably shouldn't be where it is to begin with.

What they did was host mullins-storage.com on their servers, and the webpage they present uses an iframe to load br-storage.com. That's not good. It also doesn't support what you want to do. You need to point both domains to the same server, then make sure your web server tries to serve both sites... however they need to be served. I don't know what "deluxe hosting" is but you're probably getting close to it.

If you really don't know what . and .. are then you need to research the very basics of how every single filesystem in existence works. $file is not a full path to the file. It's just the name of the file. So the question is whether you think is_dir("_photos") should say true or false.

Can you link the website?

Good first step. Now what about the other things I said?

Make sure all databases, tables, and columns, as well as the connection settings, use UTF-8. Make sure your PHP files are saved with UTF-8 encoding. Make sure your webpages use UTF-8 encoding.

The compression function is not the problem. Anymore. After you moved that imagejpeg line. So now let's go back to an earlier question: where do you expect the images to go? Have you been looking in the same directory as the PHP script?

Yes. Apache is logging errors to a file. Open the file and look at what is inside. Or wherever. Yes: the session cookie settings.

Disable all redirections, put this on your server, and browse to it. What does it say? For both http:// and https://. <?php var_dump($_SERVER["HTTPS"] ?? "unset"); Check your error log. What are the session cookie settings?

Should be, yes. But what you're describing makes it sound like that second leg is not being encrypted right now. If it was not, with my version of the URL rewriting, it would always think the connection was HTTP and would always redirect. Every time. The browser would keep being redirected to https://www.mysite.com over and over, which could appear to you as a "loop" because the CPU usage of Apache handling the same request over and over. You don't see how understanding HTTPS on your site has anything to do with redirections to HTTPS? Not necessarily. It should in theory, sure, but if they're unwrapping the SSL then this will not work, and if they're forcing SSL even if the original connection to them was not then this will not work. You've said that sessions are not working properly on your site. I've said that it was a configuration problem. You decide.

I'm wrong, nevermind.

Yes, you keep saying that. But it's irrelevant. You didn't have redirects working the way they needed to work so what your site was or was not doing doesn't matter. You might as well say that "my car is making rattling noises when I turn it on, but it wasn't doing that when I had it turned off...". I'm ignoring it. What does the access log say? Their version is not proper because it will result in multiple redirects: http and mysite.com -> https and mysite.com -> https and www.mysite.com. What they do show is the use of X-Forwarded-Proto. It suggests that your CloudFlare configuration is middleman-ing the HTTPS: browser thinks it wants HTTPS, goes to CloudFlare, CloudFlare handles the SSL and then forwards it as HTTP to your server. Is that what it's doing? Are you seeing many duplicate entries in your access log?

Alright. Now look at your compress_image function and tell me if you see anything wrong with it. Nevermind, this question is no longer relevant given your answer to the first one.

There aren't too many ways to break it. As long as your session configuration uses the right domain names and paths, and as long as the redirect does what it is supposed to do, then sessions will continue to work. Some sort of permissions are wrong. Like, the user PHP is running as does not have permissions on that ea-php72 directory. I can't explain why. Might as well as here. If it's too complicated I'll split the post(s) into a new thread.

Fair enough. Two questions: 1. What type of image are you testing with? 2. Where are you looking to see the compressed image?

The whole point of stepping away from the computer is so that you stop trying to figure it out. Your brain needs to stop working on this and do something else. Because maybe tomorrow, when you come at it fresh, you'll see (a) how compress_image is getting something particularly wrong and (b) where your files are actually going.

They all find it except for Brazil and Thailand.

"My" code has nothing to do with your session. If your sessions are breaking then your session cookie configuration is wrong. Likely the domain: it needs to be either "www.mysite.com" or ".mysite.com".

Sounds like maybe your CloudFlare configuration is wrong.