با این کلاس در واقع همون امکانات DateTime رو به اضافه پشتیبانی از تقویم‌ها و زبان‌های مختلف دارید. برای مثال:

$date = new IntlDateTime('now', 'Asia/Tehran', 'persian', 'fa');
echo $date->format('yyyy/MM/dd'); // ۱۳۸۹/۰۲/۱۰
echo $date->format('E dd LLL yyyy'); // جمعه ۱۰ اردیبهشت ۱۳۸۹

نحوه کارش مشابه کلاس DateTime هست با تفاوت های زیر:

1. پارامتر اول علاوه بر رشته میتونه timestamp و یا یک شی از نوع DateTime باشه.
2. در پارامتر اول کاراکترهای عددی به هر زبانی میتوانند باشند. یعنی اگر رشته شما شامل اعداد فارسی یا عربی یا ترکیبی از اونها و یا هر زبون دیگه ای که باشه با این کلاس بدون مشکل کار میکنه. (این قسمت رو به لطف کلاس NumberFormatter که یکی دیگه از امکانات intl هست نوشتم )
3. برای پارامتر دوم به جای شی DateTimeZone میشه از رشته هم استفاده کرد.
4. پارامتر سوم نوع تقویم رو مشخص میکنه که میتونه Buddhist, Chinese, Coptic, Ethiopic, Gregorian, Hebrew, Indian, Islamic, Islamic-Civil, Japanese, Persian, Taiwan باشه. (دم ICU گرم فکر کنم فقط تقویم مایاها رو یادشون رفته پیاده کنن!)
5. پارامتر چهارم زبانه برای مثال میتونه fa ، fa_IR ، en ، en_US ، en_UK و … باشه
6. یکی از سختی های کار با کلاس IntlDateFormatter اینه که باید حتما pattern تاریخ رو مشخص کنید ولی کلاس IntlDateTime در اکثر مواقع خودش میتونه pattern رو تشخیص بده و برای موارد خاص که pattern توسط کلاس قابل تشخیص نباشه باید خودتون pattern رو به عنوان پارامتر پنجم بدید.
7. برای استفاده از متد format باید pattern رو به فرمتی که ICU قبول میکنه بدید. برای استفاده از فرمت خود php  از متد classicFormat استفاده کنید.
8. متد فرمت timezone هم به عنوان پارامتر دوم قبول میکنه (بدون تغییر timezone داخلی شی)
9. کلاس IntlDateFormatter با تایم زون هایی که DST دارن مشکل داره که من توی IntlDateTime رفعش کردم.
10. تنها اشکالش اینه که با تاریخ های خارج از محدوده timestamp کار نمیکنه که به عنوان باگ برای IntlDateFormatter گزارش دادم. (آپدیت: این مشکل هم رفع شد.)
11. متد modify تاریخ رو مطابق با تقویمی که ست شده ویرایش میکنه (مثلا برای تاریخ امروز +1 month رو اگر روی تقویم میلادی اجرا کنی 30 روز و اگر روی تقویم هجری شمسی اجرا کنی 31 روز تاریخ رو جلو میبره)
12. با متد setCalendar و setLocale تقویم و زبان رو میتونید عوض کنید که مثلا برای تبدیل تاریخ از میلادی به شمسی و بالعکس کاربرد داره.

یک تعداد testcase هم براش نوشتم که برای آشنایی با طرز کار کلاس میتونین یک نگاهی بهش بندازین. البته هنوز تستهاش کامل نیست. بعدا اگه فرصت کنم کاملش میکنم.

همونطور که گفتم این کلاس فقط روی php 5.3 به بعد کار میکنه اگر دنبال کدی میگردید که روی php 5 هم کار کنه یک کلاس دیگه نوشتم (اینجا) که البته محدودیت هایی نسبت به این کلاس داره (در حال حاضر فقط تقویم فارسی و میلادی رو ساپورت میکنه ولی قابل گسترش برای سایر تقویم ها هست. از الگوی factory استفاده میکنه و بعد از ایجاد شی دیگه تقویم قابل تغییر نیست.)

