Có đáng nâng cấp lên phiên bản PHP 7.0 mới không? – Nó chắc chắn có giá trị, thậm chí đừng nghĩ về nó - hãy tiếp tục!
Phiên bản thứ bảy có khá nhiều đổi mới. Những cái chính:
- Lõi PHP 7 sử dụng PHPNG. Lõi mới giúp các trang web tăng hiệu suất lên 40%;
- gõ Gợi ý và trả về giá trị. Bây giờ, khi khai báo một hàm, bạn có thể chỉ định kiểu riêng của hàm đó cho từng biến, cũng như kiểu dữ liệu mà hàm sẽ trả về. Các loại có sẵn: int, float, string và bool;
- toán tử so sánh kết hợp và nhiều hơn nữa.
Một số tiện ích mở rộng đã bị xóa trong PHP 7:
- mysql
Đã có trong PHP 5.6.x việc sử dụng các phần mở rộng này là điều không mong muốn. Thay vì "mysql", bạn nên sử dụng "PDO" và thay vì ereg → preg .
Bạn có thể tìm hiểu thêm về các sản phẩm PHP 7 mới trên trang chính thức
Có đáng nâng cấp lên PHP 7 không?
Hiện tại, điều dễ nhất bạn có thể làm để cải thiện hiệu suất trang web là nâng cấp lên PHP 7.0.x. Tốc độ tăng cũng phụ thuộc vào cách viết dự án của bạn. Nếu bạn vẫn còn nghi ngờ, hãy đưa ra một số so sánh:
Điểm chuẩn PHP 5.6 so với PHP 7đối với một số khung (khung Zend, Magento, Drupal, Mediawiki, WordPress, Laravel, SugarCRM, v.v.):
Đối với tất cả các khung, hiệu suất đạt được là đáng kể. Hãy xem mọi thứ diễn ra như thế nào với các hàm và cấu trúc kernel:
Điểm chuẩn PHP 5.6 so với PHP 7 cho các hàm và cấu trúc kernel:
Nếu các biểu đồ thuyết phục bạn, bạn có thể thử di chuyển trang web của mình sang phiên bản PHP mới và cảm nhận lợi ích từ một dự án thực sự.
Các đồng nghiệp từ Elasticweb cho biết rằng trước khi tung ra một máy chủ mới với PHP 7, họ đã khởi chạy một dự án lớn của chính phủ về nó chạy trên Laravel 5. Đây là một dạng thử nghiệm hiệu năng của phiên bản PHP mới và toàn bộ máy chủ. Trước đây, dự án này nằm trên máy chủ có PHP 5.6. Sau khi di chuyển trang web, các trang bắt đầu mở nhanh hơn đáng kể, đồng thời mức sử dụng tài nguyên giảm đi một nửa.
Để chuẩn bị cho việc chuyển sang PHP 7, họ đã sử dụng Báo cáo hỗ trợ di chuyển PHP 7 (MAR). Hầu hết các CMS/Framework phổ biến đều đã tương thích với PHP 7, vì vậy nhiệm vụ chính là kiểm tra các plugin tùy chỉnh.
WordPress 4, Drupal 8/7 và phiên bản mới nhất của Joomla đã sẵn sàng cho PHP 7!
Vì vậy, bạn có một trang web cũ nhưng rất thân thiết, bạn quyết định vì tiếc nuối (hoặc có lẽ sau khi đọc lại Habr) để chuyển sang PHP7. Quá hào hứng mong đợi hiệu suất sẽ tăng lên đáng kể, bạn loại bỏ trang web kém của mình và dứt khoát chuyển đổi phiên bản PHP trong bảng điều khiển lưu trữ của mình.
Nếu trang web không còn non trẻ thì khả năng cao là điều kỳ diệu sẽ không xảy ra. Tốt nhất, tất cả các loại lỗi sẽ bắt đầu xuất hiện, và tệ nhất, bạn sẽ thấy một màn hình trắng, thế giới phát triển web. Lúc này, bạn muốn nhanh chóng chuyển mọi thứ trở lại và quên đi điểm yếu đột ngột của mình.
Nhưng hãy giả sử rằng điểm mạnh của bạn là sự kiên trì và bạn cũng có chút thời gian để thử nghiệm. Hãy cố gắng khắc phục mọi thứ.
Sao lưu
Chúng tôi tạo bản sao lưu của trang web (đồng thời là cơ sở dữ liệu). Suy cho cùng thì ai không sao lưu đều là kẻ thù của chính mình phải không? Đối với các loại thử nghiệm khác nhau, việc thêm một trang web khác trên máy chủ lưu trữ và sao chép các tệp mà bây giờ chúng tôi sẽ chỉnh sửa vào đó là điều hợp lý.
Nhật ký lỗi
Hãy định cấu hình ghi lỗi PHP trong tệp .htaccess (nếu nó chưa được cấu hình trước đó):
php_value display_errors 0
php_value log_errors 1
php_value error_log /home/vasya/domains/mysite.ru/logs/error.log
Làm việc với MySQL
Giả sử trang web sử dụng cơ sở dữ liệu và bạn thấy các lỗi như sau:
Lỗi nghiêm trọng: Lỗi chưa bắt được: Gọi tới hàm không xác định mysql_connect()
Điều này là do trong các phiên bản PHP hiện đại (bắt đầu từ PHP 5.5.0), phần mở rộng MySQL gốc không được hỗ trợ. Các nhà phát triển khuyên bạn nên sử dụng MySQLi hoặc PDO. Hãy thử chuyển sang MySQLi, thật dễ dàng:
Giả sử rằng trang web được viết bằng cách sử dụng cách tiếp cận thủ tục, đây là mã shit cổ điển và hiện được nhiều người coi là giải pháp ngắn gọn và hiệu quả. Trong trường hợp này, cấu trúc cũ sau đây để kết nối với cơ sở dữ liệu:
$link = mysql_connect('localhost', $user, $password)
mysql_select_db($dbname, $link)
mysql_query('đặt tên cp1251')
có thể được thay thế bằng:
$link = mysqli_connect('localhost', $user, $password, $dbname)
mysqli_query($link, ‘đặt tên cp1251’)
cho các truy vấn:
$result=mysql_query($query,$cid)
thay thế bởi:
$result=mysqli_query($cid, $query)
Các chức năng phổ biến khác có thể dễ dàng được thay đổi thành đối tác 'i' của chúng:
mysqli_fetch_array()
mysqli_fetch_row()
mysqli_fetch_assoc()
mysqli_fetch_array()
mysqli_num_rows()
mysqli_insert_id()
mysqli_close()
Nhờ các bước đơn giản này, dữ liệu từ cơ sở dữ liệu sẽ được thu thập và gửi thành công.
Mã hóa
Trường học cũ thực sự là trang web trong CP1251 (ít nhất). Mọi thứ đã biến thành kim cương hay những con dê khác chưa?
Rất có thể, chỉ cần chỉ định mã hóa trong .htaccess như thế này là đủ:
php_value default_charset "cp1251"
Biểu thức chính quy
Bạn cũng có thể thấy các lỗi thuộc loại sau:
Cảnh báo: preg_replace(): Công cụ sửa đổi /e không còn được hỗ trợ, thay vào đó hãy sử dụng preg_replace_callback
Điều này có nghĩa là công cụ sửa đổi /e, cho phép bạn chuyển kết quả của biểu thức chính quy sang một hàm tùy ý, không còn được hỗ trợ. Trong những trường hợp như vậy, nên sử dụng hàm preg_replace_callback
Giả sử chúng ta có một biểu thức chính quy như thế này:
$string=preg_replace(“/:((1,10)):/e”, “print_smile('\\1')", $string)
với sự thay thế cho preg_replace_callback, nó sẽ trông như thế này:
$string=preg_replace_callback(“/:((1,10)):/”, create_function('$matches', 'return print_smile($matches)'), $string)
ở đây mọi thứ đều đơn giản, biểu thức chính quy hiện được chỉ định làm đối số đầu tiên (tất nhiên không có từ bổ nghĩa /e) và đối số thứ hai, một hàm ẩn danh được chỉ định (sẽ được thực thi sau khi áp dụng biểu thức chính quy) với hai đối số : mảng $matches, nơi dữ liệu sẽ được lưu trữ, khớp với biểu thức chính quy và gọi một hàm bên ngoài bằng các đối số. Trong ví dụ này, hàm bên ngoài được gọi là print_smile và lần xuất hiện đầu tiên được tìm thấy sẽ được chuyển cho hàm đó dưới dạng đối số. \\1 trong preg_replace (lần xuất hiện đầu tiên được tìm thấy) sẽ trở thành $matches (nếu có nhiều đối số hơn, thì sẽ có $matches, $matches, v.v.).
Đây là một ví dụ khác, phức tạp hơn:
Nó giống như thế này:
$out=preg_replace(“/<(=[\’\»]{0,1}|)(.*?)([\’\»]{0,1})>(.*?)<\/>/es", "feed_out_sub_rm('\\2′,'$base_prefix','$nick','$id_entry')", $out)
Nó đã trở thành như thế này:
$out=preg_replace_callback('/<(=[\’\»]{0,1}|)(.*?)([\’\»]{0,1})>(.*?)<\/>/s', create_function('$matches', 'return Feed_out_sub_rm($matches, "'.$base_prefix.", "'.$nick.", "'.$id_entry.") '), $out )
Rất dễ bị nhầm lẫn trong các trích dẫn ở đây, hãy cẩn thận.
Đi sâu vào các biểu thức chính quy, chúng ta có thể nhớ lại hai hàm nữa được coi là lỗi thời (và không được hỗ trợ) kể từ PHP 5.3.0. Các triệu chứng như sau:
Lỗi nghiêm trọng: Lỗi chưa bắt được: Gọi hàm không xác định ereg_replace()
Nếu biểu thức chính quy trong ereg_replace đơn giản thì bạn có thể nhận được bằng cách đặt các ký tự ranh giới, như sau:
$str=ereg_replace("[\r\t\n]", "",$str)
$str=preg_replace(“/[\r\t\n]/”,””,$str)
Triệu chứng tương tự:
Lỗi nghiêm trọng: Lỗi chưa được phát hiện: Lệnh gọi hàm không xác định chia()
$var_pair=split("=",$tmp)
$var_pair=explode("=",$tmp)
Nếu biểu thức chính quy phức tạp hơn thì chúng tôi sẽ thử chuyển đổi nó thành preg_split.
Nếu có điều gì đó không ổn hoặc trường hợp của bạn hoàn toàn không giống với ví dụ của chúng tôi, hãy viết nhận xét và chúng ta sẽ cố gắng cùng nhau tìm ra giải pháp.
Để để lại nhận xét về bài đăng, hãy đăng nhập bằng tài khoản của bạn trên mạng xã hội VKontakte/FaceBook hoặc tài khoản Google/Yandex của bạn.
Một vài ngày trước, tôi đã chuyển máy chủ của mình với khoảng 30 trang web sang PHP 7. Một số trong số đó khá cũ và tạo thành nhiều loại framework và CMS khác nhau. Dưới đây là một số lời khuyên dành cho những người chưa quyết định có nên chuyển sang PHP 7 hay không.
Hãy bắt đầu với thực tế là tôi hiểu rằng có nhiều người không coi phiên bản ổn định là thực sự “ổn định” cho đến khi nó trưởng thành hơn một chút, mong rằng sẽ vẫn còn một số lỗi hoặc không tương thích. Từ những gì tôi đã thấy cho đến nay, việc thử từng ứng cử viên phát hành ngay khi nó được phát hành, việc chuyển sang PHP 7 ngay khi nó được phát hành là hoàn toàn an toàn. Tôi chưa bao giờ nhận thấy bất kỳ hành vi kỳ lạ hoặc sự cố nào mà không phải lỗi của tôi. Mặc dù thực tế đây là một phiên bản mới nhưng nó không mang lại nhiều thay đổi không tương thích, nghĩa là nhìn chung, bạn có thể coi nó như PHP 5.7, chỉ nhanh hơn nhiều.
Và tốc độ thực sự ấn tượng, thậm chí không thể tin được. Ví dụ: một trang web đơn giản trên PHPixie hoạt động nhanh hơn gần gấp ba lần, gần như bằng tốc độ của Phalcon trên PHP 5.6, một số trang web trên Wordpress cho thấy tốc độ tăng ổn định lên gấp hai lần. Nếu bạn xem xét báo cáo gần đây của Google rằng ngay cả việc giảm 10% hiệu suất tải trang cũng dẫn đến mất khách hàng đáng kể, thì nếu bạn có thể dễ dàng tăng tốc trang web của mình lên một nửa chỉ bằng cách cập nhật PHP, bạn sẽ nhận được nhiều doanh thu hơn mà không phải tốn bất kỳ chi phí nào. Hãy nhớ điều này khi bạn thuyết phục người quản lý của mình chuyển sang PHP 7. Không có gì thuyết phục tốt hơn khối lượng bán hàng.
Một vài lưu ý
Sự mở rộng mysql không còn khả dụng nữa, vì vậy nếu bạn chưa chuyển sang PDO hoặc mysqli thì bây giờ bạn chắc chắn phải làm vậy. May mắn thay, trong nhiều trường hợp, chỉ cần thay thế các cuộc gọi đến mysql_ chức năng trên mysqli_.
E_STRICT lỗi được phân loại lại thành các loại lỗi khác. Nếu trước đây bạn đã giấu chúng hoặc bỏ qua chúng thì bây giờ chúng sẽ bắt đầu xuất hiện cùng với những thứ khác. Ví dụ: việc gọi các phương thức không tĩnh bây giờ sẽ ném E_KHÔNG DÙNGđã tạo ra một loạt vấn đề với Joomla 2.5 mà vì lý do nào đó điều này xảy ra khá thường xuyên. Ngoài ra, sự kế thừa không tương thích hiện được phân loại là E_CẢNH BÁO. Wordpress đã được thử nghiệm để hoạt động với PHP 7 kể từ tháng 2, vì vậy không có vấn đề gì với bản thân nó, tuy nhiên, một số plugin hóa ra không tương thích.
cho mỗi bây giờ luôn hoạt động với một bản sao của mảng, do đó, bất kỳ thay đổi nào đối với mảng trong quá trình lặp sẽ không ảnh hưởng đến chính lần lặp đó. Trên thực tế, trong nhiều trường hợp, nó vẫn hoạt động và bản thân trường hợp này khá hiếm, nhưng tôi vẫn bắt gặp nó ở một trong các plugin.
Hiện nay $foo->$bar["baz"]được dịch là ($foo->$bar)["baz"] nhưng không $foo->($bar["baz"]) như trong PHP 5. Đây là một trường hợp hiếm gặp, nhưng nó cũng xảy ra ở một trong các plugin và hóa ra là trong Magento 1.x ( core/Pháp sư/Core/Model/Layout.php).
Hãy nhớ rằng không phải tất cả các tiện ích mở rộng đều hỗ trợ PHP 7 nữa. Tôi không còn có thể sử dụng XCache yêu thích của mình, thứ đã phục vụ tốt cho tôi trong nhiều năm.
Tổng cộng, tôi mất khoảng 5 giờ để chuyển tất cả các trang web sang PHP 7. Quá trình này không hề khó khăn và các gói đã có sẵn cho tất cả các bản phân phối phổ biến. Vì vậy, ngay cả khi bạn đang chờ bản phát hành ổn định (không lâu nữa), không có lý do gì để không chuẩn bị trước cho việc di chuyển trang web của bạn.
Có đáng nâng cấp lên phiên bản PHP 7.0 mới không? - Chắc chắn là xứng đáng, thậm chí đừng nghĩ về điều đó - hãy tiếp tục!
Phiên bản thứ bảy có khá nhiều đổi mới. Những cái chính:
- Lõi PHP 7 sử dụng PHPNG. Lõi mới giúp các trang web tăng hiệu suất lên 40%;
- gõ Gợi ý và trả về giá trị. Bây giờ, khi khai báo một hàm, bạn có thể chỉ định kiểu riêng của hàm đó cho từng biến, cũng như kiểu dữ liệu mà hàm sẽ trả về. Các loại có sẵn: int, float, string và bool;
- toán tử so sánh kết hợp và nhiều hơn nữa.
Các tiện ích mở rộng đã bị xóa trong PHP 7:
- mysql
Các tiện ích mở rộng bị xóa từ lâu đã ở trạng thái "không được dùng nữa"; việc sử dụng chúng dẫn đến cảnh báo hiển thị trên màn hình. Thay vì "mysql", bạn cần sử dụng "mysqli" hoặc "pdo_mysql" và thay vì "ereg" => "preg_*".
Bạn có thể tìm hiểu thêm về các sản phẩm PHP 7 mới trên trang chính thức.
Có đáng nâng cấp lên PHP 7 không?
Hiện tại, điều dễ nhất bạn có thể làm để cải thiện hiệu suất trang web là nâng cấp lên PHP 7.0.x. Tốc độ tăng cũng phụ thuộc vào cách viết dự án của bạn. Nếu bạn vẫn còn nghi ngờ, hãy đưa ra một số so sánh:
Điểm chuẩn PHP 5.6 so với PHP 7đối với một số framework và CMS (Zend framework, Magento, Drupal, Mediawiki, WordPress, Laravel, SugarCRM, v.v.):
Đối với tất cả các khung, hiệu suất đạt được là đáng kể. Hãy xem mọi thứ diễn ra như thế nào với các hàm và cấu trúc kernel:
Nếu các biểu đồ thuyết phục bạn, bạn có thể thử di chuyển trang web của mình sang phiên bản PHP mới và cảm nhận lợi ích từ một dự án thực sự.
Khi tạo nút, chọn "Blue" trong danh sách máy chủ để nút được tạo trên máy chủ có PHP 7.
Đây là cách bitrix 1c hiển thị dựa trên ổ SSD và PHP 7.0
Tôi quyết định viết về chuyển sang PHP 7, vì hiện tại tôi đang bận dịch mã của một công cụ bằng PHP 7. Và vì vậy, trước hết, chúng tôi bật trình gỡ lỗi hoặc trình gỡ lỗi trong bảng quản trị của trang web, nếu bạn chưa có thì bạn có thể làm như trong topic: , lúc này trên màn hình điều khiển chúng ta thấy các thông báo lỗi, ví dụ như thế này:
Cảnh báo: preg_replace(): Công cụ sửa đổi /e không còn được hỗ trợ, thay vào đó hãy sử dụng preg_replace_callback - dir/file.php (số dòng)
Thông báo này nói rằng công cụ sửa đổi e không tồn tại trong PHP 7, bạn nên loại bỏ nó, nhưng nếu bạn chỉ loại bỏ công cụ sửa đổi này, tập lệnh có thể không thực thi chính xác, không dễ để viết nó ở đó. Tôi sẽ cho bạn xem mã ví dụ từ PHPFOX 3(khi tôi viết lại mã: ), hãy làm điều này:
Ví dụ: thông báo lỗi của chúng tôi trỏ đến dòng sau:
$sStr = preg_replace("/\.+?\[\/x\]/ise", """.stripslashes(\$this->_parseUserTagged("$1")).""", $sStr);
Nó nên được thay đổi như thế này:
$sStr = preg_replace_callback("/\.+?\[\/x\]/is", function($match) ( return Striplashes($this->_parseUserTagged($match)); ), $sStr);
Ở đây chúng tôi đã thay thế chức năng preg_replace(), TRÊN preg_replace_callback(), đã xóa công cụ sửa đổi e trong đối số đầu tiên, vốn là một biểu thức chính quy. Đối số thứ hai đã được thay thế bằng một hàm ẩn danh sẽ được thực thi sau khi áp dụng biểu thức chính quy. Hàm ẩn danh chứa một mảng $match, các phần tử của mảng thay thế các kết quả khớp, ví dụ: nó là: $1, bây giờ là: $match ; là: $2, bây giờ: $match, v.v. Đã xóa dấu ngoặc kép và ký tự thoát (dấu gạch chéo ngược \).
Để kết luận, về lỗi không tồn tại từ bổ nghĩa e, tôi sẽ đưa ra một vài ví dụ khác về việc thay thế mã. Đường kẻ:
$aRow["value_actual"] = preg_replace("/s:(.*):\"(.*?)\";/ies", ""s:".strlen("$2").":\" $2\";"", $aRow["value_actual"]);
Thay đổi nó như thế này:
$aRow["value_actual"] = preg_replace_callback("/s:(.*):\"(.*?)\";/is", function($match) ( return "s:" . strlen($match) . ://" . $match . "";" ), $aRow["value_actual"]);
Và một ví dụ với một biến trong biểu thức chính quy, dòng:
$sTxt = preg_replace("/\[" . $sBbcode . "=(.*?)\]/ise", """.\$this->_replaceBbCode("" . \$sBbcode . "", "tiền tố ", true, "$1")."", $sTxt);
Thay thế như thế này:
$sTxt = preg_replace_callback("/\[" . $sBbcode . "=(.*?)\]/is", function($match) use($sBbcode) ( return $this->_replaceBbCode($sBbcode, "tiền tố ", true, $match); ), $sTxt);
Ở đây, chúng tôi đã thêm hàm use(), trong đó chúng tôi đã đặt một biến từ biểu thức chính quy, từ đó chuyển biến đó sang hàm ẩn danh. Nếu có nhiều hơn một biến trong một biểu thức chính quy, thì chỉ cần liệt kê chúng cách nhau bằng dấu phẩy, ví dụ:
hàm($match) sử dụng($a, $b, $c)
Hàm không dùng nữa ereg_replace()
Theo báo cáo của trang web chính thức của PHP: http://php.net/:
Hàm này KHÔNG ĐƯỢC DÙNG kể từ PHP 5.3.0. Rất khuyến khích không nên dựa vào tính năng này.
Và trong PHP 7 họ hoàn toàn quên mất nó... Bạn có thể nhận được thông báo lỗi sau:
Lỗi nghiêm trọng: Lỗi chưa bắt được: Gọi hàm không xác định ereg_replace()
Chức năng này nên được thay thế bằng preg_replace(), làm theo ví dụ dưới đây. Giả sử chúng ta có dòng mã này:
$str = ereg_replace("[^ -<>-)]", " ", str_replace("\x00", " ", $origincommentname));
Hãy thay đổi mã như thế này:
