A lot of people are familiar with PHP’s functions, and though Javascript functions are often quite similar, some functions may be missing or addressed differently. The Javascript implementations should be as compliant with the PHP versions as possible, a good indication is that the PHP function manual could also apply to the Javascript version.

http://kevin.vanzonneveld.net/techblog/

Thank you for contacting Server Support. Unfortunately 3rd party installations and configurations are not supported.

Rather than argue with the support team about what constitutes a 3rd party installation, I decided to google around and see if I could do it myself. Hours later, I succeeded. Here are the steps for installing libmcrypt:

1. su root
2. yum install gcc-c++
3. yum install lex
4. yum install libxml2
5. yum install libxml2-devel
6. yum install flex
7. wget http://downloads.sourceforge.net/mcrypt/libmcrypt-2.5.8.tar.gz?modtime=1171868460&big_mirror=0
8. tar -xzvf libmcrypt-2.5.8.tar.gz
9. cd libmcrypt-2.5.8
10. ./configure
11. make
12. make install
13. wget http://museum.php.net/php5/php-5.1.6.tar.gz
14. tar -xzvf php-5.1.6.tar.gz
15. cd php-5.1.6
16. ./configure –with-mcrypt=shared,/usr/local/lib
17. make (after running ‘make’, DO NOT RUN ‘make install’)
18. cp modules/mcrypt.so /usr/lib/php/modules/
19. Add a file /etc/php.d/mcrypt.ini
    ; Enable mcrypt extension module
    extension=mcrypt.so
20. /usr/sbin/apachectl restart

That’s it! To confirm a successful install, just run phpinfo() and look for the mcrypt section

ALTER TABLE wp_comments ADD INDEX ( comment_date_gmt );

Add &fmt=18 to the last part of the URL. You won’t see DVD quality video but you’ll see a great difference from whats currently available.

Edit: Want to make it even easier? This GM script does it for you.

Why it it so? After some investigations I came across this bug and came to the conclusion that in the Turkish language, the latin i is not equal to capital latin i.

AWESOME!

1. Navigate to the folder below (replace USERNAME with your user account).
C:\Documents and Settings\USERNAME\Application Data\Apple Computer\Safari

2. open up Preferences.plist and add the following two lines anywhere before the line “</dict>”

<key>IncludeDebugMenu</key>
<true />

3. Restart Safari and you should now have a Debug menu.

In PHP 5.2, Pearl Compatible Regular Expressions (PCRE) introduced with little fanfare a PHP setting called backtrack_limit, which, for the first time, set a limit on the number of backtracks a regular expression could perform before it stops operating and reports an error. Unfortunately, when PCRE encounters an error of this type, it doesn’t report a notice or warning or error. All it does is return NULL, something that the preg family of functions typically never does. There were a lot of entries on the PHP site reporting this behavior as a bug, and sites that are regex heavy (like Wiki sites) scrambled to figure out WTF was going on.

The only way to actually determine that this type of PCRE error took place in your code is to call preg_last_error() after you’ve tried to run your regex. Of course, before PHP 5.2, backtrack errors were handled much more gracefully (if they were even created), by returning the original string that was passed to the regex function.

To get around this backtrack limit, if you’re running regex on large pages (or really long strings) is to increase the backtrack limit in your PHP.ini settings. I increased ours from 100,000 to 1,000,000. Of course, you still run the risk of producing an error on really, really long strings, and that’s why a second step you should take is to add better error handling any place where you might run a PCRE function on a really long string. Should an error be produced, it’s up to you how to handle it, whether that be returning the original string, or breaking your string up into smaller pieces and running them separately.

Ultimately the best thing one can do (and should always to) is optimize your regex as much as possible, and for some people that just means knowing when to use regex and when a simple str_replace() will suffice.

In our PHP code, we are using the ISO-8601 week number of year, as specified on the PHP date function page, but we weren’t using ISO-8601 for the year. The ISO-8601 week number specifies the last monday of a year as the first week of the new year, if that new year begins before thursday. Intervals thought it was the first year of 2007!

In PHP, the fix was as easy as converting all instances of date(’Y') to date(’o'), according to php.net:

ISO-8601 year number. This has the same value as Y, except that if the ISO week number (W) belongs to the previous or next year, that year is used instead. (added in PHP 5.1.0)

That fixed everything on the PHP side of things. But next we had to dig into the SQL queries and get them to use the ISO Year.

Snag.

PostgreSQL 8.2.5 doesn’t support ISO Year in the Extract function. EXTRACT(ISOYEAR, timestamp) is being included in PostgreSQL 8.3, as specified here in the RC1 documentation. But PostgreSQL 8.3 hasn’t been released yet, and we needed to fix things immediately.

Our final PostgreSQL fix was to instead use the TO_CHAR(timestamp, ‘IYYY’) function. It’s not ideal to be using a string formatting function for data comparisons, because it slows down some of the queries. But we had to trade some performance to get things working properly again in the new year. As soon as the PostgreSQL developers release a stable version of 8.3, we’ll change our queries back to using EXTRACT(ISOYEAR, timestamp).