플러그인 개발에서 WordPress 상용구의 중요성-PHP 튜토리얼-php.cn

지난 5~10년 동안 웹사이트와 웹용 애플리케이션을 구축하는 것은 사람들이 90년대에 구축한 많은 것들보다 훨씬 더 복잡해졌습니다. 페이지에 귀여운 애니메이션을 만들기 위해 대문자 HTML, 테이블 기반 레이아웃, 보기 흉한 JavaScript를 사용해 수동으로 웹사이트를 만드는 시대는 지났습니다.

이제 우리는 브라우저에서 실행되는 완전한 소프트웨어 애플리케이션을 구축하는 데 도움이 되는 다양한 기술, 프레임워크 및 언어를 보유하고 있습니다.

개발자가 되기에 좋은 시기입니다.

보일러플레이트는 다양한 기술로 인해 점점 더 인기를 얻고 있습니다. 익숙하지 않은 분들을 위해 설명하자면, 상용구는 기본적으로 개발자가 모든 사이트 및/또는 애플리케이션에 공통적인 코드나 특정 구성 요소를 작성하지 않고도 프로젝트를 시작할 수 있도록 도와주는 코드 기반입니다.

물론 필요 이상으로 투박하고 복잡해질 정도로 과도하게 사용할 수도 있지만 모든 좋은 기능은 핵심 알고리즘, 코드 및 작성에 집중할 수 있도록 기초를 다지는 것, 즉 일종의 스캐폴딩을 제공하는 것을 의미합니다. 귀하의 프로젝트와 필요에 따라 고유한 기능을 제공합니다.

약 1년 전 저는 WordPress Plugin Boilerplate와 WordPress Widget Boilerplate라는 두 가지 프로젝트 작업을 시작했습니다. 각 프로젝트는 개발자에게 WordPress 모범 사례를 사용하여 플러그인을 구축하기 위한 기반을 제공하는 것을 목표로 했습니다. 고맙게도 이러한 프로젝트는 오픈 소스 커뮤니티로부터 많은 기여를 받아 최대한 강력해질 수 있습니다.

이 프로젝트를 유지하는 한 가지 측면은 내가 왜 이런 식으로 정리하는지에 대한 질문을 자주 받는다는 것입니다. 따라서 이 두 부분으로 구성된 시리즈에서는 상용구 파일과 이를 제가 하는 방식으로 구성하는 이유(및 장점)를 살펴본 다음 이러한 상용구 파일 중 하나를 사용하여 간단한 플러그인을 구축하여 방법에 대한 예를 제공합니다. 향후 프로젝트에 사용하세요.

파일 정리

크든 작든 상관없이 소프트웨어 애플리케이션을 구축하는 핵심 구성 요소 중 하나는 프로그램 구성 방식입니다. 이는 클래스 및/또는 함수가 관련되는 방식(다른 기사의 주제임)뿐만 아니라 파일이 구성되는 방식에도 국한되지 않습니다.

이상적으로는 파일을 단순히 디렉터리에 덤프한 다음 다른 개발자가 프로젝트를 유지 관리하기 위해 선별하도록 남겨두어서는 안 됩니다. 대신, 일관성 있는 디렉토리에 논리적으로 구성되어야 하며, 이름이 명확하게 지정되어야 하며, 프로젝트에 기여하는 개발자가 특정 파일이 어디에 있는지, 자신이 추가한 파일을 어디에 넣을지 알기 위해 거의 노력할 필요가 없어야 합니다.

옛 속담과 같습니다:

모든 것이 제자리에 있는 곳입니다.

이 두 가지 상용구를 만들 때 저는 이 특정 원칙을 따르려고 노력했을 뿐만 아니라 Ruby on Rails가 레이아웃을 모델링하는 방식에서 영감을 얻으려고 노력했습니다. 특히 그들은 "구성보다 규칙"을 선호합니다.

분명히 WordPress는 Rails도 아니고 MVC 프레임워크도 아니며 저는 그렇게 되고 싶지 않습니다. 나는 단지 우리 환경에서 우리의 삶을 더 쉽게 만들기 위해 다른 개발자들로부터 좋은 아이디어를 빌리고 싶을 뿐입니다.

핵심 플러그인 파일

