requinix

Big disagree. Having to throw a cronjob to clean up temporary assets is a sign of problems. You're creating more moving parts this way, and yet you turned down multipart because it "adds complexities"? But the worst part is that you're creating two completely opposite flows for two similar situations. Whether an entity has one file or more than one file should not result in this much of a difference. Entity first, file(s) second. No temporary crap, no cronjobs, no inconsistencies.

1. $_POST data can't be trusted, not just inside of SQL queries but also inside of $_SESSION. 2. You are not using remotely acceptable password practices. Learn about password hashing using and password_hash() and password_verify().

Oh dear. Are you perhaps brand new to web development?

A valid approach. Base-64 increases the size of the request body but that doesn't make it bad. It is totally possible to do both. After all, haven't you ever used a web form that had you upload a file and submit other data at the same time?

What have you been able to come up with so far, and what happened/didn't happen when you tried it?

Read the documentation. The answer is there. If you looked once, look again. Also in the documentation. Find the section that talks about user-defined functions. This is the same question as 1 and 2. list() has documentation. And my code is doing the same thing. Read the documentation for list() to know what the first line does. Read the documentation for arrays to know what the second line does. Frankly, I find it hard to believe you have these kinds of questions after more than 600 posts on this forum. They are very basic features of PHP, and even if you don't recognize some of them, you should know how to find out what they are without having someone tell you to read the documentation 5 times. And I suspect that after you do learn about how my code works, you'll also have found your answers to how your code worked.

Do you really want an explanation? Or are you just trying to figure out why it's not working the way you want? Because if you just want to make this work, there is a much easier way of doing the whole thing: use preg_replace_callback() to run your own code every time it finds a match. Also means you don't need the replacement array since you're just replacing the word with a suitable number of asterisks, and str_repeat() can create them easily enough.

That {VRL_CALENDAR} thing looks like it's part of some templating language. You're either going to have to work with that, or find out what that thing does and make it happen yourself directly. For example, if that thing results in calling a function, you would just call that function yourself instead. Keep in mind that you're asking questions about something nobody here knows anything about. Don't know your website, don't know your application, don't know your framework, don't know the calendar... You are going to have to do research and work here.

Oh, yeah, you're right, I read it backwards. If you can make a PHP page that shows the calendar then you can put the URL to that page inside an iframe. Not really sure what the difficulty is here.

I don't know why you did that either. It doesn't accomplish anything. $tempArray and $matchesArray don't do anything, the code using them doesn't do anything, and all of that is pointless. Maybe it was leftover debugging code?

Is it just me or did you add more code and then try to understand what that code does? Your question seems to be about what's happening with the foreach loop, but that loop does absolutely nothing useful. It doesn't need to be there at all. The only parts that matter here are (1) the pattern and replacement arrays and (2) the preg_replace().

Could create a second BBCode tag that turns [attach] into [sharedmedia], so both tags would be supported. Actually I rather suggest that in case there's something still using or generating [sharedmedia]s - wouldn't want to break those. Would also mean not having to deal with the database. If you have a more specific question, like what code you have to write or regular expression to create, then you should probably ask that.

If it's made to show inside an iframe then that probably means it comes as a complete HTML webpage and not simply some embeddable markup. Maybe there's some sort of configuration somewhere to enable the behavior you want? Because if not then that would mean you'd have to start making changes to it yourself. Is there a problem with using iframes?

Really not sure what's going on. I'm inclined to think there's something going on with your browser, like it's remembering something inconsistently (I don't see any recent logins with your account so you've been logged in the whole time), but it could be possible there's some odd bug with IP.Board regarding... something.

If you're already detecting application/json then it wouldn't be much more to handle urlencoded... Do you need to support []s in other forms in the immediate future? If not then I'd probably go for maxxd's direct approach, even if it's just for this specific form.

