최신 WordPress 개발에 접근하는 방법(1부)

WordPress 코드베이스가 엉망이라는 것은 비밀이 아닙니다. 개인적으로 그럴 때마다 웅크리고 엉엉 울고 싶은 마음뿐이다. 반면에 WordPress는 경쟁에서 훨씬 앞서 있습니다. 사용하기 쉽고 강력한 CMS는 엄청난 사업이며 WordPress는 이를 제공하기 때문에 여전히 인기가 있습니다.

그렇다면 WordPress 코어의 코드 품질에 관심을 갖는 이유는 무엇입니까? 그것은 작동, 오른쪽?

예, 작동하며 15년 된 코드베이스는 자원 봉사자 유지 관리자에 의해 완전히 리팩터링되지 않을 것입니다. 불행히도 이것은 "WordPress 방식"을 코딩하는 예로서도 작동한다는 것을 의미하며, 모범 사례와 최신 개발 기술을 따르지 않는 많은 개발자를 변명합니다. 너무 많은 WordPress 플러그인과 테마에는 악명 높은 나쁜 코드가 있으며 맹목적으로 레거시 관행을 따르는 것은 추세를 이어갈 뿐입니다.

그러나 여전히 제 역할을 하는 나쁜 코드에 대해 누가 신경을 쓰겠습니까? 글쎄, 공짜는 없으며 누군가가 잘못한 일에 대해 돈을 지불합니다. WordPress 코드베이스 자체를 통해 유지 관리자는 고맙게도 시간을 지불합니다. 그러나 자신의 코드를 사용하면 비용을 지불하는 것은 고객입니다.

어느 정도 복잡한 시스템이라도 초기 개발 비용은 유지 관리 비용에 비해 미미하며 유지 관리는 새로운 기능을 추가하는 것을 의미하기도 합니다. 잘못 설계되고 구현된 소프트웨어를 수정하기 위해 개발자를 고용하는 것은 처음부터 제대로 개발하는 것보다 몇 배나 더 많은 비용이 듭니다.

저렴한 솔루션은 장기적으로 항상 가장 비싼 솔루션입니다. 또는 예산이 소진되어 버려집니다. 입증된 소프트웨어 설계 원칙과 관행을 따를 때 실제로 고객의 비용을 절약할 수 있습니다. 이러한 방법은 과장된 유행이나 변화를 위한 변경이 아닙니다. 여기에서 지혜는 집단적인 개발자 경험에서 비롯되며, 이를 따르는 것은 실제로 효과가 있습니다.

분명히 이것은 몇 줄의 CSS 또는 몇 가지 사용자 정의 게시물 및 재작성을 추가하는 것과 같은 진정으로 간단한 작업에는 적용되지 않습니다. 그러나 몇 개의 플러그인(또는 더 일반적으로 수십 개의 플러그인)을 함께 사용하거나 Visual Composer 기반 사이트를 대량 생산하는 것은 어쨌든 소프트웨어 엔지니어링이 아닙니다.

그 자체 로 나쁜 것은 아닙니다. 일부 솔루션이 이렇게 간단하다는 사실이 WordPress가 인기 있는 이유입니다. 그러나 이 시리즈에서는 중요한 PHP, HTML, CSS 및 JavaScript 코드를 작성하는 실제 WordPress 개발에 대해 이야기할 것입니다. 일반 워크플로부터 시작한 다음 이 기사에서는 WordPress 프런트 엔드 개발에 중점을 둘 것입니다.

최신 WordPress 개발 워크플로

일반적으로 품질 코드는 다음과 같습니다.

• 읽을 수 있습니다. 코드가 무엇을 하고 왜 하는지 이해하기 쉽습니다.
• 모듈식. 명확한 목적을 가진 작은 코드 블록은 이해, 개발 및 테스트하기 쉽습니다.
• 재사용 가능. 유사한 문제를 해결하기 위해 이미 개발된 모듈을 재사용하면 개발 속도가 크게 빨라집니다.
• 유지 보수 가능. 이전 기능을 수정하거나 새로운 기능을 도입하는 것은 쉽습니다.

주요 결과(개발 및 소유 비용 절감)에는 여기에서 다루지 않을 많은 파생 상품이 있습니다.

