WordPress 및 PHP 8 – 호환성 및 이점!

대부분의 기술 괴짜는 PHP 8.0에 열광하고 있으며, 확실히 이번에는 변경 사항이 엄청납니다. 모든 사람이 PHP 8의 호환성, 구성, 이점 등을 이해하는 데 시간을 할애할 것입니다. 무엇보다도 가장 큰 질문 중 하나는 “WordPress가 이미 PHP 8과 호환됩니까? 그렇지 않다면 어떤 조치가 필요한지."

글쎄요, PHP 8이 출시되자마자 우리의 전문가 시간은 가장 깊은 수준의 테스트에 뛰어 들었고 그 결과는 누구에게나 충격을 줄 수 있습니다! 예, 우리는 이제 모든 것을 알고 있으며 우리의 보고서와 시음 결과를 자랑스럽게 생각합니다.

모든 것이 변경된 것을 보여줄 뿐만 아니라 PHP 8로 업데이트해야 하는지 여부에 대한 순수한 조언도 제공합니다.

PHP 8의 많은 주요 변경 사항: 하지만 왜?

PHP 8은 PHP의 거대한 업데이트이며, 최근의 부 버전 범위에서 주 버전의 네거티브를 제거하는 것이 일반적입니다. 화제가 된 PHP 8의 경우 이전 7.* 버전에서 몇 가지 주요 변경 사항이 축소되었습니다.

따라서 수년에 걸쳐 세심하게 업데이트된 프로젝트의 경우 저하된 API를 수정하는 경우 업그레이드가 전혀 어렵지 않아야 합니다. 사실, PHP 7.* 버전은 이전 버전의 PHP와 달리 훨씬 더 많은 사용 중단을 확인했습니다.

PHP 5.6에서 PHP 7로의 마이그레이션은 매우 간단했지만 7.x에서 8로의 이동은 특히 사용 가능한 여러 플러그인 외에도 WordPress를 포함한 이전 코드베이스의 경우 다소 고통스러울 수 있습니다.

확실히 형식이 좋은 코드베이스나 최신 PHP 버전이 있는 최신 코드베이스의 경우 큰 문제가 발생하지 않습니다. 그러나 현실은 WordPress가 그런 코드베이스가 아니라는 것입니다.

WordPress는 이미 PHP 8과 호환됩니까?

솔직히 말해서 WordPress는 이미 PHP 8과 호환되지만 해당 단어를 봉인하는 것은 불가능합니다. WordPress는 항상 최신 버전의 PHP와 호환되는 것을 목표로 합니다 . 그러나 이 가이드의 뒷부분에서 가장 큰 우려 사항을 자세히 분석했습니다.

우리는 사용 가능한 전략을 사용하여 찾을 수 있는 대부분의 호환성 문제에 대한 완벽한 수정 사항을 찾는 것과 관련하여 놀라운 작업을 수행했습니다. 우리는 모든 것이 무엇이고 그들과 함께 존재하는 문제에 대해 더 깊이 파고들 것입니다.

어떤 성능 변경 사항이 있습니까?

PHP 8에 포함된 잠재적으로 흥미로운 주요 기능은 JIT(Just In Time) 컴파일 및 디버깅입니다. 아시다시피 PHP는 해석된 언어입니다. 즉, 실행될 때 기계어로 번역됩니다.

JIT는 자주 사용되는 코드를 추적하고 기계어 번역을 최적화하여 재사용할 수 있도록 합니다. 이제 이것은 주어진 기능에 대한 엄청난 성능 향상을 가져올 수 있습니다.

JavaScript와 같은 다양한 언어에 JIT가 포함되면서 역사적으로 새로운 애플리케이션이 폭발적으로 증가했습니다. 예를 들어, JS에서 실행되는 가상 머신은 웹 초창기에 상상할 수 없었을 것입니다. 과거에는 서버에 모듈을 설치해야 했던 몇 가지 작업이 핵심 PHP 라이브러리를 사용하여 실용적으로 될 것입니다.

