PHP 8.2: WordPress, 플러그인 및 개발자에게 어떤 의미가 있습니까?

게시 됨: 2022-12-14

PHP 8.2.0은 2022년 12월 8일에 데뷔했습니다. 주요 업데이트로 null , false 및 true 를 독립 실행형 유형으로 사용하여 성능 개선, 구문 단순화 및 유형 안전성 향상을 제공합니다. WordPress 개발자에게 도전이 될 수 있는 가장 큰 변화 중 하나는 동적 속성을 허용하지 않는 읽기 전용 클래스의 도입입니다.

동적 속성은 더 이상 사용되지 않으며 PHP 9 또는 아마도 PHP 10에서 치명적인 오류를 생성합니다. 잠재적으로 고통스러울 수 있지만(특히 WordPress 코어의 경우) 사용 중단은 PHP의 핵심 기능이자 개발자에게 선물입니다.

PHP의 최근 발전과 WordPress 개발자가 최종 사용자에게 가장 큰 이점이 될 때 새로운 기능을 활용하면서 이전 버전과의 호환성을 유지하는 방법을 살펴보겠습니다.

WordPress에서 PHP 개발 따라잡기

WordPress 코어는 이전 버전이 지원되지 않는 계획된 수명 종료 날짜 없이 상당한 역호환성을 유지하기 때문에 자체 제품 또는 서비스 수명 주기와 지원할 PHP 버전을 결정하는 것은 WordPress 비즈니스에 속합니다.

최소 PHP 7.4가 필요한 WooCommerce와 달리 WordPress 코어는 현재 PHP 7.4 이상만 권장합니다. 2018년 말에 수명이 다한 PHP 5.6.20과도 "함께 작동"합니다. WordPress 프로젝트는 이 점에 주목하고 지원되지 않는 PHP 버전을 사용하면 "사이트가 보안 취약성에 노출될 수 있다"고 경고합니다. (WordPress.org 요구 사항)

다행히 현재 모든 WordPress 사이트의 5.1%만이 PHP 5.6을 사용하고 있으며 2%만이 더 오래된 버전을 사용하고 있습니다. 20%는 PHP 7.0~7.3을 사용하고 있으며 가장 큰 그룹(56.7%)은 PHP 7.4를 사용하고 있습니다. (WordPress.org 통계)

유감스럽게도 PHP 7.4는 2022년 11월 말에 EOL 날짜에 도달했습니다. PHP 8.0은 2023년 대부분까지 공식 보안 지원이 1년도 채 남지 않았습니다. 현재 적극적으로 지원되는 버전인 PHP 8.1은 결국 만료됩니다. 2024년. PHP 8.2는 2025년 12월까지 보안 지원을 받을 예정입니다.

이것은 빠른 릴리스 주기이며 WordPress 생태계가 이를 따라잡기 위해 고군분투하는 것은 놀라운 일이 아닙니다. WordPress에서 실행되는 웹의 절반 이상이 빠르게 회전할 수 없는 큰 배입니다. 최첨단을 향한 경주라기보다 훨씬 더 균형 잡힌 행동입니다. 그러나 PHP 8로의 점프는 더 적은 메모리 사용으로 더 빠른 실행을 위해 런타임에 JIT(Just-in-Time) PHP 컴파일과 같은 큰 성능 향상 기능을 통해 많은 이점을 제공합니다.

이전 버전과의 호환성과 안정성, 미래 지향적 사고와 혁신 사이의 균형

가능한 가장 광범위한 사용자를 수용하는 것과 PHP로 통화를 유지하는 것 사이의 균형은 WordPress 개발자, 호스트 및 제품 회사에 항상 딜레마를 제기했습니다. 장기 고객 및 레거시 사이트가 있는 대행사 및 프리랜서는 동일한 문제에 직면합니다. 최소 요구 사항을 업데이트하면 기존 고객이 사이트를 크게 변경하거나 사이트가 중단되는 것을 볼 수 있습니다.

한편으로 PHP를 최신 상태로 유지함으로써 얻을 수 있는 이점은 향상된 보안 및 성능과 개발자를 위한 최신 프로그래밍 개념 및 기능입니다. 다른 한편으로, 최소 요구 PHP를 지연시키는 주요 이점은 행복하고 광범위한 고객 기반입니다. "지금 지불하거나 나중에 지불"하는 상황입니다. 언젠가는 반창고를 뜯어내야 합니다.

