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 }

(foreach isn't a function) It'd be easier to show if you posted the rest of the code instead of just a couple lines, but basically, replace the while loop with a foreach loop, and then add into it a little logic for $errMess. If that still doesn't make sense, post what you came up with (as well as the original code) so we can see what happened and not have to guess about it.

You commented out the SetEnv?

That was a great, detailed answer that gave me a lot more information to work with than what you first posted. Knowing what you're doing with the session, more than just "start a session and set session variables for different things", tells me about the sorts of practices you might be following, how they might work and might not work, and gives me a good foundation I can use to ask you questions that will make more sense. Knowing that you're trying to understand the developer tools but still aren't quite able to work with them, more than just "How x 3", means I feel more invested in helping you to learn. Like I said before, those tools are invaluable when it comes to a lot of web development work, and there's a high likelihood that those tools will be able to explain what's going wrong. But knowing that you've tried this with Firefox and that it doesn't work no matter what is the best part. Web browsers don't just randomly decide how they will work. If Firefox doesn't work but Chrome might, that strongly suggests something is wrong with what you're doing - and I mean that in a very general sense of "you are doing a thing and there's a problem with it", as opposed to "you are doing a thing and Chrome isn't working correctly". 1. If you haven't done it yet, the first thing to check is the console in the developer tools. I believe F12 on any browser will pull them up. It should give you some sort of collection of tools or tabs, and one them should be clearly marked as Console. Have the tools open as you log into the admin (like in Firefox). Do you see any errors or warnings? 2. There's also a Network tab. If there's no messages then (that's surprising, but) you'll have to look a little closer at what's happening. Provided the tools were open when you logged in, the tab should show a request to your login page or AJAX endpoint or whatever. That's where cookies may have changed. Open up the information for the request and check the Response headers. What does it say for a Set-Cookie? 3. It might not have anything. That's fine. Now check the Storage tab and look for your site's cookies. One of them will be the session cookie, probably named like PHPSESSID. What are the settings for it? (Specifically, the path.) Also, what are the URLs for your login and admin pages? (Specifically, the path portion.)

If you're asking, does that mean you tried what I said and couldn't find an answer and decided to not mention that? Or does it mean you saw my answer and decided you didn't like it and wanted something else instead?

Use your browser's developer tools. If you're not sure how, spend some time getting familiar with them because they're invaluable for web development.

PHP doesn't care what browser or operating system you're using to view pages. Your problem is going to be either (a) settings in the Ubuntu browser that prevents it from accepting the session cookie, or (b) a problem with the session cookie where the Windows browser is accepting it incorrectly but the Ubuntu browser is rejecting it correctly. Actually there's a third possibility: a difference between how you're using the two browsers that is important but you don't know about and/or aren't mentioning. Such as a different hostname, source IP address that somehow matters, some sort of Windows authentication mechanism... 1. Check the network responses and confirm you're receiving a Set-Cookie on at least the first visit 2. Check that the cookie is being remembered by the browser/not being rejected for some error that should have been logged somewhere/isn't immediately expiring/something else 3. Check that the cookie is being sent in additional page requests 99% of the time the problem will show up in one of those three steps.

Did you press the Logs button to view error logs? Or check the Windows Event Viewer for more clues?

I don't remember if Intelephense provided the feature or not. In fact I might not even have tried it with PHP - maybe it was another language. But I assume the concept works the same way everywhere. But yeah, the hover or autocomplete list has always been sufficient for me. Oh well, whatever works best for each person.

It might work a little more cleanly in PHPStorm, but when I tried it in VS Code, I found it much more complicated to try to select text or read through code when the editor was injecting those things into the view. Maybe if they weren't inline, though I can't imagine how not, they might be nicer for me... But I'm also a proponent of the idea that you should be able to tell what the parameter is, be that through a variable name or an obvious literal value (or a constant...), and if you can't tell then you should do something about that. // this is obvious on what the parameters are password_verify($password, $hashedPassword) // this is not password_verify($value, $row[1])

That said, how the heck do you know what "6" means? Use column names instead.