WordPress와 함께 Composer 사용

게시 됨: 2022-06-30

WordPress는 2003년부터 사용되었으며 웹사이트를 시작하려는 대부분의 사람들을 위한 기본 도구가 되었습니다. 블로그 엔진이라는 뿌리에서 먼 길을 왔지만 기본 기술은 사용자 경험만큼 도약하지 못했습니다.

WordPress 개발은 여전히 ​​2003년에 존재했던 많은 표준을 중심으로 진행됩니다. 이렇게 하면 필요한 기술적인 이해도가 낮아 사람들이 더 쉽게 액세스할 수 있지만 많은 새로운 개발 리소스가 기본적으로 WordPress와 호환되지 않는다는 의미이기도 합니다.

오늘은 Composer라는 새로운 도구 중 하나를 살펴보겠습니다. WordPress 워크플로에 어떻게 맞는지 살펴보고 시도해 보고 싶은 이유에 대해 논의해 보겠습니다.

작곡가 란 무엇입니까?

작성하는 모든 코드에는 종속성이 있습니다. WordPress 플러그인을 작성하는 경우 가장 큰 종속성은 WordPress 자체입니다. WordPress가 제공하는 핵심 기능이 없으면 플러그인이 전혀 유용하지 않을 수 있습니다. WordPress 자체 외부에서 SOAP 기반 API와 인터페이스하려면 nusoap과 같은 최신 SOAP 클라이언트가 필요할 수 있습니다.

과거에는 대부분의 사람들이 단순히 nusoap의 저장소를 플러그인의 디렉토리에 복사한 다음 라이브러리를 사용하는 데 필요한 파일을 포함했습니다. 여기에서 Composer가 개입하여 종속성 관리의 일부를 단순화할 수 있습니다.

Composer는 종속성 관리자입니다. 종속성을 쉽게 설치하고 관리할 수 있도록 특별히 설계되었습니다. 이는 팀에서 작업하고 팀의 모든 구성원이 개발 작업을 수행할 때 동일한 라이브러리를 사용하도록 하려는 경우 특히 중요할 수 있습니다.

기본적으로 Composer는 설치한 종속성과 사용하려는 종속성의 버전을 자세히 설명하는 JSON 파일입니다. 아래에서 nusoap 종속성을 포함하는 기본 예를 볼 수 있습니다.

{

"필요하다": {

"econea/nusoap": "^0.9.10"

}

}

내 플러그인에서 composer require econea/nusoap을 실행하면 nusoap이 설치되고 지정된 버전으로 잠깁니다. 이 경우 0.9.10을 사용하고 있으며 Composer에 종속성을 업그레이드하도록 지시하지 않는 한 계속 사용할 것입니다.

이것은 업데이트가 있는지 확인하고 수동으로 내 프로젝트에 다운로드할 필요 없이 작곡가 업데이트를 사용하여 모든 종속성을 업데이트할 수 있기 때문에 단순히 nusoap을 다운로드하고 포함하는 것보다 이점이 있습니다. Composer는 이 수준에서 리소스 관리를 인수합니다.

작곡가 시작하기

작곡가를 설치하는 것은 매우 간단합니다.

Windows에서

Windows를 사용하는 경우 프로세스를 단순화하기 위해 제공된 설치 프로그램이 있습니다. 최신 버전의 Composer를 설치하고 프로젝트에 대해 전역적으로 액세스할 수 있도록 합니다.

리눅스/유닉스/맥OS

이러한 플랫폼에서 Composer 설정을 위한 몇 가지 단계가 더 있습니다. 시작하려면 Composer를 다운로드하고 설정하는 데 필요한 명령을 실행하십시오.

php -r "복사('https://getcomposer.org/installer', 'composer-setup.php');"

{'feedf -r "if (hash_file('sha384', 'composer-setup.php') === '756890a4488ce9024fc62c56153228907f1545c1628516cbf63f885e03639d47e7 } else { echo '설치 프로그램이 손상되었습니다'; unlink('작곡기 설정.php'); } 에코 PHP_EOL;”

