requinix

It's not exactly easy to tell what it is you're describing, but I think the general term you're looking for is "front controller": where most/all code doesn't start off by executing individual .php files but instead everything goes through one file (typically index.php) which then has some amount of logic to determine what code should be running. That process can start with URL rewriting (telling the web server that everything should go through index.php) or simply using specially-crafted URLs (such as query strings like /my_directory/?stuff or PATH_INFOs like /index.php/stuff); the former is the modern approach.

I don't see anything in the W3 reference for heights. Have you considered writing (gasp) your own CSS instead?

You can set height with CSS just fine. What markup/CSS do you have now?

That is a problem. Do not ignore the problem. Find out why it is taking so long and fix it.

Where are you using table_body?

The password_* functions handle everything for you.

You would be trading a negligible amount of resources to run your script unnecessarily for a lot less complexity. What's worth more to you: having to juggle cronjobs according to when you need them and when you don't, or always running some script that has a couple lines of logic that detect whether it needs to run? Also consider that this "always schedule and stop running if unnecessary" is extremely common. It's so much easier and there is virtually no downside at all to having it in there. Trying to manage the cronjob is a micro-optimization that comes with a lot of complexity. How long have you already spent trying to solve this problem? How much more time would it take to implement and troubleshoot it? It's just not worth your time.

It's only hourly. That's nothing. Your alternative of dynamically creating cronjobs is... weird, like, it feels really weird. Cron isn't designed for one-off tasks like that. I'm not even sure why you (think you) need cron for this in the first place.

Create one cronjob (manually) that decides whether or not it needs to execute.

For anybody else who wanted to know what the answer was, 1. Form has to indicate what the sid was so that the page receiving the new file contents knows which file it has to update. Do not give the src_name. That is not secure. sid is the way. 2. Write code that uses $_POST to get sid and new file contents, file_put_contents with the appropriate filename, ???, profit. Separately: loops are used when there are multiple things to work with. That query does not give multiple things to work with. There should not be a loop.

It's called a "shared server" because you share it with other people.

Why use MATCH AGAINST when you could just use LIKE?

How you pass the user depends a lot on the architecture of the site code. Current user information is often a singleton/registry, which means not passing $users anywhere, but if you need to perform operations on any user (logged in or not) then yes, you'll be passing user objects around.

If your query is hard-coded without any variables then it should be trivial to verify the syntax. If you go with prepared statements then you can easily verify their syntax too. When you do that, the "only" reason any of these queries would create errors would be with larger problems: server is down, database doesn't exist, table has the wrong columns, etc.

You've spent "months" and "years" trying to understand Composer and never found out about composer require?

You may have made a mistake by requiring that $user. In fact I think you did because that's kinda weird to do. But it's quite possible you could reuse $user and just have it be null for anonymous sessions. Also, asking questions about specific code tends to go better when you post specific code.

Try removing the session_start() and see what happens. Also try reading the documentation for sessions and session_destroy() to see what PHP says you should be doing.

If you want the new DIV to be below the .comment-meta then (1) give that new element a class like how the others have classes, then (2) since you're using flex, apparently, tell CSS that you want the .comment-meta to take up the whole line it's on and the buttons will be forced onto the next one.

See how all those new inputs are named "email"? That's not good. The name is how PHP knows which field's value to get so they all need to be different. Also the IDs, for that matter. IDs must be unique on a page. When those are fixed, post what you have (so we can see the new names) and then try adding some PHP code to get those values. It will be a couple lines that look very much like the lines to get the other fields' values. Give that a shot and post what you come up with so we can add them into the email message.

Have you added those fields to the form yet? What does the HTML look like?

Would be nice to know what answer you found. Can I assume it's JSON.stringify + json_decode?

And what email address are you trying to add as CC? Or is it BCC?

You're only giving the barest description of this "added numerous times" deal. Does that sort of pattern happen for every other (different) line in the file too? In the same way? Are they repeated the same number of times? Is each distinct line repeated always consecutively or are they ever mixed? Any discernable pattern? Any breaks in that pattern?

"[object Object]" is something created by Javascript, not by PHP. It's what happens when you try to treat an object like a string. Are you sure conn.send can take any argument type? Or, perhaps, must it be a string value?

Do you see the same line multiple times sequentially? Or are the bunch of lines repeated as a group?