maxxd

Try: $args = array( 'post_type' => 'cpt_issue', 'post_status' => 'publish', 'orderby' => 'date', 'order' => 'DESC' 'post__not_in' => array( $post->ID ) 'posts_per_page' => 2, 'offset' => 1 );

You've got issues with the backticks and quotes in your update query. UPDATE avaliacao SET `nota` = '$nota' , `comentario` = '$comentario' WHERE `íd` = $id Honestly, you only need backticks when your table or column names are a reserved word, which I don't believe is the case here, so you shouldn't need them at all. All strings have to be enclosed in quotes. I've updated your query in red above. Of course, the bigger issue is that you've got no validation or sanitization at all.

I have absolutely no idea what you're asking, if you're even asking a question. Perhaps some further explanation would help?

Hunh. It works for me in Firefox, Opera, and Chrome in Win and Mac, Safari on Mac and IE on Win. Strange - I'll have to keep an eye to how I test for form submission in the future - thanks for the heads-up!

Actually, as long as the submit button has a name property of 'submit', hitting enter instead of clicking the button works just fine. The form as a whole is submitted, so if there's a form element named 'submit' in the form, it gets submitted regardless of submission method (hitting enter on the keyboard or clicking the submit button). The only way I can think that this wouldn't work is if the element named 'submit' is a checkbox that is unselected when the form is actually submitted.

Off the top of my head, you could create a table that holds deal details (customer_id, product_id, agent, expiry, etc) and simply pass the deal id in the e-mail. Thatway all your necessary info is at your fingertips but not exposed.

Your visitor ID hidden field is named 'id', not 'visitor_id'. You'll need to change either the field name or the $_POST index.

So where is the code that we've been looking at? I assumed it was in your functions.php file; you can start the session there just fine without having to call a function on the init hook. Just put the session_start() call at the top of functions.php after the direct access check and everything should work fine across all browsers.

Broke your page how? The die() statements are there to stop execution of the script at that specific point so you can see what's happening. So, in this case, your $_POST and your $_SESSION variables are both set. Is that supposed to happen with this set up? If not, take a step back and rethink the logical flow. If so, then comment out the die() statement, fill out the form again, submit, and keep stepping forward until you find the point where the $_SESSION variables are set in Chrome but not in FireFox.

Try replacing the end of your code with this and let us know what prints: //set sessions if(empty($errors) && isset($_POST['submit'])){ $_SESSION['dob-month'] = isset($_POST['dob-month']) ? $_POST['dob-month'] : null; $_SESSION['dob-day'] = isset($_POST['dob-day']) ? $_POST['dob-day'] : null; $_SESSION['dob-year'] = isset($_POST['dob-year']) ? $_POST['dob-year'] : null; print("<p>\$errors is empty and \$_POST['submit'] is set</p><p>Session is: </p><pre>".print_r($_SESSION,true)."</pre><p>\$_POST is: </p><pre>".print_r($_POST,true)."</pre>"); die(); // header("Location: /calculator/",TRUE,303); } //set variables and clear sessions print("<p>Outside conditionals: \$_SESSION is: </p><pre>".print_r($_SESSION,true)."</pre>"); } if (isset($_SESSION['dob-month'])||isset($_SESSION['dob-day'])||isset($_SESSION['dob-year'])||isset($_SESSION['submit'])){ $month = isset($_SESSION['dob-month']) ? $_SESSION['dob-month'] : null; $day = isset($_SESSION['dob-day']) ? $_SESSION['dob-day'] : null; $year = isset($_SESSION['dob-year']) ? $_SESSION['dob-year'] : null; print("<p>This is the other conditional branch. The date is {$month}-{$day}-{$year}</p>"); die(); session_unset(); session_destroy(); } Note that your ternaries were malformed, so I updated that. I don't know if that would cause the problem you were having, but it's worth a shot. Actually, now that I think about it, are you sure this isn't an HTML issue? The php is handled on the server, so if it works on Chrome, it should work on Firefox, IE, Opera, what have you.

Typically the way this is done is to do the redirect after the form is processed. Where you're putting the $_POST variables into $_SESSION, redirecting, then processing from $_SESSION, you'll usually do it the other way around. Check to see if $_POST is set, process the data if it is. If the processing is successful, redirect the browser back to the current page. That way $_POST is clear, the form has been processed, and you don't need to muck about with stuffing things into $_SESSION when they're not entirely necessary. I can't remember the term/abbreviation for this method of handling data processing off the top of my head, sorry...

If you're wanting to play with color schemes, try out Adobe Color CC.

Gathering data from a MySQL database is anything but impossible with PHP.

