requinix

You're right, it is a frequent requirement. It's so frequent that people don't implement these things themselves. If you want to monitor for "bad" activity and ban clients, that's literally what tools like fail2ban are made for.

I'm betting that Tea was developed through vibe coding... 98% of inline CSS is bad and shouldn't be inline CSS, but IMO there are reasonable and not uncommon situations where inline CSS is the "correct" solution: Namely, when an amount of required styling for some element is just so damned specific and unique that it doesn't make sense to hoist it into CSS that exists Somewhere In The Project, and instead tightly coupling it to the element (ie. inline) actually makes understanding and maintaining it easier. Which isn't to say that it could/should never be promoted into a stylesheet, just that there's no apparent call to do so (yet). Off topic, just saying. (Even more off-topic is that Bootstrap is the worst thing to ever happen to the world of front-end development; I could write a VERY lengthy rant about how screwed up standard CSS practices are because of that nonsense.) That's the thing pro-vibe coding people leave out when they evangelize the idea: yeah, sure, the AI spit out a bunch of code much faster than a professional developer could have, but the amount of time spent screwing around with it afterwards because the output sucked offsets those gains by so, so much. As an old-school programmer, I avoid using Javascript for anything that regular HTML/non-Javascript practices can handle. Which means I hate React and its frenemies. But even setting that aside, there really is no good reason in remotely modern web development to be using Javascript to simulate CSS functionality. Back in the 2000s that was necessary because CSS was still young and web designers wanted to do much more than it was capable of (we didn't even have :hover back then), but nowadays CSS is capable of far more than many people give it credit for. Naturally there are still concepts that CSS can't do and that Javascript is required to "polyfill" - UIs will always want to be one step ahead of technology - but if CSS can do a thing then CSS should do the thing. Reasons vary: graceful degradation, requirements for technical know-how, browser performance, single-responsibility principle...

You forgot the variable for the "WHERE ID=?" at the end of the query. And are you sure you really mean to try to update the ID? That would be weird...

"Revolution"? lol. It's another Whatever from the tech world. It's not the first fad used to pump up stock prices, and it won't be the last. The current state of glorified autocomplete systems AI contributes just about as much value to the world as The Blockchain does. You remember that whole thing? Wasn't that long ago when The Blockchain was being called a "revolution" too... The next Whatever will happen in a few weeks, or months, or years, and every publicly-traded company will jump on that as fast as they can too. (Make sure you're not still holding onto all of your NVDA when that happens.) And I'm sure that'll bring its own "revolution" too.

E_DEPRECATED and E_USER_DEPRECATED are the same thing, with the one difference that the former is used by the engine and the latter is used by trigger_error. So the question is in what environments do you care/not care about getting messages about using deprecated features and functionality?

Sigh. I mean, if you're able to understand ticks from that then congratulations?

Yes, granular, as in "highly detailed; having many small and distinct parts". Because you missed the part in my reply where I said "write a bunch of code". You wrote a very small amount and you're not going to see how ticks work unless you write a lot more.

A tick happens every time the engine does something at a fairly granular level. Like executes a statement, but even lower-level than that. The easiest way to understand it is going to be to play with code: set up a ticket handler every 1/2/3/whatever ticks, have it output something, and then write a bunch of code to execute and see what happens.

Don't. PHP isn't a low-level language like C. You don't have to manage memory like that. PHP has some very smart internal logic and is perfectly capable of handling creating and destroying variables on your behalf. So let it do what it knows how to do.

if ($statu1 = "Online") { echo "<font color = green>$status1->nodeValue</font><br>"; } elseif ($statu1 = "Offline") { echo "<font color = red>$status1->nodeValue</font><br>"; } One = does an assignment, which means the above code actually works like $statu1 = "Online"; if ($statu1) { echo "<font color = green>$status1->nodeValue</font><br>"; So naturally, every status will be green. Two ==s does equality comparison. (Three ===s is if you want to be pedantic about what it means to be "equal".) if ($statu1 == "Online") { echo "<font color = green>$status1->nodeValue</font><br>"; } elseif ($statu1 == "Offline") { echo "<font color = red>$status1->nodeValue</font><br>"; } That aside, this is very outdated HTML 4-style markup. You should switch to <span>s and CSS.

Not having symbols is okay, it just means that gdb won't be able to fully translate the machine symbols it's reading into more useful, human-friendly symbols - like, parts of a backtrace will be cryptic. But it'll all still work fine.

I was following along until the "please do this for me" bit at the end. REGEXREPLACE + REGEXEXTRACT like that is silly. Not sure where you got it from, but a single REGEXEXTRACT is enough to extract all the <uppercase letter + stuff>s in the cell. Check the documentation/help docs for how to make it match everything instead of just once (which is what it does by default). For the regex part, it's currently doing <uppercase letter + lowercase letters> so naturally it will only work with lowercase letters and not with numbers or symbols. If you want to match things that look like <uppercase letter + stuff> then realize that "stuff" is a less precise way of saying "keep going until the next uppercase letter". Or in other words, "anything that isn't uppercase". Because computers need you to be precise if you want them to work a certain way. Excel's regex syntax for "anything that isn't ___" is the same as everybody else does it, so you can check either the docs (which I'm sure include a little bit of regular expression syntax) or virtually any other regex resource to find how to write that.

There was nothing "kind" about the volume of spam you just sent out. Please use the existing account tools to request a deletion of your account.

It worked for years even though it's clearly missing a comma at the end of the first line?

Did you run gdb the same way as you had before? Did you get the same output (before the bt step) as before, including the part where it says there was a segmentation fault?