requinix

It doesn't matter to PHP. It does matter to HTML and your browser. Because you told it that the button should be connected to some form named "form". The real problem is that you were specifying a form attribute at all. 99% of the time you should not: just make sure the button is contained within the <form> and you're set. The only purpose of the form attribute is to associate the button (or other input element) with a <form> that's somewhere else on the page.

Works for me, provided that I'm not using Firefox and that I think the desired behavior is to change the background color of the SVG to red. If you're trying to change the background color of the .inside-svg element then you've vastly over-thought this...

It does automatically work. It just doesn't automatically work the specific way you want it to. kicken said to use session_set_cookie_params. Have you done that yet?

Last time you asked about this, on our Discord as well as StackOverflow, and I believe you made a thread too, people pointed you to the API documentation. I'm reading through it right now and I don't see anything that says you cannot use custom prices for subscriptions. I do see really obvious ways to specify (1) that the checkout session is for a subscription, and (2) what price you want on each item. Have you even tried creating a (test) subscription with a custom price yet? Or are you just assuming that it's not possible?

So you want to allow both (a) "TMP" plus 1-5 numbers, and (b) 1-5 numbers then "M"? 1. You need ^ and $ anchors, otherwise the regex will only check if the string contains something that matches it. 2. {5} means exactly 5, but you've been saying "up to". 3. What about zeroes? That's not in the regex now but I'd be surprised if you didn't want to allow them. 4. To allow both patterns, tell the regex that you want to allow both patterns using a | /^(\d{1,5}M|TMP\d{1,5})$/

"Tag" is still fine. It's not like that term has died off or anything. And it applies to all... well, to all tags... not just certain ones. "META tag", "HTML tag", "NAV tag", whatever. "Element" is the other one in common usage. Means the same thing. Probably a bit more proper. Maybe the word you're looking for is "semantic"? Because the idea of those new tags/elements is that they have a semantic meaning: while DIV is just whatever, HEADER is specifically for "a header", and NAV is specifically for navigation, and such. Makes it easier for automated processes (like search engines) to analyze a page.

Yes. it's possible to do this. But you need to change how you do events. Using inline on* events is old and makes solving your current problem a little harder. Your first step is to modify how your hover comments work to use modern Javascript practices with event listeners. Your HTML for the button will be as simple as <but1 type='button' id='1' class='btn btn-warning hover-comment' value='Savin'>1</button> That removes the onmouseover, onmouseout, and onclick handlers, and instead added a class name of "hover-comment". Your new Javascript code will add an event listener using that "hover-comment" (or whatever you want to call it) - how you do so depends and I can't tell just from what you've posted. Once you have the modified HTML and the comment hover functionality improved, it will be much easier to do the "store the comments in the buttons" that you want.

Does the uploads/ directory exist? And does it exist at (I think:) /paypal/uploads?

I searched for "woocommerce_email_order_meta" and found this post which seemed helpful. In other words, search your application for anything that's hooking into woocommerce_email_order_meta and you should find (a) some place which renders the email's content and/or (b) some place that lists what fields to include in the (default?) template. You'd modify the former to include the order notes however you see fit, and for the latter you'd add the notes to the list of "fields" it returns.

Yeah, I think the post+user+display name table is the answer as well. A less traditional answer would be to go pseudo-NoSQL and store a JSON blob of user ID/display name mappings in the post; it comes with minor upsides and minor downsides, and probably isn't worth it. There are still some holes in here to potentially address, though. Like, if anonymized names are optional then there are two input spaces of (actual usernames) and (generated display names) and any overlap between them could be a problem. But they don't really affect database structure, I don't think.

It's like asking how to improve your skills with a pipe wrench: you can either use it when it's appropriate to do so and recognize that probably won't happen very often, or you can come up with reasons to use it that weren't going to happen naturally. How about lurking #regex on StackOverflow? You don't have to post replies yourself if you don't want to - just use them as exercises. (And do keep an eye on the answers too, as that's part of the learning process.) Plus, I imagine that'll also help teach you when regular expressions aren't the answer to a problem...

You don't have to make the primary key of an intermediate table be a composite of the foreign keys. It can be an auto-increment ID just like every other table. I don't get why people keep saying this... Databases are designed to handle large tables like that. It's what they do best. It's basically their whole reason for existence. All you need to do is put proper indexes on the right columns, or combination of columns, and the database server will handle the rest. Missing some answers to make that decision myself. Such as: Where are these usernames coming from? Are people choosing them themselves? What's to stop them from picking the same name in multiple places? Do you want to approach this feature as allowing users to pick names (optional anonymity) or requiring them to pick names (enforced anonymity)? Also, how do you handle uniqueness across the site? If I pick "BigFish" in one thread, can I use it again in another thread? Can somebody else use that name in another thread? Can I enter something which is my actual username? Can I center something which is someone else's username? In precisely what domain of inputs are names unique? Those questions are far more interesting to me than determining what database structures to use. Why? Because database design is mostly a solved problem: given a particular scenario, the requisite design is already known to the industry, and there's not really a whole lot of variability necessary beyond that.