대신 고품질 코드를 생성하는 데 도움이 될 수 있는 개발 기술과 모범 사례에 중점을 둘 것입니다. 버전 관리부터 시작하겠습니다.

버전 관리 사용

이것은 Git을 사용하는 것을 의미합니다. 안타깝게도 FTP를 통한 프로덕션의 "카우보이 코딩"은 여전히 ​​​​대부분의 일입니다. 최근에 저는 영국에 기반을 둔 에이전시에서 일했으며 코드베이스 전체에 다음과 같은 이름의 파일이 있었습니다.

• functions copy.php
• functions copy 2.php
• functions test.php
• functions2.php
• functions test2.php

워드프레스 사이트를 운영할 때 가장 먼저 해야 할 일은 버전 관리 하에 두는 것입니다. Tanking Servers는 WordPress 개발 실수에 대한 재미있는 회고입니다. Git을 사용하여 모든 사람에게 발생한 유사한 사고를 수정하는 것은 매우 쉬웠을 것입니다.

코드에서 실수를 해서 전체 사이트가 다운되었습니까? git reset 은 모든 것을 원래대로 되돌립니다. 새 버전 업데이트로 모든 것이 중단되었습니까? git reset 은 타임머신처럼 작동합니다. 어딘가에서 악성코드가 나타났다? git status 는 새 파일, 삭제된 파일 또는 추적된 파일의 변경 사항을 보여줍니다. 그런 다음 git checkout 하고 원본을 복원하면 됩니다.

.git 폴더 노출에 주의

좋습니다. Git을 사용하는 것은 분명히 중요합니다. 그러나 그렇게 할 때 Git 리포지토리가 해킹에 노출되지 않도록 하는 것만큼이나 중요합니다. 문제는 .git 폴더가 노출되고 여기에 자격 증명을 저장할 때 발생합니다.

표준 WordPress 설치는 완전히 공용 웹 폴더에 있으며 .git 폴더도 있을 가능성이 매우 높습니다. 분명히 로그인 자격 증명은 Git 리포지토리에 저장되어서는 안 되지만 대부분의 리포지토리에는 외부로 유출되어서는 안 되는 일부 민감한 정보가 포함되어 있습니다.

따라서 .git 폴더에 대한 공개 액세스를 차단해야 합니다. Apache를 사용하는 경우 .htaccess 파일 상단에 아래 스니펫을 추가하면 .git 폴더와 로그 파일에 대한 액세스도 차단됩니다. 로그 파일에는 종종 민감한 정보가 포함되어 있으므로 사용할 수 없도록 하는 것이 좋습니다. 다른 웹 서버 설정의 경우 DevOps 전문가에게 도움을 요청하십시오.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

별도의 환경 사용

라이브 사이트에서 개발을 하지 마십시오. 이것은 다운타임과 고객의 불만을 불러일으키는 방법입니다. 알겠습니다. 하지만 어떻게 설정해야 합니까?

이상적으로는 코드가 항상 한 방향(로컬 → 스테이징 → 프로덕션)으로 가는 세 가지 개발 환경이 있어야 합니다. 이것은 충돌을 피하기 위한 입증된 방법입니다. 모든 코어, 플러그인 및 테마 업데이트는 먼저 로컬에서 수행된 다음 스테이징에서 테스트되고 마지막으로 프로덕션에 배포됩니다.

예를 들어, 서버별 구성은 별도의 파일에 저장할 수 있습니다. 각 로컬 및 스테이징 환경에 대해 wp-config-local.php 를 생성할 수 있습니다. ( .gitignore 파일에 추가하는 것을 잊지 마세요!) 그런 다음 wp-config.php 에 다음 스니펫을 추가하세요.

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

종종 다른 환경을 설정하는 가장 좋은 방법은 환경 변수를 사용하는 것입니다. 이 개념에 익숙하지 않은 경우 Roots와 같은 완전한 최신 솔루션을 사용하는 것이 좋습니다.

WP-CLI 사용

