Jump to content

maxxd

Gurus
  • Content Count

    1,106
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by maxxd

  1. Thanks for the help - like I said I'll try to scrub and post the handler code tomorrow morning. What's strange is the API appears to be returning (I'm paraphrasing here) 123 My Street <br></br> My Town, ST 12345 <br></br> on dev, but 123 My Street My Town, ST 12345 <br></br> on production when I inspect the element. It's just weird.
  2. There's not - at one point, there's a bit of script that uses regex to remove the line breaks for use in a 'directions' link, but I haven't found anything that inserts a line break anywhere. And the directions link isn't involved in the actual address display - it's injected into a link offsite to Google proper. I'm at home right now so don't have the actual code to post - I'll try to scrub and post it tomorrow morning. And needless to say, I didn't write the original code, but it doesn't seem too difficult to follow. Of course, I say that rather glibly as I have no idea where the issue is...
  3. Hi y'all. I'm stumped on this and wondered if anybody had anything they could add or suggest. I've got a development version of a site on one server and the live version on another. Both use the same host, are using the same code, same data, same Google Maps API call, etc - everything is the same so far as I can tell. But, for some odd reason, on the dev site the address is returned with a line break between the street and city in the address. The live version does not have this break. It did until recently (like 2 weeks ago or so, I guess). I can't for the life of me figure out what that's all about, and if anyone's seen anything similar or has any ideas, I'd love to hear them.
  4. OK - I think I see what you're asking. You're going to want a change event handler for the dropdown outside the table that sets the value of the dropdown inside the table, something like this: $('#ddOutsideTable').on('change',function(e){ var curVal = $(this).val(); $('#ddInsideTable').val(val); }); Please note this is entirely untested code, so there may be a grammatical or logical err in there.
  5. Example2 doesn't have NumberInput() or NumberOutput() methods, it has numberInput2() and NumberOutput2() methods. In the constructor function, you call and instantiate a new instance of the example() class, but don't actually do anything with it. That's the class that has numberInput() and numberOutput() methods. So, when you call NumberInput() on the example2() object, the magic method __call() is catching that call to a non-existing method. If you look at the description for the __call() magic method, you'll see that the $arguments parameter is an enumerated array, which is the output you're getting. It looks like what you're attempting to experiment with is class inheritance and polymorphism. Consider the following long-winded and inane example: class Example{ /** * @var int An integer */ protected $_number; /** * Because $this->_number is protected, you can't access it directly from outside this class * This method allows the user to set the value of $this->_number * @param int $num Number * @return void * @throws Exception When the submitted value is not an integer */ public function setNumber($num){ if(!is_int($num)){ throw new Exception("That's not a number, you twink!"); } $this->_number = $num; } /** * Again, $this->_number is inaccessible. This returns the value of $this->_number to * the user. * @return int */ public function getNumber(){ return $this->_number; } } class Example2 extends Example{ /** * @var string A greeting */ private $_message; /** * This will be called every time you instantiate a new Example2() object. * It sets the value you pass into the class in the private $_message variable. * @param string $msg A greeting * @return void */ public function __construct($msg){ $this->_message = $msg; } /** * This public method will overwrite the parent class's getNumber() method and return the value * of parent::$_number plus 2. Because I felt like adding 2 to it. This is polymorphism - it serves * the same purpose as the parent method, uses the same implicit API, but returns a different value; * the calling code knows it can call this method and get something back that it can work with, but * it really doesn't care *what* it gets back. * @return int */ public function getNumber(){ return $this->_message." :: ".$parent->_number + 2; } } $class = new Example2('Well hi there! This is a number'); $class->setNumber(42); print("<p>".$class->getNumber()."</p>"); When this is run, it outputs "Well hi there! This is a number :: 44". The call to setNumber() on $class will bubble up to the parent class, where there is a method called setNumber(). Note that the Example2::getNumber() method refers to $parent->_number directly - because $_number is Example is protected, the child classes can do that. If it were private, this would cause an error and the Example2() class would have to use $parent->getNumber() from within it's own getNumber() method. Hopefully that makes some sort of sense and will help put you onto the right track. I'd also recommend checking out PHP Objects, Patterns, and Practice by Matt Zandstra - it's well written, clear, and explains a lot. Highly recommended.
  6. 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 );
  7. 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.
  8. I have absolutely no idea what you're asking, if you're even asking a question. Perhaps some further explanation would help?
  9. 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!
  10. 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.
  11. 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.
  12. Your visitor ID hidden field is named 'id', not 'visitor_id'. You'll need to change either the field name or the $_POST index.
  13. 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.
  14. 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.
  15. 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.
  16. 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...
  17. If you're wanting to play with color schemes, try out Adobe Color CC.
  18. Gathering data from a MySQL database is anything but impossible with PHP.
  19. 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.
  20. 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.
  21. 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...
  22. 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.
  23. 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.
  24. $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.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.