همه‌ی اینها رو گفتم که بگم اگر نسخه‌ی php روی لوکال آپدیت بود زودتر متوجه مشکل می‌شدم و این همه وقت صرف پیدا کردنش نمی‌شد. البته دلایل دیگه ای هم میتونید برای آپگرید کردن php روی لوکال داشته باشید.

حال و حوصله نصب php از سورس رو نداشتم، تازه هر موقع نسخه جدید میومد باید دوباره کامپایل میکردم. این apt هم بد جوری ما رو بد عادت کرده.

یه سرچ کردم سایت dotdeb.org رو پیدا کردم. به لطف apt به سه سوت php آپگرید شد و هر موقع هم که آپدیت جدید بیاد به یک سوت میتونم آپگریدش کنم.

به قول جادی به نظر شما این سیستم عامل زیبا نیست؟

یکی از راهکارهای افزایش سرعت لود شدن سایت استفاده از فشرده سازی gzip هست که میتونه 60 الی 80 درصد حجم صفحات رو کاهش بده. البته استفاده ناصحیح از gzip میتونه باعث بروز مشکلات و یا حتی کند شدن سایت بشه. چگونگی استفاده موثر از این راهکار موضوعیست که در ادامه این بحث به اون خواهیم پرداخت.

قبل از هر چیز از نصب بودن اکتنشن zlib روی php مطمئن بشید. این extension امکان استفاده از فشرده سازی gzip رو به php اضافه میکنه.

ساده ترین راه برای فشرده سازی صفحات سایت استفاده از گزینه ی output_compression هست. اکستنشن zlib این امکان رو به شما میده که با فعال کردن output_compression از طریق php.ini و یا .htaccess خروجی فایل های php خود رو فشرده کنید. برای مثال یک فایل .htaccess روی سرور خود می سازید و خط زیر رو درون این فایل ذخیره میکنید:

مزیت این روش اینه که بدون نیاز به تغییر در برنامه در صورتی که مرورگر از gzip پشتیبانی کنه خروجی تمام صفحات php فشرده میشه. ولی این روش اشکالاتی داره از جمله اینکه فقط خروجی فایلهای php شما فشرده میشه و فایلهای دیگه نظیر html و css و js فشرده نمیشه. و اشکال دیگه ای که داره اینه که عملیات فشرده سازی هر بار که یک صفحه صدا زده میشه، انجام میشه و امکان کش کردن خروجی سمت سرور وجود نداره و چنانچه سرور ضعیف و سایت پر بازدیدی داشته باشید مقدار قابل توجهی بار پردازشی روی سرور اعمال میکنه.

روش دوم استفاده از ob_gzhandler به عنوان output_handler هست که همون مزایا و معایب روش فوق رو داره. البته ob_gzhandler رو هم از طریق htaccess یا php.ini و هم به عنوان callback برای ob_start در برنامه میشه استفاده کرد.

نحوه استفاده از ob_gzhandler در فایل .htaccess :

php_flag output_buffering on
php_value output_handler ob_gzhandler

نحوه استفاده از ob_gzhandler به عنوان callback برای ob_start :

<?php
ob_start("ob_gzhandler"); // place this line of code at the start of your files
?>
…

در صورت استفاده از htaccess و یا php.ini در هر یک از دو روش فوق، توجه داشته باشید که نباید در برنامه خروجی با انکدینگ gzip ارسال نمایید در غیر این صورت محتوای صفحه دو بار انکد شده و فاتحه سایتتان خوانده می شود.

ضمنا همونطور که گفته شد از دو روش فوق فقط برای فشرده سازی خروجی فایلهای php میشه استفاده کرد و برای فشرده سازی فایلهای css و js و html باید خودمون دست به کار بشیم.

ابتدا از روش اولی که گفته شد برای فشرده سازی خروجی php استفاده میکنیم.
حالا برای فایلهای css و js و html باید کدی بنویسیم که نام یک فایل رو بگیره، محتوای فایل رو بخونه و به خروجی بفرسته. نیازی نیست ما فایل رو فشرده کنیم، بقیه کارها رو خود php انجام میده. برای این منظور فایلی به نام compressor.php در root سایت ایجاد می کنیم که نام فایلی که باید فشرده بشه رو از طریق GET دریافت کنه. ضمنا حتما باید پسوند فایل رو توی برناممون چک کنیم تا مشکل امنیتی پیش نیاد.

