2011-02-04 24 views
14

Chúng tôi phải di chuyển khoảng 50+ Ứng dụng (nhỏ/lớn) tới PHP 5.3 (từ PHP 4.1). Có một số người có kinh nghiệm với một nhiệm vụ như vậy không?Trải nghiệm của bạn Di chuyển PHP 4 sang PHP 5

  • Thời gian cần thiết
  • cụ
  • thiết lập tốt nhất cho môi trường (Servers/thử nghiệm?)

Liệu nó có ý nghĩa để di chuyển đầu tiên PHP 5.2? Có cách nào để tự động phát hiện các ứng dụng bằng cách sử dụng "Tính năng PHP 4" mà không làm việc trong PHP 5?

Tôi không biết cách xử lý một dự án như vậy. Cảm ơn!

+3

Erm .... chúc may mắn. – sevenseacat

Trả lời

6
  1. Một số cú pháp cho các lớp học đã thay đổi giữa PHP4 và PHP5 - ví dụ, trong PHP4, phương pháp xây dựng được đặt tên giống như các lớp, trong khi trong PHP5, các nhà xây dựng được đặt tên __construct().

    PHP5 vẫn có thể đối phó với các định nghĩa lớp PHP4, vì vậy mã của bạn có khả năng vẫn hoạt động, nhưng bạn vẫn nên thay đổi chúng theo kiểu mới, vì có rất nhiều tính năng mà bạn sẽ không có thể sử dụng khác. Ngoài ra, tất nhiên, cú pháp cũ sẽ bị xóa cuối cùng; các lớp học PHP4 của bạn sẽ phá vỡ trong tương lai, vì vậy tốt hơn để thay đổi chúng ngay bây giờ thay vì chờ đợi cho đến khi nó khẩn cấp.

  2. Hình cầu. Bạn nên đã sử dụng $_REQUEST, $_POST, $_GET$_COOKIES trong PHP4, rất nhiều mã cũ hơn có thể vẫn đang sử dụng các hình cầu tự động kiểu cũ đã được chuẩn hóa bằng PHP3. Đây là một rủi ro bảo mật lớn, vì vậy nếu bạn vẫn đang sử dụng register_globals, bạn nên bắt đầu làm việc trên mã của mình ngay bây giờ để ít nhất sử dụng $_REQUEST thay thế cho mọi địa điểm bạn đã sử dụng tự động toàn cầu. Điều này có thể hành động là một nhiệm vụ rất khó khăn - khó có thể tìm kiếm thông qua một ứng dụng lớn đang cố gắng tìm ra các biến được dự định là các hình cầu và không, khi không có gì trong mã để chỉ ra một cách hay cách khác . Lấy nó từ một người đã phải làm điều này, nó có thể là một cơn ác mộng thực sự. Nhưng đây không phải là điều cụ thể để chuyển sang PHP5 - như tôi đã nói, ngay cả khi bạn gắn bó với PHP4, bạn thực sự cần phải giải quyết vấn đề này. PHP5 không thay đổi bất cứ điều gì, ngoại trừ cờ register_globals hiện được đặt mặc định là bị tắt, điều này có thể cung cấp cho bạn nhiều động lực hơn để thực sự thực hiện công việc này.

  3. Nếu bạn sử dụng bất kỳ chức năng regex ereg_ nào, những chức năng này sẽ không được chấp nhận. Bạn nên thay thế chúng bằng các hàm preg_ tương đương. Đây không phải là một nhiệm vụ lớn, và trên thực tế các chức năng vẫn có sẵn, do đó, nó có thể chờ đợi, miễn là bạn chuẩn bị bỏ qua các cảnh báo cho bạn biết chức năng không được chấp nhận. Nhưng một lần nữa, như với cú pháp lớp, có thể hợp lý khi xem xét thay đổi chúng ngay bây giờ.

  4. Một tính năng khác đã thay đổi, trong đó cú pháp cũ không được dùng nữa là tính năng tham chiếu.Trong PHP4, chúng tôi được khuyến khích sử dụng ký tự & trong lời gọi hàm để chuyển các biến theo tham chiếu. Trong PHP5, cách thực hiện đúng là đặt ký tự & vào khai báo hàm chứ không phải là nơi bạn gọi nó. Một lần nữa, cú pháp cũ vẫn hoạt động, nhưng chỉ khi bạn có thể đưa ra cảnh báo về việc ném PHP vào bạn khắp nơi.

+0

Đó là __construct, chứ không phải __constructor. Cũng đáng nói đến là superglobals rất cũ ($ HTTP_POST_VARS, vv) đã không được chấp nhận trong PHP 4 (ủng hộ $ _POST, vv) và tôi không nghĩ rằng chúng còn tồn tại nữa trong PHP 5. –

+0