당분간 WordPress와 같은 웹 앱의 실제 성능 향상은 최소화됩니다. 그 외에도 개발자 또는 일반 WordPress 사용자가 이 새로운 기능의 이점을 누리기까지는 엄청난 시간이 걸립니다.

개발자의 삶을 편하게 해주는 몇 가지 다른 새로운 기능이 있습니다. 대다수가 여러 WordPress 사이트에서 여전히 사용 중인 PHP의 이전 버전과의 호환성을 깨뜨릴 것이기 때문에 이러한 것들이 가까운 장래에 WP 테마 및 플러그인에 사용되지 않을 것입니다.

WordPress 사이트용 PHP를 업데이트하는 방법은 무엇입니까?

이 가이드에서는 가장 중요한 것은 WordPress 사이트를 손상시키지 않고 PHP를 최신 버전으로 얼마나 편리하게 업데이트할 수 있는지 설명합니다.

경로를 알고 싶다면 현재 PHP 버전을 확인한 다음 WordPress를 최신 버전으로 업데이트하십시오. 그런 다음 "one.com PHP 스캐너"를 설치하고 스캔을 실행하여 잠재적인 문제를 수정하십시오. 또한 PHP를 최신 버전으로 업데이트하고 사이트가 예상대로 작동하는지 확인하십시오.

전체 과정을 보여드리겠습니다.

1단계: 현재 PHP 버전 확인

처음에는 현재 실행 중인 PHP 버전을 확인해야 합니다. phpinfo 페이지에서 웹사이트의 현재 PHP 버전 정보를 얻을 수 있습니다.

cPanel에서 실행 중인 경우 cPanel에서 PHP 버전 을 보고 변경하는 방법 문서에서 PHP 버전을 볼 수 있습니다.

PHP 버전 7.3 이상을 사용하는 경우 모든 것이 정상입니다. PHP 7.2를 사용하는 경우 업데이트가 필요합니다. 2단계까지 소중히 해주세요.

2단계: WordPress를 최신 버전으로 업데이트

오작동을 피하려면 WordPress 코어와 모든 플러그인 및 테마가 최신 버전으로 업데이트되었는지 확인하십시오.

1. WordPress 관리자 에 로그인하고 대시보드 > 업데이트 를 클릭 합니다 .
2. 최신 버전의 WordPress가 설치되어 있고 모든 테마와 플러그인이 최신 버전인지 확인하세요. 지금 WordPress를 최신 버전으로 업데이트하십시오.

3단계: "one.com PHP 스캐너"를 설치합니다.

1. WordPress 관리자 에서 one.com > 플러그인 을 탭 합니다 .
2. one.com PHP 스캐너 를 찾아 지금 설치를 탭합니다 .
3. 이제 활성화 를 클릭 하고 다음 단계로 이동합니다.

4단계: 스캔 실행 및 잠재적 문제 수정

1. 왼쪽 메뉴에서 PHP 스캐너 를 탭합니다 .
2. PHP 버전 7.4 , " 모든 테마 및 플러그인 "을 차례로 누른 다음 검사 시작 을 누릅니다 .
3. 스캔이 완료되면 계속 진행할 수 있습니다.
4. 세 가지 결과를 얻을 수 있습니다.

– 호환 가능 = 모든 것이 좋다는 의미입니다!

– 경고 = 작동해야 하지만 향후 PHP 버전에 문제가 발생할 수 있음을 의미합니다.

– 오류 = 그다지 좋지 않습니다. 업데이트 후에 확실히 문제가 발생합니다.

최신 버전으로 업데이트하거나 동일한 기능을 제공하는 대체 플러그인으로 교체하여 오류를 읽는 테마 또는 플러그인을 수정합니다.

팁: 정기적으로 업데이트되고 최신 버전의 WordPress와 호환성 문제가 없는 플러그인을 사용하는 플러그인만 사용하는 것이 좋습니다. 그 외에도 사이트의 성능을 향상시키기 위해 원치 않는 플러그인을 제거하는 것이 좋습니다.

5단계: PHP를 8.0 버전으로 업데이트

이제 PHP를 업데이트할 준비가 모두 되었습니다. PHP 오류 메시지를 동시에 켜는 것이 좋습니다. 코드에 문제가 있는 경우 문제의 원인과 정확한 위치를 알려주는 오류 메시지가 표시됩니다.

1. 제어판에서 PHP 및 데이터베이스 설정 으로 돌아갑니다 .
2. PHP 오류 메시지 까지 아래로 스크롤 합니다 .
3. 오류 메시지를 On 으로 설정한 후 업데이트 를 클릭 합니다.
4. 바로 아래에서 버전을 변경하고 업데이트 를 탭 합니다.

6단계: 웹사이트가 예상대로 작동하는지 확인합니다.

이제 PHP 버전이 업데이트되었으며 변경 사항이 적용되기까지 최소 20분이 소요 됩니다. 사이트 방문자가 많은 경우 시간 프레임이 몇 시간까지 연장될 수 있습니다. 그렇기 때문에 앞으로 24시간 동안 웹사이트를 최소 두 번 확인하는 것이 좋습니다.

사이트가 예상과 다르게 작동하지 않는 경우 가장 가능성이 높은 문제는 테마 또는 플러그인입니다. 문제를 일으키는 정확한 원인을 찾으려면 다음 단계를 따르세요.

1. 일시적으로 기본 WordPress 테마로 전환하면 "Twenty Seventeen"이라고 합니다.
2. 설치된 모든 플러그인을 선택하고 모두 비활성화하십시오.
3. 테마와 모든 플러그인을 하나씩 다시 활성화하고 사이트가 여전히 작동하는지 여부를 매번 계속 확인하십시오. 이 방법으로 범인을 잡을 수 있습니다.

우리가 기술적으로 이야기한다면, PHP의 새 버전이 팝업되기 직전에 WordPress 릴리스에서 거주하는 것과 유사한 수준으로 현재의 WordPress Nightly와 많이 논의된 PHP 8의 호환성이 비슷합니다.

우리의 테스트는 상당했고 수정은 세심했으며 문제 수정 수준은 WordPress 코어 내부의 PHP 호환성 수정만큼 거대했습니다. 그러나 이 가이드를 따르지 않으면 호환성 문제를 이해하고 PHP 8의 최대 이점을 얻을 수 없습니다.

PHP 8에 포함된 엄청난 양의 주요 변경 사항과 종류의 변경 사항은 버전 간 도구에 추가된 몇 가지 복잡성 외에도 이전 버전의 PHP에서 경험했던 것보다 확실히 이 호환성 문제를 더 큰 짐승으로 만듭니다. 이 보고서는 동일한 사례를 설명하는 것을 목표로 합니다.

WordPress 및 PHP8 호환성 문제

PHP 8과 호환되는 기존 코드베이스를 만들기 위해 배포할 수 있는 몇 가지 전략을 보여드리겠습니다.

• 구문 문제를 감지하는 PHPCompatibility와 같은 정적 분석 도구.
• 런타임 문제를 감지하는 자동화된 테스트.
• 런타임 문제를 감지하기 위한 수동 테스트.

테스트 스위트의 적용 범위와 구문 변경 및 런타임의 비율에 따라 이러한 전략은 새 버전의 PHP(현재 PHP 8에 대해 논의 중)와 코드베이스의 호환성을 수정하는 데 유용합니다.

실제로 PHP 8 및 WordPress의 경우 WordPress와 PHP 8의 완벽한 호환성을 보장하기 위해 이러한 전략에 의존하기 어렵게 만드는 몇 가지 추가 과제가 있습니다. 아래에서 우리가 배포한 전략에 대해 보고할 것입니다. WordPress의 경우 결과를 공유하십시오.

정적 분석 도구

PHP 8.0의 몇 가지 변경 사항의 특성으로 인해 정적 분석을 사용하여 감지할 수 있는 문제는 제한적입니다. 정적 분석이 기존의 가능성을 뛰어넘어 변수와 상수 및 런타임 유형의 값을 추적하려는 경우 이러한 스캔 결과는 확실히 오탐(false positive)이 발생하기 쉽습니다.

그 외에도 PHP 호환성은 PHP 버전 간 호환성 관련 문제를 찾기 위한 유일한 정적 분석 도구입니다.

PHP 호환성 외에도 다른 정적 분석 도구는 더 넓은 범위의 문제를 보고합니다. PHP 버전 간 호환성과 관련 되고 실제로 정확한 문제를 감지하기 위해 결과를 소중히 여기는 것은 시간이 많이 걸리고 특히 최소한의 노이즈로 구성하는 방법에 대한 심층적인 도구 관련 지식이 필요합니다.

동시에 이러한 도구는 PHP 버전의 변경 사항을 계속 적용하고 가능한 스캔을 업데이트하려고 시도하면서 지속적인 불안정 상태에 있습니다. 따라서 이러한 도구는 앞으로 더 많은 문제를 감지할 수 있습니다.

따라서 현재 존재하고 추가로 발견될 수 있는 것과는 별개로 이러한 도구가 (가까운) 미래에 여전히 더 많은 문제를 찾을 가능성이 있습니다.

PHPCompatibility로 워드프레스 스캔하기

"__destruct()는 __construct()의 die() 이후에 더 이상 호출되지 않습니다."는 PHPCompatibility에서 발견한 또 다른 PHP 8 문제입니다. 이것은 스캐너에 의해 완벽하게 감지됩니다. 그러나 추가 분석을 통해 이 경우에는 문제가 없는 것으로 판명되었습니다.

그 외에도 PHPCompatibility는 "플러그인/테마 편집기"에서 사용하는 코드에서 문제를 감지했습니다. 관련 코드의 분석을 통해 코드에 근본적인 감독이 있는지 확인했습니다. 편집기에서 WordPress는 코드에 대한 최소한의 분석을 기대합니다. 그러나 PHP 5.3+ 코드는 고려하지 않습니다.

PHP8의 관련 변경 사항을 고려하면서 이 간과를 해결하기가 더 복잡해졌습니다. 우리는 개발된 버전으로 PHPCompatibility로 스캔을 실행했고 결과는 예상대로 PHP의 이전 업데이트에서 얻은 것과 많이 달랐습니다. 스캐너에서 감지한 문제는 외부에서 유지 관리됩니다.

Exakat으로 워드프레스 스캔하기

10월 16일에 진행된 최근 공개 스캔에 대해 말하면 WP 트렁크를 기준으로 Exakat은 총 149.567개의 문제를 보고합니다.

PHP 8 호환성 보고서는 총 93개의 문제를 보여줍니다. 그러나 보고서에 PHP 8과 관련된 분석 수치가 포함되어 있지 않아 불완전합니다.

WordPress는 유형 선언을 사용하지 않기 때문에 이러한 보고서에 많은 오탐지가 포함될 것으로 예상되며, 따라서 유형은 발견된 코드와 docblocks에 표시된 유형에서 외삽되지만 이러한 문제는 여전히 개별적으로 검사해야 합니다.

발견된 문제의 1%만 맞다고 해도 여전히 ~450개의 오류로 감소할 것이며 여전히 처리해야 합니다. 그 외에도 오탐지에서 실제 문제를 제거하는 데 많은 시간이 필요합니다.

PHPStan으로 워드프레스 스캔하기

PHPStan 을 사용한 스캔은 원격으로 사용 가능한 결과를 얻기 위해 완전히 사용자 정의된 규칙 세트가 필요하지만 여전히 몇 가지 잘못된 긍정으로 인해 출력을 사용할 수 없게 만듭니다.

참고: 우리는 PHPStan 도구를 비판하는 것이 아니라 WordPress가 유형 선언을 거의 사용하지 않는 반면 PHPStan은 주로 최신 코드를 사용하는 프로젝트에 관심이 있기 때문입니다.

가장 기본적인 구성으로 구성된 초기 스캔은 20,000개 이상의 문제를 생성합니다. 특히 PHP 8 관련 문제를 대상으로 하는 고도로 사용자 정의된 위에서 언급한 규칙 세트를 사용한 스캔은 여전히 ​​레벨 5에서 ​​정확히 580개의 문제를 생성하고 레벨 7에서 추가로 2.150개의 잠재적인 문제를 생성합니다. 여기에는 몇 가지 오탐지가 포함될 수 있지만 380개 더 많은 문제가 생성됩니다. 비슷한 경고로 레벨 8에서.

