requinix

Rate limiting.

What error? Undefined variable?

1 message per second is what they give you in the sandbox. If you're using this for real messages then you should not be in the sandbox...

Are you sure you're passing data to the view correctly? That array keys in your $data will turn into variables inside the view file?

You'll probably want to switch to using a cookie at some point - that's nicer than having to use that query parameter all the time. Although I feel like I've forgotten something - maybe Xdebug sets the cookie for you? Something like that, maybe?

Rather than guess at what docs are correct, use the official ones. Like that Step Debugging link, which tells you: 1. Set xdebug.mode=debug 2. Since you're a "complex setup" with a remote setup and SSH tunneling, set xdebug.client_host=localhost and client_port=9003 (which your SSH session will forward, provided you have that running at all times). 3. To use triggered debugging for a web application, either (a) set ?XDEBUG_SESSION_START=session name in the URL of the one page you want, (b) an XDEBUG_SESSION cookie, or (c) call xdebug_break() in code. You can also look at the All Settings page to discover that settings like remote_autostart, remote_handler, and remote_mode don't exist anymore.

You have code that ends up doing something like this: $variable = false; echo $variable->current; That is wrong and broken. It needs to be fixed, and making the warnings go away does not do that.

Right: since the animation is based on progress (0-100%) instead of time, what you have to do is (1) increase the animation duration to include the amount of time when it isn't doing anything, then (2) figure out what percentage 2-3 seconds into the animation is and use that in the keyframes. It's not the cleanest solution possible - that would be literally making it not animate during that initial pause - but it is easy, and with an interstitial page like this, no one's going to notice.

Did you try altering the animation keyframes? Have it not do anything for the first 2-3 seconds, then start changing the opacity.

And I just noticed another one, and on second (third?) look I don't see anything else, so [A-Za-z]{3,16}+ The + makes it possessive, meaning there won't be backtracking if the rest of the pattern doesn't match. It's being used correctly here (backtracking won't ever cause the regex match if it didn't already) but be careful about it using it in general because it can easily cause a regex to fail when it could otherwise match. You could apply it to [A-Za-z]{3,48} as well since it's the same situation. But having it at all is an optimization that isn't going to matter much here so it's not important.

Please note that you're not writing modern HTML: attributes like bgcolor and image width/height have been discouraged for a number of years now. CSS can't respond to events like Javascript can. It has limited support for things like hovering over elements, which isn't so much an event as it is a persistent state, but doesn't really do clicks. Add some simple Javascript that applies or perhaps toggles a CSS class on some element when clicked, then write your CSS around that class.

There is a minor thing I can point out, if you want. /^[A-Za-z]{3,16}+_[A-Za-z]{3,48}$/i Since /i makes it case-insensitive, there's no need to specify both A-Z and a-z. Personally I'd probably list the two and drop the flag: it keeps the expression explicit about what it matches, and while the /i lets you write less, here it's not that much of a difference.

Looks good to me. There are a few online tools to help build and test regular expressions, like if you want to try running a few inputs through the regex to see if they match. regex101.com and regextester.com come to mind. A router takes a request and routes it to a different location or resource or code path. That sounds like what you're doing.

Don't use regular expressions to parse HTML. Use something like DOMDocument to load the markup and navigate to the table cells you want to read.

What are you trying to protect against? Someone reading source code in your repository? Developers themselves knowing how to connect to and read from a production database? Other people on a shared hosting server reading your files?

Email addresses can be validated with filter_var or filter_input. Password "validation" depends on what you want to do but, yes, typically regular expressions are involved. We can give much more precise answers if you can give us much more precise questions. Exactly what do you want it do?

So I guess you figured it out?

My first suggestion would be the same place where you discovered there were multiple processes...

Ideally you would be able to create a "submit" button on the form that is an actual submit button, then give it a form= attribute to point back to the regular form (which would allow the button to behave like a submit button even though it's not actually contained within the <form>). If you can't then add some code when the swal closes (not cancels) that uses Javascript to get and .submit() the form.

Short answer: yes, unfortunately. Because even session cookies still provide tracking ability, even if you're not doing advertising or analytics. It's probably sufficient to include a small dismissable banner that says cookies are required for log in functionality (only) and that logging in implies consent on the user's part.

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.