Tutorial: Get Google search terms and rank from HTTP referrer
coding.pressbin.com
coding.pressbin.com
Not only is it a pretty dull code snippet for which a combination of Google Analytics and Google Webmaster Tools would do a better job, but also the code has many flaws.
Even with the blatant SQL injection fixed there's still redundancy in the database - why store results_url separately when you can just use something like
echo '<a href="http://google.com/search?q='.htmlspecialchars($row['search_term']).'">results url</a>';
and save storing all that duplicate data for every referral?There's also no error handling - what if you get a referral from example.com/google/page.html? Boom! undefined index 'q' on line 5.
Why's $refer being stored on line 1 only to switch back to using $_SERVER['HTTP_REFERER'] again on line 3?
Why copy $vars into three separate variables at all?
And even if all this was fixed and the code was perfect, what's the point of this submission? Why's it interesting? What do we learn from this?
Again, I know complaining like this is frowned upon, but now and then I think it's useful to have some discussion about what's a good submission and what's not. If this faded out at 10 points then the system would be working. As it is it's been highly ranked for hours.
I could as well reply to your comment that that's what the downvote button is for.
These comments aren't going to be available to everyone who hits OP's site. If we're lucky, it's not a popular site and no-one will see it. If we're unlucky, the next web app you use could be coded by someone self-taught by articles like this.
As the author of the post, I'd like to respond.
When I wrote the code for this example, my main point was simply to illustrate how to extract certain useful bits of data from Google's referrer URL, and explain what they mean.
I was not intending it to be production-ready code -- that's why there's no error handling.
Indeed, as one other commenter noted, the storing of the values in a database could have been left off entirely.
What's the point of the submission, you ask? Well, Google's referrer URL uses variables that are not very intuitive. Who would know, just by looking at it, that the "cd" value represented the position at which a link appears on the Google search results page?
So I wrote this post for people who might see this referrer in their logs and want to know what it means. And while Google Analytics and Google Webmaster Tools do provide essentially the same information (and more!) there may be limited cases in which a person might want to use the information contained in the referrer URL within their script, e.g. "Hey, you searched for such-and-such. Here are some other posts you might like."
I didn't mean to offend. And I've also been guilty of releasing non-production-ready code.
And if you'd just included that kind of disclaimer clearly up front I don't think I'd have felt so compelled to comment on this.
As far as the point of the submission. Yes, I found it interesting to learn about Google's referers, but I think I'd rather have just read about that, rather than seeing the code too. It was unclear whether the article was "Hey lets deconstruct google referers" or "Hey lets play with some PHP". The former is interesting, the latter not.
Thanks for the reply.
$query_string = parse_url($_SERVER["HTTP_REFERER"], PHP_URL_QUERY);
parse_str($query_string, $vars);
$term = $vars['q'];
$rank = $vars['cd'];
$url = $vars['url'];
Correct code is even shorter.I'm thinking there are two sides to this, the first is that just like you added the 'don't use this' as an after thought the majority of the people that find your code will cut and paste it without actually reading the article, the second is that if this is your 'first approach' to keep it readable you probably have at least a few instances where you forgot to update to more solid code at a later stage because you thought 'x' or 'y' is not facing the web at the moment. And then one day someone bridges two systems and bang, security hole.
Your point on 'first approach' security holes accidentally being persisted is a good one, and I can certainly think of a few bits of code I wrote that were never meant to be secure, but could potentially be used in a larger, web-facing project at some point. Some food for thought there on perhaps never writing insecure code, even if it's just a test.
Tangential addendum: If security is Done Right, then there shouldn't be a choice between "easy to write, read and follow" and "secure".
If you have a blog where you routinely discuss topics that might come up in trivial back office code, you can probably think of a comment or email or hundred from the type of developer I'm thinking of.
Seriously, it's worth making it a tiny bit less readable to makie it copy/paste safe!
I believe that this is a false dichotomy. Good practices and separation of concerns often increase code readability. For example I think the updated version of your code with explicit parameter binding is much more readable than string concatenation.
Thanks, everyone!
here is a tutorial how to track these data directly in analytics: http://yoast.com/track-seo-rankings-google-analytics/
http://www.seomoz.org/blog/tracking-organic-ranking-in-googl...