보도 자료: Alain Schlesser가 출연한 WP-CLI의 이전 버전과의 호환성 문제

WMR의 WordPress 커뮤니티 팟캐스트 Press This에 오신 것을 환영합니다. 여기 호스트 David Vogelpohl이 커뮤니티 주변의 게스트와 함께 WordPress 개발자가 직면한 가장 큰 문제에 대해 이야기합니다. 다음은 원본 녹음의 필사본입니다.

Powered by RedCircle

David Vogelpohl: 안녕하세요. WMR의 WordPress 커뮤니티 팟캐스트 Press This에 오신 것을 환영합니다. 저는 귀하의 호스트인 David Vogelpohl입니다. 저는 WP Engine에서의 제 역할을 통해 WordPress 커뮤니티를 지원합니다. 그리고 매주 언론에서 들을 수 있는 최고의 커뮤니티를 제공하고 싶습니다. , 또는 iTunes, iHeartRadio, Spotify에서 이를 누르거나 wmr.fm에서 최신 에피소드를 다운로드하도록 구독할 수 있습니다. 이 에피소드에서는 WP CLI와 호환되는 이전 버전과의 호환성 커넥터에 대해 이야기할 것입니다. 그리고 이 대화에 참여하는 것은 WP CLI에 대해 꽤 알고 있는 사람입니다. XMPP의 WP CLI 기고자 Alain Schlesser를 환영합니다. Alain, Press This에 오신 것을 환영합니다.

알랭 슐레서: 데이비드. 안녕하세요. 여기가 좋습니다.

DV: 당신이 있어서 정말 기쁩니다. 이번이 이 쇼에 두 번째로 나온 것입니다. 우리는 수년 동안 WP CLI에 대한 질문을 해 왔으며 귀하를 만나서 정말 기쁩니다. 듣는 사람들을 위해. WP CLI는 특히 자동화, 워크플로 및 WordPress 빌드의 기타 측면과 관련된 WordPress 에코시스템의 중요한 부분이며 오늘 다룰 내용은 지난 1년 동안 BPCL AI로 달성한 것에 대한 생각입니다. 이전 버전과의 호환성 변경 사항은 무엇입니까? 이전 버전과의 호환성은 WordPress 이점의 큰 부분이지만 소프트웨어 개발자의 과제이기도 합니다. 물론 이러한 과제를 해결하는 방법과 WP CLI에 끝까지 기여할 수 있는 방법에 대한 가장 큰 몫도 알고 있습니다. 그래서 인터뷰가 정말 기대됩니다. 그래서 저는 모든 손님에게 똑같은 질문을 하고 전에도 이 질문을 했습니다. 하지만 가능하다면 다시 말씀해 주시기 바랍니다. 당신의 워드프레스 기원 이야기에 대해 말씀해 주시겠습니까? 워드프레스를 처음 사용한 때는 언제였습니까?

AS: 음, 예, 제 기원 이야기는 대부분의 WordPress 이야기가 더 작은 우회로 시작하는 것과 같습니다. 나는 룩셈부르크에서 정부 요원으로 일했습니다. 그리고 어느 순간 나는 모든 것의 정치에 정말 질려버렸습니다. 나는 내 인생에서 다른 일을 하고 싶었고 다른 직업을 시도했습니다. 그리고 저는 프리랜서 개발을 하기로 결정했습니다. 왜냐하면 저는 이미 개발을 해본 적이 있지만 프리랜서로 해본 적이 없기 때문입니다. 그리고 실제로 무엇에 집중해야 할지 결정할 때가 되었을 때, 나는 무엇이 있었고 당시 가장 큰 시장 점유율을 차지했던 것이 무엇인지 살펴보았습니다. 그것은 우리 모두가 알고 있는 WordPress였습니다. 그리고 0부터 시작하는 신선한 프리랜서로 클라이언트를 얻는 것이 가장 쉬울 거라 생각해서 워드프레스 개발을 막 시작했습니다.

DV: Drupal과 WordPress 사이에서 훌륭한 대행사를 기억하는 것과 같은 이유로 WordPress를 플랫폼으로 선택했습니다. 당시 Drupal이 올바른 선택이었다고 생각하지만 사람들이 오, 하지만 이것은 2010년이었습니다. 사용자 정의 게시물 유형과 메타 필드의 정점에 있었습니다. 그리고 나는 당신이 언제 이 결정을 내렸는지 궁금합니다. 대략 청취자