@ Daniel15 - oops trên '__construct()'; cảm ơn vì đã phát hiện ra nó, tôi đã chỉnh sửa câu trả lời. Re superglobals cũ - chúng vẫn tồn tại; không được chấp nhận, nhưng vẫn ở đó cho thời điểm này. Tuy nhiên, chúng không phải là superglobals, vì vậy chúng không hoạt động như '$ _POST' vv Và chúng sẽ bị loại bỏ tại một thời điểm nào đó trong tương lai, vì vậy không nên sử dụng chúng ngay bây giờ. – Spudley

3

Nếu bạn bật error_reporting và đặt thành E_ALL thì bạn sẽ có thể thấy lỗi không được chấp thuận, v.v. Tôi sẽ không bận tâm nhắm mục tiêu PHP5.2 và sau đó là 5.3.

Tùy thuộc vào việc bạn chỉ muốn ứng dụng hoạt động hoặc bạn muốn tận dụng các tính năng mới của PHP và cải tiến hiệu suất. Nếu họ chỉ cần làm việc thì chỉ sửa lỗi và bỏ qua các cảnh báo E_DEPRECATEDE_NOTICE.

Nếu các dự án được viết theo cách khá bắt đầu thì không quá khó để nâng cấp chúng.

Đó không phải là để nói rằng nó sẽ không phải là một công việc nhàm chán và gian khổ khủng khiếp. Nó cũng sẽ mất nhiều thời gian hơn bạn mong đợi; đặc biệt cho 50 ứng dụng!

11

Điều quan trọng nhất cần đọc là the php.net section on migrating from PHP 4 to PHP 5. Kể từ khi PHP 5 xuất hiện lần đầu tiên, họ đã chuyển sang ngôn ngữ khắt khe hơn (PHP sẽ ở chế độ nghiêm ngặt theo mặc định trong phiên bản 6), vì vậy bạn sẽ thấy một cảnh báo lot nếu không có lỗi.

Đã có nhiều tương thích ngược phá những thay đổi được thực hiện từ PHP 5.0 ra mắt, cho đầy đủ bạn cũng nên đọc:

Migrating from PHP 5.0.x to PHP 5.1.x

Migrating from PHP 5.1.x to PHP 5.2.x

Migrating from PHP 5.2.x to PHP 5.3.x

Tôi nhận ra đó là một rất nhiều đọc, nhưng đó phải là một danh sách toàn diện của tất cả mọi thứ có thể phá vỡ.

5

Trước hết bạn nên kiểm tra cài đặt php.ini, đặc biệt là register_globals, magic_quotes_gpc - nó có thể phá vỡ logic của ứng dụng của bạn.

6

PHP_CompatInfo có thể giúp bạn kiểm tra một số phụ thuộc. PHP_CodeSniffer có thể với việc tìm kiếm các cấu trúc đã lỗi thời.

Tuy nhiên, sự khác biệt giữa các phiên bản PHP thường được vinh hiển. Không bao giờ có nhiều vấn đề với mã dựa trên các trường hợp rìa. Trừ khi tất nhiên mã này vẫn dựa trên các siêu dài $ HTTP_POST_VARS, sau đó một vài gotchas khác được mong đợi.

Một thành ngữ hữu ích để thay thế magic_quotes phụ thuộc ví dụ là:

$_POST = array_map("mysql_real_escape_string", $_POST); 

Bởi vì thực tế hầu hết các ứng dụng không bao giờ viết lại để sử dụng các API cơ sở dữ liệu hiện đại hơn.

3

Tắt display_errors, bật log_errors, thiết error_reporting để -1 và tìm ra cho E_STRICTE_DEPRECATED cảnh báo.

This migration script (plug shameless) có thể giúp bạn với một số điều không được chấp nhận. Nó nói 5,2-5,3 nhưng có thể hữu ích cho việc di chuyển từ 4 quá. Và bạn có thể mở rộng nó (các bản vá chào mừng :) cho những thứ bạn khám phá thường xuyên gặp phải.

PHPStorm IDE có trình phân tích mã khá tốt, có thể chỉ ra một số vấn đề tiềm ẩn trong mã của bạn. Cung cấp cho nó một chạy qua ứng dụng của bạn và xem nếu nó có một cái gì đó thú vị để nói. Ngoài ra, nó có thể giúp bạn tìm nhanh các lỗi có thể theo sau khi sử dụng từ khóa mới làm tên hàm, v.v.

Câu hỏi cuối cùng của bạn: IMHO bạn nên đi với 5.3, thực hiện công việc hai lần.

+0

Lý tưởng nhất, bạn nên tắt 'display_errors' trên trang web sản xuất. – Spudley

+0

@Spudley về lý thuyết, vâng, nhưng bạn sẽ ngạc nhiên khi có bao nhiêu lời phàn nàn như "E_STRICT đã phá vỡ máy chủ sản xuất của tôi" Tôi đã nghe. Mọi người bỏ qua lời khuyên này như không có ngày mai. – StasM

Các vấn đề liên quan