.josh

Usually you shouldn't directly access a property (even within the class. Normally you should have getter and setter methods for it defined, and they are the only methods that should directly access it. set_exception_handler('exception_handler'); function exception_handler($e) { echo "Error: ".$e->getMessage()." in ".$e->getFile()." on line ".$e->getLine(); } class FooBar { protected $_bar; public function __construct() { } public function get_bar() { return $this->_bar; } public function set_bar($bar=0) { if ( ctype_digit((string)$bar) && ($bar>=0) && ($bar<=200) ) $this->_bar = $bar; else throw new Exception('number is not within acceptable range'); } } // end FooBar $x = new FooBar(); // example 1 $x->_bar = 123; // fails // example 2 $x->set_bar(250); // fails // example 3 $x->set_bar(10); // works So in this code, I want to enforce that $_bar can only be set with a number between 0 and 200. Example 1 fails because I attempt to directly set the property when it's protected. It will give me an error like: Fatal error: Cannot access protected property FooBar::$_bar in /var/www/test.php on line 31 Example 2 fails because I throw an exception when the value doesn't match the validation. I will get an error like this: Error: Number is not within acceptable range in /var/www/test.php on line 31 Example 3 works because I have set $_bar through the setter and it passes validation. So, the reason for doing it this way is so that you have a place to enforce what kind of value $_bar can have. This goes towards what KevinM1 was saying about a "contract" between codes. This is how you can guarantee to other pieces of code that something will have an expected value or variable type or whatever. So let's say I have another method in that class that attempts to do something with $_bar but $_bar is set by someone else's code like some plugin or w/e.. I don't want my code to break, so I do this to enforce expected values. Then if someone tries to write code that sets it to something other than what I expect, they get an error and their code won't work.

You refer to it like this: $this->myvartest

There is no cut rope guaranteed method to get your emails through. Even the most prominent businesses and domains out there tell you to check your spam/junk folder if you don't receive their email, and to explicitly mark their domain as "safe" or "not junk" in your settings. But, the spam assassin tests is a good place to start.

mail goes to spam because of things like improper headers, actual content of the email, and the reputation/history of the email server that's sending the email out. It has nothing to do with the mail function.

failing and succeeding at what? Those are just the operators. You need to be more specific.

After all this time I'm still getting the impression that $i doesn't contain what you expect. So once again I tell you to echo out $enquery to see what your query string actually shows. You said you did that and it didn't echo anything out, which is kind of impossible, unless it was visually hidden because of the rest of the html layout on your page. I then asked you to ctrl+f for it in viewsource or output a js console log or alert and... near as I can tell, you just ignored me. Look, this is really simple. If it works if you hardcode a number, but doesn't work when you use $i then obviously $i doesn't contain what you expect. Either it's not getting a value, or it's getting a bad value, or maybe it's getting an id that just isn't in your table. Look at the trigger error message, where you echo out $enquery. That red stuff right there. That's your query string your sending to the db. Notice how there is no number after newsid? So, $i is not getting a value. $i is defined as an argument passed to your editnews() function. You said way back in your original post: So, assuming this code is really there and in the correct order/scope, are you including an "i" parameter on your page when you view it? e.g. mypage.php?i=123. I.. I feel like this too is something that was mentioned already.

lol I was trying to figure that out too.. I can't decide whether he's just masking for posting purposes or if it's part of some kind of weird template system or what..

Okay well FYI, this code doesn't work as expected either. Run the following: ini_set('display_startup_errors',1); ini_set('display_errors',1); error_reporting(-1); echo '<b>test1: 0<br/>'; $_GET['____']=0; if ( isset($_GET['____']) && $i=$_GET['____'] . is_int($i) ) echo 'true'; else echo 'false'; echo '<br/>'; echo 'i is: ';var_dump($i); echo '<br/><br/>'; unset($i); echo '<b>test2: 5<br/>'; $_GET['____']=5; if ( isset($_GET['____']) && $i=$_GET['____'] . is_int($i) ) echo 'true'; else echo 'false'; echo '<br/>'; echo 'i is: ';var_dump($i); echo '<br/><br/>'; unset($i); echo '<b>test3: foobar<br/>'; $_GET['____']='foobar'; if ( isset($_GET['____']) && $i=$_GET['____'] . is_int($i) ) echo 'true'; else echo 'false'; echo '<br/>'; echo 'i is: ';var_dump($i); echo '<br/><br/>'; Output: test1: 0 Notice: Undefined variable: i in /home/crayonvi/public_html/test.php on line 8 false i is: string(1) "0" test2: 5 Notice: Undefined variable: i in /home/crayonvi/public_html/test.php on line 20 true i is: string(1) "5" test3: foobar Notice: Undefined variable: i in /home/crayonvi/public_html/test.php on line 32 true i is: string(6) "foobar" With error reporting turned on, you can see you're getting the same Notice. It's coming from is_int($i) being evaluated when $i doesn't actually exist yet. Then you can see that you are getting a false negative on test 1 because 0 is being evaluated as a falsey value, even though it's legitimately an integer. Then in the 2nd one, it's getting true but not for the reason you think. It's getting true because overall $i=5.false evaluates true. This "conveniently" works out for you in this scenario, but as you can see it didn't work out in the first scenario. Well maybe you don't care about 0. So let's move on to the non-integer example #3. In #3 it's doing the same thing as before, where overall $i='foobar'.false == $i='foobar' == true. So IOW, as long as you path a truthy value to $_GET['____'], regardless of whether it's an integer, string, object, sql or xss injection code, etc.. anything that evaluates true..