AS: 음, 그건 2014년, 2014년 중 일부였고 WordPress는 버전 332 정도였거나 그와 비슷한 것 같아요. 솔직히 확신이 서지 않습니다.

DV: 프리랜스 개발자로서 사용자 정의 포스트 사이트의 이점은 이미 공개되었습니다. 그래서 여러분은 이 생태계로 걸어 들어가 그 능력을 보고 있었습니다. WP CLI는 아직 2년이 더 남았습니다. 따라서 개발자로서 필요로 하는 모든 것에 대해 완전히 답변하지 못했다고 생각합니다. 하지만 지금 해당 프로젝트를 관리하는 것을 보니 반갑습니다. 이제 XMPP로 작업한다는 것을 이해하십시오. 그리고 XMPP가 하는 일과 그곳에서 하는 일을 알려드리겠습니다.

AS : 그래서 X Delta P는 고성능 엔터프라이즈급 워드프레스 프로젝트에 주력하는 에이전시입니다. 주요 초점은 성능에 있지만 사이트 로드 속도뿐만 아니라 비즈니스를 얼마나 잘 충족시키는가도 중요합니다. 저는 약 2년 반 동안 XWP로 작업하고 있습니다. 그리고 그 기간 동안 amfa WordPress 플러그인 작업을 한 다음 WordPress 플러그인 페이지 경험을 함께 했습니다.

DV: MIDI 프로젝트처럼 들립니다. 나는 WordPress를 사용하지 않은 것에 대해 확실히 익숙합니다. 저는 아직 페이지 경험을 해보지 않았으며 XMPP를 실제로 보도한 XMPP의 몇 사람이 있다는 것을 알고 있습니다. 그들은 정말 멋진 프로젝트를 수행합니다. 가장 멋진 작업을 하고 있는 것 같습니다. 굉장합니다. 쇼의 주제와 관련하여 오늘은 WP CLI가 무엇인지 모르는 청취자가 있을 것이라고 가정하고 높은 수준에서 WP CLI가 무엇인지 이해할 수 있도록 프레임을 구성할 수 있는지 궁금합니다. 이다.

AS: 네, 물론입니다. 따라서 WordPress에는 옵션을 구성하는 변경을 수행하는 사이트의 모든 유지 관리를 수행하는 관리 백엔드가 있습니다. 그리고 WP CLI는 WordPress 사이트를 제어하기 위한 다른 인터페이스입니다. 커맨드 라인에서 사용할 수 있는 인터페이스입니다. 따라서 텍스트 형식으로 명령을 입력하여 사이트를 제어합니다. 이를 통해 관리자 백엔드가 수행하는 모든 작업 등을 수행할 수 있습니다. 그리고 관리자 백엔드보다 훨씬 더 많은 표현이 가능한 인터페이스인 명령줄을 사용하면 관리자 뒤로 미리 만들어진 사용자 인터페이스 요소가 없는 사용 사례에 매우 특정한 많은 문제를 해결할 수 있습니다. 끝. 어디에서나 이러한 문제를 해결하기 위해 WP CLI 명령을 혼합하고 일치시킬 수 있습니다. 그런 다음 한 단계 더 나아가 WP CLI로 할 수 있는 모든 작업을 스크립트에 넣을 수도 있고 궁극적으로 모든 관리 프로세스를 자동화할 수 있고 원격으로 실행할 수도 있습니다. 따라서 텍스트 기반 인터페이스로 이동하면 많은 이점이 있으며 WP CLI를 사용하면 WordPress에서 이를 수행할 수 있습니다.

DV: 와, 정말 우아했습니다. 마케팅 분야에서 또 다른 경력을 갖고 계신 것 같아요. 그것은 VCI를 프레이밍하는 아주 좋은 방법이었고 매우 훌륭했지만 설명하는 것을 기억하십시오. 좋아요, 제 생각에는 WordPress 역사에서 중요한 순간의 타임라인에 대한 작은 치트 시트가 있습니다. 사람들의 기원 이야기를 들었을 때 그들이 언제 들어갔고 무슨 일이 있었는지 물어볼 때 사용합니다. 시간. 그리고 WP CLI는 실제로 제가 여기에서 언급하는 WordPress 역사의 중요한 순간 ​​중 하나입니다. 2016년으로 돌아가서 타임라인 보기에서 유지하고 있어서 굉장히 중요하다고 생각합니다. 그리고 더 많은 기능과 기능을 출시하기 위한 이러한 노력이 있다는 것을 알고 있습니다. 하지만 기능이나 리팩토링 등과 관련하여 최근 릴리스 배치에 대해 상대적으로 궁금합니다. 최근 릴리스에서 가장 기대했던 점은 무엇입니까? ?