1
2
3
4
5

<?php
if (!preg_match('/\.(js|css|html|htm)$/i', $_GET['file'])) die('Access Denied');
if (!file_exists($_GET['file'])) die('File Not Found');
readfile($_GET['file']);
?>

حالا به نظر میرسه که این کد باید بدون مشکل کار کنه. اما در عمل ممکنه باعث بروز مشکلاتی از قبیل کاهش سرعت، افزایش مصرف پهنای باند و افزایش مصرف cpu هم بشه. و علتش هم اینه که بدون استفاده از این کد وقتی یک نفر از سایت شما دیدن میکنه تمام فایل های استاتیک در مرورگر کش شده و در مراجعات بعدی مادامی که تغییر نکرده باشند از کش خونده میشن. این در حالیست که با استفاده از این کد در واقع فایل های استاتیک شما به فایل های دینامیک تبدیل شده و هر بار از سرور لود میشن.

برای رفع این مشکل باید کدی بنویسیم که تاریخ آخرین تغییرات فایل رو هم به مرورگر بفرسته در این صورت دفعات بعد که مرورگر فایل رو از سرور درخواست کنه تاریخ آخرین نسخه موجود در کشِ خودش رو هم به سرور میفرسته و ما میتونیم این تاریخ رو با تاریخ فایل مقایسه کنیم و در صورت یکسان بودن به مرورگر بگیم که از همان نسخه موجود در کش استفاده کند.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?php
if (!preg_match('/\.(js|css|html|htm)$/i', $_GET['file'])) die('Access Denied');
if (!file_exists($_GET['file'])) die('File Not Found');
 
$mtimestr = gmdate("D, d M Y H:i:s", filemtime($_GET['file'])) . " GMT";
if (@$_SERVER['HTTP_IF_MODIFIED_SINCE'] == $mtimestr) {
header('HTTP/1.1 304 Not Modified');
die();
}
 
header("Last-Modified: " . $mtimestr);
header("Cache-Control: must-revalidate", false);
readfile($_GET['file']);
?>

در نهایت برای اینکه از بار پردازشی سرور کم کنیم میتونیم از کش سمت سرور هم استفاده کنیم. یعنی فایل های فشرده شده رو روی سرور ذخیره کنیم و مادامی که فایل تغییر نکرده از کش استفاده کنیم. البته این کار پیچیدگی های خاص خودش رو داره. چون در این صورت باید فایل رو خودمون فشرده کنیم و فشرده سازی خودکار رو غیر فعال کنیم. که در این صورت باید قبل از gzip کردن بررسی کنیم که آیا مرورگر از gzip پشتیبانی میکنه یا نه. شاید فکر کنید که این کار لزومی نداشته باشه، چون تقریبا اکثر مرورگر ها از gzip پشتیبانی میکنند، ولی اینطور نیست. به عنوان مثال IE به صورت پیش فرض در صورت استفاده از proxy از HTTP 1.0 استفاده میکنه و gzip رو پشتیبانی نمیکنه.

و البته یک راه دیگه هم برای فشرده تر کردن فایل های js و css وجود داره و اون حذف کامنت ها و فاصله های اضافی از درون کد هست.

در رابطه با این دو مورد آخر برای مشاهده نمونه کد میتونید به سورس jsmart compressor مراجعه کنید.

خوب حالا برنامه ما آماده هست، باید تمام لینک هایی که در سایت به فایل های css و js و html هست رو تغییر بدیم و به جاش لینکی به فایل compressor.php قرار بدیم که نام فایل مورد نظر هم به صورت پارامتر بهش پاس شده باشه. کاره طاقت فرسایی هست و شاید غیر ممکن.

