kicken

Make sure you have your error_reporting set to E_ALL and display_errors set to On in the php.ini file for your development environment so you can be informed of any errors that occur. Dump the value of $response with var_dump($response); so you can see what you're getting as a response after curl_exec is complete.

Test for what you expect, and if you don't get what you expect then handle it however you see fit. For example: if (!is_array($_POST['myarray'])){ $_POST['myarray'] = []; }

Not committing the changes is essentially undoing everything. Sure, why not? That's exactly what someone who was already a member and needed to renew would be doing. The user and order should already be tied together. Then you tie the payment to the order and record whatever it's result is, be it failure or success. If it's a failure, notify the user and offer them a chance to try another payment. For the second payment you can either make a new order or just add a new payment record to the existing order. Totally up to you and what you want to do. Unless you're doing a one-time payment thing, which if I remember correctly from prior threads you're not, then that's work you have to do anyway for when a member's subscription expires. When that happens they need to be able to login so they can manage their account (and potentially renew) but you'll want to block the content. So...Do the work and take advantage of it for new sign-ups as well. That is something you can and ideally should catch client-side with JS before the form is submitted. Sure, you can do that. If you go for the simple roll everything back method then that's probably all you need to do. If you create and keep the account however, consider this scenario: I'm trying to sign up for your site but, unexpectedly, my payment fails. "Oh my, how can this be!" I say. I open a new tab and rush over to my online banking to double check my account. Upon logging in I discover my card has been deactivated due to potential fraud, some other site must have been hacked! My new card is on the way in the mail. "Drats, I guess I will just have to wait til next week for the new card" I sigh. Since signing up obviously won't happen today I shutdown the computer and go on with my day. **inspired by a true story With the accout having already been created as part of the original attempt, I can't just sign up again with the same details, an account already exists. So I'd need a way to login then complete the checkout from there. Ultimately, this entire thread just boils down to "Pick something, and do it" There's not a single right way to handle this. There are some ways that can arguably be better than others, but every option has a pros and cons list and it's to you to decide how the pros weigh vs the cons. Option 1) Single transaction, roll it all back if the payment fails Pros: Easy to implement. Fairly easy for users to understand (had a problem, nothing saved, start over) Cons: Less flexible. Less data to track/analyze. If the user calls wondering why their payment failed, you may not be able to answer that question. Possibly annoying for users, particularly if the sign-up process is long. Option 2) Create account, handle payment separately. Pros: More flexible. Able to track all orders and payments. Potentially able to answer user's questions about payment failures. Cons: Users may not expect the account to exist (easily addressed though). Harder to implement. Other: Details can implemented in a range of different ways, either with their own pros/cons and level of difficulty. Option n) whatever other way you can think of. Weigh it's pros and cons. Pick a route. Figure out what process you want to follow and Just do it.™ If you're ok with not tracking every payment and want to take the easy route, then go for option 1. Otherwise go for option 2 and figure out what features you need and what you can live without. Have some other idea you think is good? Go for option n. You can always revise the process later if it turns out to not work out as well as you'd hoped. If it were me, I'd lean toward option 2 and putting in the work necessary to track all the payment details. I'd probably make the sign-up a two-step process rather than a one-step process just to help make it clear to then user that the account is created regardless of payment status. You can have both steps on the same page if you wanted for a nicer UX, just use JS to process the account creation via AJAX in the background. Most places I've dealt with in the last few years offer a trial period which kind of forces them into creating the account separate from payment handling. Many don't even ask for payment details until the trial ends. Some have asked up front but don't process them until after the trial. A few have run a small authorization (which is later voided) just to check the validity of the card and prevent signup on failure; mainly to prevent abuse where people just sign up for a new trial every month and/or as a type of captcha to prevent bots from signing up.

You need to alias the result column to the name you are using to access it within PHP. SELECT SUM(noopaxs-gattl) as gattl