사용자 환경에 대한 우수한 데이터 및 원격 분석은 최소 PHP 버전 요구 사항을 높이기 위해 최소한의 중단 시간을 결정하는 데 도움이 될 수 있습니다. 대부분의 플러그인 개발자는 WordPress.org 플러그인 저장소의 활성 설치 데이터의 일부가 아니기 때문에 자체 도구를 사용하여 이러한 수치를 주시합니다. 필연적으로 많은 사람들에게 영향을 미칠 수 있는 잠재적인 주요 변경 사항은 지원 티켓을 쏟아부을 것입니다.

이전 버전과의 호환성을 우선시하려면 높은 유지 관리 작업도 필요합니다. 매우 크고 다양한 사용자 기반을 지원하는 것은 최종 사용자에게 매우 좋지만 이는 개발자가 다양한 환경에서 코드가 작동하도록 유지해야 함을 의미합니다. "새로운 기능이 추가됨에 따라 이전 PHP 버전을 지원하는 것이 좋습니다." — 개발자는 절대 말하지 않습니다!

걱정해야 하는 것은 레거시 PHP만이 아닙니다. 레거시 데이터베이스와 WordPress 스택의 수십 가지 변형도 있습니다. 구식 요소가 포함된 광범위한 WordPress 서버 환경이 있는 경우 Edge 사례가 발생하고 전문가도 당황합니다.

최소 PHP 요구 사항을 높이기에 가장 좋은 시간

iThemes Security Pro 7.2 릴리스는 기존 고객에게 혁신과 안정성을 모두 제공하기 위해 WordPress 제품의 최소 PHP 요구 사항을 높이는 좋은 예입니다.

7.2 버전 릴리스부터 iThemes Security Pro는 PHP 7.3 이상이 필요하며 최대 8.1을 지원합니다. WebAuthn 프레임워크를 구현하기 위해 iThemes Security Pro에 대한 PHP 요구 사항을 업데이트하기로 결정했습니다. 구현에는 암호화 및 공개 키를 관리하기 위해 PHP 7.3 이상이 필요한 라이브러리가 필요했습니다. iThemes Security Pro 7.2에 도입된 2FA, 암호 키 및 생체 인식 로그인 기능은 이러한 결정의 직접적인 결과입니다. 명확한 암호가 깨졌을 때 iThemes 보안 팀은 기본 사용자 인증 경험으로 처음으로 암호 없는 로그인을 WordPress에 도입했습니다.

이전 버전의 PHP와의 호환성을 위해 WebAuthn 라이브러리를 다시 작성하여 이러한 기능을 구축하는 것이 가능했을 것입니다. 물론 그렇게 하면 훨씬 더 많은 작업이 필요하고 유지 관리할 추가 코드가 생성됩니다. 더 현명한 방법은 PHP 7.3 이상이 필요한 종속성을 채택하여 적절한 속도로 PHP 커뮤니티를 따라잡는 것이었습니다. 대부분의 사용자는 이미 거기에 있었습니다. 이것이 바로 iThemes Security 개발팀이 신규 및 기존 사용자에 대한 최소 PHP 요구 사항을 높이기로 결정한 이유입니다.

GiveWP와 같이 구텐베르크 블록 편집기에 많은 투자를 한 WordPress 제품의 경우 변경 관리가 훨씬 더 어려울 수 있습니다. WordPress 코어의 안정성과 느린 변경 속도는 백엔드 PHP 개발자에게 실망스러울 수 있지만 프론트엔드 JavaScript/React 개발자가 플랫폼을 발전시킬 수 있도록 합니다.

GiveWP의 개발 관리자인 Jason Adams는 사이트 편집기가 발전함에 따라 버전 간에 사용자를 마이그레이션할 수 있기 때문에 이전 버전과 호환될 필요가 없다고 말합니다. 그러나 “PHP를 위한 마이그레이션 같은 것은 없습니다.”라고 그는 말했습니다. 결국 그들은 PHP 8.2에서 더 이상 사용되지 않는 새로운 기능에서 벗어나 PHP 9 아키텍처에 적응해야 할 것입니다.

WordPress 에코시스템의 모든 제품에 대해 최소 PHP 요구 사항을 업데이트해야 하는 단일 "적절한 시기"는 없습니다. Adams는 "철학적으로 해결할 수 있는 문제가 아닙니다."라고 말했습니다. 얼마나 많은 사용자가 변경으로 인해 부정적인 영향을 받을 것인지에 따라 판단이 달라집니다. 90% 이상이 PHP 7.2 또는 7.4인 경우 최소 요구 사항을 해당 수준으로 높이는 것이 가능합니다.