WordPress 명령줄 인터페이스(WP-CLI)는 WordPress 설치를 관리하는 데 매우 유용한 도구입니다. WP-CLI에 액세스할 수 있다는 것은 거의 모든 WordPress API 기능을 실행할 수 있다는 의미입니다. 예를 들어, WP-CLI를 사용하여 사용자와 암호를 추가, 제거 및 편집할 수 있습니다. 사이트를 방금 상속했고 소유자가 스스로를 잠근 경우에 유용합니다.

또 다른 예는 WP-CLI를 사용하면 초기 배포가 간편하다는 것입니다. 다음과 같은 몇 가지 명령으로 수행할 수 있습니다.

• 핵심, 테마 및 플러그인 다운로드
• 데이터베이스에서 검색 및 바꾸기
• 관리자 추가

또한 이러한 작업을 스크립트로 작성하고 자동화할 수 있습니다.

고급 배포 옵션 사용

자동화에 대해 말하자면 다음과 같은 일부 배포 기술 및 프로세스를 배울 가치가 있습니다.

• 지속적 통합/지속적 배포/전달(CI/CD)
• 도커
• 자동화된 테스트(프론트 엔드 회귀 테스트 포함)

물론 버전 제어를 사용하지 않는 것에서 Docker를 다루는 것은 엄청난 도약이며 일반적인 1인용 WordPress 프로젝트에서는 압도적일 것입니다. 일부 옵션은 호스팅 제공업체에 따라 불가능할 수도 있습니다. 그러나 고급 배포는 팀과 대규모 프로젝트의 필수 요소입니다.

린트 사용

모든 규모의 프로젝트에서 Linting은 대부분의 개발자에게 도움이 됩니다. Linting은 코드에 오류가 있는지 자동으로 검사하는 것을 의미합니다. PHPStorm과 같은 완전한 기능을 갖춘 IDE는 이미 이를 즉시 수행합니다. 그러나 VSCode 또는 Sublime Text와 같은 간단한 편집기에는 linter라는 전용 프로그램이 필요합니다. 이를 설정하는 한 가지 방법은 파일을 저장할 때마다 린터를 실행하도록 편집기를 구성하는 것입니다.

PHP_CodeSniffer는 사실상 PHP용 린터입니다. 구문 오류를 확인하는 것 외에도 코드가 PSR-2와 같은 스타일 지침을 따르는지 확인할 수도 있습니다. 이는 다음 코딩 표준을 크게 단순화합니다.

JavaScript의 경우 ESLint는 인기 있는 린터입니다. 광범위한 규칙 세트가 있으며 JavaScript의 모든 특징 및 프레임워크에 대한 사용자 정의 구성을 지원합니다.

강력한 사용 사례는 CI/CD 빌드 파이프라인에 Linting을 통합하여 모든 코드가 배포되기 전에 자동으로 검증되도록 하는 것입니다.

최신 WordPress 프론트엔드 개발 기술

이제 전체 WordPress 프로젝트에 대해 적절한 워크플로가 설정되었으므로 프런트 엔드에 대한 모범 사례를 살펴보겠습니다.

최신 도구 사용: Sass 및 ES6+

프론트 엔드 개발 세계는 끊임없이 변화하고 항상 움직이고 있습니다. Sass가 CSS 작성을 위한 최고의 도구라고 생각하고 구텐베르그 이전 WordPress 개발을 위한 도구라고 생각했지만 여전히 그렇습니다. 하지만 모든 사람들이 CSS-in-JS 및 스타일이 지정된 구성 요소에 대해 이야기하기 시작했습니다.

WordPress조차도 저항하지 못하고 이러한 새로운 기술 중 몇 가지를 선택했습니다. 새로운 블록 편집기인 Gutenberg는 React 및 REST API를 기반으로 합니다.

다음과 같은 핵심 프론트 엔드 기술에 대해 확실히 알아야 합니다.

• ES6+. WordPress 문서에서는 이를 ESNext라고 부르며 심지어 사용을 권장합니다.
• 사스. WooCommerce에서 사용하며 아직 CSS-in-JS에 익숙하지 않은 경우 CSS를 작성하는 가장 좋은 방법입니다.
• 웹팩. 워드프레스 코어도 이제는 Webpack과 Babel을 사용합니다.

