nrg_alpha

I used the default settings in the W3C validator (set to "automatically detect" - which has the site treated as HTML 4.01 Transitional). In any case, nothing can save that thing. It's an eternal abomination.

http://yvettesbridalformal.com/index.htm Pftt, doesn't even validate. (152 errors - 5 warnings) Fail. Bonus CSS Fail. (360 errors)

whythef***doyouhaveakid.com [ot]I thought I've seen it all... apparently not even close.[/ot]

http://gizmodo.com/5455457/airplane-hotel-gallery/gallery/1

In the event of say preg_match vs built-in functionality like str_replace, explode, etc, it's circumstancial. Typically, while regex is extremely robust and useful, it is heavier (as there is more overhead involved). Depending on the task at hand, sometimes it does make sense to use those built-in functions as opposed to regex. In reality, it appears that in most cases, the speed difference comparison between both methods won't amount to anything special (but again, it highly depends on the task at hand and the data involved). Often you'll see benchmarking tests with a loop involving thousands of iterations, and the difference between methods is so small that on a reasonable amount of looping, it will even make less of a difference (we humans won't be able to tell the speed difference). Having said that, I am personally an advocate of squeezing out performance (as a generality anyways). If the situation calls for making better use of built-in functions over regex, so be it. That's the way I'll go (or vise versa). Squeezing out extra performance juice never hurts IMO. But admittedly, the speed differences are most likely to be infinitesimal at best in most real world situations.

aeroswat, for future refernce, please don't wipe out your posts like that (don't edit out original posting content). What you initially posted may be relevant to others who may stumble upon it (or have similar issues and could possibly gain insight from your initial question / issue).

Ohhh even better.. how 'bout nested ternary operators? $test = 'one'; echo $test == 'one' ? 'one' : $test == 'two' ? 'two' : 'three'; /* Ultimately evaluates to 'two'; as the initial test for $test evaluates as 'one' * however, (in the wise words of Billy Mays "But wait! There's more!") that 'one' is now checked to see if it is in turn true... * in which case it is, thus 'two' of the final 'two' or 'three' choice is chosen. Nice way to cluster f#$k the mind. */

Yeah, I suppose... lol [ot] Hmmm.. do words like"a" and "I" make great palindromes (much like PHP )? [/ot]

Two issue though: a) I think you accidently inserted a ] in your a-z character class, and b) Your character class would suffice with zero times (due to using the * quantifier). So your pattern would be problematic in something like: $str = 'I took my dad to the bb range!'; preg_match_all('/\b([a-z])[a-z]*\1\b/i', $str, $matches); echo '<pre>'.print_r($matches[0], true); Both dad and bb will register in the $matches array. I suspect you would need to make the quantifier a + like so: [a-z]+ This would force the word to be at least 3 characters long (unless of course the OP doesn't mind matching "words" like bb, or qq, ii, etc...

Right.. sorry, the way his post was worded, I was interpreting it as suggestive of using $_POST / $_GET as opposed $_REQUEST., but I now see the context. All for naught..

Sorry, I didn't state that solution properly (now upon re-reading it). The book mentions: So I mistated the solution. So when I mentioned 'one of the solutions', I meant it was part of a series of steps.. but yeah, poorly worded on my part.. my bad. In any case, the link provided in the edit in the previous post should help shed light on the issue.

Actually CV, according to Chirs Shiflett (author of 'Essential PHP Security'), $_REQUEST is not recommended. One of the reasons is that it is susceptible to CSRF (Cross-Site Request Forgeries) attacks. CSRF is when an attacker sends arbitrary HTTP requests from the victim. The book mentions this is particularly dangerous when say the victim is always logged onto a site that sells goods and uses $_REQUEST in its form. The attacker can profile the form code, see what elements and their expected values are, and observe the overall form's behavior. Once this is figured out, the attacker tests to see if GET data can perform the same behavior as achieved by using the form normally. If so, the doors are blown wide open for the attacker to use this to his/her advantage (getting the victim to visit the set-up URL in question). One of the solutions in mitigating CSRF attacks is to use POST instead. Granted, I'm no security expert (and having not read the book in a while, it would do me good to re-read it as a refresher). EDIT - Here's an article from Chris' site regarding this issue: http://shiflett.org/articles/cross-site-request-forgeries

I think he was referring to my comment about bad variable names (like $x representing say a car budget). $x was probably a bad example, as he probably thought about using variables inside loops as counters. In hindsight, I should have used say $cb (for car budget) instead. But, like they say, hindsight has 20/20 vision.

With the use of array_slice, the last 20 entries will be retained (including their indices.. so using an array with say 25 indices, the new array will start at index 5 and go through to 24: $arr = array(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25); $last20 = array_slice($arr, -20, 20, true); echo '<pre>'.print_r($last20, true); // index 5 thru 24, with values 6 thru 25 Not sure if this is a big deal or not.. but if you want to have the indices renamed from from 0 instead, you can use array_splice instead: $arr = array(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25); $last20 = array_splice($arr, -20); echo '<pre>'.print_r($last20, true); // index 0 thru 19, with values from 6 thru 25

I suppose one way could something like: $html = <<<EOF <br>Forta +95<br>Aparare +20<br>Dexteritate +20<br> <br>Forta +70<br>Dexteritate +80<br> EOF; preg_match_all('#(?:<br>(?:Forta|Aparare|Dexteritate).*?(?=<br>))+#i', $html, $matches); foreach($matches[0] as $val){ echo $val . "<br />\n"; }