이러한 수치는 제품의 특정 사용자 기반에 따라 크게 다를 수 있다고 Adams는 말합니다. 기술적으로 더 숙련된 고객이 사용하는 제품은 현재 지원되는 PHP 버전에 더 가까운 경향이 있습니다. 많은 비영리 단체에서 사용하는 GiveWP와 같은 제품은 이전 버전과의 호환성에 더 많은 비중을 두어야 합니다. 앞으로 나아가는 또 다른 방법은 레거시 코드와 그 사용자가 지원되지만 새로운 기능이 추가되는 것을 볼 수 없는 장기 릴리스에서 분기되도록 하는 것입니다. 사용자가 업그레이드할 준비가 되면 향후 PHP 호환성을 위해 구축된 새로운 주요 릴리스로 마이그레이션할 수 있습니다.

지원 중단 알림으로 개발 진행

WordPress.com은 호스팅 기능이 활성화된 비즈니스 및 전자상거래 계획의 옵션으로 PHP 8.2를 출시했습니다. WordPress.org 생태계에서는 합리적으로 잘 설계된 이전 코드가 차기 주요 PHP 버전에서 손상되거나 안전하지 않을 가능성이 높습니다. 풀어 주다. WordPress.org 핵심 코드베이스는 공식적으로 PHP 8.0에 대한 "베타" 지원만 제공하지만 일반적으로 최신 버전의 PHP와 잘 작동하며 잘 지원되는 플러그인도 마찬가지입니다. 치명적이거나 구문 분석 오류가 발생하지 않습니다. 디버깅이 켜져 있으면 많은 경고가 표시되지 않습니다. 아직은 오류가 아닌 더 이상 사용되지 않는 함수 알림을 많이 볼 수 있습니다.

빠른 PHP 릴리스 주기의 좌절은 개발자가 자신의 코드를 리팩토링하고 PHP의 더 이상 사용되지 않는 측면을 따라잡는 잡초에 빠져드는 것과 많은 관련이 있습니다. 이 중요한 작업으로 인해 최신 PHP 버전이 제공하는 새로운 개념과 기능을 탐색하고 혁신할 시간이 줄어들 수 있습니다.

이 상황을 보는 또 다른 방법이 있습니다. 더 이상 사용되지 않는 PHP 기능을 다루는 것은 실제로 미래지향적이며 개발자는 진화하는 언어의 다음 반복에 능숙해야 합니다. 이 다소 강요된 연습이 없다면 기존 지식은 구식일 때 나쁜 습관이 될 오래된 습관에 더 쉽게 정착할 것입니다.

지원 중단 알림은 현재 작동하지만 향후 PHP 버전에서 중단될 사항을 지적합니다. Brent Roose가 설명하듯이 이것은 개발자라면 유용합니다. 개발자가 이러한 알림에 주의를 기울이면 더 이상 사용되지 않는 코드를 파악할 수 있는 충분한 시간을 갖게 됩니다. 그리고 마이너 버전 업데이트를 차단해서는 안 됩니다.

iThemes 보안 수석 개발자이자 WordPress Core Committer인 Timothy Jacobs는 지원 중단 경고가 있는 것이 좋다고 말합니다. 그들은 개발자들이 점점 더 안전하고, 성능이 뛰어나고, 실수를 방지하고, 에지 케이스에 더 잘 대처할 수 있는 "더 정확하고" "덜 깨지기 쉬운" 코드를 수용하도록 합니다. 이 보기에서 오류 로그를 채우는 E_DEPRECATED 알림은 "미래에 문제가 발생하지만 지금은 문제가 발생하지 않는다는 조기 경고 시스템과 같습니다."

PHP 8.2 이후 동적 속성 없이 하기

Nikita Popov가 PHP 9에서 동적 속성을 단계적으로 제거한 이유는 보다 탄력적인 코드와 프로그래밍 규칙을 향한 PHP의 진화적 추진력을 보여주는 좋은 예입니다.

이 변경의 동기는 두 가지입니다. 일반적인 경우의 실수(오타 또는 이름 변경으로 인한)를 방지하고 의도적인 사용을 명시하기 위함입니다. 핵심 문제는 존재하지 않는 속성에서 읽는 것은 문제를 즉시 명백하게 만드는 진단을 발행하는 반면 존재하지 않는 속성에 쓰는 것은 완전히 침묵한다는 것입니다. PHP는 프로그래머가 실수를 했다는 표시를 전혀 하지 않습니다.

PHP 5.6에서 8.2로의 진화에 대한 Brent Roose의 2분짜리 비디오는 PHP가 2014년부터 현재까지 얼마나 발전했는지를 훌륭하고 간단하게 시각적으로 보여줍니다. 간단한 데이터 전송 개체의 예를 사용하여 Roose는 PHP 5.6 코드가 PHP 8.2로 가는 과정에서 어떻게 훨씬 더 단순하고 간결하며 전반적으로 더 우아한 코드 블록으로 극적으로 축소되는지 보여줍니다.

