requinix

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.

$stmt = $conn->prepare("INSERT INTO `admins` (username, email, phone, address, state, password, isadmin, create_datetime) VALUES (?, ?, ?, ?, ?, ?, 'Yes', ?)"); By the way, "Yes" is absolutely not the kind of value that should be in an isadmin column.

array_filter + str_contains

Did you install Try into that Dispatcher? Try looks like a module by itself - as in it's a separate install, and I assume it should end up in some Syntax\Keyword\ directory (and not part of your vendor\).

$password = md5(rand()); $verify_token = $_POST['password']; Isn't that backwards?

Is this all code from a single file? You aren't posting bits from one place and bits from another? Because there's a lot of confusing work going on with the $images variable - and honestly, I didn't look a whole lot further than that. Programming is like cooking, or mixing paint colors, or sticking your foot in your mouth: if something is going wrong, adding more on top of it isn't going to help. You need to stop, reset, and try again. So my advice is to take all the code you've written so far, move it to a scratch pad somewhere that you can look at for reference, and then start over from the beginning. Figure out what it is that you need to do with your code. Plan ahead. Experiment even, if that helps. I figure that you should end up with maybe 3-5 total lines of code in order to build your $images array. And let me be clear here: you're damn close to it. In fact I'm pretty sure that the correct answer is in that code you currently have. But the problem is there's a whole bunch of not-correct code mixed in as you were trying it out.

https://www.google.com/search?q=what+is+a+php+framework You build websites using code. A framework is a large amount of code whose job is to make sure you have to write less in order to do what you want. It does so by providing you easy ways to access a database, easy ways to build webpages, easy ways to support users and a login system, and so on so that you don't need to implement it yourself from the ground up. You can download Laravel by going to Laravel.com, clicking the "GET STARTED" button, and reading the documentation it links to until you reach the point where it says how to create your first Laravel project. (You should continue reading the documentation after that point too, of course.)

At first glance it seems fine - except for the fact that you're using backticks for some of your PHP strings, and they mean something completely different from regular ' and " quotes.