Learning? That's fine. But there's one really important thing about programming that lots of newbies don't always get around to learning, and it's really, really important that they understand it sooner rather than later. Indentation. This if(isset($_POST['new']) && $_POST['new']==1){ $pickups = ''; foreach($_POST['pickups'] as $cnt => $pickups) $pickups .= ',' .$pickups; $locations = count($_POST["pickups"]); makes it look like (1) the if statement isn't doing anything and (2) the $locations line is inside the same foreach loop that the $pickups line is. Every { means the next line indents further in by one, every } means the next line indents back out by one. Plus a couple other rules, like how when you don't use braces { } with control structure (like foreach) then the single line after it gets indented - or better yet, always use braces { }. The above code should look more like if(isset($_POST['new']) && $_POST['new']==1){ $pickups = ''; foreach($_POST['pickups'] as $cnt => $pickups) $pickups .= ',' .$pickups; $locations = count($_POST["pickups"]); That properly shows where each line is relative to the if (all of them are included and thus only run when new=1) and to the foreach (it only affects the $pickups line and not the $locations line). Take a moment to learn some more about indentation, then go back to the code you first posted - definitely the PHP but the HTML could benefit from proper indentation as well (<tag> indents in, </tag> indents out) - and then post the revised version. It still won't work correctly, because PHP is a reasonable language and doesn't do stupid things like care about how many spaces or tabs you used to indent your code, but it will be much easier to scan through. Plus it will help to point out exactly what other code is part of that one problematic for loop that is now the subject of conversation.

Well yeah: you put the code to insert inside the for loop that goes over each location.

I have no idea. It's your website, not mine.

Whatever ecommerce thing you're using for that shop has to have its configuration updated so that it knows about the new URL. You're also going to discover that you need another RewriteRule flag. When that happens, check the mod_rewrite documentation for a flag dealing with query strings.

And you're saying that it's specifically a reCAPTCHA problem, right? According to the code, $url = "https://www.google.com/recaptcha/api/siteverify secret =$secretKey&response=$responseKey&remoteip=$UserIP"; the URL you're trying to retrieve is https://www.google.com/recaptcha/api/siteverify%0D%20%20%20%20secret%20=(key)&response=(value)&remoteip=(ip) Does that look like a good URL to you? Those %s represent the line break (because your $url string spans multiple lines) and spaces (because there are spaces in the string) and really, really need to not be there. With that out of the way, 1. You've posted your secret key on a public website. You can safely assume that it has now been compromised. Deactivate that key immediately and get a new one. 2. Screenshots of code are nice but posting the actual code is better. Because I had to type out that $url thing earlier. Please don't make me do that again. When you're writing a post, use the Code <> button and its popup to insert the code into your post.

I don't know what solution you found "at the moment", but a while ago I told you that you have to update the URLs you put onto your site to use the new forms, and that it will not happen automatically for you. For example, that means you have to replace every <a href="/index_pl.php?src=home"> with <a href="/home">

Any particular reason you have to be sending JSON from this form? REST commonly uses JSON nowadays, sure, but that doesn't mean you can't also accept requests in other formats as long as the data decodes into the correct schema. In an ideal web framework, the Content-Type of the input is not restricted. It can be whatever as long as the framework knows how to interpret it. That's why abstracting out $_POST is nice: PHP only handles a couple types, but a framework could read the Content-Type and decode the input appropriately.

That was too easy... To make sure we're on the same page, I'm talking about replacing those 10 $postals with a single array containing up to 10 items. Note the "up to". You only store the good values in there, meaning the whole "I have to check if they're empty" doesn't need to happen (at least not once the values are in there). It also means you could store more than 10 if you wanted. Like (up to) 15. Or maybe you decide you have too many and want to lower it to having (up to) 5. Or whatever. And the code using the array wouldn't have to change.

If your code has and $$s in it then it is doing something terribly wrong. Use an array for the postal codes like a normal person.

Don't make a random number. Use a real number. Even better, don't restrict yourself to a literal number but allow it to be a string. You can do a lot more with a string, such as create an order "number" built from the customer ID and date. But if you want advice that's actually good then you'll have to describe your system and the nature of these order numbers.