Yup. My bad.

And it's a completely viable strategy; I just typically figure why go through the process of testing and sanitizing the user input to avoid SQL injection when you can use prepared statements and it's not an issue. That having been said, the other caveat for my method is that you only get that security if you set PDO::ATTR_EMULATE_PREPARES to true, as I believe it's false by default.

You only need to prepare the statement one time, then you can run the execute through the loop - the resource is still allocated, so it doesn't eat any additional space. The parameters are bound on the execute() call using the $insert variable (current iteration of the $vars array). It's one of the main reasons I like PDO over MySQLi.

Personally, I'd go a step further and use PDO's prepared statement for added security, like so: foreach($_POST['multiBox'] as $val){ $tmp['user_id'] = $_POST['user_id']; $tmp['comp_id'] = $val; $vars[] = $tmp; } $qry = "INSERT INTO user_compentency (user_id, comp_id) VALUES (:user_id, :comp_id) "; try{ $sql = $conn->prepare($qry); $numRows = 0; foreach($vars as $insert){ $numRows += $sql->execute($insert); } print("<p>There were {$numRows} inserted into the database!</p>"); }catch(PDOException $e){ print("<p>Oops! There was an issue - this is the message: {$e->getMessage()}</p>"); } Of course, this assumes you're using PDO and have set the error handling to PDO::ERRMODE_EXCEPTION. Also, note that this is completely untested code and I'm still on my first cup of coffee, so there very well could be a typo or logical glitch in there...

Turn on error checking. You should be getting an error regarding an extra comma at the end of your $insStr. That having been said, the entire issue could be avoided - and you could have safer and easier database interaction that will still work next year - by moving to PDO or MySQLi. the mysql_* functions have been deprecated for something like a decade now and are slated to be removed from the language with version 7, which I believe drops later this summer.

I would start here - wish I could be more specific, but I've only used Ninja Forms on one site and I didn't have to interact with it too much on a code level, so I'm not really sure which is going to be the right place to start.

$formID is passed in to your function from the ninja_forms_display_fields hook. There may be other parameters passed, but the docs only mentioned this one. Try just printing it to see if it's an ID, or an array, or what it is - you may have to use it to get further data from the database. If you run the code you have above, what's the output? I got the idea that the hook is fired before each field is displayed (not just once), but I could be mistaken about that.

The reply to your post on WordPress forum is probably due to the fact that this isn't the WordPress way of including the jQuery library. Also, check to make sure that WordPress isn't already including it. WP installs a local copy of jQuery in non-conflict mode in order to lessen the chances of conflicts when two different plugin developers use different libraries. You can always dequeue the WP version and enqueue the newer version, but be ware that it may actually break things. Like apparently Huge-it. WordPress is like that. Dequeue a script. Enqueue a script.

Your theme has a file called functions.php. If you open that up, you'll find all the hooks that the theme uses, and it's here you'd add the call to ninja_forms_display_fields like so: add_action('ninja_forms_display_fields', 'thisIsMyFunction', 0, 10); function thisIsMyFunction($formID){ //do whatever you need to do, using $formID } Again, I'm not sure this is the hook you need, but it's a place to start. Also, if you're using a downloaded or purchased theme you might want to create a child theme out of it before you start messing with the functions.php file as that file runs your entire site.

Hey y'all. I've got the following code: $(window).scroll(function(){ if($(window).width() > 640){ $('#bg').css({top:$(this).scrollTop()}); } if($(window).width() > 981){ $('.switch').css({top:$(this).scrollTop() + 75});//75 pixels is the top-offset of the element in the style sheet } }); In Firefox, Chrome, Safari, Opera, and Chrome Canary on osX and Firefox, Chrome, and Opera on Windows the div 'bg' stays pinned to the top of the browser window when I scroll. Exactly as intended. Unfortunately, in IE, the div scrolls downwards (against the mouse scroll). But, the 'switch' div stays put - just like it should! It's acting as if the scrollTop() call is returning negative numbers, despite the fact that it's not (I've logged to console and everything looks fine) and it's only doing it in the first conditional. If I change $(this).scrollTop() to a flat 0, it works in IE but nowhere else. I'm starting to doubt my own sanity. Can anyone come up with a reason I might be seeing this behavior?

Do none of the Ninja Forms hooks give you the chance to inject the data you want? Using add_filter() in your functions file would at least keep the php together and not force you to try to hack it into the CSS - it seems like the ninja_forms_display_fields hook might be the one you're looking for.

You could also give a shot to highlight_string() or highlight_file(). I've not used either so I can't vouch for their effectiveness, but it's something to look at.