PHP 작곡가-setup.php

php -r "unlink('composer-setup.php');"

다음으로, 로컬 개발을 위해 Composer를 전역적으로 실행하려고 할 것이므로 Composer를 사용하고자 할 때 언제든지 사용할 수 있도록 기본 설치를 조정해야 합니다. Composer를 다운로드한 동일한 디렉토리에서 다음 명령을 실행하여 Composer를 전역적으로 사용할 수 있도록 이동할 수 있습니다.

mv composer.phar /usr/local/bin/composer

작곡가 업그레이드

Windows 및 macOS에서 최신 버전의 Composer로 업그레이드하려면 작곡가 자체 업데이트를 실행하기만 하면 됩니다. Linux/Unix를 사용하는 경우 시스템이 최신 버전을 확인하도록 sudo apt update && upgrade를 실행해야 합니다. 그러면 작곡가 자체 업데이트를 실행하여 최신 버전을 얻을 수 있습니다.

이제 설정이 완료되었으므로 Composer를 사용하여 WordPress를 설치하는 방법을 살펴보겠습니다.

Composer로 워드프레스 설치

Composer로 전체 사이트를 관리하고 싶다면 어떻게 하시겠습니까? 먼저 WordPress가 프로젝트의 종속성인지 아니면 프로젝트의 핵심인지 결정해야 합니다. 예, 약간의 두뇌 회전.

고객의 최종 목표는 WordPress를 설치하는 것이 아니기 때문에 WordPress는 프로젝트의 종속성으로 간주될 수 있습니다. 그들은 상점이나 블로그를 원하고 WordPress 설치에 따라 다릅니다. 이것은 Roots와 같은 프로젝트가 Bedrock이라는 Composer 기반의 Bedrock WordPress 설정으로 취하는 입장입니다.

Bedrock을 사용한다는 것은 WPackagist가 이미 설정되어 있기 때문에 Composer에 WPackagist에 대해 말할 필요가 없다는 것을 의미합니다. Composer로 전체 사이트를 관리하려는 경우 시작하는 것이 좋습니다.

Bedrock을 설치하려면 다음 명령을 실행하십시오.

작곡가 create-project 루트/기반

그러면 다음과 같은 파일 구조가 제공됩니다.

├── 작곡가.json

├── .env

├── 구성

│ ├── application.php

│ └── 환경

│ ├── 개발.php

│ ├── 스테이징.php

│ └── 프로덕션.php

├── 벤더

└── 웹

├── 앱

│ ├── 뮤 플러그인

│ ├── 플러그인

│ ├── 테마

│ └── 업로드

├── wp-config.php

├── index.php

└──

이것은 표준 WordPress 설정과 매우 다릅니다. 시작하려면 설치 루트에 composer.json 파일이 있어야 합니다. 여기에서 Composer 구성을 볼 수 있습니다.

.env 파일은 다양한 데이터베이스 구성을 저장할 수 있는 곳입니다. 이것은 로컬 사이트와 라이브 사이트의 데이터베이스 비밀번호와 사용자 이름이 다르기 때문에 필요합니다. 기본 wp-config.php 파일은 .env 파일에 넣은 변수를 이해할 것입니다. 왜냐하면 Bedrock은 데이터베이스 연결 정보에 하드 코딩하는 대신 이러한 변수를 사용하기 때문입니다.

Git 저장소에서 .env 파일을 무시해야 합니다. 새 사이트를 구성할 때 필요한 데이터베이스 구성 정보와 함께 새 .env 파일을 추가합니다.

Bedrock을 시작하기 위해 여기에서 설정해야 하는 몇 가지 다른 변수가 있으며, 모두 해당 문서에 자세히 설명되어 있습니다.

