루트 스택을 사용한 최신 WordPress 개발 워크플로

게시 됨: 2022-03-11

워드프레스는 최소한 인터넷 표준에 따라 오랫동안 사용되어 왔으며 그 철학은 항상 이전 버전과의 호환성을 유지하는 것이었습니다. 오늘날 온라인에 있는 WordPress 웹 사이트의 양을 감안할 때 호환성에 대한 이러한 초점은 이해할 수 있습니다. 그러나 이것은 이전 PHP 및 MySQL 버전(이 자체로 보안 위험이 있지만 오늘 기사의 주제가 아님)이 있는 레거시 환경을 사용하는 사람들에게 도움이 될 수 있지만 최신 WordPress 릴리스에서는 최신 PHP 기능.

이것은 또한 많은 WordPress 개발자가 새롭고 현대적인 프론트 엔드 개발 기술을 배우도록 인센티브를 받지 못하고 WordPress 거품 속에 살게 했으며 때로는 일을 하는 "좋은 방법"에 갇히게 되었습니다.

WordPress에 최신 개발 워크플로를 채택할 수 있습니까?

가장 확실히 할 수 있으며 WordPress Roots 스택은 세 가지 놀라운 도구를 사용하여 2019년처럼 개발할 수 있도록 도와줍니다.

Sage 를 스타터 테마로,
현대 WordPress 상용구 로서의 기반,
다양한 환경에 대한 배포 및 프로비저닝을 관리하기 위한 Trellis

Roots 팀은 또한 플러그인 구축 프레임워크인 Acorn과 플러그인 상용구인 Clover라는 두 가지 추가 도구를 개발 중입니다. 둘 다 알파 버전이라는 사실 때문에 이 기사에는 포함되어 있지 않지만 확실히 지켜봐야 합니다.

많은 최고의 브랜드는 웹사이트에 Sage 및/또는 Bedrock을 사용합니다. 루츠 쇼케이스에서 만나보세요.

루트 스택이란 정확히 무엇입니까?

원래 Roots 테마로 알려진 이 테마는 새로운 WordPress 웹사이트를 위한 더 깨끗한 출발점을 제공하는 것을 목표로 하는 견고한 HTML5 스타터 테마였습니다. 시간이 지남에 따라 모든 주요 현대 웹 기술 및 표준(Grunt에서 Gulp 및 Webpack, LESS 및 SCSS, NPM 및 Yarn, Bootstrap, PSR-2 코딩 표준 및 DRY 원칙까지)을 통과하는 완전한 도구 세트로 발전했습니다. 따라서 이를 채택한 WordPress 개발자는 최신 프론트 엔드 개발 기술이 제공하는 것을 지속적으로 배우고 최신 상태를 유지해야 합니다.

오늘날 Roots는 개발에서 스테이징 및 프로덕션에 이르는 전체 주기를 따라 더 나은 WordPress 사이트를 구축할 수 있도록 지원하고 편안함에서 벗어나도록 하여 더 나은 개발자로 만드는 것을 목표로 하는 지속적인 확장을 통해 완전한 도구 세트로 성장했습니다. 이른바 워드프레스 버블이 제공하는 영역.

그러나 그들이 제공하는 세 가지 주요 도구, 그 도구가 무엇인지, 사용을 고려해야 하는 이유를 살펴보겠습니다.

루트 세이지 9

Roots Sage 9는 원래 2011년에 Roots로 출시된 전문적으로 유지 관리되는 WordPress 스타터 테마 의 마지막 반복입니다. 사용 기간 동안 모범 사례에 대한 많은 변경, 개선 및 재검토를 거쳐 마침내 다음이 되었습니다. 오늘은 WordPress 개발을 위한 최신 프론트 엔드 개발 워크플로를 소개하는 좋은 출발점입니다.

Sage가 하려는 것은 View와 Controller가 완전히 분리된 MVC 패턴(Model-View-Controller)을 채택하는 것입니다. 이를 통해 뷰를 재사용할 수 있습니다. 뷰는 데이터가 어디에서 오는지 반드시 "알" 필요는 없지만 컨트롤러가 표시할 일부 데이터를 제공하기를 기다리기만 하면 됩니다.