Not a whole lot here to work from so it'll be hard to provide more than just an educated guess... I take it when you say "refund" you mean as an alternative to "complete"ing the raffle? You're cancelling the entire raffle and refunding the tickets, not just refunding a single ticket? I suggest picking a different verb that more accurately reflects that the raffle is not active anymore - such as "cancel". The pieces you need are: 1. Getting all the tickets in the raffle 2. Refunding all of them 3. Closing out the raffle #1 is apparently in $raffle->tickets. I don't know exactly what that is but I'm confident you can use it to identify all the tickets. You'll likely want a foreach loop. #2 is going to be something in the AccountService. Possibly createTransaction as well. Inside your loop, you create a new AccountService for every ticket's account (since it depends on the account) and then calling whatever method you need according to the price of the ticket. #3 is likely going to be a copy of the second half of your complete() except (1) using a different Raffle::STATUS, and (2) maybe or maybe not "replicate"ing the raffle, and (3) firing an event that may or may not be RaffleCompleted but should obviously be somehow different than a regular "raffle completed" event. Side note: in this new method as well as your complete() you should make sure that the raffle is still active before continuing - wouldn't want to accidentally refund the same raffle multiple times, or one that's been completed and paid out, right? Similarly for buy() that your code shouldn't allow buying a ticket for something that isn't running anymore.

What does var_dump($row['sku']) output?

I assume that's supposed to be Javascript code? Describe what it is you need to do, in detail, then post the full code you've written so far and explain what sort of problem you're having with it.

Still not following, and I can't go through your site at the moment, but: It typically doesn't make sense to put values into both the session and cookies. One of them is enough: put the values in the session if you want to remember it for the user account (kinda), or put the values in cookies if you want to remember it for the device they're browsing with. And if you choose to use cookies only, you don't even need AJAX - you can create cookies perfectly fine with Javascript. So, then, I guess, general troubleshooting: Can you see that the AJAX request is being POSTed correctly with the right data? Does your browser show the cookies updating values, or at the very least expiration times?

If you're using 16 connections and you have 2 connections per user then that means you have at least 8 users. At least if I'm doing the math correctly.

What do you mean, "save a button"?

"User" means $this->dbuser, not the people browsing your site. Your dbuser is allowed to have 16 connections at once, which means 16 PHP scripts running at once. Apparently you're exceeding that. Talk to your hosting provider about increasing your limits.

Given that the website is about a company whose work is based on physical presence, namely "interior renovation" and "bespoke carpentry", concentrate your efforts on knowing whether the site is fast enough for potential customers in the area. In other words, it doesn't really matter much to me on the US west coast that your site takes 1-2 seconds to load a page because I'm not going to be requesting your services. I do see a number of assets loaded - Javascript and CSS and such - and each one takes a noticeable fraction of a second to load, however they load in parallel so that doesn't add much time to the overall page load. And they do appear to be properly cached so they'll only need to get loaded one time. That said, you could look into a CDN. Especially for common things like jQuery, where all you have to do is point to one of the free CDNs instead of having it load from your own servers. Beyond that, the first question to answer for yourself is how much money you want to spend on improving performance; for example, doing things like hosting your site in multiple geographic zones will speed up international and overseas traffic, but it isn't necessarily cheap to do.

Thanks for admitting you're phpsane because I couldn't prove it. If you remember why you were blocked then you should be able to avoid repeating those circumstances. Walk carefully because you're on very thin ice.

Keep in mind that the URL you give people to embed in a site will be visible to every single person on the internet who cares... Basically, you make a form like normal, but you take a parameter from the URL to identify which user to associate the form with, and you pass that parameter along when submitting the data. So it looks something like Embed this in your website! <iframe src="https://www.example.com/path/to/embeddable/form.php?user=123456789" other attributes...></iframe> Your form.php takes the user value, validates it's good, and if so copies it into the form, either as a URL parameter <form action="/path/to/submission/script.php?user=<?= $userId ?>" method="post"> or as a hidden input <input type="hidden" name="user" value="<?= $userId ?>"> When the user submits the form, you have the data as well as the owning ID. Disclaimer: that's all quick and easy but in exchange it's rife with opportunities for abuse...

Is the <select> inside a <form>? Has that form been submitted? Because that's the only way PHP will be able to do this. If you want the text to appear when you change the option without submitting a form, you need Javascript...

There's no need to tag people: if they have something to contribute to your thread and want to do so, they will.

Don't close the connection. PHP will do it for you. Besides, what if you close the connection and then decide you want to do something else with it... And take another look at what you're doing with $create_datetime. And please, please, stop storing passwords unhashed.