알 수 없는 구성을 기반으로 문제 목록을 해결하기 위해 최근 Trac 티켓 이 열렸지만 완전히 대상이 지정된 매개변수 유형 불일치(레벨 5)를 통과했습니다. 초안 PR 을 사용하여 이러한 문제를 해결할 수 있습니다.

이 PR에 대한 경솔한 평가는 제안된 수정 사항의 대부분이 변수를 예상 유형으로 유형 변환하고 문제를 숨길 것이지 실제로 제대로 확인하여 수정하지 않는다는 것을 나타냅니다. 이러한 변경 사항에 엄격한 단위 테스트가 수반되지 않는 경우 애플리케이션에서 예기치 않은 동작이 발생합니다. 그 외에도 tit는 오류를 디버깅하는 동안 확실히 더 어려워지는 결과를 초래할 수 있습니다.

현재 제안된 수정 사항이 보증되는지 또는 확인된 문제를 오탐지로 관찰해야 하는지 여부는 확인되지 않았습니다.

테스트

정적 분석은 PHP8에서 문제가 있는 스왑의 특성 때문에 지금까지 진행되었습니다. 소프트웨어를 수동으로 검토하고 테스트하는 것은 힘든 작업임이 입증되었으며 인간은 또한 주의해야 할 사항이 많을 때 간과하는 경향이 있습니다.

이제 최종 사용자가 수행하는 테스트에 대해 이야기 하면 일반적으로 "행복한 경로"가 테스트되는 결과를 가져 오기 때문에 상대적으로 쓸모가 없는 것으로 판명 되었습니다. 보다 신뢰할 수 있는 결과를 얻으려면 포괄적인 탐색 및 회귀 테스트가 필요합니다.

고품질 테스트를 자동화하고 이를 PHP 8에서 실행하는 것이 무엇보다 중요합니다. 이것은 예상되는 PHP 8.0 문제에 대한 완벽한 표시를 제공합니다.

대부분의 기술 괴짜는 PHP 8.0에 흥분하고 있으며, 확실히 이번에는 변경 사항이 엄청납니다. 모두가 PHP 8의 호환성, 구성, 이점 등을 이해하는 데 시간을 할애할 것입니다. 무엇보다도 가장 큰 질문 중 하나는 “WordPress가 이미 PHP 8과 호환됩니까? 그렇지 않은 경우 어떤 작업이 필요합니다.”

글쎄요, PHP 8이 출시되자마자 우리의 전문가 시간은 가장 깊은 수준의 테스트에 뛰어 들었고 그 결과는 누구에게나 충격을 줄 수 있습니다! 예, 우리는 이제 모든 것을 알고 있으며 우리의 보고서와 테스트 결과를 자랑스럽게 생각합니다.

이제 PHP 8에서 자동화된 테스트 실행으로 넘어갑시다.

PHP 8에서 자동화된 테스트 실행

PHPUnit 9.3은 공식적으로 PHP 8.0과 호환되는 최초의 PHPUnit 버전이며 2020년 8월에 출시되었습니다. 글쎄요, PHP에서 실행되는 자동화된 테스트 스위트를 실행하는 것은 사실상 단위 테스트를 위한 도구이기 때문에 어렵습니다.

PHP 8에서 실행되는 자동화된 테스트 스위트를 얻는 것은 PHP 세계에서 단위 테스트를 수행하기 위한 사실상의 도구로서 다음 토끼 구멍으로 우리를 데려갑니다. PHPUnit은 일반적으로 이전 PHP 버전에 대한 모든 단일 주요 드롭 지원과 함께 매년 대규모 릴리스를 수행합니다. 그것은 주요 변경 사항을 소개하지만 PHPUnit 9.3은 위에서 언급했듯이 PHP 8.0과 공식적으로 호환되므로 걱정할 필요가 없습니다!