플러그인이 아무리 간단하든 복잡하든 적어도 하나의 PHP 파일을 포함해야 합니다. 이 파일은 핵심 플러그인 파일 역할을 하며 플러그인에 생명을 불어넣는 모든 코드, 로직 및 기능을 포함합니다.

다양한 플러그인을 살펴보면 개발자가 다양한 접근 방식을 취하고 있음을 알 수 있습니다.

일부에는 모든 콘텐츠가 하나의 파일
일부 관련 기능을 별도의 파일로 나누고 핵심 플러그인 파일을 사용하여 각 기능을 간단히 포함합니다.
일부는 일부 프런트엔드 코드를 서버측 코드와 분리합니다

저는 이러한 방법(또는 언급된 방법)이 다른 방법보다 나은 이유를 증명하기 위해 여기에 있는 것이 아닙니다. 보드가 이런 방식으로 배치된 이유와 이것이 어떻게 작동하는지 증명하려는 것이 아닙니다.

README 파일을 기반으로 한 플러그인 홈페이지입니다.

핵심 플러그인 파일 외에도 WordPress 플러그인에는 최종 사용자에게 플러그인 사용 방법에 대한 지침을 제공하고 WordPress 플러그인 저장소의 페이지를 채우는 추가 정보 파일도 필요합니다.

가장 기본적인 수준에서 WordPress 플러그인에 필요한 것은 핵심 플러그인 파일과 추가 정보 파일입니다. 이 두 파일만 사용하여 매우 복잡한 플러그인을 구축할 수 있지만 유지 관리가 매우 어려워질 수 있습니다. 특히 다른 개발자가 기여하기 시작하면 결국 예상치 못한 버그가 발생할 수 있습니다.

그래서 저는 코드를 논리적으로 분리하는 구성 요소를 좋아합니다.

조회수

View는 MVC 패턴에서 빌린 단어입니다(Rails에서 영감을 얻었습니다).

뷰는 관리자와 웹 사이트 방문자를 위해 화면에 요소를 렌더링하는 프런트 엔드 마크업으로 정의할 수 있습니다.

그게 다예요. 쉽지요?

물론, 우리는 PHP로 작업하고 있기 때문에 코드 전체에 작은 PHP 태그가 배치될 것입니다. 그러나 뷰 파일의 대부분은 클래스 및 ID 속성이 있는 HTML이어야 합니다.

상용구에는 두 가지 보기가 있습니다.

admin.php는 관리자 대시보드에서 사용자에게 요소를 렌더링하는 데 사용되는 보기입니다
widget.php 또는 plugin.php는 웹사이트 방문자에게 요소를 렌더링하는 데 사용되는 보기입니다

물론 플러그인에는 대시보드나 웹사이트 방문자 보기가 없을 수도 있습니다. 이 경우 views 디렉토리가 삭제되고 이를 핵심 플러그인 파일에 포함시키는 코드가 제거됩니다.

스타일 시트

프런트 엔드 개발을 수행하는 사람이라면 누구나 스타일시트를 관리하는 방법을 알고 있으며 스타일시트를 구성하는 자신만의 방법이 있을 것이므로 이것은 상용구의 사소한 구성 요소입니다.

그러나 일관성을 위해 css 디렉토리에 모든 스타일시트가 보관된다는 점을 언급할 가치가 있습니다. 또한 이러한 파일은 관련 뷰와 동일한 명명 규칙을 따릅니다.

구체적:

admin.css는 관리자 대시보드에서 사용자의 요소 스타일을 지정하는 데 사용되는 보기입니다
widget.css 또는 plugin.css는 웹사이트 방문자를 위한 요소의 스타일을 지정하는 데 사용되는 뷰입니다

LESS나 SASS에 디렉터리 구조를 도입하는 것을 고려해 봤지만 개발에 너무 독선적이며 상용구가 가고 싶은 방향도 아닌 것 같습니다. 차라리 개발자들이 자신만의 스타일을 선택해서 거기에 접목시키는 게 좋을 것 같아요.

이 작업을 수행하기 위해 일반적으로 내 프로젝트에서 스타일시트를 구성하는 방법은 css 디렉터리 내에 dev 디렉터리를 가져온 다음 admin .less 및 plugin.less 파일을 가져온 다음 컴파일하는 것입니다. 루트 css 디렉토리로 이동하세요.

이것은 조직의 상용구 접근 방식을 계속 따르면서 LESS 파일을 포함할 수도 있습니다.

자바스크립트