AS: 매우 흥미로운 기능 중 하나는 YouTube가 구축된 이후로 필요한 전역 컨텍스트가 추가되었다는 것입니다. 도구가 프론트 엔드 프로세스나 관리 프로세스 등으로 실행되어야 하는 경우 도구가 실행되어야 하는 컨텍스트에 대한 논의가 항상 있었습니다. 사이. 그리고 모든 접근 방식에는 항상 고유한 문제가 있었습니다. 그래서 정말 깨끗한 해결책은 없었습니다. CLI가 기본적으로 실행되는 방식은 관리자 프로세스도 프론트 엔드 프로세스도 아닌 이상한 혼합입니다. 예를 들어 현재 요청이 관리자 요청인지 여부를 확인하는 일부 프로세스는 역사적인 이유로 인해 자동으로 실패합니다. 이것은 업데이트를 실행하기 위해 실행할 때 프리미엄 플러그인 및 테마에서 가장 악명이 높습니다. 따라서 일반적으로 관리자 백엔드에서 작동하는 업데이트를 볼 수 있습니다. 그러나 WP CLI를 사용하면 관리자가 표시되는 업데이트가 아니거나 예상대로 작동하지 않습니다. 각 플러그인에 대한 이러한 업데이트를 관리하는 사용자 정의 로직이 프론트 엔드 속도를 저하시키지 않는 관리 프로세스를 확인하고 자동으로 WP CLI를 실행하기 때문입니다. 이제 이 새로운 컨텍스트 플래그를 사용하여 실행할 컨텍스트를 선택할 수 있으며 이를 통해 컨텍스트를 관리자 컨텍스트로 전환할 수 있습니다. 예를 들어 플러그인 업데이트를 수행한 다음 갑자기 모든 프리미엄 통합이 예상대로 작동합니다. 이것은 매우 흥미진진합니다. 죄송합니다. 이것은 그다지 흥미롭지 않은 새로운 기능이었습니다. 현재 기본적으로 켜져 있지 않은 단계에서 테스트 중이라는 점에서 cloudways와 공동으로 구축되었습니다. 따라서 수동으로 이 자동 프로비저닝이 다음 반복에서 기본값이 되어야 합니다.

DV: 훌륭합니다. 나는 당신이 그것에 대해 흥분하는 이유를 알 수 있습니다. 그리고 제 생각에 당신이 프론트엔드나 관리자가 될 거라고 생각하고 있었던 것은 정말 영리한 일이라고 생각합니다. 하지만 실제로 개발자에게 선택권을 줌으로써 해결할 수 있는 능력을 제공하거나 최소한 개발자가 해결할 수 있는 능력을 제공합니다. 한 번에 여러 사용 사례에 대해. 나는 당신이 그것에 대해 흥분하는 이유를 알 수 있습니다. 특히 그 영웅 사용 사례에 대해 생각하고 프리미엄 플러그인에 대한 업데이트를 렌더링할 수 없습니다. 꽤 일반적인 사용 사례입니다. 그리고 많은 다른 사람들이 거기에서 쏟아져 나온다고 상상해보십시오. 하지만 로드맵을 깨고 이전 버전과의 호환성 고려 사항에 대해 생각하는 것과 같은 몇 가지 질문이 있습니다. 하지만 우리는 첫 번째 휴식을 취합니다. 곧 돌아올 것입니다. 광고 시간에 연결할 시간입니다. 잠시 후 이 버튼을 더 눌러주세요. 여러분의 호스트 David Vogel인 Omar에게 제가 제공하는 WordPress 커뮤니티 팟캐스트를 다시 눌러주세요. 폴. 저는 WP CLI 및 일부 이전 버전과의 호환성 커넥터에 대해 출시 임대인을 인터뷰하는 중입니다. 휴식 직전에 혼자 즐겨 사용하는 기능에 대해 공유하거나 최근에 WP CLI가 프론트 엔드인지 관리 프로세스인지 플래그를 전환하는 글로벌 컨텍스트였습니다. 그리고 그것이 정말 영리하다고 생각했습니다. 미래 로드맵과 이전 버전과의 호환성에 대해 설명하기 전에 추가하고 싶은 모든 것입니다.