우리는 최소한 WordPress가 여전히 PHP 5.6을 지원한다는 것을 알고 있습니다. PHP 8.0에서 테스트를 실행하려면 WordPress와 관련된 모든 테스트 스위트가 PHPUnit 5부터 PHPUnit 9까지 완벽하게 호환되어야 합니다. 확실히 도구는 이를 돕기 위해 제작되었습니다. 테스트 스위트를 호환 가능하게 만들기 위해 이러한 도구를 구현하는 데 여전히 노력과 시간이 소요됩니다.

WordPress Core용 PHP8에서 테스트 실행하기

WP Core에 대한 테스트는 현재 PHP 8에 대해 통과하여 실행 중입니다. 이 테스트는 PHPUnit 7.5의 작곡가 설치 버전에서 수행됩니다. PHPUnit 9.3은 공식적으로 PHP 8과 호환되는 가장 오래된 PHPUnit 버전이지만.

이 마지막 문제는 Composer 자동 로드 생성에서 PHPUnit의 기본 클래스를 제외하고 WordPress 테스트 스위트에서 PHPUnit 9.3의 사본 사용을 지원하는 PHPUnit 9.3에서 선택한 수의 파일/클래스를 WordPress 테스트 스위트로 복사하여 해결되었습니다. 이것은 작동하지만 현재로서는 해킹 솔루션이라고 부를 수 있으며 현재 필요한 유지 관리 외에 향후에는 지속 가능하지 않을 수 있습니다.

테스트의 품질을 위해 이것은 시작하기에 확실히 낮았으며 대부분의 경우에 느슨한 유형 검사가 사용되었습니다.

더 깊이 들어가면 이 문제를 해결하기 위한 Trac 티켓이 2016년에 열렸습니다. PHP의 엄격한 유형 준수를 고려하여 이 티켓이 복원되었습니다. 이를 완화하기 위해 많은 작업이 수행되었습니다.

작성하는 동안 약 800개의 인스턴스(676개의 assertEquals()가 96개의 assertNotEquals()에 추가됨)가 있습니다. 8000개 이상의 인스턴스에서 계속해서 느슨한 유형 검사를 활용합니다.

부분적으로 남아 있던 느슨한 형식의 주장은 개체를 비교할 때 합법적입니다. 부분적으로 이것들은 확실히 다루어질 필요가 있습니다. 그러나 현재 테스트 실패로 이어질 것입니다. 이 마지막 것들은 테스트 중 하나의 단점을 강조하지만 더 가끔은 테스트 중인 코드에서.

테마 및 플러그인 테스트

전문적으로 개발된 플러그인과 더 인기 있는 플러그인 중 일부만 사용 가능하며 자동화된 테스트가 마련되어 있습니다. 일반적으로 일반적인 WordPress 사이트는 거의 19개 또는 20개의 플러그인을 확실히 실행하기 때문에 이것은 걱정스러운 일입니다. 훨씬 더 많은 플러그인을 제공하는 사이트가 꽤 있습니다! 테마에 대한 자동화된 테스트를 수행하는 것은 훨씬 더 드뭅니다.

이러한 테스트 스위트를 PHP 버전 8에서 실행하는 것은 어렵습니다. 또한 플러그인 및 테마와 PHP 8의 호환성에 대한 통찰력을 얻기 전에도 마찬가지입니다.

그러나, 최소한의 PHP 8.0 문제가 예상될 수 있는 플러그인/테마가 대부분입니다 . 그러한 테마/플러그인이 전문 개발 모델을 사용하기 때문에 그렇게 주장합니다.

더 큰 문제는 테스트가 없는 테스트와 테마 가 많다는 것입니다. PHP 8에서 실행하는 동안 문제가 발생하기 쉽기 때문입니다.

테스트 가 있는 테마 및 플러그인의 경우 기본적으로 두 가지 유형의 테스트가 있습니다.

• 단위 테스트 . 플러그인 코드 테스트를 허용하기 위해 WP를 "비웃는" 독립 실행형 테스트. BrainMonkey 및 Mockery 와 같은 인기 있는 프레임워크 가 사용됩니다.
• 통합 테스트 . 이제 통합 테스트 는 테스트 스위트를 실행하기 전에 WordPress 자체가 로드되는 곳이며 WPcore 코드를 사용하고 WP 테스트 스위트와 통합됩니다.

통합 테스트

우리는 WordPress가 PHPUnit 7.5를 고수하기로 결정했다는 것을 알고 있습니다. 그게 무슨 뜻이야?

음, 테마 및 플러그인에 대한 통합 테스트의 경우 PHPUnit 7.5(최대)로 점프합니다.

테마 및 플러그인은 통합 테스트를 완벽하게 실행하기 위해 WP 코어의 해킹을 복사하거나 WP 코어의 파일 을 사용해야 합니다. 그러나 동일한 Composer 자동 로드 생성 해킹을 사용할 수 없기 때문에 사용자 지정 자동 로더를 만들어야 합니다.

어쨌든 PHPUnit 기본 파일이 로드되지 않도록 해야 하는 경우 이러한 사용자 지정 자동 로더는 반드시 Composer 자동 로드 파일 바로 전에 부트스트랩되어야 합니다.

단위 테스트

Mockery 또는 BrainMonkey의 도움을 받는 단위 테스트의 경우 PHPUnit 7.x에 사용할 수 있는 Mockery 프레임워크가 PHP 8.0과 호환되지 않으므로 PHPUnit > 8이 필요합니다. 따라서 이러한 테스트 스위트의 비교 가능성은 PHPUnit 5에서 9까지 필수이며, 이는 확실히 또 다른 도전을 추가합니다.

어떻게?

두 종류의 테스트 스위트를 모두 사용할 때 각 테스트 스위트를 실행하려면 다른 버전의 PHPUnit이 필요합니다. 이러한 상황을 악화시키기 위해 플러그인은 일반적으로 런타임 종속성이 PHP 5.6과 완벽하게 호환되고 의존할 수 있는 주어진 버전에 있는지 확인하기 위해 커밋된 composer.lock 파일을 갖게 됩니다.

특정 시간에 이 마지막 부분은 composer.json 파일에 플랫폼 PHP 5.6 구성을 가짐으로써 시행됩니다. 이는 또한 개발 종속성인 BrainMonkey, Mockery, PHPUnit 도 PHP 5.6과 호환되는 버전에서 잠길 것임을 의미합니다. 이제 PHP 8.0에서 테스트를 실행하는 것을 확실히 막을 수 있습니다.

Composer.lock 파일과 composer.json을 업데이트하는 것 외에 플랫폼을 즉시 제거하여 이를 극복할 수 있습니다. 그러나 이것은 PHP 8.0에서 테스트를 실행하는 것이 개발자를 위해 CI와 로컬 모두에서 더 복잡하게 만듭니다.

대형 WordPress 사이트에서 PHP 8 호환성이 다소 까다로워 보입니다.

PHP 8의 일련의 주요 변경 사항을 조사함으로써 우리는 이것이 파손의 원인이 불분명한 사이트에서 큰 파손을 일으키는 경향이 있음을 확인할 수 있었습니다. 특정 시간에 오류는 한 곳에서 발생하지만 다른 곳의 테마 또는 플러그인에 의해 생성되며, 이러한 문제를 디버깅하기가 상당히 어렵습니다.

accuwebhosting.com 은 확실히 적극적으로 유지 관리되는 WordPress 사이트이며 전문 개발자로 구성된 전담 팀이 이를 지원합니다. 대다수의 WordPress 사이트에는 그러한 사치가 없으며 이러한 사이트에서 호환성 문제를 완화하는 것은 확실히 어려울 것입니다.

개발자는 얼마나 오래 업데이트해야 합니까?

PHP의 각 버전의 수명 주기는 2년이며 이 시대에 버그가 수정되었습니다. 보안 문제가 패치되는 동안 1년이 더 추가됩니다. PHP 7.4는 2019년 11월에 도착했습니다. PHP 7의 최종 버전이었습니다. 이는 PHP 7.4의 버그가 2021년 11월까지 수정된다는 것을 의미합니다. 보안 문제는 2022년 11월까지 패치됩니다. "수명 종료"에 도달합니다 그 시점에서.