I generally find the best thing to do is just create your tables and start working. You'll probably make a mistake/forget something in your initial table design but that's fine. You catch it while you're writing the code and then update your database as needed. There's a point at which trying to plan ahead become counter-productive. You spend far too much time trying to anticipate everything you'll need/want and either make things overly complicate or still miss something anyway. So instead just put in the basic stuff you know for sure you'll need and then let the design evolve as you work. I generally don't even bother with indexes outside of the primary key / foreign keys until I have something mostly developed, tested and working. That way I have a better understanding of what my actual queries are rather than trying to guess what they will be early on. Pretty much every mistake can be fixed, some may just take longer or be more complicated than others. Most of your mistakes will probably be minor like "Oh, I should save this too" or "This should go in a different table" or "Maybe I should have an index here". You'd be hard pressed i think to make any mistake that I'd classify as "fatal". Bottom line, don't worry about mistakes and trying to get things right the first time. Spend more time actually working the problem so you know what you need rather than trying to think of everything first. Don't be afraid of re-factoring things later on, possibly multiple times as your understanding of things improves.

You need to compare the values to what was submitted as you generate the options and add the selected attribute to the one they chose. So you'd end up with one of the options looking like: <option value="blah" selected>Blah</option> One method for accomplishing that would be to add a parameter to your getStates() function that indicates which item to select. Then when you call it pass in their post value.

If you use it regularly, you should just wrap it up in a function that you can call. I used a function like this often in my earlier days. function dv(/*...*/){ if (!defined('ENABLE_DEBUG') || !ENABLE_DEBUG){ return; } echo '<pre>'; for ($i = 0, $len = func_num_args(); $i < $len; $i++){ var_dump(func_get_arg($i)); echo "\r\n"; } echo '</pre>'; } Then if I wanted to dump some variables I could just dv($_POST, $_GET); for example. The check for ENABLE_DEBUG is there so that if by chance any calls got left in the code they would do nothing on the production site as I only setup that constant on my development system. These days I just use Xdebug with breakpoints which is much nicer and easier. Xdebug will also change var_dump to be readable without the <pre> tags so such an extra functions isn't really necessary.

Afaik, this is no longer an issue in any modern browser. This was an issue back the the old days, but was only an issue via implicit submit (via Enter in a text field). If you hit enter in a text field to submit the form some browsers would not include the submit button name/value where as others would. I forget which browser did which action. Fun fact, google actually used to detect if the button name was submitted and show a "Tip: You can just hit enter to search" bit on the results page. I believe old IE also had issues with <button> specifically, ignoring the value attribute and passing it's label content instead at times. As such, it was best to give the buttons different names and check for that instead of the values. These days however, there's no problem with just providing several buttons with the same name and different values. The browser will submit the value of the button you clicked on and you can detect that in your script just fine. If your form has other fields, then what happens on the implicit submit is now clearly defined in the spec.

$('#sum').innerText That syntax mixes jQuery and plain Javascript which you cannot do. $('#sum') creates a jQuery object, but .innerText is a DOM property in plain javascript. The jQuery way to read/set the text value of an element is with the .text() method.

To alias a directory you'd generally need something like this at least. Alias /want "C:/The/Directory/You/Want" <Directory "C:/The/Directory/You/Want"> Require all granted </Directory> Depending on what exactly you want you might need some more configuration options inside the <Directory> block, like Options +ExecCGI if you need to run PHP scripts using fast-cgi. $_SERVER['SERVER_ADDR"] represents apache's local address. If you want the address of the client connecting to the server you need $_SERVER['REMOTE_ADDR']. With regard to VPN's, that remote address will be the VPN exit server's public IP. There's no way to get the clients local pre-vpn IP (which is part of the reason people use VPNs these days).

@Niksou, when you're posting code, do so as text not images. Copy your code then use the Code button (<>) in the editor to create a code block and paste your code there. If you don't post it as text, nobody can copy it to a file and test it in order to help you, so they will likely just skip your thread and you'll get no help at all. If you want to change your Add to Cart button to a quantity input then change the <button> tag to an <input> tag of type number. Add your new add to cart button where you want it. After that you'll have to figure out how to update the code that handles your cart to work with the new design. If you have a specific problem you are stuck on then post about it, but a post like "I want to do <some generic thing>" followed by a bunch of code is generally not well received.

https://securitynews.sonicwall.com/xmlpost/thinkphp-remote-code-execution-rce-bug-is-actively-being-exploited/

You could probably just simulate a click on the link to show the popup again. if ($login==='fail'){ echo '<script type="text/javascript"> jQuery(function(){ $(".open-popup").click(); }); </script> '; }