برای اینکه نیاز به تغییر در کدهای فعلی سایتتون نداشته باشید از ماژول mod_rewrite آپاچی کمک می گیریم. یعنی با استفاده از یک rewrite rule تمام request هایی که به فایل های css و js و html ارسال میشه رو به فایل compressor.php می فرستیم.
با این حساب محتوای فایل .htaccess یه چیزی شبیه به این میشه :

1
2
3
4
5
6

php_flag zlib.output_compression on
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*\.(js|css|htm|html))$ compressor.php/?file=$1
</IfModule>

البته برای اینکه این rule با rule های دیگه ای که در برنامه ها برای تبدیل لینک های php به html استفاده میشه تداخل پیدا نکنه یک condition هم بهش اضافه کردیم تا فقط درمورد فایل هایی که وجود خارجی دارند این rule عمل کنه.

تموم شد.
امیدوارم مفید بوده باشه

عمده ترین مشکل در بروز رسانی از نسخه 4 به 5 تداخل شناسه های برنامه شما با شناسه ها و یا کلمات کلیدی جدید در php5 هست که با تغییر نام دادن اون شناسه مشکل حل میشه. برای مثال تداخل نام کلاس soapclient در nusoap با کلاس soapclient در php5.
بهترین راه برای پیشگیری از وقوع اینگونه تداخل ها استفاده از namespace در نام گذاری کلاس ها و توابع است. یعنی از انتخاب نام های عمومی برای شناسه ها خودداری کنید و مثلا حروف اختصاری نام خودتون یا شرکتتون رو به عنوان پیشوند یا پسوند در نام گذاری شناسه استفاده کنید. مثلا بهتر بود که به جای نام soapclient از نام nu_soapclient استفاده میشد.

و اما مشکل دیگه ای که من برخورد داشتم این بود که در php5 در حالت CLI (خط دستور) دایرکتوری جاری با مسیر فایل php یکسان نیست و اگر بخواهید فایلی رو include کنید و یا با فایل ها کار کنید باید حتما قبلش chdir کنید به مسیر مورد نظر. جالب اینجاست که این تغییر در php5.2.4 مجددا به حالت قبل برگشته است.

مشکل دیگه ای هم که من بعد از بروز کردن به php 5.2 داشتم و ساعت ها وقت من رو گرفت این بود که در صورت استفاده از ob_start با callback چنانچه output buffering بدون استفاده از توابع مربوطه خاتمه یابد درون تابع callback نمیتوان از یک آبجکت که قبلا تعریف شده استفاده کرد.
این مشکل بیشتر شبیه به یک باگ هست تا تغییر ورژن. لذا من بعد از کلی کلنجار رفتن با این مشکل به قسمت گزارش باگ در سایت php رفتم و با یک سرچ متوجه شدم که این مشکل ناشی از اینه که در ورژن جدید بعد از خاتمه کد اول آبجکت ها destroy میشن بعد بافر خالی میشه. پس برای رفع این مشکل تنها راه اینه که قبل از خاتمه برنامه خودمون بافر رو خالی کنیم. برای اطلاعات بیشتر در مورد این مشکل اینجا رو کلیک کنید.

و اما مشکلی که در آخرین بروز رسانی به php 5.2.4 پیش اومد. اینکه در حالت CLI عنصر SCRIPT_FILENAME از آرایه سراسری $_SERVER مقدار نداره. (در مورد سایر عناصر تست نکردم شاید اونها هم تغییر کرده باشه)
و اما تغییر دیگه ای که تو این نسخه بود و قبلا بهش اشاره کردم اینکه در حالت CLI دایرکتوری جاری مجددا در این ورژن با مسیر فایل php یکسان شده.

البته این ها فقط مواردی بود که من برخورد داشتم و تغییرات بیشتر از این حرفهاست.

معمولا خود سایت php برای تغییرات در نسخه های ماژور، سرفصلی در php manual باز میکنه. که موارد زیر از آن جمله اند:

http://www.php.net/manual/en/faq.migration5.php
http://www.php.net/manual/en/migration5.php
http://www.php.net/manual/en/migration51.php
http://www.php.net/manual/en/migration52.php

برای نسخه های مینور هم میتونید به ChangeLog مراجعه کنید.