AS: 예, WP CLI가 받는 가장 빈번한 지원 요청 중 하나일 것이기 때문에 정말 기대됩니다. 업데이트가 관리 버킷에서 작동할 때 WP CLI에서 작동하는 이유는 무엇입니까?

DV: 예, 프리미엄 플러그인 리포지토리 프로세스가 워드프레스에서 찾을 수 있는 많은 다른 위치와 머리를 들고 있지만 예, 사람들이 핵심 기능인 곳을 알 수 있습니다. 도대체 왜 이렇게 하지 않는지 ? 워드프레스의 기본입니다. 그 놀라운. WP CLI의 미래에 대해 생각할 때 나는 이전 버전과의 호환성 고려 사항을 잠시 도입하고 싶지만 미래에 대해 기대하는 상위 2~3개의 기능을 좋아합니다.

AS: 그래서 제가 지금 꽤 오랫동안 계획한 것은 WP CLI의 스캐폴딩을 완전히 재정비하는 것입니다. 스캐폴딩 명령은 빈 테마 생성 빈 플러그인 생성과 같은 코드를 생성할 수 있도록 템플릿을 사용하는 명령입니다. 그리고 저는 슈퍼볼을 완성하기를 원했습니다. 시작하기 도구라기보다는 워드프레스 개발에 사용되는 모든 개념이 고유한 명령을 가지고 있는 자폐증 명령이 있는 Laravel 공간에서와 같이 지속적인 개발 도움이 되기를 원했습니다. 정식 버전을 생성합니다. 그리고 그것은 개발을 크게 가속화할 뿐만 아니라 엄청난 학습 도구가 될 것이며 WordPress 공간의 전반적인 품질을 형성하는 데 도움이 될 것입니다.

DV: 정말 좋은 소리가 납니다. 또한 로드맵 기능과 같은 다른 기능이 있습니까? 아주 좋은 것 하나 더 추가하시겠습니까?

AS: 여전히 타사 명령인 Profile 명령을 다시 작성하는 작업도 현재 진행 중입니다. 아직 번들로 제공되지 않습니다. 그러나 재작성이 완료되는 즉시 모든 사람이 쉽게 프로파일링할 수 있도록 해당 명령을 번들로 제공하고 싶습니다. 웹 사이트에서 요청하고 어떤 작업에서 주요 성능 병목 현상이 발생하는 필터를 확인해야 하는지 확인합니다.

DV: 또 다른 좋은 점입니다. 자, 두 가지 유용한 로드맵 항목이 있습니다. 물론 그 이상은 당신이 미래에 대해 생각하고 있고 다른 기여자들이 미래에 대해 생각하고 있다는 것입니다. 그러나 분명히 이전 버전과의 호환성은 WordPress에서 중요한 것입니다. 그렇다면 그 로드맵을 이행할 수 있는 능력에 대해 생각할 때 어떤 고려 사항이 마음을 짓누르고 있습니까?

AS: 예, WP CLI는 작동 방식이며 내부 작업은 WordPress 코어의 이전 버전과의 호환성 정책과 직접 연결되어 있습니다. 현재 WordPress Core는 여전히 최소 PHP 5.6 WP CLI를 지원하고 있습니다. 그리고 WordPress의 최소값이 무엇이든 변경될 때마다 WP CLI에 대한 정책이 있습니다. WP CLI는 모든 사람이 WP CLI를 사용하여 이전 사이트에서 마이그레이션할 수 있는 기회를 제공하기 위해 해당 변경을 최소 1년 동안 연기합니다. 새로운 사이트로. 그리고 WP CLI는 일반적으로 이전 사이트에서 마이그레이션하는 데 사용되는 도구이기 때문에 여전히 내보내기 작업을 수행해야 합니다. 따라서 WP CLI는 최신 버전의 PHP 등을 지원하는 접근 방식을 주도할 수 없습니다. 그러면 이전 사이트에 대한 액세스 권한을 얻고 이동을 허용하는 주요 목적이 실패하기 때문입니다. 따라서 그런 점에서 WP CLI에서 코드를 최신 상태로 유지하고 유지 관리할 수 있는 방식으로 개발하는 것은 정말 어렵습니다. 그러나 여전히 WordPress 코어에서 이 매우 낮은 PHP 최소 요구 사항을 고수하여 점점 더 많은 문제를 일으키고 있습니다.