Roose가 동적 속성(PHP 8.2에서 더 이상 사용되지 않음)을 처리하기 위한 팁에서 언급한 것처럼 개발자는 사용 중단 경고가 치명적인 오류로 바뀌기 전에 기존 코드를 업데이트할 수 있는 충분한 활주로를 가져야 합니다. 그러나 활주로는 빠르게 줄어들고 WordPress는 특별한 경우입니다. Tonya Mork는 WordPress 코어에서 알 수 없는 동적 속성 지원 중단을 처리하기 위해 Trac에서 승인된 제안을 받았습니다. 그녀와 Juliette Reinders Folmer는 WordPress 개발자가 코드를 리팩터링할 시간이 충분하지 않을 것이라고 우려하고 있습니다. Mork, Reinders Folmer, Sergey Biryukov는 이 벅찬 작업에서 잘 알려지지 않은 영웅이었습니다.

PHP 8.2의 동적 속성 및 매직 메서드에 대한 논의에서 Mork 및 Reinders Folmer는 PHP가 객체 지향 언어로 계속 발전하는 동안 WordPress의 뿌리인 PHP 3 및 4가 견고한 절차적 프로그래밍 세계를 유지한다고 지적합니다. 핵심 개발자는 Reinders Folmer가 말했듯이 "코드를 더 우수하고 안전하게 만들고 PHP 8.2 동적 속성 사용 중단을 완화"하면서 이전 버전과의 호환성을 깨지 않고 오늘날의 PHP에서 레거시 코드의 동작을 유지하는 방법을 찾아야 합니다. "우리는 실제로 [WordPress 코어의] [하위 호환성] 중단 금지 규칙으로 우리 자신의 삶을 매우 어렵게 만들고 있습니다."라고 그녀는 비디오에서 언급합니다.

Mork는 “그럴 만한 이유가 있습니다.”라고 대답합니다. “사용자를 위한 것입니다. 사용자는 버튼을 누르고 업그레이드할 수 있으며 이전 버전과의 호환성에 대해 생각하고 우선 순위를 정했다는 확신을 가지고 있습니다. 그것은 우리에게 초석입니다… 그래서 사용자는 확신을 가지고 업그레이드할 수 있습니다.”

모든 개발은 유지 관리입니다…

WordPress 코어에서 이전 버전과의 호환성을 유지하기 위해 두 개의 이전 주요 버전의 PHP와 함께 작동하도록 "현대" PHP를 백포트하는 것은 독특한 도전입니다. 플러그인 개발자는 PHP 8.2의 읽기 전용 클래스 및 동적 속성 지원 중단과 같은 새로운 기능을 활용할 수 있는 방식으로 코드를 업데이트하는 작업이 훨씬 쉬워졌습니다. 이 작업의 대부분은 대체로 유지 관리의 한 형태이기도 합니다.

구조적으로 PHP 8+의 변경 사항은 불변성과 같은 프로그래밍 개념에 초점을 맞추고 있습니다. 변경할 수 없는 데이터 구조는 "본질적으로 보안 문제를 해결하지는 않지만" Jacobs에 따르면 개발자의 코드가 오류가 덜 발생하고 더 정확하도록 도와줍니다.

변경할 수 없는 데이터 구조가 본질적으로 안전하고 변경 가능한 데이터 구조가 안전하지 않다고 말할 수는 없습니다. 오히려 불변 데이터 구조는 보안 문제로 이어질 수 있는 프로그래밍 실수를 제거하는 데 도움이 될 수 있습니다. 코드가 존재할 수 있는 다양한 상태의 수를 줄임으로써 코드의 복잡성을 줄일 수 있으므로 실수할 가능성을 줄일 수 있습니다.

코드를 적극적으로 지원되는 PHP 버전의 표준으로 유지하는 가장 좋은 이유는 보안 위험을 줄이기 위해서입니다. PHP 8.2는 Adams의 관점에서 유용한 편의와 "가드 레일"을 제공하지만 프로그래머를 흥분시키거나 게임 체인저로 보일 수 있는 것은 거의 없습니다. #[\SensitiveParameter] 속성과 같은 속성은 종종 타사 서비스로 이동하는 스택 추적에서 민감한 데이터를 필터링할 수 있으므로 실질적으로 더 중요할 수 있습니다. PHP 8에 도입된 속성은 Adams가 이전에는 할 수 없었던 무언가를 가능하게 한다는 점에서 그의 눈길을 사로잡은 마지막 혁신에 대한 선택입니다.

