requinix

I suppose it's quite possible you installed it (or some other software) at some point thinking you would need it, however now it turns out you are not. There are bundles like XAMPP that include PostgreSQL instead of MySQL. Maybe that's where yours is coming from.

phpMyAdmin is for MySQL so I don't know what you're doing. If a malicious program wanted a database then it would not use PostgreSQL for it. That means you have it installed for some other reason; multiple "instances" could be simply multiple processes, which is a very normal thing to see.

For that approach, I mean have the submit button not submit the form. Period. Make it be a regular button, not a form submit button. Then, when that button is clicked, you make it Swal.fire. Nothing about the form happens yet. Second step is using the confirm button of the alert to submit the form. Like it was a submit button.

The "first button" would be the one that started submitting the form (and at which point you have it now showing the popup). By the look of it, I'm talking about #submit-btn. Another approach is, if possible, to block submitting the form based on whether the popup is visible: if not then cancel the submit and instead show the popup, and if so then let it run normally. Then make the popup's button also submit the form. That way the first time the form tries to get submitted (via #submit-btn) it will cancel and show the popup, then the second time the popup will be visible and it will continue.

Then in that case, don't submit the form when they click the first button. Make that trigger the popup, then have the popup's button submit the form.

It may be possible to eliminate the resubmit warning too: by redirecting after a form submission to a reasonable page. That could be the same URL or a different one, point is that the page the user sees is from a normal GET request instead of displayed during their original POST request. It's called POST/Redirect/GET.

Do you want to wait a few seconds, literally to give the user time to read? Or do you want to wait for the user to read the popup and click a button?

Theoretically, sure.

Yeah, there's no way 121k files should take 20 minutes unless you have an incredibly slow hard drive. Like, a tape drive might even be faster. I can't help but notice that your error message doesn't match the code: it says you're creating a RDI on I:\System Volume Information while your code clearly says it creates one on M:...

HTML in emails are notoriously - and I cannot stress that enough - inconsistent between clients. My advice is to ignore these sorts of minor differences. That said, I don't see a border-collapse in there...

Confusion about how Promises execute is one of the big reasons why async/await exists: that code would otherwise be written as async function first() { let x = 20, y = 20; if (x == y) { return; } else { throw undefined; } } async function second() { try { await first(); console.log("that's correct"); } catch (_) { console.log("that's not correct"); } } second(); "async" means the function might not finish running immediately and it implicitly returns a Promise, and "await" means to wait around for whatever function call (Promise) to finish before continuing. But you can more or less ignore those keywords and just look at the code like it was two normal functions. To answer the question, 1. p is a Promise that starts with a simple function. 2. You add a "layer" to that Promise which says if it executes normally (resolves) then log "that's correct". This creates a second Promise. 3. You add a "layer" to that Promise which says if anything before it executes abnormally/throws (rejects) then log "that's not correct". This includes problems with the p function but also the .then function you passed - because .catch will catch problems with any of the previous Promise "layers", not just the first or the most recent one. 4. At the end of all this you have a Promise which does not get assigned anywhere, but that's okay because you don't care about the (third) Promise itself - you just wanted it to execute, which it does. If you want to know exactly when each of those steps executes - like literally when it happens - that's a bit of a more complicated subject. The simplest answer would be "as soon as it can", and in the case of your (trivial) example it all happens more or less immediately since none of it needs to try to wait around for anything.

What do you mean by "restarting"? The loop won't actually restart, of course. Are you remembering to truncate the table before every run of this script? If you're getting "too many" files then compare what files you're getting versus what files you expect. The difference would have to be somewhere in there, but without knowing it then you'd have to guess.

Are you sure you want to be following symlinks? Are there any hardlinks on the drive?

You've given every field its own distinct <form>. If you want to access all the fields at once then you have to put them all in the same form.

That's because your "back" button is not a back button. It's a link that takes the user to the URL of the previous page. Which, in all possibility, is not going to present them with the same information as it had when they left it. Question #1: Why do you have a back button at all? Question #2: Why aren't people using their own browser's back button?

You can overcome the issue by not installing PHP and its extensions manually. Revert the changes and installations you've made and go back to trying to use Remi's repo. What was the "No php package available" error you were getting then?

I think the "modern" things are more along the lines of React. I'm old-school myself, still using jQuery for literally DOM manipulation - not even using its AJAX features anymore because fetch() exists. Something I had looked at a while ago was Backbone. Seemed like it was essentially the DOM updating stuff (like seen in React) coupled with some API conveniences.

Context of what you're doing?

Yielding the same object multiple times in a generator creates the sorts of problems you get like with SplFileInfo; I'd give a link to what I mean but I can't find one, so I'll summarize by saying that iteration on it (when a directory) yields the same object over and over, which means you can't do things like use iterator_to_array or even hold onto the iterated value for long. It's somewhat similar to the problem of foreaching with a reference. I recommend cloning the $obj each time - it's a test so who cares about performance and memory usage? public function someProvider(): \Generator { $obj = new SomeObject(); foreach([4,3,6,1] as $i) { $obj = clone $obj; $obj->setIndex($i); yield [$i, $obj]; } } (Or another solution where $obj changes. Depends on what SomeObject is and how much you can alter it for use as a provider.)

PHP doesn't see non-breaking spaces as whitespace. So it gets confused while parsing and will spit out seemingly random error messages.

Make sure you're using an editor which is not inserting obnoxious characters into your code. Such as non-breaking spaces, which I see a few of in there.

There are a few other problems besides that one... 1. Don't use inline styles. Learn and use CSS. It will make your life easier. 2. I don't think the name of the class is "table-borderrer". 3. If any of those values from the table contains anything that looks like it might be HTML then it will screw up your page. Instead of thinking about whether they will, assume they will: it's much easier. Use htmlspecialchars() when you want to output a value. 4. Similarly, if the name has any apostrophes then it'll break the link and you'll never be able to delete it. If you switch to using double quotes for your attributes then htmlspecialchars() will solve half of that problem. The other half is using urlencode() so that the name doesn't screw up your URLs. You can use them together with htmlspecialchars(urlencode(the value you want to output)). 5. Do you have a $buttonStyle variable? 6a. Things like deletes should not be handled through URLs you can see in your browser's address bar. They really need to be <form>s with method=post. You could stick a quick form in your table cell, but... 6b. If all you need to delete a booking is a single value then a <button> can do it. Wrap your entire table in a <form> then, in the table cells, use a <button> with type=submit (so it submits the form) name="Name" (this is the name of the booking) value=the name of the booking (remember to use htmlspecialchars, and since this isn't going in a URL you don't need urlencode). Inside the button's markup you can put the word "Delete". 6c. Either way, remember to fix your delete_booking.php to use $_POST. 7. Once again, if the name contains any sorts of symbols or spaces then it will screw up your query (for more reasons than that too). Don't try to escape the value. Do use a prepared statement.

If you have a lot of files then yeah, I can definitely see having a memory problem with that code. Have you ever heard of RecursiveDirectoryIterator?

filectime is not file creation time. The "c" means "change", as in inode change time (which also does not mean modification time). There is no way in PHP to get the creation time because many file systems don't actually store that information.

Well, first question would be, what's changed recently? Because something has changed - software doesn't just randomly decide it's not going to work anymore. Second question would be if you can see any errors: stuff related to PHP, stuff inside your own browser (like while you sit on the alerts page), anywhere. It not working means that whatever changed is likely creating some number of error messages.