maxxd

Very much worth exploring - thanks for the idea. Unfortunately, it's a WordPress site and contact form plugin, so I'm not entirely sure it's possible, but I'm definitely going to check it out now - thanks again!

Hey y'all, I've got a weird one here and was hoping someone had a word or two of wisdom. I've got a php script that outputs a couple banks of checkboxes in a dynamic form. I've also written a JavaScript script that will sort through the form elements on page load and hide a form element, replacing it with a setup of divs that I can then style. I've got the JS working to emulate form element interaction depending on form element type and state. To cut way back (I hope) on the TL;DR quotient, I've cut the code down pretty significantly below. Hopefully it still makes sense. Here's the JS: ;function StylishForms(frm){ "use strict"; var _form, _overlay, _elementHelpers = {}, _elementTotals = { 'checkbox' : 0, 'selects' : 0, 'text' : 0, }; kickOff(frm); function kickOff(frm){ if(typeof frm === 'string'){ _form = document.forms[frm]; }else{ if(typeof _form.jquery !== 'undefined'){ _form = document.forms[_form.attr('id')]; }else{ _form = frm; } } for(var i in _form.elements){ console.log(_form.elements[i].type + ' : ' + _form.elements[i].name); } } } Second JS file: (function($){ if($('form').length > 0){ $('form').each(function(){ StylishForms( $(this) ); }); } }) (jQuery); And the HTML: <form action="" method="post" class="wpcf7-form testing-forms" novalidate="novalidate" id="test_1"> <p> <span class="wpcf7-form-control-wrap selector"> <select name="selector" class="wpcf7-form-control wpcf7-select selector" id="testing" aria-invalid="false"> <option value="first option">first option</option> <option value="option 1">option 1</option> <option value="option 2">option 2</option> <option value="option 3">option 3</option> <option value="option 4">option 4</option> <option value="option 5">option 5</option> <option value="option 6">option 6</option> <option value="option 7">option 7</option> </select> </span> </p> <p> <span class="wpcf7-form-control-wrap secondselect"> <select name="secondselect" class="wpcf7-form-control wpcf7-select" id="test_more" aria-invalid="false"> <option value="Second Option 1">Second Option 1</option> <option value="Second Option 2">Second Option 2</option> <option value="Second Option 3" selected="selected">Second Option 3</option> <option value="Second Option 4">Second Option 4</option> </select> </span> </p> <p> <span class="wpcf7-form-control-wrap checkTester"> <span class="wpcf7-form-control wpcf7-checkbox" id="checkTesterOption"> <span class="wpcf7-list-item first"> <input type="checkbox" name="checkTester[]" value="Option 1" /> <span class="wpcf7-list-item-label">Option 1</span> </span> <span class="wpcf7-list-item"> <input type="checkbox" name="checkTester[]" value="Option 2" /> <span class="wpcf7-list-item-label">Option 2</span> </span> <span class="wpcf7-list-item last"> <input type="checkbox" name="checkTester[]" value="Option 3" /> <span class="wpcf7-list-item-label">Option 3</span> </span> </span> </span> <br /> <span class="wpcf7-form-control-wrap checkTester2"> <span class="wpcf7-form-control wpcf7-checkbox" id="checkTesterOption2"> <span class="wpcf7-list-item first last"> <input type="checkbox" name="checkTester2[]" value="Option 2-1" /> <span class="wpcf7-list-item-label">Option 2-1</span> </span> </span> </span> </p> <p> <span class="wpcf7-form-control-wrap text_testing"> <input type="text" name="text_testing" value="" size="40" class="wpcf7-form-control wpcf7-text" aria-invalid="false" /> </span> </p> <p> <input type="submit" value="submit" class="wpcf7-form-control wpcf7-submit" /> </p> </form> And finally, the console output: select-one : selector select-one : secondselect undefined : undefined undefined : undefined undefined : undefined checkbox : checkTester2[] text : text_testing submit : The select and text objects work exactly as expected across OS's and browsers - it's the checkboxes that are the issue. In Firefox, Opera, and Chrome on Windows, Mac, IOS, and Android they work as expected. In Safari on IOS and Mac, everything works as expected. On IE 10, 11, or Edge (obviously on Windows), they fail almost entirely. You can see from the console output that the only time Edge reports a checkbox is when there's only one associated with the name (in this case, checkTester2[]). If there's more than one checkbox, it reports both the input type and name as undefined. As much as I'd love to simply say "people using MS-based browsers need to stop doing that", unfortunately I can't. But I also can't find what I'm missing here. Anyone see anything that I don't? Any and all help is much appreciated.

