requinix

Are we talking "make an election" like CIA? I could help you with that... but then I'd have to shoot you.

Is this another "someone else did some work for me earlier and I don't understand what they did so please do the work for me this time too" question? This $loggedin = $_SESSION['member_id'] ?? 0; plus this if ($loggedin) { both look very much like they qualify as "activated only when logged in as a user or admin". Have you tried applying that to "the link" (I don't know what link you're talking about) so that it only appears when the person is logged in?

I'm confident that the less complicated one is the better solution. In terms of code, all you need is something that can tell what option the user selected, and something that can do what it needs to do to give the user the PDF they requested. Try writing the code yourself. If you have problems getting it to work then post what you have with a description of what you're trying to do and what problem(s) you're having with it.

I hear a lot of "Barand did this" and "Barand did that". Do you actually know what he did? Because if you don't then that's a problem and you need to start learning... If you can read the code then the first thing you can do is find out/remember whether it's using mail() or a library. Which is it?

One of those options is significantly less complicated than the other, and the outcome is the same.

If the tutorial is telling you to do something you don't want to do then why are you using the tutorial? Tutorials are not documentation. Try reading the documentation.

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.