requinix

I get that you're saving yourself some effort, but when you tell people "I asked a question somewhere else, go see what it was and try to answer" it's typically going to be taken as an insult. But I'll answer anyway because it doesn't look very good. According to what I'm seeing in the Docker Hub page, there is no simple upgrade path once the PHP version is no longer supported. Normal Docker practices would allow it, but this image isn't set up to follow normal Docker practices. So you'll have to go into the container itself and update it manually - like if it was an actual computer running Alpine Linux and you needed to upgrade it. You can look around for instructions on how to do that. Which means you should reconsider how this all works. For example, you could convert your existing installation to the "Static image" one that's described in the docs... though you'll have to reverse-engineer some of that process in order to preserve the details of your existing setup. But once that process is done and you've converted to a static deployment, future upgrades seem like they would be as simple as updating image versions in your docker-compose. (And you would then do all updates that way - not from within WP itself.)

Not sure I follow. You have code there that goes through every single keyword in the array, which is known as "$keywords" inside that function and not "$spam_keywords" as it's called outside the function, testing to see if it matches, and then returning true if it does. All you need to change here is to make it return the keyword that matched instead of true.

Right now, you have the function returning just true/false depending whether it found a match. Perhaps it would be more useful if, instead of returning true for a match, it returned the actual keyword that matched?

yq probably won't work since the lines are commented out, which more or less leaves you with the standard find-and-replace tactics using sed. Like sed -i '/#cluster.name: MyCluster/s/#//g' filename.yaml

I have unhidden PHP5000's post. Unfortunately he chose to also send me a PM containing some rather rude language, which is why I am now speaking about him in the third-person. He's welcome to try again next month, though.

I've hidden your, let's say, unconstructive post. Since I'm an actual developer who wants to see other people learn and grow so they can become actual developers, I don't tell people something that they can copy and paste into their code. I give them information and hope that they're willing to put in the time and effort into understanding what it is they're doing. So thank you for your feedback but I'm going to continue calling out instances of people writing 1990s-era Javascript without understanding what they're doing and why it isn't working. After all, there's a very simple and fundamental principle in play right here: if you're going to work with something, the least you can do is try to learn more about it. If you want something to tell you the answer so that you can copy and paste it into your code then you already know about ChatGPT, but did you also know you can do things like throw terms like "javascript onclick modern way" into Google and it'll spit out some AI nonsense of its own that is actually occasionally useful? I tend to assume people will invest time into a thread so I tend to avoid writing long knowledge-dump replies - because it's too much information at once, and also becomes sometimes it turns out to be a waste of my time - but had this thread continued, maybe it could have gone like this: Q: Okay, so I understand that onclick is just executing code, but what do you mean it isn't returning a value? The return statement is right there. A: Yes, the return statement for ConfirmDelete, but there's no return statement for the onclick itself. Like I said, it is basically a function even though it's written as an attribute in the HTML, and it's that function that needs to return true/false. Q: So is that the modern way? Returning from the onclick? A: No, the modern way is to not use any of those on* attributes and instead attach events through Javascript. As in, when the page loads you run a bit of Javascript that attaches events to whatever elements it needs to using addEventListener. Q: I read up on addEventListener and switched to using it, but now when I click the button, I get the confirmation and it still submits the form. [Insert code here.] A: That's because event handlers done through addEventListener work a little differently. You can't just return false to stop the event - the code needs to be a little more sophisticated in that it explicitly says "stop the event"... except you don't actually need that. There's another way that (IMO) is simpler to work with. Q: What's the other way? A: Instead of making the button be a submit button, make it be a regular button. And instead of making the event handler stop the form from submitting, it directly makes the form submit. Meaning instead of "if not confirmed then stop" it's now "if confirmed then submit". Which probably makes more sense from a human-being angle: you typically think about these things in a proactive way like "if I click the button then I want to get a popup asking me if I'm sure I want to submit the form" (which the new code would say) and not the reactive way of "if I click the button then submit the form, but only first after asking the user if they want to" (which the old code says). It's a subtle distinction, and admittedly not one that's relevant all the time. Q: I don't follow. What would I do differently? A: Change the button to a regular "button"-type button, keep with the addEventListener, but change your popup thing to be "if (confirmed) { submit form }". [Insert code here.] Q: That sounds complicated. Why should I do all this when I could have just stayed with onclick and returning true/false? A: Because if you ever want something fancier than the confirmation popup you have now, the onclick+return pattern simply won't work. You can only do that when the code can make an immediate determination of whether or not to continue with submitting the form. If the confirmation was any sort of Web 2.0-style modal then it couldn't return immediately and you'd be forced into this alternate scheme. You might as well get used to the pattern now so it'll be easier to remember when you need it. Besides, it's not like it's a huge amount of work, and the additional work compared to onclick+return isn't wasted because you're improving the quality of the code as you go. And quality of code directly translates into quality of life.

It makes no sense whatsoever to use Javascript in a place where a plain <a> link will work just fine. HTML first, CSS second, Javascript last.

lol. Glad to see that Powershell had nothing to do with your question, though.

What's asking for a directory? Why? What does Powershell have to do with anything?

The "expert sex change" website still exists? Wow. That's amazing. The way for this (dated) design to work is that onclick has to return true/false. Right now, all it does is execute a function. Yes, that function returns true/false itself, but nothing happens with that value. It's just like writing function onclick() { ConfirmDelete(); } You should try to do Javascript the modern way, which is "modern" for very good reasons, but if you won't then you fix this problem by making the onclick code "return" a value.

"White and orange" kinda sounds like Xdebug's output.

Their tech support is exactly the place to ask. Because this is going to be an issue related to server configuration, which we can't see - but they can. A new host will have two major differences: different file paths (potentially) and different PHP settings. One of those is almost guaranteed to be the explanation.

You put that code in the place where you want to use the library... That is, after all, the reason you have this, right? To make use of it in your own code?

Where is the printer? Is it connected to the client or to the server? If it's connected to the client then the only thing you can do is present a print dialog. The user will have to choose the printer (potentially) and hit the button to print. If it's connected to the server then you can use a library to have PHP print the page. The details of that depend on what you're printing...

The simple answer is probably also obvious: if you don't want to show the form under certain conditions (like after the form was submitted successfully) then don't show the form under those conditions. There's a bunch of different ways to go about it, but the one thing they all have in common is that there's an if statement that checks whether or not you want to show the form, and if you do then it shows the form. For example, if (/* show the form */) { ?> (the form) <?php }