ES6과 Sass는 각각 최신 JavaScript 및 CSS이며 Webpack은 이전 버전과의 호환성에 대한 걱정 없이 이러한 모든 최신 기능을 사용할 수 있는 도구입니다. Webpack은 브라우저에서 사용할 파일을 생성하는 프론트 엔드 앱 컴파일러라고 할 수 있습니다.

jQuery에서 Vue.js 또는 React로 전환

WordPress 코어 및 거의 모든 WordPress 플러그인은 jQuery에 의존하므로 사용을 중단할 수 없습니다. 사실, 몇 개의 <div> 를 숨기거나 그런 식으로 하는 데 익숙할 때 일회성 AJAX 요청을 수행하는 것과 같은 간단한 작업에 사용을 중지하는 것은 이치에 맞지 않습니다. jQuery는 어쨌든 로드될 것이며 간단하고 사용하기 쉽습니다.

복잡한 앱은 jQuery가 어려움을 겪는 곳입니다. 따르기 어려운 로직, 콜백 지옥, 전역 변수 및 HTML 템플릿 없음. 이것은 분명히 프론트 엔드 앱을 구성하는 다른 방법을 요구합니다.

React와 같은 최신 프론트 엔드 라이브러리는 객체 지향 프로그래밍(OOP) 원칙을 사용하고 프론트 엔드 앱 아키텍처를 재사용 가능한 모듈식 구성 요소로 구성합니다. 구성 요소에는 특정 요소에 대한 모든 코드, 마크업 및 "구성 요소 상태"(변수)가 포함됩니다. 요소는 거의 모든 것이 될 수 있습니다. 버튼, 입력 필드, 사용자 양식 또는 WordPress REST API 백엔드의 최근 게시물을 표시하는 위젯. 구성 요소는 계층적 관계를 형성하는 다른 구성 요소를 포함할 수 있습니다.

오늘날 웹 페이지의 복잡성으로 인해 앱을 구성 요소로 구성하는 것은 모든 복잡성의 유지 관리 가능하고 빠른 웹 앱을 구축하는 입증된 방법입니다. 구성 요소는 재사용 가능성이 높고 격리되어 있으므로 쉽게 테스트할 수 있는 "벽돌"이므로 이 개념을 배우는 것이 정말 좋습니다.

현재 유행하는 두 가지 구성 요소 기반 라이브러리가 있습니다: Vue.js와 React. React는 이미 Gutenberg에서 사용하고 있기 때문에 명백한 선택이 될 것입니다. 그러나 현대 JavaScript를 처음 접하는 사람에게는 Vue.js가 시작하는 것이 더 나을 수 있습니다.

React는 ES6 기능, 클래스, 독점 JSX 구문 및 Webpack 빌드 파이프라인을 즉시 사용하여 사용자를 딥 엔드로 안내합니다. 학습 곡선이 상당히 가파르다.

반면 Vue.js는 훨씬 더 초보자 친화적이며 <script> 태그를 삽입하기만 하면 사용할 수 있습니다. Vue.js는 일반 JavaScript(ES5), HTML 및 CSS를 사용합니다. 새로운 개념에 대한 소개는 훨씬 더 점진적입니다.

몇 가지 Vue.js 프로젝트를 통해 작업한 후에는 React에 대해 자세히 알아볼 준비가 더 잘 될 것입니다. 항상 필요한 것은 아니지만 예를 들어 구텐베르그 개발에서는 필요합니다.

WordPress REST API 사용

WordPress의 REST API는 WordPress에서 데이터를 원격으로 요청하고 수정하기 위한 표준화된 인터페이스일 뿐입니다. 완전히 다른 코딩 방식이라기보다는 소프트웨어 아키텍처에 가깝습니다. 동일한 이전 jQuery AJAX 스니펫을 약간 다른 매개변수와 함께 사용할 수 있습니다.

가장 중요한 혜택은? WordPress REST API는 백엔드와 프론트엔드 간의 통신을 표준화하므로 코드의 모듈성, 재사용성 및 가독성을 향한 주요 단계입니다. HTML과 PHP가 혼합된 끔찍한 템플릿과 혼합에 던져진 일부 SQL은 사라져야 합니다. 템플릿이 매개변수로 전달된 데이터에 대한 자리 표시자가 있는 HTML이면 해당 데이터를 PHP로 전달하거나 REST API를 통해 프런트 엔드 앱에 전달하는 것 사이에 큰 차이가 없습니다.