따라서 하드 컷오프 날짜는 2022년 11월입니다. 이 시간까지 모든 PHP 코드는 PHP 8과 호환되어야 합니다. 그렇지 않으면 잠재적으로 취약한 PHP 버전에 고정될 위험이 있습니다.

결론

PHP 8에는 수많은 주요 변경 사항이 포함될 것입니다. 우리는 보고서에서 이러한 변경 사항의 범위를 설명했습니다. 전문가들은 더 넓은 WordPress 생태계 외에도 WordPress에 더 강력한 영향을 미칠 것이라고 가정합니다. 일반적으로 문제가 되는 경고를 처리해야 합니다. 그리고 다루기 힘든 몇 가지 오류가 발생합니다. 런타임에 이러한 변경 사항의 더 높은 비율을 감지할 수 있습니다.

이러한 모든 호환성 문제를 해결하는 것은 엄청난 작업입니다. 이를 위해서는 정적 분석에서 자동 테스트에 이르기까지 다양한 전략을 사용해야 합니다. 엄청난 시간+노력이 필요합니다.

모든 것을 완벽하게 수행할 수 있는 도구를 사용할 권리가 있어야 합니다. 다양한 PHP 버전을 지원해야 하는 WordPress와 같은 프로젝트의 경우 위에서 논의한 것처럼 다양한 버전의 분석 도구를 저글링할 때 몇 가지 추가 복잡성이 도입됩니다.

확실히 PHP 5와 8의 런타임 및 구문 차이가 엄청나게 크기 때문에 상당히 어려워집니다.

WordPress에서 PHP 8을 사용하는 것이 좋습니까? 사실 여기에서 주장하는 것은 아닙니다. 여기에서 유일한 결론은 – 그렇게 하는 것이 매우 어려워진다는 것입니다.

또한 적용 범위 및 WordPress의 PHP 종속성 문제를 고려했습니다. 호환성을 안정적으로 감지하려면 높은 테스트 범위가 필요합니다. 그리고 PHP 8에 대해 이야기하면 호환성 문제의 수가 평소보다 많기 때문에 더욱 중요합니다. 그들 중 대부분은 런타임에만 감지할 수 있습니다.

그래서 우리는 무엇을 조언합니까?

문제가 감지되면 WordPress, 테마, 플러그인 또는 PHP 호환성과 직접 연결되어 있더라도 문제의 근본을 찾기 위해 광범위한 디버깅이 필요합니다.

종속성에 대한 테스트 커버리지가 거의 없으며 낮습니다. 따라서 진정한 의미에서 PHP 8과 WordPress 코어 호환성이 무엇인지 주장하기는 어렵습니다.

PHP 8이 엄격한 타이핑에 너무 집중하기 때문에 WP의 안전하지 않은 유형 확장 시스템은 문제에 더욱 취약해지며 잠재적으로 플러그인이 다른 플러그인이나 WP 자체에서 유형 오류를 생성할 수 있습니다.

지난 달 오류 데이터에 대한 분석을 실행하여 이를 테스트했습니다. 거대한 사이트로서 우리는 그것이 우리가 예상할 수 있는 종류의 문제에 대한 강력한 표시를 줄 수 있다고 생각했습니다. 확실히, 우리는 PHP 8에서 오류로 발전할 몇 가지 경고를 발견했습니다.

여기서 마지막으로 메모하는 것이 좋습니다. WordPress는 사용 가능한 유일한 레거시 코드베이스가 아닙니다. 또한 광범위한 PHP 버전을 지원하는 것을 목표로 하는 유일한 프로젝트가 아닙니다. 이 기사의 정보는 다른 프로젝트에도 잘 적용될 수 있습니다.

Accuweb 에서 제공하는 이 기사의 주요 목표는 WP의 PHP 8 호환성과 관련된 문제 및 문제를 알리고 개요를 만드는 것입니다. 이 목적에 완벽하게 부합하기를 바랍니다.