I understand that the missing bracket was a typo. But when you say something works, then no, you don't get a free pass on expecting people to treat it as pseudo-code. Saying something works implies that you actually tested it and it should work. Can someone easily pick that error out and fix it? Sure. But I was nonetheless being pedantic because you were being an asshat via PM. But that missing bracket isn't really the point. The point is that you don't understand what your code is doing and yet you are arguing that it works for some unknown reason, when it fact it doesn't. "." does not allow you to put more instructions between an && when testing the TRUE of a statement. That is not what is happening at all. A dot is a concatenation operator; it joins strings together. Then you have several variable assignments going on which isn't going to work as you expect because of operator precedence. This is where things get really confusing, and honestly I don't fault you at all for not understanding wtf is going on.. it took me a good while to sort it out myself. What I do fault you is for not properly testing the code and passing it off saying it works, despite admitting you don't know what it's doing. Even if you don't know what's going on, you could have easily tested the code and seen that it doesn't work as expected, by doing exactly what I did in my last post. So here is what is happening. First, isset($_POST['str']) is evaluated, and (presumably) evaluates as true (which it does in my example where I just hardcode it to a value instead of receive a form input). Then, with this: $str=$_POST['str'] . $length=strlen($str) . $length>=15 What really happens is everything on the right side of that first equal sign is evaluated and assigned to $str and if that overall value works out to a truthy value, then overall we have an equivalent of if (true && true). Why does it work out this way? The key is the 2nd example note in the Operator Precedence entry that states even though the assignment operator has lower precedence than most other stuff, you can still use it within a condition to make the condition evaluate the value assigned to the variable. This practically flips order of operations, making the equal sign one of the highest in precedence. So, let's examine whether or not we get a truthy value from the rest of that stuff: $_POST['str'] . $length=strlen($str) . $length>=15 $_POST['str'] will have an actual value, whatever the user entered in the form. The same value evaluated in the first isset call. In my example I used a long string "aaa...". For this example I'm just going to assume it's "foobar" for the sake of space. So, so far we have "foobar" as the value being assigned to $str. At this point in time, it really doesn't matter what comes next. Even if everything else returns false or some other value, overall you have a truthy value. But let's be thorough and finish this exercise so that you may fully understand what is going on. Next, we have a concatenation operator, which means we're going to start gluing shit to the end of "foobar" to make a longer string. $length=strlen($str) is same concept as before.. we're going to evaluate strlen($str). Which is null because at this point, $str doesn't actually exist yet, and trying to pass nothing to strlen gives you null, and a Notice. So, if you had error reporting on, this would have been your first clue that something is amiss; you should have gotten something like this: Notice: Undefined variable: str in test.php on line 8 This is a Notice level error. You claim that you have all error reporting turned on except strict. So you should have seen this. Which means your error reporting settings aren't what you think it is, or else you just lied on that count. Anyways.. since this returns false, we're still sitting with "foobar" as what's ultimately going to be assigned to $str. So now we have $length=null.$length>=15. Firstly, we're actually still assigning things to $length at this point, since you have another concatenation operator between this and the last thing. So $length isn't defined at this point, so you should have received a 2nd notice: Notice: Undefined variable: length in test.php on line 8 So null.undefined is undefined, and then undefined>=15 is false, so overall, $length=false. Then that gets concatenated onto "foobar", so overall we now have... $y="foobar".false ...which effectively makes nothing get concatenated to it and thus we effectively have $str="foobar" as the 2nd expression being evaluated in the case. And since "foobar" is a truthy value, the overall condition is true. So IOW: $_POST['str']='foobar'; if (isset($_POST['str']) && $str=$_POST['str'] . $length=strlen($str) . $length>=15) if (isset('foobar') && $str=$_POST['str'] . $length=strlen($str) . $length>=15) if (true && $str=$_POST['str'] . $length=strlen($str) . $length>=15) if (true && $str='foobar' . $length=strlen($str) . $length>=15) if (true && $str='foobar' . $length=strlen(undefined) . $length>=15) if (true && $str='foobar' . $length=null . $length>=15) if (true && $str='foobar' . $length=null . undefined>=15) if (true && $str='foobar' . $length=undefined>=15) if (true && $str='foobar' . $length=false) if (true && $str='foobar' . false) if (true && 'foobar') if (true && true) if (true) Now, I hope you learned something here today. Firstly, don't just pawn something off as an answer when you don't understand what it's doing. Second, don't be a jackass about it, especially when you admit you don't understand what it's doing. But thirdly more important, I hope you now more fully understand the code and why it's wrong.