DV: 코어가 언제 최소 버전 번호 5.6을 올릴 것인지 알거나 알 수 있습니까? 다음으로 AB가 있는 이유는 5.6이 과거 버전이 상당히 많고 유지하기가 어렵기 때문입니다. 최신 버전이 언제 최소 버전일지 알 수 있습니까?

AS: 솔직히 말해서 저는 WordPress 코드가 이 시점에서 최신 버전의 PHP로 빠르게 이동할 수 있도록 하는 많은 메커니즘이 있는 sub happy 프로젝트에 많은 작업을 투자했다고 말할 수 없습니다. 모든 기술적 전제 조건은 다음과 같습니다. 거기. 결정을 내리는 것뿐입니다. 그리고 언제 그런 일이 일어날지 장담할 수 없습니다. 이미 오래전부터 계획된 일이지만 아직까지 아무 일도 일어나지 않았기 때문입니다.

DV: 그리고 WP CLI가 지원되는 최소 PHP 버전을 올릴 수 있는 1년 후에 발생하는 순간부터 발생합니다. 소프트웨어 스택의 다른 부분이나 언어 또는 로드맵을 제공할 수 있는 능력에 대해 생각할 때 부담이 되는 부분이 있습니까? 아니면 주로 PHP입니까?

AS: 이전 버전과의 호환성 측면에서입니까? 주로 php입니다. WP CLI는 PHP와 작은 오이 및 셸 스크립트로 빌드됩니다. 따라서 작은 오이는 실제로 문제가 되지 않는 테스트 언어이며 20년 동안 변경되지 않은 셸 스크립트입니다. 나는 곧 문제가 있을 것이라고 생각하지 않는다.

DV: 매우 오래된 버전의 PHP와 소프트웨어를 호환되도록 유지하는 것은 분명히 어려운 일이지만 이해하는 데 도움이 되는 것과 같은 영향은 무엇입니까? 5.6에 대한 지원을 고수하기 위해 해야 하는 절충점은 무엇입니까?

AS: 5:6을 지원하는 것 자체는 그다지 큰 문제가 아닙니다. 그것은 언어의 한 버전일 뿐이고 더 추한 언어였습니다. 그 당시이지만 여전히 매우 유용한 것입니다. 문제는 최신 버전의 PHP에서도 실행할 수 있기를 원하는지 여부입니다. 따라서 전체 스펙트럼을 커버해야 합니다. 그리고 우리가 최소 버전을 올리지 않는 한 PHP와 함께 지원해야 하는 버전을 점점 더 추가할 뿐입니다. 하지만 이제는 매년 새로운 주요 버전이 출시되어 마이너 버전이지만 기능 면에서는 메이저 버전이며 마지막 몇 릴리스에서는 언어에서 더 크고 급진적인 변경이 있었습니다. 그리고 지금 당장은 5, 6, 8에서 동시에 작동하는 방식으로 더 낮은 수준, 더 낮은 수준의 건축물을 짓는 것이 정말 어렵고 시간이 지남에 따라 악화될 뿐입니다. 거기에 추가되는 것은 PHP에서 작업하는 데 필요한 도구, 단위 테스트를 실행해야 하고 기능 테스트 등을 실행해야 한다는 것입니다. 이 모든 도구는 PHP 단위로 무언가를 위해 PHP 케이던스를 고수합니다. 예를 들어, 테스트 자체가 모든 버전의 PHP 장치에서 작동하도록 테스트를 작성하는 것은 이제 매우 어렵습니다. 이 모든 PHP 버전을 다루려면 를 사용해야 합니다.

DV: 알겠습니다 . 여러 집단의 가중치입니다. PHP 유형은 TA를 단위로 하고, 다른 버전의 함수를 새 함수로 사용하는 방법을 아는 데 어려움을 겪을 수도 있습니다. 사용 가능해지고 더 이상 사용되지 않습니다. 그리고 추가 작업의 모음이 마찰로 인해 새로운 기능을 제공하는 능력이 저하되는 것처럼 들립니다. 과연 그럴까요?

AS: 예, 음, PHP가 점점 더 엄격해지고 있습니다. 따라서 이전에는 여러 버전의 PHP를 매핑해야 하고 코드를 모호하게 유지하여 한 버전 또는 다른 버전의 문제에 부딪히지 않도록 할 수 있습니다. HP는 대부분의 알림과 경고, 사용 중단 문제를 많이 던지고 있기 때문에 지금은 점점 더 어려워지고 있습니다. 지금까지 가장 작은 세부 사항에 대해, 그리고 때로는 빌드를 여러 번 실행해야 하는 함수를 만들고 실행 중인 PHP 버전에 따라 해당 함수의 올바른 버전을 가져오는 메커니즘이 있어야 함을 의미합니다. 모든 것의 유지 관리 노력이 기하급수적으로 증가합니다.

DV: 네, 완전히 이해가 됩니다. 좋습니다. 글쎄, 나는 당신이 그것을 어떻게 입는지, 그리고 아마도 WordPress가 일반적으로 어떻게 더 잘할 수 있는지에 대한 당신의 생각에 대해 조금 탐구하기 시작하고 싶습니다. 그러나 우리는' 마지막 휴식을 취하고 곧 돌아올 것입니다. 광고 시간에 연결할 시간입니다. 잠시 후 이 버튼을 더 눌러주세요. W EMR에서 이 WordPress 커뮤니티 팟캐스트를 누르기 위해 다시 오신 것을 환영합니다. 우리는 출시 임대인과 WP CLI의 역방향 거주 가능성 문제에 대해 이야기하는 중입니다. 이 쇼에 대해 덜 혀 트위스터 제목을 선택했어야 했습니다. 하지만 여기 있습니다. 오랜만에 좋은 책입니다. 그래, 끝나기 전에 빨리 세 번 말해야 해. 하지만 알겠습니다. 휴식 시간 전에 여러 버전의 PHP를 다루기 시작하면서 기하급수적인 유지 관리 문제에 대해 이야기하고 있었고 이것이 혼자 기분이 나아지는지 모르겠지만 WP 엔진의 100%처럼 고객은 우리가 강제로 업데이트한 PHP의 최신 버전에서 패치되지만 분명히 모든 사람이 그런 것은 아닙니다. 권리? 모든 호스트가 웹사이트를 호스팅하는 모든 사람이 이 작업을 수행하는 것은 아니므로 이 작업은 따로 따로 설정되어 있고 구식, 소프트 PHP 버전 또는 WordPress 확실히 플러그인을 생성합니다. 따라서 WordPress의 이러한 특성은 이전 버전과의 호환성에 대한 이 아이디어에서 WordPress의 일부라는 점입니다. WordPress의 인기도는 내가 직접 설정하더라도 문제가 되지 않습니다. WP CLI는 업그레이드해야 하는 사람들을 위해 일하기 때문에 지연되어야 합니다. 그게 좋은 일이죠, 그렇죠? 그것은 그 역동성의 좋은 부분입니다. 그러나 WP CLI 또는 WordPress 전체가 이러한 좋은 부분을 유지하고 역호환성의 기하급수적인 유지 관리 요구 사항과 같은 나쁜 부분을 더 많이 피하는 데 어떻게 개선할 수 있는지에 대한 귀하의 생각이 궁금합니다. 그 큰 글에 대해 어떻게 생각하세요?

AS: 네, 제 생각에는 지금 WordPress가 PHP와 관련하여 현재 가지고 있는 매우 극단적인 하위 호환성 접근 방식을 고수함으로써 사용자 기반을 해롭게 하는 시점에 있다고 생각합니다. 왜냐하면 모든 징후가 사실을 가리키는 것처럼 보이기 때문입니다 우리는 더 이상 최신 버전의 PHP에서 WordPress를 계속 실행할 수 없는 단계에 천천히 진입할 것이며, 이는 실제 문제입니다. 그리고 오늘날 PHP에서 더 많은 변경 사항이 발생함에 따라 변경 사항이 있기 때문에 호환성에 대해 작업하는 데 많은 시간이 필요합니다. 이 문제를 해결할 수 있는 유일한 방법은 PHP 주기에 지속적으로 적응하는 것입니다. PHP 주기는 PHP보다 뒤쳐질 수 있지만 PHP보다 속도가 느리다고 문제를 점점 더 악화시킬 수는 없습니다. 따라서 PHP의 속도가 2년 뒤처지지 않더라도 PHP의 속도와 일치해야 합니다. 그리고 나서 우리는 항상 최신 버전의 PHP를 지원하기 위해 작업할 수 있도록 도구, 테스트, 도구 등에 대한 모든 것을 최신 상태로 유지할 수 있는지 확인해야 합니다. , 우리가 접근 방식을 변경하지 않으면 WordPress가 적응할 수 없는 것처럼 보이기 때문에 PHP 9가 아마도 첫 번째 버전이 될 것입니다. 바라건대, 네.

