requinix

Executed. Not inserted. PHP did not perform some sort of virtual copy-and-paste of the included file's contents into the point where the include call was. What PHP did was execute the file. You said that an include "is the same as though you cut and pasted". I'm picking at how and why that statement is factually incorrect.

No, it does not work like that. Consider this: <?php // one.php if (false) include "two.php"; <?php // two.php echo "first statement\n"; echo "second statement\n"; and compare with <?php if (false) echo "first statement\n"; echo "second statement:\n";

In other words, no: each file has to be syntactically valid in its own right. An include means to run the file, not to "insert" the code at that point.

Alright. Your active and expired links/images are the same. What is supposed to be different?

Right. Each child comes from the parent and each parent comes from the grandparent, and the grandparent table already has a discriminator. That one column can handle all descendants of the grandparent, not just its immediate children.

Right now your query is going along the lines of taking a room, finding bookings for it, and filtering the results according to the date. By putting the date range in the WHERE you require that all rows match the criteria - that it find bookings in the range. That won't help you find rooms without bookings. What you need to be doing is taking a room, finding bookings for it in the date range, and filtering the results according to whether there was a booking. With an outer join on the bookings you'll have all rooms with and without bookings in the range, then you use the WHERE to find the room+booking rows that did not actually have a matching booking. Make sense?

Using your browser's dev console tool thing. They all have some feature to watch requests, like regular pages or AJAX. They'll also show you the form data being submitted, if any. That's what we're trying to find out. Asking the same question again doesn't make any progress.

Yeah, but that's the access log, and while it does show the 403 it doesn't give a why. Let's try guessing from the other direction. Do the POST request in your browser, watching it as it happens. Make sure you can see the whole request - where it's going and what data it is sending - then post it here.

No, it tells you the request was forbidden. What I'm trying to get you to discover is whether there is something installed in Apache that is inspecting the request and deeming it unsafe. Something like mod_security. .com files are not a thing (anymore). Open it with a text editor: what are the first few characters you see (assuming it's not all plain text)?

"Escaping" means like adding a backslash or some other magical character. That there is just switching to using concatenation instead of putting the variable inside the string ("interpolation").

Okay, making sense so far... What's your question?

🤔

It means you can't use IDs anymore. Consider this: <tr> <td style="width:70%;"> Item Name </td> <td class="text-center"> <input name="moneyQty" type="text" value="2"> </td> <td class="text-center"> <input name="singleValue" type="hidden" value="90.00"> <input name="lineTotal" type="text"> </td> </tr> Inside the <tr> is a <input name=moneyQty>, a <input name=singleValue>, and a <input name=lineTotal>. I don't know how you intend to trigger the Javascript to run, but if you can find the <tr> group you want to run it on, you can find a particular input with tr_element_you_found.querySelector("input[name=whatever]")

Try inserting some data and see what gets stored.

Yes: the server error log.

I was referring to the code in the first post. exceedinglife and I made our replies at the same time.

Variables do not work in single-quoted strings.

error_log is PHP's log. PHP is not the one responding with the 403 error. The 403 error is coming from Apache. The fact that Apache is responding with a 403 error, and likely the reason why, should have been written to the error log configured for Apache and/or the virtualhost serving your site. If there isn't an error log set up, set one up, then trigger the error again and see what the log says.

Okay... but I don't see how that's relevant.

Apache should have put an entry in its error log saying why it delivered a 403.

What does your server error log say?

Basically, yes, and if the API can't do what you need (I doubt it can) then your PHP can do it instead.

Are you submitting some request to an API? Does that have any sort of searching, filtering, or sorting capability? $response = strip_tags($response); $response = trim(preg_replace('/\s+/', ' ', $response)); Why are those lines there? Are you sure you need them? (You shouldn't.) Does the script still work if you remove them? (It should.)

That is code that runs after the call.