@eldan88: psycho's missing and inaccurate code is because it was a "quick and dirty, untested" example, just like he said it was. Basically there are typos and half-fleshed out ideas, which is to be expected from a quick and dirty, untested example. It was meant to be pseudo-code to give you a general idea about how you can structure your stuff in general. You're missing the forest for the trees, as the saying goes.

Really? Because this code right here: <?php switch (TRUE) case (isset($_POST['str']) && $str=$_POST['str'] . $length=strlen($str) . $length>=15): echo "string is 15 char or longer."; break; default: echo "string is shorter than 15 char."; } ?> Immediately gives the following error: Parse error: syntax error, unexpected T_CASE, expecting ':' or '{' in test.php on line 3 This isn't a "strict" error. It's a straight up syntax error, showing you are missing an opening bracket. So let's go ahead and fix that and move on and do some test shall we? First, let's use a string longer than 15 chars: <?php $_POST['str'] = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'; // 39 chars switch (TRUE) { case (isset($_POST['str']) && $str=$_POST['str'] . $length=strlen($str) . $length>=15): echo "string is 15 char or longer."; break; default: echo "string is shorter than 15 char."; } ?> Output: string is 15 char or longer. Okay, working good so far... or is it..... let's try something less than 15 chars: <?php $_POST['str'] = 'aaaaa'; // 5 chars switch (TRUE) { case (isset($_POST['str']) && $str=$_POST['str'] . $length=strlen($str) . $length>=15): echo "string is 15 char or longer."; break; default: echo "string is shorter than 15 char."; } ?> Output: string is 15 char or longer. Wait, what?? Why would it do that?!?!? Q695 I would explain why, but you already "burst my bubble" so why don't you explain why this doesn't work. Oh, right. You can't, because you think it's working. You don't know wtf it's doing, just like you said you didn't know wtf it's doing right here. I'm sorry to be harsh, but you know.. maybe you shouldn't be so quick to PM someone making snide remarks, especially when out of your own mouth you admit you don't know what's going on.

as-is there are a lot of issues with the code psycho posted. He did say it was "quick and dirty and untested". But overall it was meant to show you a better way of doing it: write individual methods for each type of validation. That way you (moreso) de-couple the logic from the data, and de-coupling is one of the major principles of object oriented programming.

Never trust someone's advice who says this. Q695 did you even run your code? Do you have all your error reporting turned off? There are all kinds of wrong in that code both logically and syntactically.

googling "php format string" gives that function as first result. googling "php format number" gives another alternative number_format. It's literally as easy as typing in exactly what you ask here. I'm not trying to be a douche and I'm trying to give you the benefit of the doubt, but I'm starting to get the impression that you're treating us like your personal google service.

sprintf dude seriously.. stop walking around in the dark. RTFM. It's one of the best manuals ever made, ever.

There are a ton built-in functions and extensions (that are often included standard) for checking string length, some that will return true or false if the string has only numbers or letters or numbers and letters only, etc.. spend a romantic evening with the manual. Here's a few links to get you started: http://www.php.net/manual/en/ref.strings.php http://www.php.net/manual/en/ref.pcre.php http://us1.php.net/ctype http://us1.php.net/mb_string

$list=<<EOL <before>http://www.soundcloud.com/artist/track<after> <before>www.facebook.com/page<after> <before>www.youtube.com/watch?v=1234567<after> <before>www.somesite.com/bla<after> EOL; preg_match_all('~<before>(?!.*(?:soundcloud|youtube))((?:https?://)?(?:www\.)?[^<]+)<after>~',$list,$urls); print_r($urls); /* output: Array ( [0] => Array ( [0] => <before>www.facebook.com/page<after> [1] => <before>www.somesite.com/bla<after> ) [1] => Array ( [0] => www.facebook.com/page [1] => www.somesite.com/bla ) ) */

Well okay, i don't really see how it's possible that your form would output but not that. Unless maybe your html markup elsewhere is causing it to be visually hidden.. look in your view-source and ctrl+f for it... or, how about echoing it to your js console or doing an alert instead.. $enquery = "SELECT * FROM news WHERE newsid=$i"; echo "<script>console.log('{$enquery}');alert('{$enguery}');</script>"; The overall goal here is to find out what $i actually contains.

