requinix

Users aren't going to care about what the URL looks like. The only purpose of creating friendly URLs like this is so that if a human being looks at it then they can understand what it means, and that matters if you're giving them these links in something like an email. Have you ever looked at Amazon URLs with referrer codes? If one of the biggest sites on the internet isn't doing friendly affiliate IDs then it's just not going to matter much. So take your intentions with a grain of salt, and consider that having a page with an "unfriendly" URL is going to be 1000x better than having no page at all. 1. Search engines don't care about URLs either. They did once long ago, but technology and practices have advanced far since then. Concepts like semantic page markup and mobile friendliness are far more important. 2. Why would you want search engines to index these URLs/pages in the first place? One of the main points of an affiliate link is that the affiliate alone controls it - if it starts showing up in search results then you lose a lot of the benefits. 3. You haven't mentioned yet what these URLs/pages actually do. Are you redirecting? Then SEO is mostly irrelevant. Are you displaying content? If the content is the same for different affiliates then your site will lose in SEO because they're going to think you're a content farm. Forget the .htaccess stuff for the moment and implement the PHP page first.

You need both .htaccess (to tell the web server how it should handle these custom URLs) as well as PHP (to know what to do with the code in that URL). The exact details of how you do that varies between applications. Nowadays, most sites already have the .htaccess stuff in place because they're already using URL redirecting - such as this page, whose URL is /topic/$number-$string which "redirects" to some internal PHP script. If you don't have that already then fine, you just need to add something for these URLs specifically. But there's some preliminary work you have to go through first: create a PHP script which is capable of taking a "XXXXXX" code and doing whatever is necessary. You can just hardcode it into your script to test with, <?php // todo: $code = value from $_GET $code = "XXXXXX"; // ... URL rewriting will transform /XXXXXX into something like /path/to/script.php?code=XXXXXX. Speaking of, /XXXXXX isn't a great choice as it will be ambiguous with any other page at the root of your website - how do you tell whether the "XXXXXX" thing is an actual page or a tracking code? So I suggest giving it a "directory" of something like /track/XXXXXX. The "/track/" makes it unique so it won't conflict with anything else.

By the way, if it wasn't clear, when your browser says "not redirecting properly" what it really means is that you created a redirect loop: the page was redirecting back to itself over and over again until the browser decided enough was enough. Conditionally redirecting would solve this, of course, by virtue of the fact that it won't redirect at all. But it does mean that you aren't completing a POST/Redirect/GET cycle. Which could be fine for you...

E NOT FOUND. Means the domain name doesn't exist. Check again what you're supposed to be using.

Looking through their docs myself, I can't tell either... So what will probably be the easiest way to get an answer is to get the answer yourself: set the return URL and have that page log $_GET and $_POST somewhere for you to look at. That data will probably match up with something in the docs.

"Resource id #X" means you have code that is trying to echo a resource - that's a type of value, like strings and integers and arrays are. Two things: 1. Code doesn't just randomly start behaving differently. What changed recently? 2. "Resource id #34" has to be coming from somewhere. If it's not those two var_exports then where is it?

You need to alter your run configuration in VS Code to pass the -S argument to php.exe. That customizes where it listens on. You'll want "-S localhost:80". It really shouldn't matter. Why does it not work?

You can "yield from" another generator. private function getTextFiles(File $file):\Generator { foreach($file->getChildren() as $child) { if($child instanceof IsTextFile) { yield $child; } else { yield from $this->getTextFiles($child); } } }

Seems fine... I think. I mean, kinda no, but that's a different matter. Have you tried outputting $sql to see if it has the value you think it does?

"Make the button go away and open another button" isn't exactly the most descriptive thing ever... As long as something isn't visible, it doesn't really matter much whether it exists or not. The simplest thing here is going to be a sort of toggle: start with the first button visible and the second not, then "toggle" the two so the first is not visible and the second is. 1. Start with the HTML that includes both buttons. 2. Figure out how you want to hide the unwanted button and apply it now so that the second one is hidden. 3. When the first button is clicked, do whatever it takes to hide the first button and show the second. Okay, so reading that now it doesn't seem helpful, but I'm trying to word it in a way that makes it flexible. Because when it comes to HTML and CSS and Javascript, there's always 100 ways to accomplish a task... however 95 of them are terrible. Here's what I would do. 1. Create a CSS class for these types of button. It doesn't have to do anything (unless you want it to) and only really exists to mark these buttons as being particular types of buttons. So in that sense there's nothing to "create" per se. 2. Create a CSS class for "the active button". Apply it to the first button now, and use CSS to make "these types of buttons" which are not "the active button" be hidden. This means you control visible vs. hidden using a CSS class and not the direct style.* attributes. 3. Add Javascript for the first button that will remove its own "the active button" class and add it to the second button. 4. Add Javascript for the second button that will remove its own "the active button" (assuming you want it to be removed when clicked as well) and make the DIV you want visible; the latter should be through CSS too but it's not really that important. Personally, if I'm dealing with behaviors that are tied to Javascript, I prefer to deal with data attributes instead of class names, but that's not very important either. All together you get something like this: <style> #step-container .step-button:not(.active-step) { display: none; } </style> <!-- This is a nice thing that "scopes" the buttons - using step-button or active-step outside this won't get the CSS applied --> <div id="step-container"> <button id="step1" name="button" class="btn step-button active-step">Click to Verify Information</button> <button id="step2" name="button" class="btn step-button">Show Div</button> </div> <div id="thediv" style="display: none;">...</div> <script> // Creating and running this anonymous function immediately means you can use variables without making them global (function() { // Grab these three ahead of time to make the function code nicer const btn1 = document.getElementById("step1"); const btn2 = document.getElementById("step2"); const thediv = document.getElementById("thediv"); // Add event listeners through code instead of putting them inline with onclick attributes btn1.addEventListener("click", () => { // Use .classList to add and remove classes instead of going through the .className string btn1.classList.remove("active-step"); btn2.classList.add("active-step"); }); btn2.addEventListener("click", () => { btn2.classList.remove("active-step"); // Literally removing the "display" override is better than forcing it to be block/inline/whatever it's naturally supposed to be thediv.style.removeProperty("display"); }); })(); </script> This is closer to the sort of modern stuff that we can do nowadays; the above isn't actually quite ideal, but it's a good step-up from the sorts of stuff we had to do 10 and 20 years ago with inline event handlers and quick-and-dirty Javascript.