Unless you're using AJAX, the page has to be submitted before PHP can get the variables to validate. So the page should refresh and automatically be at the top... Perhaps post the form and validation code?

In which case it's not an object. Note in the code I provided $values['IssueDate'] is a DateTime() object. Convert $values['IssueDate'] to a DateTime object and try it again.

I did not know that. Strange thing is, it worked when I tested it here in 7.0.4...

Admittedly, I get a bit concerned when I see variables named incrementally, but I'm going to assume you're using them as examples. So, to answer the question, you can use a DateTime object. //stub values for testing purposes $tz = new DateTimeZone('America/New_York'); $values['IssueDate'] = new DateTime('now', $tz); $values['Workings1'] = 'D'; $values['Workings2'] = 'tomorrow'; $values['Workings3'] = '730'; //actual functionality if ($values['Workings1'] == "F") { $values['ExpiryDate'] = new DateTime($values['Workings2'], $tz); } else if ($values['Workings1'] == "D") { $values['ExpiryDate'] = clone($values['IssueDate']); $values['ExpiryDate']->modify("+{$values['Workings3']} days"); } print("<p>This is the expiration date: {$values['ExpiryDate']->format('Y-m-d')}</p>"); This is obviously a less than perfect solution as there's no error checking (what if the 'Workings3' index contained a number of years or seconds? Or 'Bob'?), but it should point you in the right direction. Also, if it's possible for 'Workings1' - and I have to stress again that I really hope that's not what you're calling your indexes - to contain anything other than 'F' or 'D', I'd recommend looking at a switch() statement instead of a spaghetti pile of else if()'s.

Sorry, but no. Are talking about an auto-increment type situation or result set pagination? Or something else entirely?

option_id is the primary key in the table, so I'd think running the queries separately is the way to go. However, I'm wondering why you're running another update using $table, $data, and $where right before you run the updates you're asking about. Nowhere in the code you've posted are $table, $data, or $where actually set. So it is possible that you can cut half the update calls depending on the contents of those variables.

What hook are you using to run your attach_doc_to_email() function? Are you sure it's actually being called and The Event Calendar isn't returning the default event instead of the one you're trying to grab? Try throwing in a wp_die('This is attach_doc_to_email() calling!'); right after the function declaration. At least you'll be able to tell that the function is being called at all and can continue to troubleshoot from there.

I've not got a lot of experience with WooCommerce, but what I've found is that the product is a custom post type. Have you tried "get_posts( [productID] )"? It should return a WP_Post object - the post_title attribute should be the product name.

We're going to need a lot more information than this to help at all. What theme are you using? Have you created a child theme (you should have, if you're editing the files)? What e-commerce plugin are you using? Have you read the documentation for the theme and plugin?

Wow - thanks for the explanation! I love learning new things - didn't even know that function existed! Thanks - it's much appreciated.

Thanks, Jacques1 - I was hoping you'd chime in on this. Unfortunately, as you say maintaining a list of possible names is a bit impractical, though I may look into it further as I near the end of the project and (hopefully) fewer surprises pop up. As I understand it, the null byte injection weakness was fixed in 5.3 - at least for file_exists(), so wouldn't doing that check before including the file provide the necessary validation? Either way, I very much like the idea of validating the content of the file name, and feel kinda silly for not thinking of it earlier. Although, honestly, regex is possibly my least favorite part of coding. But, time to buck up and figure it out. Thanks for the input!

