A very basic PHP syntax thing usually ignored by developers is that you can directly update current element from within the foreach loop.
Just precede value variable with & character and it will be assigned by reference:
$arr = array(1, 2, 3, 4); foreach ($arr as &$value) { $value = $value * 2; }
Read the rest of this entry »
Update notification for a commercial plug-in
WordPress CMS has a nice auto update feature that displays update notifications for outdated plug-ins and themes in admin panel. Once you got a notification you can go to Dashboard->Updates and install all updates with few clicks while WordPress will automatically download and extract archives, remove old versions and reactivate plug-ins for you.
The only problem is that it works for plug-ins published on wordpress.org which are open-source so it’s not an option for commercial plug-ins.
Luckily there is a very good solution to this problem: Upgrademe plug-in. Read the rest of this entry »
Escaping from HTML is a very cool feature of PHP because it allows easily to inject portions of dynamic content into predefined HTML template. But when you come to HTML tags with many dynamic attributes and relatively complex logic beyond them, this cool feature turns into complete disaster. If you constantly develop view templates or web page scripts then you definitely know how many times you hated starting yet another “<?php echo…” just for another attribute value.
Right, even if you strongly pretend to write clean code, multiple dynamic attributes per HTML tag, variable styles or class sets usually result in total mess of HTML and PHP which is very hard to read. This usually happens with form elements or jQuery widgets that require a lot of data converted into HTML attributes, classes and styles. Read the rest of this entry »
Recently we found that our Zend Framework based application was running into infinite loop and terminated by execution timeout on some hostings. The problem was found in Zend_Http_Client_Adapter_Socket class which uses stream_copy_to_stream if you configure Zend_Http_Client for writing data to stream.
The problem already was reported on ZF issue tracker but wasn’t fixed: http://framework.zend.com/issues/browse/ZF-9265. It seems that the cause is a bug in stream_copy_to_stream that was fixed at some point during PHP 5.2.x development.
But as we need to run our code on virtually any hosting we decided to work around this problem by replacing stream_copy_to_stream with fread and fwrite in Zend_Http_Client_Adapter_Socket code. Notice that Zend_Http_Client_Adapter_Curl is not affected by this problem as it uses internal code for writing to streams. Thus, switching to Zend_Http_Client_Adapter_Curl sounds as the easiest solution. We added automatic switching to it by checking if ‘curl_init’ function exists and if so we use Zend_Http_Client_Adapter_Curl as the adapter for Zend_Http_Client.
You may find the timestamp value returned by MySQL UNIX_TIMESTAMP() function 24 seconds grater than that returned by PHP functions and methods like strtotime(), mktime(), DateTime::getTimestamp(), Zend_Date::getTimestamp().
While testing some crawler script on GoDaddy shared hosting I noticed that the script is quitting w/o any notice at random points. Both web and CLI execution modes where affected. The script was previously tested on XAMPP server where it worked fine.
Lately, I identified that script always quits after calling one of regular expression functions (PRCE) like preg_replace, preg_match and preg_match_all. The script called them hundreds of times and one of the calls became fatal.
UPDATE: Actually it appears to be some kind of general problem with long string operations. But switching to multi-byte string regular expression functions helped in most scenarios.
Modern database driven web sites implement SEO-friendly URLs emulating static directories and files. Switching to such “clean” URLs enables good indexing by search engines, makes URLs more user-friendly and hides the server-side language. For example, this clean URL may refer to the page in some product directory:
http://somesite.com/products/network/router.html
In fact, there is no /products/network folder on the server and no router.html file at all. The page is generated by server script using database query for “network” product category and “router” product. But who calls the script and where it gets the query parameter values?
This technique is usually referred as “URL rewriting”. It allows web server to recognize what information was requested by parsing the URL string. Apache and PHP allow multiple options to implement URL rewriting. So which one is the best?
Many many years ago I learned Delphi language. It has one interesting feature not found in other languages: you don’t need return statement to specify return value for a function. Instead, you can use a pseudo-variable called Result. You can change its value many times during function execution but only the last value is returned.
That’s really a great idea! Even if your programming language doesn’t have such a built-in variable, why not to create it? Most functions actually need a variable to forge future return value, so why call it differently if we can always call it result?
Perl-compatible regular expression functions in PHP can properly work with Unicode strings. Just add /u modifier to turn on UTF-8 support in preg_replace, preg_match, preg_match_all, preg_split and other PCRE (preg) functions. This way you can parse strings with national characters. For example:
$clean = preg_replace('/\s\s+/u', ' ', $dirty);
If used without /u modifier this code damages UTF-8 encoded strings by replacing national character bytes improperly interpreted as whitespace characters. This and many other problems are caused by improper interpretation of every byte as ASCII character which is not always true for UTF-8.
The modifier is available from PHP 4.1.0 or greater on Unix and from PHP 4.2.3 on win32. UTF-8 validity of the pattern is checked since PHP 4.3.5. I found this tip as well as many other useful info on regular-expressions.info. It’s not easy to find it in the PHP documentation but it’s actually hidden here.
The Web community is going crazy about SEO-friendly URLs like http://somesite.com/products/network/router/. Well, it looks much better than a script URL http://somesite.com/products.php?c=network&p=router which may actually serve the page behind the scenes. There are a lot of good articles on how to implement SEO-friendly URLs, for example this one or my own post. But they do not warn the reader about one usual problem: once you have updated your site to handle virtual paths you will probably get a bad surprise:
CSS, image and internal page links are totally broken!
Why? Because those links are usually relative to the page location. The browser has no idea about virtual folders and tries to get files from locations relative to the page URL context. For example, if there is a usual CSS link in the page header:
<link rel="stylesheet" href="style.css" type="text/css" media="screen" />
Then the browser will try to download non-existing file http://somesite.com/products/network/router/style.css and fail silently. No CSS style will be applied.
It’s incredible how many words were spoken about SEO-friendly URLs with almost no word about this relative link problem. So, what you have to do? Don’t worry, there are multiple solutions available and I’ll try to explain them all.