DV: WP CLI에서 다루고 있는 이 기하급수적인 문제는 WordPress 전체에서 일종의 복합적인 문제처럼 들릴 것입니다. PHP 9용. 그리고 이것은 이와 같은 관점에서 의미가 있습니다. 유지 관리에 대해 더 나은 WordPress를 움직이는 힘은 해당 속도와 일치하여 서비스에 너무 뒤쳐지지 않고 PHP 버전에서 너무 뒤떨어지지 않도록 합니다. 마지막 몇 분 동안에는 이전 버전과의 호환성과 관련하여 많은 문제가 있음을 알고 있습니다. 귀하가 훌륭한 기능을 제공하고 있으며 더 많은 기능을 제공하기를 원한다는 것을 알고 있습니다. 그리고 Gutenberg에 대한 기고자들의 쇄도를 본 것처럼 기고자들을 위한 이 팟캐스트에서 WP CLI를 조금 사랑하지 않는 한 서비스를 하지 않을 것이라고 생각합니다. 사람들이 WP CLI에 기여하여 WordPress의 이 정말 중요한 부분을 계속 유지하고 추진할 수 있습니까?

AS: 우선 wordpress.org Slack 팀의 메인 팀입니다. CLI 채널이 있습니다. 따라서 해당 채널에 접속하여 인사하고 질문할 수 있습니다. 시작하고 싶다면 WP CLI 기여에 온보딩하는 데 기꺼이 도움을 줄 사람들이 항상 있습니다. 또한 모든 문서의 진입점인 make wordpress.org/cli가 있으며 좋은 첫 번째 문제 등에 대한 링크가 있습니다. 그런 다음 이상적으로는 지금 다시 일어나고 있는 웹캠 기고자의 날 중 하나에 참여하는 것입니다. 나는 그것에 대해 정말 기쁩니다. 이 기고자의 날 동안 사람들은 실제로 적절한 로컬 개발을 수행하기 위해 자신의 시스템을 설정하는 데 도움을 줄 수 있습니다. 이것은 때때로 온보딩이 사람들이 설치해야 하는 가장 어려운 장애물이기 때문에 라이브를 중단할 것입니다.

DV: 네, 제가 증명할 수 있습니다. 기여를 하게 된 몇몇 친구와 그들이 극복한 것. 코스와 지침이 거의 없는 사람들이 꽤 많다는 것을 알고 있습니다. 물론 WordPress에 문서화 측면에서도 이와 관련된 내용이 있습니다. Slack 채널 가입을 요청하신 방법도 마음에 들었습니다. 그것은 Mike Liddell이 내가 Mac Mullenweg 블로그 게시물에 댓글을 달고 있는 것에 대해 어떻게 WordPress에 관여했는지를 상기시켜줍니다. 글쎄, 이것은 매우 멋졌다. 오늘 함께해주셔서 감사합니다.

AS: 함께해주셔서 감사합니다.

DV: 당신이 여기 있어서 정말 기쁩니다. Alon이 하는 일에 대해 더 알고 싶다면. make wordpress.org를 방문하여 WP CLI 사이트를 검색하거나 wordpress.org slack 및 WP CLI 채널에서 그를 찾으십시오. WMR의 WordPress 커뮤니티 팟캐스트를 들어주셔서 감사합니다. 이번에도 호스트 David Vogelpohl입니다. 저는 WP Engine에서 제 역할을 통해 WordPress 커뮤니티를 지원합니다. 그리고 매주 Press This를 통해 커뮤니티 최고의 소식을 전해드리고 싶습니다.