In diesem Tutorial inkl. Beispiel, Screenshots & PHP-Code zum Thema ' Einfache AdSense Optimierung' wird Schritt für Schritt erklärt, wie man verschiedene Versionen von AdSensen-Werbung mit einem PHP-Script abwechselnd auf seiner Homepage einblenden lässt und wie man mit dem Standard-AdSense-Interface auswertet, welche dieser Versionen am meisten Geld einbringt.
One of the best things about PHP is that it's a great language to just "dive into", thanks to its wide-ranging popularity. Anyone with the ability to hit "Search" on Google can quickly create a program. However, this also lends to a major criticism of PHP: it's almost too easy to find and reproduce bad code.
Here are 10 PHP mistakes that any programmer, regardless of skill level, might make at any given time. Some of the mistakes are very basic, but trip up even the best PHP programmer. Other mistakes are hard to spot (even with strict error reporting). But all of these mistakes have one thing in common: They're easy to avoid.
Take the time and make sure that your PHP is secure, clean and running smoothly by checking your site for these common PHP blunders.
There are a shed-load of ways to “eval()” code without actually calling the eval() function — usually done simply to avoid the use of the dreaded “evil()” function, but often times because the system has eval() disabled using “disable_functions” in php.ini
Here are some PHP mistakes I’ve encountered, which have often been very difficult to track down…
The @-operator is often used to silence errors in noisy PHP functions—functions that generate warnings that can not be easily prevented. An example might be to silence network errors with stream_socket_client(), or hiding connection errors for mysql_connect(). In those cases, there is no way how to check up-front whether the function call will not issue a warning when being called (unlike fopen() where you could first call file_exists() for example).
When a language is defined by its implementation rather than a standard, it can sometimes be tricky to decide what should be considered correct behaviour and what should be considered an implementation bug.
What follows isn’t so much a PHP trick as a fix for something that really should work, but doesn’t. Although the manual implies that the behaviour described below is specific to Zend Engine 1, all my tests were performed against Zend Engine 2.2, PHP 5.2.5.
Array notation is fine, but it can look a bit clunky when you’re working with complex structures. This is a fairly simple example, but I’m sure we’ve all dealt with worse: ...
So I've had enough of different PHP versions compiled in different modes (ZTS or DEGBUG) and having to change the php.ini file every now and then on my dev machines. So I added conditional INI support ...
Despite the proliferation of debugging tools, especially real-time debuggers, “debugging by print statement” remains the most common form of debugging in most programming languages. It’s especially important when you run into a fatal error on a production server that you can’t use a real-time debugger on, display_errors is Off, and you can’t take the server down to test something (which is the only place that the most critical bugs appear, according to Murphy). Of course, even if you can hide debug statements throughout the code without the user knowing you still need to know which is which in order to trace code execution. (You wouldn’t believe the number of times I’ve had to do that to deal with weirdly configured servers.)
It's gotten a bit more complex; The proxy handler didn't pass all the client headers to the proxy server. This caused problems with having the wrong client type, no Etag caching, cookie passing, etc. Here's the current rev, which solves a lot of these issues.
The cookie handling was broken because I wasn't using cookies on my back-end app. My SSO implementation was caching the cookies to the back-end server in the session.