Your HTML has 4 <tr> elements with an id of 'row', which is wrong from a purely semantic point of view. The point of an id is that (much like Highlander) there can be only one (per page). You've also got 2 'container' ids. You'll find JavaScript and jQuery much easier to deal with if your markup up is syntactically correct, so I'd start looking there. Associate each of the 'new row' buttons with the form by putting the button in the form itself, then you've got a frame within which to work.

Hey y'all. So, I was reading a post here where @Jacques1 linked to an article about local file inclusion vulnerability, and it got me thinking. At the end, the article mentions converting characters to hexadecimal to get around the updir stop; this piqued my interest so I checked some work I'm doing right now for a client. I've got the following set-up: This is the front-end controller of sorts.... //set up the custom post types we're going to create for this site $cpts = array( 'news_story', 'team_member', ); require_once('includes/Functions.php'); $fn = \Client\Functions::getInstance($cpts); Now, in my Functions.php file, I've got my class that includes the following methods: /** * Constuctor method. * Private - Singleton pattern * @param array $cpts Allowable custom post types for the system to attempt to create * @return void */ private function __construct(array $cpts){ $this->_cpts = $cpts; $this->createCPTs(); } /** * Returns the singleton instance of this class. * @param array Array of strings describing the necessary custom * post types for the site. * @return \Client\Functions */ public static function getInstance(array $cpts){ if(empty(self::$_inst)){ if(!is_array($cpts)){ $cpts = array(); } self::$_inst = new self($cpts); } return self::$_inst; } /** * Create the site custom post type(s). * @return void */ private function createCPTs(){ foreach($this->_cpts as $i => $cpt){ $fn = str_replace(array('.','/',' '), '', ucwords(str_replace('_', ' ', $cpt))); if(file_exists(dirname(__FILE__)."/cpts/{$fn}.php") && is_readable(dirname(__FILE__)."/cpts/{$fn}.php")){ require_once(dirname(__FILE__)."/cpts/{$fn}.php"); $fn = "\\Client\\{$fn}"; $this->_cpts["client_{$cpt}"] = new $fn(); unset($this->_cpts[$i]); } } } To my eye, this seems secure. By doing a string replace for both the '.' and the '/' character, I believe I'm stopping a local file inclusion vulnerability by basically voiding both directory traversing and specific file names - by removing the slash and the dot separately, it shouldn't match anything of interest on the server, right? I mean it's not like 'varwwwmysitehtaccess' is the same as '/var/www/mysite/.htaccess', './.htaccess', or '../../../.htaccess', right? Any opinions? Just want a sanity check - it's been a long day...

Psycho's example is good, especially given the relative vagueness of the problem description. Offering another idea on what you're possibly asking, if you've got two complete forms - one with information and one without - and you want to copy the info from the filled-out form to the empty form, you don't need to use clone. Assuming the field names are similar (for instance, id 'name_left' on the left form maps to id 'name_right' on the right form, etc.), simply loop through the filled-out form, get the value of each element and assign that value to the corresponding element in the other form. HTML: <form id='left'> <input type='text' name='name_left' id='name_left' /> </form> <div id='copy-button'>Copy left to right</div> <form id='right'> <input type='text' name='name_right' id='name_right' /> </form> JavaScript: $('#copy-button').click(function(e){ $('#left input').each(function(){ var currentValue = $(this).val(); var currentField = $(this).attr('id'); var fieldArray = currentField.split('_'); var newField = '#' + fieldArray[0] + '_right'; $(newField).val(currentValue); }); });