스타일시트와 마찬가지로 JavaScript 파일은 WordPress를 사용하고 테마나 플러그인을 개발하는 대부분의 사람들이 JavaScript를 사용했기 때문에 상용구의 간단한 구성 요소입니다.

안타깝게도 사용자와 개발자로서 WordPress에서 JavaScript를 사용할 때 가장 실망스러운 부분 중 하나는 개발자가 모범 사례를 따르지 않는 경우가 많다는 것입니다.

일반적으로 개발자는 항상 다음을 수행해야 합니다.

WordPress에 번들로 제공되는 jQuery 버전을 사용하세요
익명 함수를 사용하여 jQuery '$' 함수에 액세스하여 충돌을 피하세요
jQuery를 다른 플러그인으로 등록 취소하지 마세요. 테마에서 사용 중일 수 있습니다.

즉, 스타일시트 및 뷰와 같은 상용구 파일은 다음과 같이 구성됩니다.

admin.js는 관리자 대시보드에서 사용자 요소의 동작을 관리하는 데 사용되는 JavaScript입니다
widget.js 또는 plugin.js는 방문자의 요소 동작을 관리하는 데 사용되는 JavaScript

스타일시트와 마찬가지로 개발자는 플러그인을 게시하기 전에 플러그인의 JavaScript를 검토 및/또는 축소할 수도 있습니다. JavaScript 파일 관리 방법에 대해 너무 엄격한 것을 피하기 위해 상용구에는 하위 디렉터리가 포함되어 있지 않지만, 사전 확인되고 미리 축소된 JavaScript를 순서대로 관리하기 위해 js 디렉터리 내에 dev 디렉터리를 만드는 경우가 많습니다.

언어

플러그인 구축의 한 가지 측면은 다른 언어를 사용하는 사람들이 플러그인에 액세스하고 번역할 수 있도록 보장하는 것입니다. 최대한 단순하게 유지하기 위해 상용구에는 lang 디렉터리와 프레임워크 plugin.po 파일도 포함되어 있습니다.

이 파일은 POEdit과 함께 사용하도록 설계되었으므로 개발이 완료되면 모든 현지화된 문자열을 쉽게 처리할 수 있습니다.

이미지 및 기타 자산은 어떻습니까?

스타일시트 및 JavaScript 파일을 제외하고 상용구는 이미지와 같은 다른 자산을 관리하기 위한 디렉터리나 규칙을 제공하지 않습니다.

다시 말하지만, 지나치게 자기 주장을 피하는 동시에 개발자가 핵심 기능에 집중할 수 있도록 충분한 기반을 제공하는 것이 균형을 이루고 있습니다. 모든 플러그인에 관리 CSS, JavaScript 또는 보기가 포함되어 있는 것은 아니지만 이미지 및 기타 리소스를 포함하는 것보다 더 일반적입니다.

그러나 제공된 규칙에 따르면 assets 디렉터리, images 디렉터리, icons 디렉터리 또는 사용할 수 있는 다른 유형의 파일을 만들 수 있습니다.

왜 귀찮게 하나요?

WordPress 위젯 템플릿

그럼 이 모든 것의 요점은 무엇인가요? 파일을 열고 모든 코드를 작성하기 시작하는 것이 쉽지 않을까요? 정말. 하지만 대부분의 개발은 제품이 출시된 후에 이루어지며, 플러그인 개발에 대해 진지하게 생각하고 있다면 제품을 만드는 일을 하고 있다는 점을 기억하세요.

그래서 끝을 염두에 두고 시작해야 합니다. 파일 정리, 파일 이름 지정 등을 위해 일관된 체계를 사용하세요.

장기적으로 개발을 단순화하여 귀하와 기여하는 개발자가 파일 관리 방법, 새 파일을 저장할 위치, 필요할 때 종속성을 찾을 수 있는 위치를 알 수 있습니다
플러그인을 향상할 수 있는 공통 구성 및 패턴을 제공하여 유지 관리가 더 쉬워집니다
코드베이스가 다루기 어려워질 때 광범위한 리팩토링 없이 첫 번째 버전 이상으로 프로젝트를 확장하는 능력이 향상되었습니다

가장 중요한 것은 스캐폴딩을 통해 개발자가 방해받지 않고 제품의 핵심 비즈니스 로직 작업을 쉽게 시작할 수 있어야 한다는 것입니다.