yep.. wow indeed. p.s. I typo'd. content != Content. Hopefully you caught that from your pro debugging skillz.

Also, I understand it's off-putting to hear stuff like "this is php 101 basic shit" but it's also off-putting on the helper's end when someone is struggling with how to do something because they won't take the time to first learn the "php 101 basic shit". If you really want to learn how to code, take a step back and learn the basic syntax rules, how to echo things out, array structures, methods for debugging when things don't work as expected, etc.. because all of these issues you have posted have basically amounted to you not understanding php 101. And that's the point.. you aren't posting to learn php 101. You're asking for help on how to solve an issue despite you not learning the basics. We aren't really here to write code for people. Nor are we here to even handhold people through coding issues. This is a learning site. We expect people to learn things and if they get stuck, push them in the right direction. So, when you got stuck and post an issue like this and basically say "it doesn't work" and have taken no steps to figure out what the problem is, that's when we tell you to step back and learn how to figure out what/where the problem is (debugging). Not because we're being elitist pretentious douchebags pointing at the noobie, but because teaching you how to solve your own problem is more valuable than solving your problem for you. I'm sorry if that's not what you wanted to hear, but as said, this is a learning site, not a "help you bluff your way through a problem" or "do your work for you" site. If you aren't really interested in learning to code, then I suggest you hire a freelancer to do it for you, or hit up one of the rep-whore sites like Stack Overflow where people will be more than happy to show you the answer no-questions-asked for an upvote.

Try echo $data[0]['content'];

$enquery = "SELECT * FROM news WHERE newsid=$i"; echo $enquery; This doesn't output anything?

Fair enough. Okay then, echo out $enquery and see if $i contains what you expect.

Sounds like your mysqli_connect is failing. Put some error reporting around that.

Okay, there are a number of issues wrong still. You need to work on your debugging skills. Start at the beginning. - You have a form, and you click submit. What is the first thing your script does? It checks to see if $_POST['submit'] is set. So, put print_r($_POST); above that condition and see what you are getting. Do you see that it is being set? From this, you can see that there is no $_POST['submit'] in the array dump. - Look at your form. Did you typo something somewhere? Look closely, you can see that you did name"submit" when it should be name="submit" - Now that that is sorted, what does your script do next? It assigns some posted values to some variables and then calls your method. Is there a typo in the $_POST indexes? Is there a typo in the variable names? Is there a typo in the method or argument passed? A typo in the method name you call?Yes. You made the change to your method name, but didn't change the name where you are calling it. - Now examine your method. Are you sure it's receiving the values (even if they are empty)? echo out something in your foreach like "foreach called". Are you sure the condition is working as intended? echo out "condition triggered". Are you sure $errors is being set with something? echo out $errors (before you return it). Is return even in the right place? This isn't so much an error but a matter of "sense": technically this part is right in that it will return an error on first error encountered. However, your implied intention vs. your code don't seem to match up. You make $errors an array as if you want to return multiple errors, one for each field. But you have a generic message in it and return on first error. You need to pick one style or the other. If you want to just return a generic message on first error, ditch making it an array. But if you want a specific error message for each element, make the message specific, e.g. "{$field} is empty". In order to do that, you will also need to pass the element names (the post keys) to your function, not just the values). - Now go back to where you called the method. You returned a value from your method. Are you doing anything with it? No. You just called the function and returned a value but you didn't assign the returned value to anything. Instead, you just echo'd out $errors. That's not how returned values and variables within functions work. There is scope to variables within functions. The code that called your function doesn't know anything about the variable you set in the function. Therefore you need to assign the function call to a variable, or else echo out the function call: $errors = $form_validation->validate_fields($fields); echo $errors; // or echo $form_validation->validate_fields($fields); - Is the error now outputting when something is empty? Maybe? If you had changed $errors to just be a string instead of array within your validation method, you should see the error echo'd now. But as-is, you should be seeing "Array". That's because you assigned it as an array, not a string, and that's what you get when you try to echo an array. So now we're back to the generic message vs. specific message debate. If you want to just output a generic message on any error, go back and change it to be a string instead of array (remove the []). If you want a list of error messages to be returned, you need to check if the array has error messages and output them accordingly, e.g. : $errors = $form_validation->validate_fields($fields); // example: implode them to a string to echo, where each message is on a separate line. if (count($errors)>0) echo implode("<br/>",$errors); Okay, so this was a lot of typing, so I hope you take the time to use this to learn how to fish for yourself (debug), instead of just fix the problem and then ask for more fish. If you have an issue, walk through your code one line at a time. Figure out what you are expecting and output what you can to validate that you get what you are expecting. Also, while developing, turn on all error reporting. There are a number of issues that would have displayed errors as clues if your error reporting had been turned on properly. Put this at the top of your code: ini_set('display_startup_errors',1); ini_set('display_errors',1); error_reporting(-1);