You'll have to target each 'show-details' class individually. Put that div inside the 'product' div and target it specifically. This is untested, but should theoretically work: $(document).ready(function(){ $('.product').mouseover(function(){ $(this).find('.show-details').css({ display: 'block' }); }); $('.product').mouseout(function(){ $(this).find('.show-details').css({ display: 'none' }); }); });

Am I wrong in thinking I read somewhere that it's pretty easy to spoof the request method header? I'm assuming now that I am, but I've always avoided checking it for that very reason. What I will typically do is insert a hidden value in the form (which can easily be changed, but there are stops to avoid that) and check for that hidden value in the superglobal of choice. For instance, <?php public method handleIt(){ if(isset($_POST['axn']) && isset($_POST['nonce'])){ $method = "action".ucfirst($_POST['axn']); if(method_exists($this, $method)){ $this->_something = $this->$method($_POST); } } } private function actionAnAction(array $vars){ if(!$this->_nonceObject->checkNonce($vars['nonce'])){ return false; } return $this->doStuff(); } ?> <form name='doIt' method='post'> <input type='hidden' name='axn' value='anAction' /> <input type='hidden' name='nonce' value='generatedNonce' /> <input type='text' name='lah' value='deDah' /> <button type='submit' name='whatever' value='Do It' /> </form> Please excuse the obviously inane code (it's been a rather long day), but hopefully it's enough to illustrate the point, and it seems to me this is safe and thorough enough to make sure you're dealing with a legit form submission, exactly how you intended the form to be submitted. Either way, $_REQUEST needs to be retired immediately. Then we can all just sit back and watch WordPress burn.

Theoretically, yes, you can combine arrays in nested foreach() loops, but I'm not sure I understand what your end goal is, which makes it difficult to advise how one would possibly go about doing that. What's the correlation between the array values? Right now it seems utterly random.

If it's a Debian flavor of Linux, you should be able to run sudo apt-get update sudo apt-get upgrade and that'll update everything except the operating system itself. Honestly, if you're already thinking about wiping the system and starting over, there's nothing to lose by giving it a shot. And you may end up saving yourself some time and headache.

This may be a dumb question, but why not just update PHP? I'm not a server jockey by any stretch, but I don't remember hearing anything about PHP updates that would cause it to not compile on even old equipment. I've got a severely under-powered 7-year old eMachines box sitting in my office that I use as my development LAMP stack and it works wonders for developing and testing. Granted, it's not directly connected to the Internet, and it's not up to version 7 yet, but it does work well.

Hunh. I thought 'visibility: hidden' behaved more like 'display: none' - good to know. Thanks for running the tests and posting your findings!

No disrespect taken - it was a quick and dirty answer, honestly. I almost went so far as to use .toggle() instead of .css(), but had a meeting to go to. The only thing about using opacity instead of toggle(), hide(), show(), or display/visibility is that opacity will leave the element in the DOM. Which can be a pain for form processing (there will be extra variables in there that you don't really care about), but it will still at least take up the physical space in the DOM so that anything beneath the second select element won't suddenly reflow upwards. At any rate, thanks for fleshing out the example and pointing out the omissions!

$('#location').on('change',function(){ if($(this).val() == 'loc5'){ $('#second').css({ opacity: 1 }); } }); Of course, you'll need to set the secondary element to 0 opacity in the stylesheet.

There's no way for us to tell why it's failing right now as the SQL looks fine. What you need to do is check the results of the query. See if the query failed; if it did check the error using mysqli_error(). if(!mysqli_query($con, "UPDATE news SET news_title='$news_title', news_content='$news_content', publish='$publish', facebook='$facebook' WHERE news_id='$news_id'")){ print("<p>Don't print the error to screen in a real application; but for testing purposes the error is ".mysqli_error($con)."</p>"); } Also, please note that you're inviting SQL injection by putting suspect data ($_POST values) directly into the SQL. Look into prepared statements - honestly, here's where you're going to find PDO much easier to deal with.