requinix

Which makes sense given the nature of this.

First thing that I see is the "httpResponseCode: -11". Why is that happening? Because there's no way the script returned -11.

Now you've reverted your change and gone back to the original version, so yes my answer is the same.

You made the two samples even more similar to each other. If my answer before was "they're basically the same" then that will be even more true now.

They will both submit to the same location: the current URL. The only meaningful difference between them is that the first fills in a provided username while the second does not. I would recommend the one that behaves the way you want it to behave.

Don't. It is not a "waste" to let your script continue executing. Trying to kill it early is the wrong answer. The only normal reason anyone should ever exit/die in a script is because they're redirecting with header(). No. They both get the same result so it doesn't matter. Perhaps the author didn't know you can have the action empty.

You aren't using mysqli_stmt_store_result so you don't need mysqli_stmt_free_result. Most of the time PHP scripts run quickly, and since PHP will clean up resources for you automatically at the end you often don't need to worry about cleaning them up yourself.

Okay. Does your markup validate now?

Validate your markup. There are a few places where you're missing closing tags, like with the edit and delete forms, and that can throw off the rest of the document.

Like I said earlier, I doubted this was the source of your problem. But regardless it needed to be fixed. Use your browser's network monitor to see the request that gets sent when you try to submit the form. You should be able to see the data submitted with it. First make sure that everything you see there is correct: the fields are named properly, there aren't duplicates with the same name, that sort of stuff. Then check whether the checkbox data is in there: if so then your PHP is the problem, if not then something in your markup or Javascript is the problem. This would be easier to understand if I could see it happening for myself. Is the form online somewhere we can see? If not, can you create an HTML file that demonstrates the problem in a way that we could copy/paste the code to try on our own?

Remember what I said about using absolute URLs? That's true not just for Javascript and CSS includes but any time you need to reference some thing on your site.

var formURL='processing/factuur_mail.php';

<!-- jQuery --> <script src="vendor/jquery/jquery.min.js"></script> <!-- Toggele http://www.bootstraptoggle.com --> <script src="vendor/bootstrap-toggle/bootstrap-toggle.min.js"></script> <!-- Toggele CSS --> <link href="vendor/bootstrap-toggle/bootstrap-toggle.min.css" rel="stylesheet"> When using URLs to files and paths on your own site, always use absolute URLs. They start with a slash and the path is according to the root of the site. So "vendor" is bad and should be "/vendor" instead, and "../vendor" (from your modals directory) is bad and should be "/vendor" as well. I'm skeptical that fixing this will also fix your problem.

GDPR article 15 allows EU citizens to request an export of the personal data collected by this site ("right of access"). GDPR article 17 allows EU citizens to request that personal information collected by this site by removed ("right to be forgotten"). To request either action, post a new thread in this forum. Pursuant to article 3 we are not required to perform these actions for individuals we can reasonably assert to not be EU citizens in an EU country during the time of the data collection. Pursuant to articles 2 and 17 we also will not delete posted content - we are only required to remove personally identifiable information, and we have the means to accomplish that while keeping user submitted content (which is not covered by GDPR). This is in line with our long-standing policy of not deleting content. How official is this? I speak on behalf of the volunteers running this forum. PHP Freaks and related IP is legally owned by an entity based in Florida and I cannot speak for it. Everything written here is to the best of my knowledge and intentions. What data does this site collect? Username and display name (required during registration) Email address (required during registration) IP address (collected automatically) Timezone (optionally provided by the user and/or determined automatically) Profile information such as gender, age, and instant messaging accounts (optionally provided by the user) Does this site use cookies? Of course it does. IP.Board's standard cookie disclaimer What third parties is content and/or information shared with? PHP Freaks does not share anything with any third-parties. We do include advertising on this site (currently via Google Ads) and Google Analytics, but that does not involve sending them any information about the visitor. They do collect information on their own, of course, but we are not responsible for it nor can we address any GDPR requests on their behalf. What is our privacy policy? Good question. As this forum is run by volunteers who do not also own it, it is difficult to come up with an official Privacy Policy. We do have Terms of Service that you agree to by using this site, which is currently the closest thing we have to a privacy policy. Informally: we do not sell, give, share, etc. content or information to anyone. However, remember that content you post publicly is accessible to anyone who wants to harvest it, be they human or automated. Especially, remember that sites such as archive.org can and will archive publicly-viewable content. As a citizen of the UK, how does Brexit affect my rights? GDPR covers data collected from EU residents while members of the EU. The UK officially left the EU at midnight February 1st, 2020 (the "cutoff"). Data collected before the cutoff is subject to GDPR and will still be removed when requested. Data collected on or after the cutoff is not subject to GDPR. In the case of an account that was created before the cutoff requesting data to be removed, it is up to the site administrators' discretion whether data collected after the cutoff (if any) will also be removed; accounts created after the cutoff will be treated the same way as non-EU accounts. Note that users are able to edit or remove all personal information that was entered into their accounts, including changing the email to a "one-time" or throwaway address, however posted content is subject to constraints that may prevent editing later. What if I do not/have not lived in the EU? PHP Freaks will respect laws similar to GDPR, but beyond that any requests to export data, delete accounts, remove personal information from content, etc. may or may not be performed at our discretion.

Like much of the stupidness that is WordPress, there's one function to output something and another function to get the value. Which one do you think you have there? Can you find the one you want?

This forum is for the posting of job or contract opportunities - not for discussing the job. Replies will be moderated and very likely ignored by staff. Due to technical limitations, replies are allowed in case of situations where the original post does not include enough information, such as a means of contacting the poster or the company they represent, however this will be handled on a case-by-case basis. Staff will not monitor this forum for threads missing important information or for posts asking follow-up questions; use the reporting system if you feel such action is necessary. Abusing these privileges may get you a warning and/or ban.

According to the documentation, file_data is not simply the raw contents of the file. Take a look. Do you know what you need to do to fix that? It could be MailChimp is trying to un-

That would have to do with code that you haven't posted.

The right way to get the contents of a file is with file_get_contents(). Dealing with a file handle and manually reading from the file is a chore. And swapping out the fopen/fread/fclose with file_get_contents will not affect anything with the API call. The error says that the request body was null. That would mean json_encode() returned "null", which means $fileInfo was null. Probably. What's the full code, uninterrupted, between defining $fileInfo and the cURL stuff?

Look at the structure: Array ( [0] => Array ( [prices] => Array ( $prices is an array (first line) which contains a [0] key (second line) which is itself an array that contains a [prices] key (third line). foreach ($prices[0]["prices"] as $price) {Each $price looks the same as the first one, which is [0] => Array ( [price] => 4.99 ) an array that contains a [price] key. echo "<li>" . $price["price"] . "</li>";

You did define $fileInfo before the cURL call, right? And in the same scope? And $fd = fopen($file_name, "rb"); $contents = fread($fd, filesize($file_name)); fclose($fd);that is silly. I don't understand why people keep doing that.

Actually, forget the coin. Find a code style guide from a project you like and adopt that.

Consistency is good, sure. But you're spending time on a matter which is not even a matter. The name you give to a temporary variable that lasts less than a dozen lines of code is more important than this. Don't know which to choose? Flip a coin. Programming is not about copying what other people are doing. ...what coin you flip is probably more important than this...

The first number is a standardized error code that will probably only give you a general explanation as to what the problem was. Compare MySQL's error codes with PostgreSQL's and you'll see MySQL uses SQLSTATE 23000 for no less than fourteen distinct error conditions while PostgreSQL uses just the one. The second number is vendor-specific. So no.

I think it's completely and utterly irrelevant.