requinix

Did you restart Apache/nginx/PHP so the change takes effect?

"Related" how? The PHP needs to be executed before the HTML, and they must both happen during the same request (so like without any redirects).

Switch from IDs to classes. Or data attributes. What's the HTML for the table, including the input?

If "row" is the row you want to move around within the current table, then row.parent().prepend(row); // move to beginning row.parent().append(row); // move to end

Executed. Not inserted. PHP did not perform some sort of virtual copy-and-paste of the included file's contents into the point where the include call was. What PHP did was execute the file. You said that an include "is the same as though you cut and pasted". I'm picking at how and why that statement is factually incorrect.

No, it does not work like that. Consider this: <?php // one.php if (false) include "two.php"; <?php // two.php echo "first statement\n"; echo "second statement\n"; and compare with <?php if (false) echo "first statement\n"; echo "second statement:\n";

In other words, no: each file has to be syntactically valid in its own right. An include means to run the file, not to "insert" the code at that point.

This is what converts. function convertToBTCFromSatoshi($value) { $BTC = $value / 100000000 ; return $BTC; } Do I need to say anything more?

#define HTTPC_ERROR_READ_TIMEOUT (-11)

What is the name of it? Where can it be viewed online?

Your HttpClient library is returning -11. Not PHP. You have to find out why. What library are you using?

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.