Works just fine for me using those options. First, login and get the session setup. wget --load-cookies jar --save-cookies jar --keep-session-cookies --post-data='user=test&pass=example' https://example.com/login Then run the command to mirror the site. wget --load-cookies jar --save-cookies jar --keep-session-cookies -m https://example.com/ I setup a small script that requires a login session and re-generates the session ID on every page load to test those commands with. Had no problems fetching all the content. Keep in mind that if there are links on the page that trigger a logout, you need to avoid crawling those links or you'll loose your session. That might be the issue your running into. Resolve that using the --reject or --reject-regex option.

Try looking into the --load-cookies, --save-cookies, and --keep-session-cookies options.

You need to have the ID isolated in the html so it's easier to find and work with. Best way to do that is to add it as a data attribute like so echo "<div class='btn btn-primary m-1 tagInArticle' data-id='$pid'>$fn $ln</div>"; Notice I also removed the onclick. Rather than having every button define it's own click handler, you can use jQuery's event delegation to handle it. $('#searchResultsHere').on('click', '.tagInArticle', function tagInArticle(){ var tagButton = $(this); tagButton.appendTo('#taggedInArticleContainer') }); No need to even mess with the ID there now, you can just reference the button directly using this and move it. Now, when searching you just gather up all the IDs from the buttons in #taggedInArticleContainer and submit them with your request. $('#searchForPeopleBox').keyup(function(){ var searchVal = $(this).val() var tagged = $('#taggedInArticleContainer').find('.tagInArticle').map(function(){ return $(this).data('id'); }).get(); $.ajax({ type: 'post', data: {"ajax" : 'one', "val" : searchVal, exclude: tagged}, success: function(resp){ $('#searchResultsHere').html(resp) } }); }); Finally, update your PHP search to account for $_POST['exclude'] when performing a search.

You'll have to do some debugging by var_dumping your values at various points and seeing what they are. Make sure your query is returning the data you think it is. You should also probably be zeroing out all your variables before the loop so they start fresh for each customer. Otherwise your previous customer's data will influence the next customers data.

You don't have any input fields named 'submit', so $_POST['submit'] won't exist. Note: <form> tags are not inputs, giving them a name doesn't make them submit something.

I would be using PDO with Exceptions.

Perhaps you should look at what the possible values are for button's type attribute. While you're at it, read through the rest of the spec and you'll learn all sorts of things. Bookmark it so if you have a question later you can refer back to it.

mysqli_stmt_bind_result just returns a bool value, not something you'd use in mysqli_stmt_fetch. You use your $stmt variable there like you did just above. Speaking of the line just above, it shouldn't be there. You don't fetch before your loop.

If you can get the quantity you could use a simple if statement. Something like <?php echo ($quantity>50)?'Secret':$order->get_formatted_line_subtotal($item);?> I'm not familiar with WooCommerce so I don't know how to determine $quantity, but if you look at the part of the template that shows the quantity you can probably figure it out.

You need to make sure to exit word when you're done, otherwise it will hang around in the background causing issues. wdFieldPrint / wdPropertyTitle don't mean anything. These are constants that have a particular value so you either need to define them or use the real value in their place. wdFieldPrint isn't something you'd look for in BuiltInDocumentProperties either Make sure you use a full path to the document. When I tried a relative path it looked in C:\Windows\System32 rather than the current directory. Rather than using ActiveDocument, you could just use the value returned from your open call. <?php const wdPropertyPages = 14; const wdPropertyWords = 15; const wdPropertyTitle = 1; $word =new COM('Word.Application'); try { $document = $word->Documents->Open('W:\\test.docx'); $value = $document->BuiltInDocumentProperties[wdPropertyPages]; var_dump((string)$value); $value = $document->BuiltInDocumentProperties[wdPropertyWords]; var_dump((string)$value); $value = $word->ActiveDocument->BuiltInDocumentProperties[wdPropertyTitle]; var_dump((string)$value); } finally { $word->Quit(0); }

If your query is only intended to return one row, then you just fetch the row and check with a simple if statement whether data was fetched or not. $row = $result->fetch_assoc(); if ($row){ //Yep, got data } or $row = $result->fetch_assoc(); if (!$row){ //Nope, no data available. } depending on whether a positive or negative test fits best with your situation.

Perhaps you should check for errors when executing your query also.