I mean, it still works (except the ADODB thing), so... I'm not exactly the youngest web developer either and I find myself falling back on outdated practices occasionally. The IndexedDB thing isn't especially hard, but does make you work a bit more to get some basic stuff. Fortunately the MDN has a reasonable example to reference.

Between the inline onclick, script with a type attribute, and use of var to define variables, I'm going to guess some of this wasn't necessarily written in a time when we had our modern browsers.

Bonus fact: the default min value is 0 and the default max value is unbounded/infinity, so if you use that comma (to indicate it's not an {exact} count but a {min,max} range) then you can leave out the min value itself to get the same "up to X" count. \d{,5}

*slow clap* response.ok will always be true as long as your endpoint is returning 200. If you want to use response.ok then you have to send a non-200 on failure.

Can you throw something up in a JSFiddle so we can see it in action?

I don't see how you're expecting this to work. Is PHP supposed to stream the server desktop UI to the client? Which it won't be able to do unless you have some highly insecure PHP setup, since services on Windows run in a protected sandbox that doesn't actually allow interaction with a user's desktop? If you're on Windows then why not just use RDP?

__DIR__ is a "magic constant" (it's a constant with a value that varies) that is the directory of the file you put that code in. That's all there is to it. Period. Super simple. Nothing to do with URLs. Nothing to do with MVC design. Nothing to do with your website, really. Just a directory path.

Like I mentioned on Discord, put your application behind a login - because if it's an internal thing then you really aren't going to want anybody to go in there and screw around. I also mentioned robots.txt but Google says not to use that to prevent indexing and to do something else instead (like put the area behind a login).

What's more, even a successful run of your endpoint doesn't return JSON. Your JS has no business attempting to read JSON from the response at all. If you're going to do this then do it right: always return JSON, and use status codes like 400 and 500 for errors.

Then it's easy: show the time of the reservation in Florida's timezone. Look at most travel and reservations sites and you'll see them presenting the time in the local timezone. Why? Because if I'm going to go to Florida to go scuba diving, I have to be in Florida to do it. Plus, it's really easy to implement since you don't have to care about anybody's timezone but your own. On the technical side, it's hard to tell for sure with what you've posted, but you're probably not using some of the date functions correctly. Certainly not if you're getting December 31st 1969 as output. How is the user (you) choosing the date and time? What's the code for that part?

Like you started to hit on towards the end of your post, the actual problem you're trying to solve here is to display the time in the user's timezone. When you're the user, that means US Central. When I'm the user, that means US Pacific. You have four options: you can guess their timezone, you can guess their timezone, you can ask for their timezone, or you can ignore their timezone. "Ignore it?" Potentially. What sort of reservations are you talking about here?

You seem to be really enjoying single quotes today. https://www.php.net/manual/en/language.types.string.php#language.types.string.syntax.single

As a general rule of thumb, if you have an error message that you don't understand and would like help understanding what's wrong, post the error message.

That does not make sense. What is the value of the DOCUMENT_ROOT? I would expect it to be /home/bierglae/www/Webseite.ch. I don't know what the /var/services/web path is supposed to represent.

There are two paths you have to think about: the path to files as they exist on your server, and the URL that you see in the address bar of your browser. For files on your server, it's best to always use absolute paths all the time for everything. That way there's no confusion about "well what if I put this in a different place, then I have to change all the paths". To get an absolute path you can use the DOCUMENT_ROOT in $_SERVER. That will tell you what directory is the root of your website, then you can continue building a path from there. include $_SERVER["DOCUMENT_ROOT"] . "/phpadds/head.php"; For URLs, it's common to use absolute paths all the time for everything. Again, so there's no confusion. This time you start everything with a leading slash for the root of your website, then build from there. <a href="/index.php">This one always goes home</a> <a href="/google/index.php">This one always goes to the Google thing you set up</a>