PHP 8.0에서 8.2 및 향후 릴리스의 새로운 기능을 활용하는 것은 개발자의 창의성이 빛날 수 있는 곳이지만 단순히 해당 버전을 지원하여 플러그인과 WordPress 코어가 중단되지 않도록 실용적이고 중요합니다.

…그리고 모든 유지보수는 예술입니다

Jeff Atwood는 Kale Davis의 Hacker Newsletter 덕분에 "The Noble Art of Maintenance Programming"이라는 오래되었지만 뛰어난 블로그 게시물을 최근에 읽었습니다. "유지 보수 프로그래밍은 청소 작업으로 널리 간주됩니다."라고 Atwood는 말합니다. 이것은 나에게 프로그래밍 및 웹 개발과 매우 관련이 있다고 생각하는 "Maintenance Art Manifesto"의 예술가 Mirele Laderman Ukeles를 생각나게 했습니다.

두 가지 기본 시스템: 개발 및 유지 관리. 모든 혁명의 신랄한 공: 혁명 이후 월요일 아침에 쓰레기를 줍는 사람은 누구입니까? ] 개발 시스템은 큰 변화의 여지가 있는 부분적인 피드백 시스템입니다. 유지보수 시스템은 변경할 여지가 거의 없는 직접 피드백 시스템입니다.

Laderman Ukeles는 1969년 선언문을 작성하고 유지 관리가 예술이라고 선언했을 때 젊은 예술가이자 새 엄마였습니다. 그녀는 첨단 예술 작품과 높은 지위의 노동이 그것을 가능하게 하는 일, 즉 육아, 예술 기술과 전통을 가르치거나 예술 쇼를 하는 것과 어떻게 분리되어 있는지에 대해 좌절했습니다. 그녀는 박물관 관리인으로 활동하는 자신을 중심으로 기억에 남는 전시를 했습니다. 그런 다음 그녀는 뉴욕시 위생국의 상주 예술가로서 (지속적인) 경력의 대부분을 보냈습니다. 그 역할에서 그녀의 첫 번째 프로젝트는 "뉴욕을 살아 있게 해준" 8,500명의 환경미화 노동자 모두에게 개인적으로 감사를 표하는 것이었습니다.

Atwood는 프로그래밍에 대해 비슷한 견해를 가지고 있습니다. 그는 유지 보수 작업을 폄하하는 것은 완전히 잘못된 것이라고 말하는 소프트웨어 엔지니어링의 여러 주요 인물을 인용합니다. Robert L. Glass는 "유지 관리는 문제가 아니라 해결책일 뿐만 아니라 중요한 지적 과제"라고 느꼈기 때문에 가장 숙련된 사람들에게 중요한 작업으로 간주되어야 합니다. 조엘 스폴스키(Joel Spolsky)는 오래 전에 개발자들이 게으르다고 썼고 그들이 "항상 코드를 버리고 다시 시작하기를 원하는" 이유는 "코드를 작성하는 것보다 읽는 것이 더 어렵기" 때문입니다.

Andy Hunt와의 대화에서 Dave Thomas는 “원래 코드를 거의 작성하지 않기 때문에 모든 프로그래밍은 유지 관리 프로그래밍입니다. .... 유지 관리 모드에서 대부분의 시간을 보냅니다. 그래서 당신은 총알을 물고 "나는 첫날부터 유지하고 있습니다. "라고 말할 수도 있습니다. 유지보수에 적용되는 원칙은 전 세계적으로 적용되어야 합니다.” Hunt는 “처음 입력할 때 코드가 원본인 것은 처음 10분뿐입니다. 그게 다야.”

Atwood는 궁극적으로 이 관점에 기대지만 Jason Adams와 Timothy Jacobs에게서 들은 일반적인 WordPress 개발자 관점을 반영합니다. 워드프레스 개발/유지보수의 특별한 기술?

"균형을 잡는 행위입니다."

WordPress 보안 및 보호를 위한 최고의 WordPress 보안 플러그인이 이제 35% 할인됩니다!

WordPress는 현재 모든 웹사이트의 40% 이상을 지원하므로 악의적인 의도를 가진 해커의 손쉬운 표적이 되었습니다. iThemes Security Pro 플러그인은 WordPress 보안에서 추측을 제거하여 WordPress 웹사이트를 쉽게 보호하고 보호할 수 있도록 합니다. WordPress 사이트를 지속적으로 모니터링하고 보호하는 상근 보안 전문가가 있는 것과 같습니다.

지금 35% 할인!