requinix

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.

First things first: you really shouldn't be letting anybody on your site screw around with your database. Because that's what you're doing now by putting $_POST values into your SQL like that. Stop doing that and switch to prepared statements.

I'll try to explain a little better about the approach I'm thinking of. It's recursive. You start looking at the outermost values - the "test" keys in your example - and you decide whether they should be included in the common array. Should they? Only if they're present in the other arrays. So you look at the other arrays. If they don't have a "test" then you already know the answer (no) and you can skip ahead to the next key. If so, you know that the key is present but you don't know if the corresponding value (the vehicle information) is the same; if it's partly the same, you just keep the common parts. Next you look at that array's values - the "make" and "vehicle_info" keys - and you decide whether they should be included in this inner common array. Should they? Only if they're present in the other "test" sub-arrays. So you look at the other sub-arrays. If they don't have the "make"/"vehicle_info"/whatever then you already know the answer (no) and you can skip ahead to the next sub-key. If so, you know that the key is present but you don't know if the corresponding value (the make, or vehicle info array) is the same; the make is a string so you can compare that, while if the vehicle info is partly the same, you just keep the common parts. See how that's working? The same overall approach applies to the "test" parts, as well as the "make" and "vehicle_info" parts, as well as the actual vehicle parts themselves, as well as the data about the vehicle parts. At each of those different "layers", when you have an array to compare, you need to delve into that array to see what may be common with the other usages. The main point to illustrate was the ability to stop early: if you're looking for some particular key, like the "make", then you naturally have to check the other arrays to see if they have it, but if they don't then you don't have to keep looking any further. And the technique for "stopping early" is that you (a) have this array of "common" parts you build up, as you confirm that each piece of data exists in the other arrays, and (b) at the end of whatever loop, you take that common array and add it to whatever the "parent" thing is (be that the big common array of data, or some sub-array of vehicles or parts or whatever), and you can use a continue as you're checking things to skip over that and immediately start checking the next key. However, Working through this now, I'm seeing that it's not as effective as I thought it might be, and that the code will be nicer if it took a slightly different approach: do the whole "stop early" thing, but instead of building up the common data, try tearing down the uncommon data. There's also not so much a need to continue; anymore - as in, do something to skip past some code and restart a loop - because there's no dangling code. Could break; though, but I opted for using if/else blocks instead to make it easier to follow. $vehicleGroups = [...]; $firstGroup = array_shift($vehicleGroups); $commonGroup = $firstGroup; foreach ($firstGroup as $id => $vehicle) { foreach ($vehicleGroups as $otherGroup) { // layer 1: the vehicle IDs // check if $id exists in all the other groups if (!isset($otherGroup[$id])) { // if not, tear down unset($commonGroup[$id]); } else { // if so, go deeper $otherVehicle = $otherGroup[$id]; // for convenience, to pair with $vehicle // layer 2: the make and vehicle_info // check if make exists and is in all the other groups if (isset($vehicle["make"])) { if (!isset($otherVehicle["make"])) { // if not, tear down unset($commonGroup[$id]["make"]); } else { // nothing to potentially go deeper into } } // same for vehicle_info if (isset($vehicle["vehicle_info"])) { if (!isset($otherVehicle["vehicle_info"])) { // if not, tear down unset($commonGroup[$id]["vehicle_info"]); } else { // layer 3: the vehicle_infos foreach ($vehicle["vehicle_info"] as $infoid => $info) { // check if $infoid exists in all the other groups if (!isset($otherVehicle["vehicle_info"][$infoid])) { // if not, tear down unset($commonGroup[$id]["vehicle_info"][$infoid]); } else { // if so, go deeper // layer 4: the bits of data in the vehicle_infos // I'm going to assume that "brake" is only one of many possible values // rather than handle each one like make/vehicle_info did individually, do another foreach foreach ($vehicle["vehicle_info"][$infoid] as $partid => $part) { // check if $partid exists in all the other groups if (!isset($otherVehicle["vehicle_info"][$infoid][$partid])) { // if not, tear down unset($commonGroup[$id]["vehicle_info"][$infoid][$partid]); } else { // nothing to potentially go deeper into...? } } } // don't keep the info if there was nothing in common if (!$commonGroup[$id]["vehicle_info"][$infoid]) { unset($commonGroup[$id]["vehicle_info"][$infoid]); } } } // don't keep vehicle_info if there was nothing in common if (!$commonGroup[$id]["vehicle_info"]) { unset($commonGroup[$id]["vehicle_info"]); } } // don't keep it if there was nothing in common if (!$commonGroup[$id]) { unset($commonGroup[$id]); } } } } print_r($commonGroup); Note the similarities in the different "layers", and how they all repeat the same idea more or less the same way: if the thing is not present then remove, otherwise check it in more detail. Is it better, or even shorter or simpler, than what you have? Not really. Could it be improved? Undoubtedly. But the point was to show the "you can stop early if you know it won't work" concept.

All you really need is some sort of "array_intersect_recursive", because the exact structure of the $products doesn't actually change how you compare the different parts of it to others, but unfortunately PHP doesn't have that built-in and implementing it yourself is a bit complicated. A quick improvement is that you can array_shift($products) to remove the first one from the array and return it back to you. Means you don't need to skip $index 0 anymore. A more complicated improvement would be to adjust your approach: rather than count how many times something appears before adding it, it would save some processing time if you immediately bailed out when you discovered that something did not appear. As in: $commonArray = []; $first = array_shift($products); foreach ($first as $key => $vehicle) { $commonVehicle = []; // check if $key exists in all the other $products // if not, use continue (likely a continue 2; or continue 3;) to skip ahead of this loop here and go to the next $key // if so, build up the contents of $commonVehicle... if ($commonVehicle) { // only add this $key if there is something to add $commonArray[$key] = $vehicle; } } And like I said, while the keys of $products changes as you dig into it, you're repeating the same "check if <key> exists in other <arrays>" all the way down, so you'd basically just repeat the above code a couple more times with different variable names.

That's the initial call from your site to PayPal to begin the transaction. What's missing is the second one from PayPal to your site after the transaction has completed. Do you see anything in your access logs for the URL https://websitename.com/aj/wallet/get_paid and that also includes a token=?

There ya go: this installer needs to be run over HTTPS. It looks like you don't have your site set up for that yet? You really, really ought to do so. There's no excuse for running insecure sites anymore.

Database information really shouldn't be stored in a cookie... Keep that developer console open and try going through the installation. Do you see the cookie ever show up? Are there errors in the Console that might suggest problems trying to set a cookie?

It's not a notification. I'm talking about a record in your [whatever the value of that T_VIDEOS_TRSNS constant is] table. I can't tell for sure but it sounds like the code that handles the callback from PayPal, which I believe is the code starting from if ($first == 'get_paid') { Do you have access to server access logs? They would tell you what URLs are being hit on your site - to confirm that this "get_paid" URL (maybe /get_paid/???) is being hit by PayPal, and likely also whether it returned a successful 200 or something else like a 3xx redirect or a 500 error.

There's no logging of errors in here so it's going to be hard to know why something isn't working... They should have been able to confirm that your side was correctly checking the results after they call your site back, so if that's working then I assume the issue is going to be after. Can you at least see that a transaction has been recorded?

It appears a missing cookie is the problem? You should be able to check this easily yourself by looking in the browser to see if the cookie is there. But database information isn't something that should be in a cookie, so I wouldn't expect cookie problems to result in that error - more likely, they'd result in forgetting you were logged in or what step of an installation wizard you were on.

That would be a very typical approach: you have your own identifiers, they have their own identifiers, and in order to associate them you have to store theirs alongside yours.