maxxd

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.

Sorry - it's early and all, but I'm not following that last comment (other than the typo bit). Post some code and more detail on the expected and actual results and we can get you moving in the right direction.

Barand, Psycho - thanks so much! Looking at both suggestions together got me to where I needed to be. I ended up with this: SELECT * FROM tbl_feature_images WHERE (pg_id = :page) UNION SELECT * FROM tbl_feature_images WHERE NOT EXISTS (SELECT * FROM tbl_feature_images WHERE pg_id = :page) AND pg_id IS NULL UNION SELECT * FROM tbl_feature_images WHERE pg_id IS NULL AND display_order NOT IN (SELECT display_order FROM tbl_feature_images WHERE pg_id = :page) ORDER BY zone, display_order; which lets my user replace specific images in the rotation on a per-page basis. Y'all rock the hizzy - I would say 'I knew it was something easy', but it wasn't. Thank you much!

Hey y'all. I'm having a bit of brain trouble here in that this seems like it should be really simple, but I'm just ... not coming up with the right query. Any help would be greatly appreciated. Basically, I've got three featured image 'zones' on each of the pages in my site. Each of the zones has a variable number of absolutely-placed images, stacked one on top of the other. Once the images are in place, my JavaScript takes over and cycles the opacity of each of the images in each of the zones in order from top to bottom, in effect rotating the images. That part I have working nicely, all the way around. However - and here's where my brain starts to stick - I want the site admin to be able to set site-wide default images for each zone, as well as page-specific images for each zone. So basically, if the page ID is in the featured images table, I want to select those images associated with that page ID. Otherwise, I want to select the images where page ID is null. I'm embarrassed to say that this is as far as I can get right now on it: SELECT fi.loc ,fi.title ,fi.alt ,fi.zone FROM tbl_featured_images fi WHERE fi.pageID = :page OR fi.pageID IS NULL ORDER BY fi.zone This isn't giving me the results I want (for obvious reasons). I feel like the answer's on the tip of my brain, I just can't quite seem to grasp it. Any suggestions? Many thanks in advance!

You've still got to pass the variable to the function. $data = 'My data'; function test($data) { echo $data; } test($data);

I agree with sKunKbad - stay away from global variables. If you're extending classes, make the parent class property protected and call it from the child class or inject the property through the constructor of the secondary class.