maxxd
-
Posts
1,698 -
Joined
-
Last visited
-
Days Won
53
Everything posted by maxxd
-
Specify the method in your form tag (method="post").
-
You'll have to define "isn't working". The following works for me as expected: <?php if($_SERVER['REQUEST_METHOD'] == 'POST'){ print("<pre>".var_export($_POST, true)."</pre>"); } ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Testing</title> </head> <body> <form method="post" name="firstForm"> <button id="whatever" name="click" value="button_1">Click Me!</button> <button id="whatever2" name="click" value="button_2">Click Me, Too!</button> </form> </body> </html>
-
Thanks for the clarification, @kicken!
-
True. This would solve the issue. I want to say (though to be honest I'm not entirely confident in my memory so don't quote me) that some browsers have issues passing button and submit element attributes on submission? Like if you name your submit button and then check for that index in the $_POST array being set it doesn't always catch it - I want to say it's mostly IE, which probably doesn't really matter any more anyway. @SaranacLake The reason your third form results are off is that both the buttons have the same name, and they're both submitted with the form. So the value of `which_choice_did_i_make` is overwritten and will always be 'Form4_Input2'. The thing about it is, if you're using AJAX and JavaScript you can easily use one form - the onClick event tells the JS event handler which button was clicked, that information is put into the data array and passed to the PHP script. No hidden fields, one form, no page refresh necessary. However, the way you're doing it, there's no way the hidden field can tell the PHP script which button was clicked - all the data is always submitted. Just the act of clicking an HTML button doesn't trigger any special actions that will bind a field value to a field (obviously this can be done with JavaScript, but it won't happen in plain old HTML). Assuming my memory is as bad as it seems to be these days, Barand's suggestion is the way to go for you - check the value of the button element name in $_POST and go from there. This allows you to have one form, no hidden fields, with mandatory page refresh.
-
<?php if($_SERVER['REQUEST_METHOD'] == 'POST'){ foreach($_POST['options'] as $option){ doSomething($option); } } ?> <form method="post"> <input type="text" name="options[]" value="First Option"> <input type="text" name="options[]" value="Second Option"> <input type="text" name="options[]" value="Third Option"> <input type="text" name="options[]" value="Fourth Option"> <submit> </form> This is a very common method of handling post input. It's also a lot easier and more efficient than trying to loop over every sku in the database and see if it's set in the $_POST array one by one.
-
<?php if($_SERVER['REQUEST_METHOD'] == 'POST'){ print("<p>{$_POST['which_choice_did_i_make']}</p>"); } ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Testing</title> </head> <body> <form method="post" name="firstForm"> <button id="whatever" name="click1">Click Me!</button> <input type="hidden" name="which_choice_did_i_make" value="firstForm"> </form> <form method="post" name="secondForm"> <button id="whatever2" name="click2">Click Me, Too!</button> <input type="hidden" name="which_choice_did_i_make" value="secondForm"> </form> </body> </html> See what happens when you click the buttons.
-
Caveat - unless you're using ajax in a SPA. In which case, use one form and give the buttons differentiating data-plan attributes and use that to decide what to do with it. But it's late and my brain is being a bit overactive, so I'm probably muddying the waters by saying that.
-
OK - that clears up my confusion. Maybe it's my cynical nature, but I couldn't see someone not choosing the "upgrade at a discount" option after their account had expired. Given that, if you're processing all of it using the same script I would recommend using separate forms on the same page, each with a single hidden field to denote which form the user is filling in (which option they've chosen). Just remember to make sure on the back end that the user is eligible for the choice they've submitted.
-
fetch() help and understanding
maxxd replied to Self_Taught_Still_Learning's topic in Javascript Help
I'm honestly not sure your setup makes sense to me, but it sounds like you may want to look into web workers and forgo the database polling entirely, unless I'm misunderstanding the goal. Which is, quite honestly, very possible at this point. -
I guess I'm getting hung up on why the first two options you describe show up on the same page as the last three. You say the first two are available to users before a certain date, the last three are available to the same user after the certain date. So why do you ever have all five choices on the same page? All that being said, I'm not privy to the business logic and that will dictate how you handle the situation. I'm assuming in my comments that you're handling all the possibilities in the same form processing script, but that's not necessarily true - this means you can set it up in a way very different than the one I'm thinking of and describing. The big takeaway is there's really not a difference. Your user will more than likely not be able to tell if there's one form on a page or a million. It really comes down to how you process the submitted data and how willing you are to have similar or related code in different places.
-
Why do you need to track each line individually? It seems like overkill to me, but maybe the business logic has a reason for it... I mean, honestly, a database of 10,000 records really isn't that big a deal, but I think it would be more efficient to track versions of the full text area contents. If you need to you can check the differences in PHP on display using something like xdiff_string_diff(), or you can track the character numbers changed in a separate table and highlight those changes by using those character offset values and substr() or something.
-
Sorry, yes - of course you need a to know which option the user has chosen. So if you're doing it with a button per option then perhaps hidden fields on separate forms on the same page could be the best way to go. If you've got a drop-down, one form without a hidden field is fine. Totally up to you - the user shouldn't be able to tell, and there's no hit to page load or usability either way. The one thing I would recommend is you don't name several different buttons different things in the same form - as far as I know there are still some browsers in use that don't pass the name attribute of a button.
-
Please note, there's a massive difference between this: and this: It's not just that mac_gyver's is output from PHP. Set up your form to let you use arrays in it's processing and your life will be much easier. Jodunno's code is technically sufficient, but you're going to find yourself jumping through hoops to figure out what the $_POST key you're looking for is, whereas you can run a simple loop with mac_gyver's code. Understand, I'm not bashing Jodunno's code, s/he was very clear that this was just example code written rather quickly - I just want to make sure the example isn't taken too literally.
-
You don't have five forms - you have two separate forms with two or three options, respectively. Before the deadline, the user can renew or upgrade (1 form, 2 options). After the deadline, the user can select from three options (1 form, 3 options). That's pretty normal, really - there's no need for a hidden field as you should know prior to outputting the form whether the it's before or after the deadline for that particular user. The only thing you have to concern yourself with is the user's selection from the options available to the form presented to that user.
-
SELECT * FROM income WHERE `date` BETWEEN '2020-04-06 00:00:00' AND '2020-12-05 23:59:59';
-
's' is often used as the variable name for search terms. If the developer doesn't escape properly, and they used double quotes in their code, I think this particular bit would parse and stop script execution with the output that is the sha1 encrypted string of 'xyzt', which one would assume the sender knows. This would then mean that your search endpoint doesn't escape properly and is capable of evaluating php code, which means it could potentially output credentials, secrets, or simply damaging information. And yes, WordPress uses 's' as the search variable name by default - as do other CMS systems and frameworks, but as requinix pointed out WordPress has more than it's fair share of issues and potential vulnerabilities.
-
Hunh - got some reading to do. Thanks for the pointer!
-
I've never heard of $_SERVER['CONTEXT_DOCUMENT_ROOT'] and it's not listed in the documentation - echo that out and see what it says.
-
Glad that did it!
-
Is the div in the DOM on page load or is it added dynamically later? You may have to use .on() to bind the event to the element.
-
What minifier are you using? As requinix pointed out, `.class1.class2` is very different from `.class1 .class2` and if your minifier is adding or removing spaces like that it's broken. I always had good luck with cssmin if you're using gulp - I assume it's usable via webpack.
-
The pro paid version supports this, the free doesn't. If you've paid for the plugin you should also have customer support information and I'd venture to say that's probably the best place to start.
-
Yup - I'd've been no help at all there; glad you got it figured out, and thanks for posting the reason!
-
Is error reporting enabled on your new server? Granted it's early for me, but nothing in your sample code jumps out as being wrong.
-
Check your cURL version across your environments. I had a similar issue once - Centos 6 uses an old version of cURL apparently, so everything I was doing locally and on the staging server worked perfectly but blew up completely on production until I manually updated the cURL version.