config 폴더 아래에는 사용할 환경에 대한 다양한 기본 구성이 있습니다. 개발 시 오류 보고 기능이 켜지고 프로덕션 환경에서는 오류 로깅이 사이트의 원활한 작동을 방해하지 않도록 합니다.

Bedrock을 기반으로 하면 이제 Composer를 사용하여 WPackagist를 통해 WordPress 플러그인을 설치할 수 있습니다.

WPackagist는 WordPress 테마 및 플러그인 저장소의 미러입니다. 이것은 기본적으로 대부분의 플러그인과 테마를 Composer가 설치할 수 없기 때문에 필요합니다. 미러는 플러그인 관리에 Composer를 사용할 수 있도록 각 플러그인에 필요한 파일을 추가합니다.

Bedrock 기반 WordPress 설치에 WooCommerce를 설치하려면 먼저 WooCommerce가 필요하고 작곡가에는 wpackagist-plugin/woocommerce가 필요합니다. 그런 다음 Composer에 종속성을 설치하도록 지시해야 합니다.

이제 WordPress 설치의 관리 영역으로 이동하여 WooCommerce를 활성화하고 사이트를 구축할 수 있습니다. 새로운 버전이 나올 때 WooCommerce를 업데이트하거나 WordPress를 업데이트하려면 작곡가 업데이트를 실행해야 합니다.

이것은 Composer 기반 프로젝트가 약간의 문제에 빠질 수 있는 곳입니다. WordPress 관리자를 통해 업데이트를 실행하면 Composer가 예상하는 것과 WordPress가 설치한 것이 일치하지 않습니다. Composer를 사용하려는 경우 업데이트 도구로 계속 사용하고 WordPress 관리자를 통해 작동하지 마십시오.

언제 작곡가를 사용해야 합니까 ?

많은 분들이 Composer가 WordPress 개발을 위한 훌륭한 도구인 이유를 궁금해하실 것입니다. WordPress는 Composer를 염두에 두고 제작되지 않았으므로 제대로 작동하려면 몇 가지 문제를 해결해야 합니다.

플러그인 및 테마 개발자의 경우 Composer를 사용하면 더 넓은 PHP 에코시스템에서 가져와야 하는 종속성을 더 쉽게 처리할 수 있습니다. WordPress 개발자의 경우 주장이 덜 명확합니다. 일부는 Roots처럼 Composer를 사용하여 전체 사이트를 관리하는 것을 좋아합니다. 이렇게 하면 Git에서 관리하는 파일 수가 줄어들 수 있지만 내게는 그렇게 매력적인 사례처럼 보이지 않았습니다.

내가 좋아하는 경우는 Composer가 다른 환경에 대해 다른 종속성을 쉽게 가질 수 있다는 것입니다. 그런 다음 배포 프로세스를 사용하여 이러한 종속성을 환경에 배포할 수 있으며 수동으로 관리할 필요가 없습니다.

개발자는 클라이언트의 요구 사항도 고려해야 합니다. 사이트를 장기간 관리할 개발 팀이 없는 경우 비표준 WordPress 설치에 문제가 발생할 수 있습니다. 어떤 경우에는 호스트가 WordPress를 설치하고 사용하는 일반적인 방법을 사용하지 않기 때문에 지원을 사용할 수 없다고 말할 수 있습니다. 고객에게 서비스를 제공할 때는 항상 사용하는 멋진 기술과 고객이 장기적으로 처리할 수 있는 기술 간의 균형을 유지해야 합니다.

이러한 이유만으로 저는 전체 사이트 프로젝트에서 Composer를 사용하지 않습니다. 내 고객은 몇 년 동안 매일 관리해야 하며 추가 장벽을 설정하고 싶지 않습니다. 우리는 둘 다 그들의 사이트가 앞으로 몇 년 동안 원활하게 운영되기를 바랍니다.

최신 기술로 PHP 기술을 업그레이드하려는 경우 Composer가 WordPress 워크플로에 어떻게 적용되는지 확실히 살펴봐야 합니다.