- This topic is empty.
-
AuthorPosts
-
July 31, 2014 at 9:49 am #177121__Participant
I think I’ve left something in from before.
I think so too. The bits of code I described above should not be added to your existing script; I was only describing the changes I made. I understand not wanting to copy+paste (and I would normally agree), but in this case, you should simply replace your working scripts, in their entirety, with the ones from the new gist.
July 31, 2014 at 11:18 pm #177164AnonymousInactiveGreetings Traq,
Well, I found out what the problems were. I wasn’t getting the latest contact page to show because I was putting the updated one into the wrong file on the server. Second, I wasn’t putting the proper closing on the definitions in the coding.
It is working and the message is appearing on the form page.
Two problems:
1) Using the back button the form can be sent again.
2) Anything can be entered in the from e-mail box, even without an @ sign.I will be leaving in a few hours and will return (hopefully) tomorrow.
Best Regards.
August 1, 2014 at 12:35 am #177165__ParticipantAnything can be entered in the from e-mail box, even without an @ sign.
At some point,
type=text
was added to the email field. I didn’t notice this when I updated the gist. It should betype=email
; I have corrected it.This relies on the browser to validate the value as an email address, which not all browsers support. For user experience, we can add a javascript fallback. This is not strictly necessary, however, because we do validate the value on the server.
!!
We did uncover another bug, here: ourvalidate
method checks all the submitted values, but returns true/false based on on whether the anti-spam question was valid. I thought we had coded a validation “flag” which kept track of the validation state. I’m changing thevalidate
method like so:public function validate( array $_post ){ // if the token is missing, or the honeypot is full, // we conclude the submitter is either a spambot or an attacker if( empty( $_post["token"] ) || ! empty( $_post["required"] ) ){ $this->_spamTrap(); return false; } // check if the provided token is valid if( ! $this->_validateToken( $_post["token"] ) ){ return false; } // validation flag $v = true; // validate each form field foreach( $this->_validation as $field=>$validation ){ // missing values might simply be optional $value = isset( $_post[$field] )? $_post[$field]: ""; // trim whitespace? if( $this->_option["value.trim"] ){ $value = trim( $value ); } // try any validation methods foreach( (array)$validation as $method ){ $methodName = "_validate{$method}"; if( is_callable( array( $this,$methodName ) ) && ! $this->$methodName( $value,$m ) ){ // $m is a _reference_ {@see http://php.net/references}, // which validation methods will use to provide our error messages. $this->_errors[$field] = $m; // set validation flag to false $v = false; // discard the invalid value $value = ""; // stop checking if any validation fails break; } } // if the submitted value was valid, we'll keep it. // if it was invalid, then it will have been replaced with an empty string. $this->_values[$field] = $value; } // save antispam for last, since legitimate users will sometimes miss it // (give them a chance; we don't want to discard an otherwise valid form submission) if( isset( $_post["spam"] ) && $this->_validateAntispam( $_post["spam"] ) ){ // submission was good! return $v; } // submission was bad. return false; }
Note the variable
$v
, which is initiallytrue
(meaning “valid”). If any of the form fields are invalid, we change$v
tofalse
(meaning “invalid”). Then, we return$v
at the end to indicate whether validation was successful or not.Using the back button the form can be sent again.
The user can submit the form again, yes. Preventing this is impractical because the browser saves the previously filled-out form data in its history (which is, normally, a useful thing to do).
However, duplicate submissions are ignored (because the unique token has already been used, the submission is not processed again; the script simply returns a new, blank form in its place). You won’t receive multiple emails unless the user actually makes the effort to fill out the form multiple times.
August 2, 2014 at 10:07 pm #177376AnonymousInactiveGreetings Traq,
I finally got everything in its place, it appears, as the form is working and the success message appears where the form initially is.
I want to look at the code and Google some things to try to understand the latest additions. I’ll get back here later today for more.
Best Regards.
August 3, 2014 at 5:01 am #177409serenade76Participant“Contact form” is a good one
August 4, 2014 at 10:24 pm #177655AnonymousInactiveGreetings traq,
Earlier you mentioned creating a template for the message or have it include its own HTML and skip the template. You stated the latter would be easier.
I assume that the message isn’t responsive to styling added to the div it appears in given it is PHP, am I correct? I’m pleased with the message appearing on the contact page, but would like it to be a little fancier and styleable.
Sorry for the delay, but I’ve been looking over this thread to review and have been Googling the codes to try to understand what they do and why.
Best Regards.
August 4, 2014 at 11:31 pm #177658__ParticipantAlright. One change: in the class definition, in the
htmlMarkup_userNotice
method, change this line:'<p class="cform notice">'.htmlspecialchars( $this->_notice ).'</p>':
to
'<div class="cform-notice">'.$this->_notice.'</div>':
Now, you can put HTML markup into the messages, and it will be printed as normal HTML, and not escaped as text. For example:
protected $_notice_failure = "Sorry; there was a problem. Please try again.";
can now be changed to include HTML, like
protected $_notice_failure = <<< HTML <p class=fancy> <strong>Sorry!</strong> You've caught us on a bad day. <code>The server <span style="color:red;">caught on fire!!!</span> <em>Try again tomorrow, kthxbye</em></p> HTML;
Make sure your HTML is correct, since this approach does not allow us to validate it before printing it to the webpage.
August 4, 2014 at 11:57 pm #177664AnonymousInactiveGreetings traq,
I missed that it was a
<p class="">
Therefore, why can’t it be styles using something like
.cform notice { text-align: center; color: red; }
in the protected CSS Rules?
Best Regards.
August 5, 2014 at 12:41 am #177668__ParticipantYou could do that also/instead, yes.
You’d only need to make those changes to the
htmlMarkup_userNotice
method if you wanted to also use HTML markup inside the message itself.August 5, 2014 at 12:50 am #177670AnonymousInactiveI’m a bit lost on what you mean by
You’d only need to make those changes to the
htmlMarkup_userNotice
method if you wanted to also use HTML markup inside the message itself.I prefer making changes in the CSS and not using HTML markup withing the message.
I tested the .cform notice CSS as I queried earlier and it didn’t work. I’m not sure why.
Many Thanks!
August 5, 2014 at 3:34 am #177682AnonymousInactiveFollow up to previous:
I do believe that is supposed to be
p.cform notice {
but in any event it doesn’t work either.August 5, 2014 at 8:59 am #177711AnonymousInactiveI found the problem, a silly and obvious mistake on my part. There needs to be a hyphen or something to style the messages.
This won’t work:
`
p.cform notice {
text-align: center;
color: red;
}
`
This will:
`
p.cform-notice {
text-align: center;
color: red;
}
`
Now to have variable answers to the anti-spam question, such as Green, green, & 12, Twelve, twelve.
Many Thanks Traq!
August 5, 2014 at 11:14 am #177747__ParticipantI found the problem, a silly and obvious mistake on my part. There needs to be a hyphen or something to style the messages.
That’s actually something I changed in our last post. Sorry for the confusion. Previously, it was
class="cform notice"
—two class names— which you would select like.cform.notice
(no space). After changing it, it isclass="cform-notice"
—one class name— which, as you figured out, is selected like.cform-notice
.I prefer making changes in the CSS and not using HTML markup withing the message.
Well, we didn’t need to make that last change at all, then. But it doesn’t hurt anything, and gives you the flexibility if you want to add HTML in the future.
Now to have variable answers to the anti-spam question, such as Green, green, & 12, Twelve, twelve.
First, for any questions that you want to have multiple answers, we’ll just add all acceptable values as an array.
protected $_antispam = array( // instead of this: //"What is 1+1?" => "2" // we'll do this: "What is 1+1?" => array( "2","two" ) // etc. ... );
When you define values, it is best to use all lowercase letters (see below*).
Then, in order to use that, we need to change the validation method. In
_validateAntispam
, find this line (~398):&& $this->_antispam[$_SESSION[__CLASS__]["antispam"]] === $value
and change it to:
&& in_array( $value, (array)$this->_antispam[$_SESSION[__CLASS__]["antispam"]] )
What we’re doing here is, instead of making sure the provided value matches, we’re making sure it matches one of the values in the array of acceptable answers.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~
* I am also adding another option: case-insensitivity. This way, “two” or “Two” or “tWo” (etc.) will all validate. If you don’t want it, set the property$_options["value.ci"]
tofalse
.Inside the
validate
method, we’ll add this:if( $this->_option["value.ci"] ){ $value = mb_strtolower( $value ); }
This isn’t really a big change, so don’t worry too much about it. It’s something I probably should have thought of when we wrote it in the first place.
The gist is up-to-date. It should work just fine, but I haven’t had a chance to test it yet. I’ll get back to you on that, or let me know if you find any problems.
August 5, 2014 at 10:51 pm #177857AnonymousInactiveGreetings traq,
No, the fault is mine as not having the space is obvious. In order to have the text styled in CSS as I chose instead of the HTML as you proposed, there needed to have something between .cform notice which I should have realized.
Is it Ok for me to use display: table-cell; in the CSS for the notice text? I want to be able to center the text vertically and I don’t believe it can be without using that. I’ve tested it and it appears to work fine.
I’m getting a strange reaction to the page with the addition of
// case insensitive? if( $this->_option["value.ci"] ){ $value = mb_strtolower( $value ); }
After the form is submitted the “success page” is shifted down as if there is something unseen added above it.
I haven’t made changes to the antispam yet.
Best Regards.
August 5, 2014 at 11:02 pm #177859__ParticipantIs it Ok for me to use display: table-cell; in the CSS for the notice text?
Not sure if you’d have any problems… it’s well-supported, however. I would think it would be okay.
After the form is submitted the “success page” is shifted down as if there is something unseen added above it.
This might be an error message, unseen because of the css on your page. Do [right click]->”view source”. Likely at the very top.
Did you also make the appropriate addition to the
$_option
property? I think I glossed over that detail, but I did make the change in the gist.protected $_option = array( "append" => "IP", "token.max" => 1800, "token.min" => 2, "value.trim" => true, "value.ci" => true //<--- this one );
Let me know if you can’t figure it out (give a link).
-
AuthorPosts
- The forum ‘Other’ is closed to new topics and replies.