WPGraphQL을 살펴볼 수도 있습니다. 결국 WordPress REST API를 대체할 수도 있고 대체하지 않을 수도 있지만 빠르게 견인력을 얻고 있습니다.

Gutenberg 배우기(고객이 곧 요구할 예정)

Gutenberg의 궁극적인 목표는 다른 계획 중에서 전체 사이트 사용자 지정입니다.

이것은 궁극적으로 플랫폼의 전체 게시 경험에 영향을 미칠 WordPress Core의 새 모델을 위한 토대를 마련합니다.

GitHub의 WordPress Gutenberg 프로젝트 페이지

Gutenberg는 WordPress 개발자로부터 큰 반발을 받았습니다. WordPress 코어에 병합하는 것에 대한 몇 가지 주장은 다음과 같습니다.

• 최종 사용자의 상당 부분은 필요하지 않으므로 코어의 일부가 아닌 선택적 플러그인이어야 합니다.
• 그것은 일부 사이트를 깨뜨렸다.
• 단순히 준비가 되지 않았고 더 많은 연마와 더 적은 버그를 사용할 수 있었습니다.

그러나 WordPress를 블로깅 플랫폼으로 사용하는 콘텐츠 작성자에게는 Gutenberg가 이전 편집기보다 분명히 더 나은 경험을 제공합니다.

Gutenberg를 비활성화하는 것은 필요한 한 지원됩니다. 그러나 지금 그것을 완화하는 것이 현명한 생각입니다. 클라이언트가 구텐베르그 개발을 요청하면 준비가 된 것입니다.

속도를 낼 시간: "WordPress 방식"도 진화하고 있습니다

WordPress 개발에서 위에 설명된 모든 도구와 기술을 사용하는 것에 대한 가장 일반적인 주장은 다음과 같습니다. 작업을 수행하는 "WordPress 방식"이 여전히 작동하며 그 방식이 이 모든 새로운 반짝이는 것보다 낫다고 가정합니다.

그러나 이제 WordPress 핵심 개발자가 모든 최신 개발 사항을 잘 알고 있다는 것을 알았습니다. 뿐만 아니라 분명한 장점 때문에 코어의 새로운 부분에 최대한 많이 사용합니다. 우리를 가로막는 유일한 것은 아무도 리팩토링하지 않을 레거시 코드입니다.

한동안 WordPress와 WooCommerce는 새로운 기술을 구현하고 사용하는 "기능 플러그인"을 개발하는 관행을 따라왔습니다. 때가 되면 이 플러그인은 구텐베르크처럼 코어에 병합됩니다. WooCommerce에는 자체 React 프로젝트도 있습니다. WordPress REST API도 별도의 플러그인으로 시작되었으며 이제 WordPress 코어의 일부입니다.

문제는 우리가 새로운 것을 배우고 일상 업무에서 사용해야 하는지 가 아니라 어떻게 . 답은 한 번에 한 단계씩 "점진적으로"입니다. 새로운 것을 배우거나 잘 알고 있는 것을 새롭고 다른 방식으로 하십시오.

예를 들어, 모든 이전 스크립트와 함께 Webpack을 사용하는 방법을 배우십시오. Webpack은 새 ES6+ 코드를 이전 브라우저와 호환되는 "일반" JavaScript로 변환할 수 있습니다. 또한 스크립트를 축소하고 함께 묶을 수 있습니다. 그것은 하나의 새로운 것입니다. 완료? 그런 다음 ES6 기능을 활용하여 JavaScript를 다시 작성하십시오. 그것은 당신이 잘 알고 있는 것을 하는 새로운 방법입니다.

결과: Webpack과 ES6을 배우게 됩니다. 전문가로서 우리는 물러서지 말고 한발 더 나아가야 합니다. 항상 배우십시오. 그리고 공유할 때: Toptal은 WordPress 개발 모범 사례 목록을 유지 관리하고 이에 대한 커뮤니티 기여를 환영합니다.

시리즈의 2부에서는 최신 WordPress 백엔드 개발의 PHP 부분에 대해 알아보겠습니다.