Sage 9에 포함된 컨트롤러는 Laravel과 같은 다른 프레임워크에서 이미 친숙한 실제 컨트롤러가 아닙니다. 주요 차이점은 Sage 9 컨트롤러가 URL 기반 라우팅 대신 템플릿 기반 라우팅을 사용한다는 것입니다. 기본적으로 WordPress가 URL 라우팅을 처리하도록 하고 템플릿 파일용 컨트롤러를 작성합니다.

전체 개발 프로세스에 약간의 복잡성을 추가함으로써 Sage 9는 초보자를 위한 최고의 선택이 아닐 수 있습니다. 결국 마스터하고 프로덕션에서 사용할 수 있도록 상당한 양의 학습을 하게 될 것이기 때문입니다. 의존성 및 자산 관리, 코드 버전 관리, 새로운 프로젝트 구조, Laravel에서 파생된 새로운 템플릿 엔진, DRY(Don't Repeat Yourself) 원칙, 그리고 당신은 지금과는 조금 다른 엄격한 코딩 표준을 고수해야 할 것입니다. 워드프레스는 권장합니다. 그러나 노련한 개발자라면 좋은 출발점이 될 수 있습니다.

Sage에 올인하고 싶다면 Roots 팀의 개발자 중 한 명인 Ben Word의 다음 조언을 명심하십시오.

Sage는 테마 프레임워크가 아니라 시작 테마입니다. 업데이트할 필요가 거의 없으며 일반적으로 여기에서 자식 테마를 만들면 안 됩니다. 스타터 테마인 Sage는 새 프로젝트의 시작점으로 사용됩니다.

그러나 또한:

Underscores가 1,000시간 앞서 출발했다면 Sage는 10,000시간 앞서 출발한 것입니다.

Sage를 사용한 파일 및 폴더 구조

Sage의 파일 및 폴더 구조는 Underscores와 같은 다른 스타터 테마 또는 Sage 8의 이전 주요 버전에서 보던 것과 약간 다릅니다.

다음은 Sage를 설치한 직후에 찾을 수 있는 내용입니다.

 ├── app/ # it contains all the PHP code of your theme │ ├── controllers/ # your Controllers, it already contains a few │ │ # examples to use as a starting point │ ├── admin.php # setup for the WordPress theme customizer │ ├── filters.php # a good place to group all your theme │ │ # filter hooks │ ├── helpers.php # for various helper functions you want │ │ # to reuse in your theme │ └── setup.php # the main theme setup file ├── config/ # theme configuration files ├── dist/ # all built theme assets, never edit this! ├── resources/ # original theme assets, edit this instead! │ ├── assets/ # all front-end assets │ │ ├── build/ # Webpack and ESLint config │ │ ├── fonts/ # theme fonts │ │ ├── images/ # theme images │ │ ├── scripts/ # theme JS scripts │ │ ├── styles/ # theme SCSS stylesheets │ │ └── config.json # settings for compiled assets │ ├── views/ # all theme Blade templates │ │ ├── layouts/ # base Blade templates │ │ └── partials/ # partial Blade templates │ ├── functions.php # Composer autoloader and theme includes, │ │ # normally you should not edit this unless │ │ # you know what you're doing │ ├── index.php # required by WordPress but left blank │ │ # intentionally, never edit this! │ ├── screenshot.png # the screenshot used in the WordPress admin │ └── style.css # required by WordPress, it should contain │ # only the theme meta information ├── vendor/ # Composer packages, never edit this! ├── composer.json # autoloading for `app/` files ├── composer.lock # Composer lock file, never edit this └── package.json # Node.js dependencies and scripts

또한 .editorconfig, .eslintrc.js, .stylelintrc.js, phpcs.xml 등과 같은 코드 편집기 및 IDE에서 사용하는 다른 파일도 있습니다.

다음은 기본 Sage 9 요구 사항에 대한 간략한 개요입니다.

워드프레스 >= 4.7
PHP >= 7.1.3(php-mbstring 활성화됨)
작곡가
Node.js >= 8.0.0
실

근본적인

Bedrock은 스테로이드의 WordPress와 같습니다!

Sage가 테마 개발을 개선한다면 Bedrock은 전체 WordPress 설치를 개선합니다. 개선된 폴더 구조 및 보안(예: 웹사이트 루트에 구성 파일이 없는 경우), 구성 및 ENV 파일, 적절한 종속성 관리(예, WordPress 플러그인 및 테마 포함)와 함께 최신 프로젝트 상용구 를 제공하여 이를 수행합니다. .

한 문장으로 설명하자면, Bedrock은 핵심 파일 및 필수 플러그인 설치를 자동화하는 독립형 WordPress 프로젝트라고 말할 수 있습니다.

파일 및 폴더 구조

기본 베드락 설치를 보면 처음에는 길을 잃을 수도 있습니다. Bedrock은 웹, 구성 및 종속성 파일을 자체 폴더로 분리합니다. 베어 본 구조는 다음과 같습니다.

 ├── config/ # WordPress configuration files │ ├── environments/ # configuration files for other │ │ │ # environments, they will override │ │ │ # production configuration │ │ ├── development.php # overrides for WP_ENV === 'development' │ │ └── staging.php # overrides for WP_ENV === 'staging' │ └── application.php # main configuration for production │ # environment, it's the equivalent of │ # the wp-config.php file ├── vendor/ # Composer packages, never edit this! ├── web/ # the new root folder of the webserver │ ├── app/ # your new wp-content folder │ ├── wp/ # WordPress core files, never edit this! │ ├── index.php # WordPress view bootstrapper │ └── wp-config.php # required by WordPress, never edit this! ├── .env # all environment variables: db name, │ # user and password, salts, current │ # environment, site urls, and others ├── composer.json # here you can manage versions of │ # WordPress, plugins and other │ # dependencies └── composer.lock # Composer lock file, never edit this

기타 덜 중요한 파일도 있습니다.

기반 요구 사항은 다음과 같습니다.

PHP >= 7.1
작곡가

격자

Trellis는 개발, 스테이징 및 프로덕션 서버를 원활하게 관리하기 위한 최신 LEMP 스택 으로, 가능한 한 서로 유사하게 유지하는 것을 목표로 합니다("개발 및 프로덕션 패리티"). 즉, 사용자 지정 WordPress 사이트가 개발 환경에서 작동하는 경우 프로덕션에서도 작동한다고 가정하는 것이 안전하며 자신 있게 배포할 수 있습니다.

로컬 개발을 위해 Trellis는 Vagrant를 사용하며 간단한 vagrant up 사용하면 적절한 최신 환경을 실행하는 가상 머신을 갖게 됩니다.

스테이징 및 프로덕션 환경에 대한 프로비저닝 및 배포는 Ansible에 수행할 작업을 알려주는 YAML 파일인 Ansible 플레이북으로 관리됩니다.

격자 제안 폴더 구조

Trellis는 단 두 개의 하위 폴더로 구성된 제안된 폴더 구조를 가지고 있습니다.

 ├── trellis/ # the clone of the Trellis repository └── site/ # the Bedrock-based WordPress website

그대로 두는 것이 좋지만 기호와 필요에 따라 사용자 정의할 수 있습니다.

격자 요구 사항

작곡가
버추얼박스 >= 4.3.10
방랑자 >= 2.1.0

그것을 사용해야 하는 이유

WordPress가 이미 그대로 작동하고 있다면 왜 더 복잡한 스택으로 전환하고 마스터하는 데 상당한 시간을 투자해야 합니까? 분명한 장점과 덜 분명한 장점이 있기 때문입니다. 그들이 무엇인지 봅시다.

프레임워크 불가지론적 시작 테마

너무 많은 워드프레스 스타터 테마는 당신이 좋아하거나 알지 못할 수도 있는 특정 CSS 프레임워크를 사용하도록 강요하지만 Sage는 완전히 프레임워크에 구애받지 않습니다. 설치하는 동안 Bootstrap 4, Bulma, Foundation, Tachyons, Tailwind CSS를 자동으로 포함하거나 처음부터 시작하거나 다른 것을 사용하려는 경우 프레임워크를 전혀 포함하지 않는 옵션이 있습니다(힌트: 최근 Tailwind를 좋아하기 시작했습니다. CSS 많이).

프로 팁: Windows 시스템에서 설치하는 동안 "TTY 모드는 Windows 플랫폼에서 지원되지 않습니다"라는 메시지가 표시될 수 있으며 프레임워크를 선택하거나 Sage를 구성할 수 없습니다. 자동 구성을 활용하려면 테마 폴더 내에서 이 세 가지 명령을 수동으로 실행해야 합니다.

 $ vendor\bin\sage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendor\bin\sage config # to specify your theme's dev URL and # theme directory. $ vendor\bin\sage preset # to set up the theme with one of the # supported frameworks or no # framework at all.

더 나은 종속성 및 패키지 관리

Roots 스택은 Composer를 사용하여 WordPress 코어, 플러그인 및 테마를 포함한 모든 종속성과 패키지를 관리합니다. 이것은 타사 도구를 사용하여 WordPress 업데이트(예: ManageWP, MainWP 또는 InfiniteWP)를 관리하는 경우 문제가 될 수 있지만 누군가는 모든 것을 버전 제어하면 더 많은 제어가 가능하고 이전 작업으로 더 쉽게 롤백할 수 있다고 주장할 수 있습니다. 뭔가 잘못되면 버전.

또한 Sage는 Yarn을 애플리케이션 코드에 대한 패키지 및 종속성 관리자로 사용하고 빌드 프로세스를 시작합니다.

더 나은 템플릿 파일

WordPress에는 실제 템플릿 엔진이 없기 때문에 Sage는 이를 보완하기 위해 Laravel's Blade를 채택했으며 DRY 원칙인 Don't Repeat Yourself를 따릅니다.

6줄의 코드로 기본 single.blade.php 템플릿 파일은 다음과 같습니다.

 @extend('layouts.app') @section('content') @while(have_posts()) @php the_post() @endphp @include('partials.content-single-'.get_post_type()) @endwhile @endsection

블레이드 템플릿 엔진은 보기와 컨트롤러를 완전히 분리하며 해당 구문은 PHP 태그보다 더 우아하고 간결하며 읽기 쉽고 작성하기 쉽습니다. 여기에서 경험적 규칙은 모든 PHP 코드를 템플릿 파일에서 제외하는 것입니다(또는 최소한 시도).

Blade를 사용할 때의 또 다른 이점은 템플릿 상속입니다. 기본 레이아웃 템플릿(기본값은 /resources/views/layouts/app.blade.php )은 공통 웹사이트 요소를 포함하는 블록을 정의한 다음 하위 템플릿에 상속됩니다. 템플릿 상속은 개별 템플릿에서 반복되는 마크업을 제거하고 건조한 상태로 유지하는 데 유용합니다.

브라우저 동기화

yarn start 를 실행하면 Browsersync 세션이 시작됩니다. Browsersync는 개발하는 동안 동기화된 브라우저 테스트를 위한 모듈입니다. 프론트 엔드 자산에 대한 변경 사항을 감시하고 Webpack과 함께 작동하여 변경 사항을 브라우저 세션에 자동으로 삽입합니다.

빠르고 쉽고 안전한 WordPress 배포

Trellis는 다운타임이 없는 WordPress 배포를 제공합니다. 배포를 시작하면 Trellis는 저장소를 git clone하고, composer install을 실행한 다음 현재 프로덕션에서 제공되는 파일을 직접 편집하지 않도록 현재 릴리스로 심볼릭 링크를 업데이트합니다.

Bedrock을 사용할 때 Trellis는 또한 구성이 거의 필요하지 않습니다.

단점

전체 Roots 스택을 사용할 때의 유일한 단점은(전혀 문제로 간주되어서는 안 되는 새로운 것을 배우는 것 외에) Kinsta, DigitalOcean droplet 또는 웹 루트 경로를 업데이트하는 옵션과 함께 최소한 SSH, Composer 및 WP-CLI를 지원합니다.

이것은 대부분의 저렴한(ish) 공유 호스팅을 게임에서 제외하고 새 프로젝트를 시작하기 전에 귀하 및/또는 귀하의 클라이언트가 고려해야 하는 사항입니다.

시작하는 방법

이것은 유명한 "WordPress 5분 설치"에 대한 새로운 해석으로 간주될 수 있지만 현대 프론트 엔드 개발자를 위한 것입니다. 나중에 개발할 때 약간의 복잡성이 추가되지만 결국 얻을 수 있는 이점은 확실히 그만한 가치가 있습니다.

우리는 전체 스택(Sage, Bedrock 및 Trellis)을 채택하는 데 중점을 둘 것이지만 이들 중 하나만 사용하거나 조합하여 사용할 수 있습니다. Sage는 모든 WordPress 설치에서 독립 실행형 테마의 시작점으로 사용할 수 있습니다. Bedrock은 원하는 모든 WordPress 테마와 함께 사용할 수 있습니다. Trellis 배포는 Bedrock 기반 사이트용으로 구성되어 필요한 모든 것을 처리하지만 약간의 수정만 하면 거의 모든 요구 사항에 맞게 사용자 지정할 수 있습니다.

새 프로젝트를 만드는 방법

Trellis, Bedrock 및 Sage를 사용하여 새 WordPress 프로젝트를 설정하는 것은 몇 가지 명령줄만 있으면 매우 쉽습니다.

원하는 폴더(예: example.com )에 Trellis를 설치합니다.

 $ mkdir example.com && cd example.com $ git clone --depth=1 [email protected]:roots/trellis.git $ rm -rf trellis/.git

/site/ 하위 폴더에 Bedrock을 설치합니다.

 $ composer create-project roots/bedrock site $ cd site/web/app/themes/

Sage 설치 및 빌드:

 $ composer create-project roots/sage your-theme-name $ cd your-theme-name/ $ yarn && yarn build

배포

공식 문서에 따라 모든 것을 올바르게 구성했다면 스테이징 또는 프로덕션에 배포하는 것이 훨씬 더 쉽습니다. 명령줄 하나만 있으면 됩니다( example.com/trellis/ 폴더에서 실행).

 $ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"

다음을 실행하기만 하면 배포를 쉽게 롤백할 수도 있습니다.

 $ ansible-playbook rollback.yml -e "site=<domain> env=<environment>

Windows에서 개발 환경 설정에 대한 팁

Google에서 Roots 스택, 특히 Trellis를 설치하고 사용하는 방법에 대해 검색하면 Linux 또는 MacOS에 중점을 둔 많은 자습서를 찾을 수 있지만 두 가지 주요 문제를 찾을 수 있는 Windows에 대한 정보는 거의 없습니다. Ansible을 사용할 수 없습니다. Windows의 경우 Vagrant는 일반적으로 Windows 시스템에서 매우 느립니다.

이 기사에 대해 처음 생각했을 때 Windows용 공식 Trellis 문서는 Vagrant 가상 머신 내에서 Ansible을 실행하도록 제안했지만 이것은 일종의 해킹 방식이었고 그다지 안정적이지 않았습니다.

그 이후로 그들은 WSL(Linux용 Windows 하위 시스템)을 사용하여 모든 것을 설정하는 방법에 대한 적절한 지침으로 설명서를 업데이트했으므로 바퀴를 재발명하고 이에 대한 자습서를 작성할 필요가 없습니다. Trellis를 설치하기 전에 세 페이지 분량의 자세한 단계별 지침이 있음을 아는 것이 좋습니다. Windows 설치, Windows 설치: Sage 및 Windows 설치: Trellis.

즐거운 코딩!

관련: 최신 WordPress 개발에 접근하는 방법(1부, 프론트 엔드) 및 2부(백엔드)