최신 PHP로 WordPress 코드 개선하기

WordPress는 15년 전에 탄생했으며 역사적으로 이전 버전과의 호환성을 유지했기 때문에 최신 버전의 코드에서는 최신 버전의 PHP가 제공하는 최신 기능을 최대한 활용할 수 없었습니다. 최신 버전의 PHP는 7.3.2이지만 WordPress는 여전히 PHP 5.2.4까지 지원합니다.

그러나 그런 날은 곧 끝날 것입니다! WordPress는 최소 PHP 버전 지원을 업그레이드하여 2019년 4월에 최대 PHP 5.6으로, 2019년 12월에 PHP 7(모든 것이 계획대로 진행되는 경우)로 업그레이드할 예정입니다. 그런 다음 마침내 클라이언트의 사이트가 손상될 염려 없이 PHP의 명령형 프로그래밍 기능을 사용할 수 있습니다. 만세!

WordPress의 15년 동안의 기능 코드는 개발자가 WordPress를 사용하여 구축하는 방식에 영향을 미쳤기 때문에 사이트, 테마 및 플러그인은 기꺼이 업그레이드를 받을 수 있는 최적이 아닌 코드로 가득 차 있을 수 있습니다.

이 문서는 두 부분으로 구성되어 있습니다.

1. 가장 관련성이 높은 새로운 기능
   PHP 버전 5.3, 5.4, 5.5, 5.6 및 7.0에 추가 기능이 추가되었으며(PHP 6은 없음) 가장 관련성이 높은 기능을 살펴보겠습니다.
2. 더 나은 소프트웨어 구축
   이러한 기능과 이러한 기능이 더 나은 소프트웨어를 구축하는 데 어떻게 도움이 되는지 자세히 살펴보겠습니다.

먼저 PHP의 "새로운" 기능을 살펴보겠습니다.

클래스, OOP, SOLID 및 디자인 패턴

클래스와 객체가 PHP 5에 추가되었으므로 WordPress는 이미 이러한 기능을 사용하고 있지만 그다지 광범위하거나 포괄적이지 않습니다. WordPress 코딩 패러다임은 대부분 객체 대신 함수형 프로그래밍(응용 프로그램 상태가 없는 함수를 호출하여 계산 수행)입니다. 지향 프로그래밍(OOP)(객체의 상태를 조작하여 계산 수행). 따라서 클래스와 객체와 OOP를 통해 사용하는 방법도 설명합니다.

OOP는 모듈식 응용 프로그램을 생성하는 데 이상적입니다. 클래스를 사용하면 구성 요소를 생성할 수 있습니다. 각 구성 요소는 특정 기능을 구현하고 다른 구성 요소와 상호 작용할 수 있으며 캡슐화된 속성 및 상속을 통해 사용자 지정을 제공하여 높은 수준의 코드 재사용성을 가능하게 합니다. 결과적으로 개별 기능이 응용 프로그램과 분리되어 자체적으로 처리될 수 있으므로 응용 프로그램을 테스트하고 유지 관리하는 비용이 더 저렴합니다. 개발자는 이미 개발된 구성 요소를 사용하고 각 응용 프로그램에 대한 바퀴를 재발명할 필요가 없기 때문에 생산성도 향상됩니다.

클래스에는 private (정의하는 클래스 내에서만 액세스 가능), protected (정의 클래스와 그 조상 및 상속 클래스 내에서 액세스 가능) 및 public (어디서나 액세스 가능)을 사용하여 가시성을 제공할 수 있는 속성과 기능이 있습니다. 함수 내에서 클래스 이름 앞에 $this-> 를 추가하여 클래스 속성에 액세스할 수 있습니다.

 class Person { protected $name; public function __construct($name) { $this->name = $name; } public function getIntroduction() { return sprintf( __('My name is %s'), $this->name ); } }

클래스는 new 키워드를 통해 객체로 인스턴스화되며, 그 후에 -> 를 통해 해당 속성과 기능에 액세스할 수 있습니다.

 $person = new Person('Pedro'); echo $person->getIntroduction(); // This prints "My name is Pedro"

상속하는 클래스는 상위 클래스의 public 및 protected 함수를 재정의할 수 있으며 상위 함수에 parent:: 를 추가하여 상위 함수에 액세스할 수 있습니다.

 class WorkerPerson extends Person { protected $occupation; public function __construct($name, $occupation) { parent::__construct($name); $this->occupation = $occupation; } public function getIntroduction() { return sprintf( __('%s and my occupation is %s'), parent::getIntroduction(), $this->occupation ); } } $worker = new WorkerPerson('Pedro', 'web development'); echo $worker->getIntroduction(); // This prints "My name is Pedro and my occupation is web development"

메서드를 abstract 할 수 있습니다. 즉, 상속하는 클래스에서 구현해야 합니다. abstract 메서드를 포함하는 클래스는 그 자체로 abstract 되어야 합니다. 즉, 인스턴스화할 수 없습니다. 추상 메서드를 구현하는 클래스만 인스턴스화할 수 있습니다.

 abstract class Person { abstract public function getName(); public function getIntroduction() { return sprintf( __('My name is %s'), $this->getName() ); } } // Person cannot be instantiated class Manuel extends Person { public function getName() { return 'Manuel'; } } // Manuel can be instantiated $manuel = new Manuel();

클래스는 또한 클래스를 개체로 인스턴스화하지 않고 클래스 자체 아래에 있는 static 메서드와 속성을 정의할 수 있습니다. 이들은 클래스 내에서 self:: 를 통해 액세스하고 클래스 외부에서 클래스 이름 + :: 를 통해 액세스합니다.

 class Factory { protected static $instances = []; public static function registerInstance($handle, $instance) { self::$instances[$handle] = $instance; } public static function getInstance($handle) { return self::$instances[$handle]; } } $engine = Factory::getInstance('Engine');

OOP를 최대한 활용하기 위해 SOLID 원칙을 사용하여 응용 프로그램에 대한 건전하지만 쉽게 사용자 정의할 수 있는 기반을 구축하고 테스트 및 테스트된 방식으로 특정 문제를 해결하기 위한 디자인 패턴을 사용할 수 있습니다. 설계 패턴은 표준화되고 잘 문서화되어 있어 개발자가 응용 프로그램의 여러 구성 요소가 서로 어떻게 관련되어 있는지 이해하고 전역 변수(예: global $wpdb )의 사용을 방지하는 데 도움이 되는 질서 있는 방식으로 응용 프로그램을 구조화하는 방법을 제공합니다. 지구 환경을 오염시키는 것.

네임스페이스

네임스페이스는 PHP 5.3에 추가되었으므로 현재 WordPress 코어에서 완전히 누락되었습니다.

네임스페이스를 사용하면 코드베이스를 구조적으로 구성하여 서로 다른 항목이 동일한 이름을 가질 때 충돌을 피할 수 있습니다. 운영 체제 디렉토리와 유사한 방식으로, 서로 다른 디렉토리에 저장되어 있는 한 동일한 이름을 가진 다른 파일을 가질 수 있습니다. 네임스페이스는 PHP 항목(클래스, 특성, 인터페이스 등)에 대해 동일한 캡슐화 트릭을 수행하여 서로 다른 항목을 서로 다른 네임스페이스에 배치하여 동일한 이름을 가질 때 충돌을 방지합니다.

네임스페이스는 타사 라이브러리와 상호 작용할 때 필수 항목입니다. 항목 이름이 지정되는 방식을 제어할 수 없기 때문에 항목에 "파일", "로거" 또는 "업로더"와 같은 표준 이름을 사용할 때 충돌 가능성이 있습니다. 또한, 단일 프로젝트 내에서도 네임스페이스는 "MyProject_Controller_FileUpload"와 같은 이름이 발생할 수 있는 다른 클래스와의 충돌을 피하기 위해 클래스 이름이 너무 길어지는 것을 방지합니다.

네임스페이스는 키워드 namespace ( 여는 <?php 바로 뒤에 있는 줄에 위치)를 사용하여 정의되며 \ 를 사용하여 구분되는 여러 수준 또는 하위 네임스페이스(파일을 배치하는 여러 하위 디렉토리를 갖는 것과 유사)에 걸쳐 있을 수 있습니다.

 <?php namespace CoolSoft\ImageResizer\Controllers; class ImageUpload { }

위의 클래스에 액세스하려면 네임스페이스를 포함하고 \ 로 시작하는 이름을 완전히 정규화해야 합니다.

 $imageUpload = new \CoolSoft\ImageResizer\Controllers\ImageUpload();

또는 클래스를 현재 컨텍스트로 가져올 수도 있습니다. 그 후에 이름으로 직접 클래스를 참조할 수 있습니다.

 use CoolSoft\ImageResizer\Controllers\ImageUpload; $imageUpload = new ImageUpload();

확립된 규칙에 따라 네임스페이스를 명명함으로써 추가적인 이점을 얻을 수 있습니다. 예를 들어, PHP 표준 권장 사항 PSR-4를 따르면 응용 프로그램은 파일 로드를 위해 Composer의 자동 로드 메커니즘을 사용할 수 있으므로 복잡성이 감소하고 종속성 간에 마찰 없는 상호 운용성이 추가됩니다. 이 규칙은 공급업체 이름(예: 회사 이름)을 최상위 하위 이름 공간으로 포함하도록 설정하고 선택적으로 패키지 이름이 뒤에 오고 그 다음에 각 하위 이름 공간이 동일한 이름을 가진 디렉토리에 해당하는 내부 구조가 뒤따릅니다. 결과는 파일에 정의된 요소의 네임스페이스를 사용하여 드라이브에 있는 파일의 물리적 위치를 1에서 1로 매핑합니다.

특성

특성이 PHP 5.4에 추가되었으므로 현재 WordPress 코어에서 모두 누락되었습니다.

PHP는 단일 상속을 지원하므로 하위 클래스는 여러 클래스가 아닌 단일 상위 클래스에서 파생됩니다. 따라서 서로 확장되지 않는 클래스는 클래스 상속을 통해 코드를 재사용할 수 없습니다. 특성은 동작의 수평 구성을 가능하게 하는 메커니즘으로, 서로 다른 클래스 계층 구조에 있는 클래스 간에 코드를 재사용할 수 있습니다.

특성은 클래스와 유사하지만 자체적으로 인스턴스화할 수 없습니다. 대신, 트레잇 내부에 정의된 코드는 컴파일 시간에 작성 클래스에 "복사 및 붙여넣기"되는 것으로 생각할 수 있습니다.

특성은 trait 키워드를 사용하여 정의한 후 use 키워드를 통해 모든 클래스로 가져올 수 있습니다. 아래 예제에서 완전히 관련이 없는 두 클래스 Person 과 Shop 은 특성 Addressable 을 통해 동일한 코드를 재사용할 수 있습니다.

 trait Addressable { protected $address; public function getAddress() { return $this->address; } public function setAddress($address) { $this->address = $address; } } class Person { use Addressable; } class Shop { use Addressable; } $person = new Person('Juan Carlos'); $person->setAddress('Obelisco, Buenos Aires');

클래스는 또한 둘 이상의 특성을 구성할 수 있습니다.

 trait Exportable { public class exportToCSV($filename) { // Iterate all properties and export them to a CSV file } } class Person { use Addressable, Exportable; }

특성은 다른 특성으로 구성될 수도 있고, 추상 메서드를 정의하고, 다른 기능 중에서 두 개 이상의 구성된 특성이 동일한 기능 이름을 가질 때 충돌 해결 메커니즘을 제공할 수도 있습니다.

인터페이스

인터페이스가 PHP 5에 추가되었으므로 WordPress는 이미 이 기능을 사용하고 있지만 극히 일부만 사용합니다. 코어에는 총 10개 미만의 인터페이스가 포함됩니다!

인터페이스를 사용하면 구현해야 하는 메서드를 지정하는 코드를 만들 수 있지만 이러한 메서드가 실제로 구현되는 방법을 정의할 필요는 없습니다. 구성 요소 간의 계약을 정의하는 데 유용하므로 응용 프로그램의 모듈화 및 유지 관리 용이성이 향상됩니다. 인터페이스를 구현하는 클래스는 코드의 블랙박스가 될 수 있으며 인터페이스의 기능 서명이 변경되지 않는 한 코드는 주요 변경 사항을 생성하지 않고 마음대로 업그레이드할 수 있으므로 기술 부채의 축적을 방지할 수 있습니다. 또한 일부 인터페이스의 구현을 다른 공급업체의 구현으로 교체할 수 있으므로 공급업체 종속성을 줄이는 데 도움이 될 수 있습니다. 결과적으로 구현 대신 인터페이스에 대해 애플리케이션을 코딩하는 것이 필수적입니다(그리고 종속성 주입을 통해 실제 구현을 정의).

인터페이스는 interface 키워드를 사용하여 정의되며 해당 메서드의 서명만 나열해야 public .

 interface FileStorage { function save($filename, $contents); function readContents($filename); }

클래스는 implements 키워드를 통해 인터페이스를 구현하도록 정의합니다.

 class LocalDriveFileStorage implements FileStorage { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } }

클래스는 , 로 구분하여 둘 이상의 인터페이스를 구현할 수 있습니다.

 interface AWSService { function getRegion(); } class S3FileStorage implements FileStorage, AWSService { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } function getRegion() { return 'us-east-1'; } }

인터페이스는 구성 요소가 수행해야 하는 작업의 의도를 선언하므로 인터페이스의 이름을 적절하게 지정하는 것이 매우 중요합니다.

폐쇄

클로저는 PHP 5.3에 추가되었으므로 현재 WordPress 코어에서 완전히 빠져 있습니다.

클로저는 익명 함수를 구현하기 위한 메커니즘으로, 전역 네임스페이스를 일회용(또는 거의 사용하지 않는) 함수에서 정리하는 데 도움이 됩니다. 엄밀히 말하면 클로저는 Closure 클래스의 인스턴스이지만 실제로는 아무런 피해 없이 이 사실을 인식하지 못할 가능성이 큽니다.

클로저 이전에는 함수를 다른 함수에 인수로 전달할 때마다 미리 함수를 정의하고 그 이름을 인수로 전달해야 했습니다.

 function duplicate($price) { return $price*2; } $touristPrices = array_map('duplicate', $localPrices);

클로저를 사용하면 익명(즉, 이름이 없는) 함수가 이미 매개변수로 직접 전달될 수 있습니다.

 $touristPrices = array_map(function($price) { return $price*2; }, $localPrices);

클로저는 use 키워드를 통해 컨텍스트로 변수를 가져올 수 있습니다.

 $factor = 2; $touristPrices = array_map(function($price) use($factor) { return $price*$factor; }, $localPrices);

발전기

생성기는 PHP 5.5에 추가되었으므로 현재 WordPress 코어에서 모두 누락되었습니다.

Generator는 간단한 반복자를 구현하는 쉬운 방법을 제공합니다. 생성기를 사용하면 메모리에 배열을 만들 필요 없이 데이터 집합을 반복하기 위해 foreach 를 사용하는 코드를 작성할 수 있습니다. 제너레이터 함수는 한 번 반환하는 대신 반복할 값을 제공하기 위해 필요한 만큼 여러 번 yield 할 수 있다는 점을 제외하면 일반 함수와 동일합니다.

 function xrange($start, $limit, $step = 1) { for ($i = $start; $i <= $limit; $i += $step) { yield $i; } } foreach (xrange(1, 9, 2) as $number) { echo "$number "; } // This prints: 1 3 5 7 9

인수 및 반환 유형 선언

다른 인수 유형 선언이 PHP의 다른 버전에서 도입되었습니다. WordPress는 이미 인터페이스와 배열을 선언할 수 있습니다(그렇지 않습니다: 코어에서 배열을 매개변수로 선언하는 함수의 인스턴스를 겨우 하나 찾았고 인터페이스는 없음). 곧 호출 가능 항목(PHP 5.4에 추가됨) 및 스칼라 유형: bool, float, int 및 string(PHP 7.0에 추가됨)을 선언할 수 있습니다. 반환 유형 선언이 PHP 7.0에 추가되었습니다.

인수 유형 선언을 통해 함수는 인수가 되어야 하는 특정 유형을 선언할 수 있습니다. 유효성 검사는 호출 시 실행되며 인수 유형이 선언된 유형이 아닌 경우 예외가 발생합니다. 반환 유형 선언은 동일한 개념이지만 함수에서 반환될 값의 유형을 지정합니다. 형식 선언은 함수의 의도를 더 쉽게 이해하고 예기치 않은 형식을 받거나 반환하는 런타임 오류를 방지하는 데 유용합니다.

인수 유형은 인수 변수 이름 앞에 선언되고 반환 유형은 인수 뒤에 선언되며 앞에 : :

 function foo(boolean $bar): int { }

스칼라 인수 유형 선언에는 강제 및 엄격의 두 가지 옵션이 있습니다. 강제 모드에서 잘못된 형식이 매개변수로 전달되면 올바른 형식으로 변환됩니다. 예를 들어, 문자열을 예상하는 매개변수에 정수가 주어진 함수는 문자열 유형의 변수를 얻습니다. 엄격 모드에서는 정확한 선언 유형의 변수만 허용됩니다.

강제 모드가 기본값입니다. 엄격 모드를 활성화하려면 strict_types 선언과 함께 사용되는 declare 문을 추가해야 합니다.

 declare(strict_types=1); function foo(boolean $bar) { }

새로운 구문 및 연산자

WordPress는 이미 func_num_args 함수를 통해 가변 길이 인수 목록을 식별할 수 있습니다. PHP 5.6부터 ... 토큰을 사용하여 함수가 가변 개수의 인수를 허용한다는 것을 나타낼 수 있으며 이러한 인수는 지정된 변수에 배열로 전달됩니다.

 function sum(...$numbers) { $sum = 0; foreach ($numbers as $number) { $sum += $number; } return $sum; }

PHP 5.6부터 상수는 정적 값뿐만 아니라 배열뿐만 아니라 숫자 및 문자열 리터럴과 관련된 스칼라 표현식을 포함할 수 있습니다.

 const SUM = 37 + 2; // A scalar expression const LETTERS = ['a', 'b', 'c']; // An array

PHP 7.0부터 다음을 사용하여 배열을 define 할 수도 있습니다.

 define('LETTERS', ['a', 'b', 'c']);

PHP 7.0은 Null 병합 연산자( ?? )와 우주선 연산자( <=> )와 같은 몇 가지 새로운 연산자를 추가했습니다.

Null 병합 연산자 ?? isset()과 함께 삼항을 사용해야 하는 일반적인 경우에 대한 구문 설탕입니다. 존재하고 NULL이 아닌 경우 첫 번째 피연산자를 반환합니다. 그렇지 않으면 두 번째 피연산자를 반환합니다.

 $username = $_GET['user'] ?? 'nobody'; // This is equivalent to: // $username = isset($_GET['user']) ? $_GET['user'] : 'nobody';

우주선 연산자 <=> 는 두 표현식을 비교하는 데 사용되며, 첫 번째 피연산자가 각각 두 번째 피연산자보다 작거나 같거나 크면 -1, 0 또는 1을 반환합니다.

 echo 1 <=> 2; // returns -1 echo 1 <=> 1; // returns 0 echo 2 <=> 1; // returns 1

이것은 버전 5.3에서 7.0까지의 PHP에 추가된 가장 중요한 새 기능입니다. 이 문서에 나열되지 않은 추가 새 기능 목록은 버전 간 마이그레이션에 대한 PHP 문서를 검색하여 얻을 수 있습니다.

다음으로 우리는 이러한 모든 새로운 기능과 웹 개발의 최근 동향을 최대한 활용하여 더 나은 소프트웨어를 생산할 수 있는 방법을 분석합니다.

PHP 표준 권장 사항

PHP Standards Recommendations는 인기 있는 프레임워크 및 라이브러리의 PHP 개발자 그룹에 의해 만들어졌으며 서로 다른 프로젝트를 보다 원활하게 통합하고 서로 다른 팀이 서로 더 잘 협력할 수 있도록 규칙을 설정하려고 했습니다. 권장 사항은 고정적이지 않습니다. 기존 권장 사항은 더 이상 사용되지 않을 수 있으며 이를 대체하기 위해 새로운 권장 사항이 생성될 수 있으며 새로운 권장 사항이 지속적으로 릴리스됩니다.

현재 권장 사항은 다음과 같습니다.

컴포넌트에서 생각하고 코딩하기

구성 요소를 사용하면 프레임워크 자체에 종속되지 않고 프레임워크에서 최상의 기능을 사용할 수 있습니다. 예를 들어, Symfony는 Symfony 프레임워크와 독립적으로 설치할 수 있는 재사용 가능한 PHP 구성 요소 세트로 출시되었습니다. 또 다른 PHP 프레임워크인 Laravel은 여러 Symfony 구성 요소를 사용하고 모든 PHP 프로젝트에서 사용할 수 있는 자체 재사용 가능한 구성 요소 세트를 출시했습니다.

이러한 모든 구성 요소는 공개 PHP 패키지 저장소인 Packagist에 게시되며 매우 인기 있는 PHP용 종속성 관리자인 Composer를 통해 모든 PHP 프로젝트에 쉽게 추가할 수 있습니다.

WordPress는 이러한 선순환 개발 주기의 일부여야 합니다. 불행히도 WordPress 코어 자체는 구성 요소를 사용하여 구축되지 않았으며(인터페이스가 거의 없는 것으로 입증됨) 더욱이 Composer를 통해 WordPress를 설치하는 데 필요한 composer.json 파일도 없습니다. 이것은 WordPress 커뮤니티가 WordPress가 사이트의 종속성인지(이 경우 Composer를 통해 설치하는 것이 정당할 수 있음) 또는 사이트 자체인지(이 경우 Composer가 작업에 적합한 도구가 아닐 수 있음)에 동의하지 않았기 때문입니다. .

제 생각에 WordPress가 향후 15년 동안(최소한 백엔드 CMS로서의 WordPress) 관련성을 유지하려면 WordPress 를 사이트의 종속성으로 인식하고 Composer를 통해 설치할 수 있어야 합니다 . 그 이유는 매우 간단합니다. Composer는 터미널에서 단 하나의 명령으로 Packagist에 게시된 수천 개의 패키지에서 프로젝트의 종속성을 선언하고 설치할 수 있으므로 매우 강력한 PHP 응용 프로그램을 순식간에 만들 수 있으며 개발자들이 좋아합니다. 이 방법으로 작동합니다. 워드프레스가 이 모델에 적응하지 못한다면 Git 기반 배포가 도입된 후 FTP가 인기를 잃게 된 것처럼 개발 커뮤니티의 지원을 잃고 망각에 빠질 수 있습니다.

Gutenberg의 출시는 WordPress가 사이트 자체가 아니라 사이트 종속성임을 이미 보여주었다고 주장하고 싶습니다. Gutenberg는 WordPress를 헤드리스 CMS로 취급하고 Drupal Gutenberg가 예시한 것처럼 다른 백엔드 시스템에서도 작동할 수 있습니다. 따라서 Gutenberg는 사이트에 전원을 공급하는 CMS를 교체할 수 있으므로 종속성으로 처리해야 함을 분명히 합니다. 또한 Gutenberg 자체는 npm을 통해 릴리스된 JavaScript 구성 요소(코어 커미터 Adam Silverstein이 설명함)를 기반으로 하므로 WordPress 클라이언트가 npm 패키지 관리자를 통해 JavaScript 패키지를 관리할 것으로 예상되는 경우 이 논리를 다음으로 확장하지 않는 이유는 무엇입니까? Composer를 통해 PHP 종속성을 관리하기 위한 백엔드?

이제 좋은 소식입니다. WordPress를 사이트의 종속성으로 취급하고 Composer를 통해 설치할 수 있으므로 이 문제가 해결될 때까지 기다릴 필요가 없습니다. John P. Bloch는 Git에 WordPress 코어를 미러링하고 composer.json 파일을 추가하여 Packagist에 출시했으며 Roots' Bedrock은 최신 개발 도구와 강화된 보안을 지원하는 맞춤형 폴더 구조로 WordPress를 설치할 수 있는 패키지를 제공합니다. 테마와 플러그인도 다룹니다. WordPress 테마 및 플러그인 디렉토리에 나열되어 있는 한 WordPress Packagist에서 사용할 수 있습니다.

결과적으로 테마와 플러그인의 관점에서 생각하지 않고 구성 요소 관점에서 생각하여 워드프레스 코드를 생성하는 것이 합리적인 선택입니다. 이를 Packagist를 통해 제공하여 모든 PHP 프로젝트에서 사용할 수 있도록 하고 추가로 테마 및 플러그인으로 패키징하여 출시합니다. WordPress의 특정 사용을 위한 플러그인. 구성 요소가 WordPress API와 상호 작용해야 하는 경우 이러한 API는 필요한 경우 다른 CMS에 대해서도 구현할 수 있는 인터페이스 뒤에서 추상화될 수 있습니다.

보기 계층을 개선하기 위해 템플릿 엔진 추가하기

구성 요소에서 생각하고 코딩하는 권장 사항을 따르고 WordPress를 사이트 자체가 아닌 사이트의 종속성으로 취급하면 우리 프로젝트는 WordPress가 부과한 경계에서 벗어나 다른 프레임워크에서 가져온 아이디어와 도구를 가져올 수 있습니다.

서버 측에서 HTML 콘텐츠를 렌더링하는 것은 일반적인 PHP 템플릿을 통해 수행되는 적절한 사례입니다. 이 뷰 레이어는 템플릿 엔진 Twig(Symfony 제공) 및 Blade(Laravel 제공)를 통해 향상될 수 있습니다. 이 엔진은 매우 간결한 구문과 일반 PHP 템플릿보다 유리한 강력한 기능을 제공합니다. 특히 Gutenberg의 동적 블록은 이러한 템플릿 엔진의 이점을 쉽게 얻을 수 있습니다. 서버 측에서 블록의 HTML을 렌더링하는 프로세스가 WordPress의 템플릿 계층 구조에서 분리되기 때문입니다.

일반 용도의 애플리케이션 설계

인터페이스에 대해 코딩하고 구성 요소 측면에서 생각하면 우리가 가지고 있는 각 프로젝트의 특정 용도를 위해 코딩하는 대신 일반 용도로 애플리케이션을 설계하고 제공해야 하는 특정 용도에 맞게 사용자 지정할 수 있습니다. 이 접근 방식은 단기적으로는 더 많은 비용이 들지만(추가 작업 포함), 일반 사용 응용 프로그램을 사용자 지정하는 것만으로도 더 적은 노력으로 추가 프로젝트를 제공할 수 있을 때 장기적으로 가치가 있습니다.

이 접근 방식이 효과적이려면 다음 사항을 고려해야 합니다.

고정 종속성 피하기(가능한 한 많이)

jQuery와 Bootstrap(또는 Foundation 또는 <–insert your favorite library here–> )은 몇 년 전만 해도 필수품으로 간주될 수 있었지만 기본 JS 및 새로운 기본 CSS 기능에 비해 꾸준히 입지를 잃어가고 있습니다. 따라서 이러한 라이브러리에 의존하는 5년 전에 코딩된 범용 프로젝트는 오늘날 더 이상 적합하지 않을 수 있습니다. 따라서 일반적으로 제3자 라이브러리에 대한 고정 종속성이 낮을수록 장기적으로 최신 상태인 것으로 판명됩니다.

기능의 점진적인 향상

WordPress는 사용자 관리를 포함하는 완전한 CMS 시스템이므로 사용자 관리 지원이 기본적으로 포함됩니다. 그러나 모든 WordPress 사이트에 사용자 관리가 필요한 것은 아닙니다. 따라서 우리의 애플리케이션은 이를 고려하고 각 시나리오에서 최적으로 작동해야 합니다. 필요할 때마다 사용자 관리를 지원하지만 필요하지 않을 때 해당 자산을 로드하지 마십시오. 이 접근 방식은 점진적으로 작동할 수도 있습니다. 고객이 문의 양식을 구현해야 하지만 예산이 없어서 기능이 제한된 무료 플러그인을 사용하여 코드를 작성하고 다른 고객이 상용 플러그인 제품에서 라이선스를 구입할 예산이 있다고 가정해 보겠습니다. 더 나은 기능. 그런 다음 매우 기본적인 기능을 기본으로 하도록 기능을 코딩할 수 있으며 시스템에서 사용할 수 있는 가장 유능한 플러그인의 기능을 점점 더 많이 사용할 수 있습니다.

지속적인 코드 및 문서 검토

이전에 작성된 코드와 해당 문서를 주기적으로 검토하여 새로운 규칙 및 기술에 관한 최신 정보인지 확인할 수 있으며 그렇지 않은 경우 기술 부채가 극복하기에 너무 비싸지기 전에 업그레이드 조치를 취할 수 있습니다. 그리고 처음부터 다시 코딩해야 합니다.

추천 자료 : 조심하세요: 사이트를 안전하지 않게 만들 수 있는 PHP 및 WordPress 기능

문제를 최소화하려고 하지만 문제가 발생했을 때 대비하십시오

100% 완벽한 소프트웨어는 없습니다. 버그는 항상 존재하지만 아직 발견하지 못했을 뿐입니다. 따라서 문제가 발생하면 쉽게 해결할 수 있도록 해야 합니다.

간단하게

복잡한 소프트웨어는 장기적으로 유지될 수 없습니다. 다른 팀원이 이해할 수 없을 뿐만 아니라 코딩한 사람이 몇 년 후 자신의 복잡한 코드를 이해하지 못할 수도 있기 때문입니다. 따라서 단순한 소프트웨어만 정확하고 빠를 수 있기 때문에 단순한 소프트웨어를 생산하는 것이 우선순위가 되어야 합니다.

컴파일 시간에 실패하는 것이 런타임보다 낫습니다.

코드 조각이 컴파일 시간 또는 런타임 시간에 오류에 대해 검증될 수 있다면 컴파일 시간 솔루션의 우선 순위를 지정해야 합니다. 그래야 오류가 발생하고 개발 단계에서 그리고 애플리케이션이 프로덕션에 도달하기 전에 처리될 수 있습니다. 예를 들어, const 와 define 은 모두 상수를 정의하는 데 사용되지만 const 는 컴파일 타임에 검증되지만 define 은 런타임에 검증됩니다. 따라서 가능하면 const 를 사용하는 것이 define 보다 선호됩니다.

이 권장 사항에 따라 클래스 이름이 있는 문자열 대신 실제 클래스를 매개 변수로 전달하여 클래스에 포함된 WordPress 함수를 후킹할 수 있습니다. 아래 예에서 Foo 클래스의 이름이 바뀌면 두 번째 후크는 컴파일 오류를 생성하지만 첫 번째 후크는 런타임에 실패하므로 두 번째 후크가 더 좋습니다.

 class Foo { public static function bar() { } } add_action('init', ['Foo', 'bar']); // Not so good add_action('init', [Foo::class, 'bar']); // Much better

위와 같은 이유로 전역 변수(예: global $wpdb ) 사용을 피해야 합니다. 이러한 변수는 전역 컨텍스트를 오염시킬 뿐만 아니라 시작 위치를 추적하기 쉽지 않을 뿐만 아니라 이름이 바뀌면 오류가 발생합니다. 런타임에 생성됩니다. 솔루션으로 Dependency Injection Container를 사용하여 필요한 개체의 인스턴스를 얻을 수 있습니다.

오류/예외 처리

우리는 Exception 객체의 아키텍처를 생성하여 애플리케이션이 각각의 특정 문제에 따라 적절하게 대응할 수 있도록 할 수 있습니다. 가능할 때마다 이를 복구하거나 그렇지 않을 때마다 사용자에게 유용한 오류 메시지를 표시하고 일반적으로 오류를 기록합니다. 관리자가 문제를 해결합니다. 그리고 항상 죽음의 흰 화면으로부터 사용자를 보호하십시오. 포착되지 않은 모든 Error 와 Exception 은 set_exception_handler 함수를 통해 가로채어 화면에 무섭지 않은 오류 메시지를 인쇄할 수 있습니다.

빌드 도구 채택

빌드 도구는 수동으로 실행하기 매우 지루한 작업을 자동화하여 많은 시간을 절약할 수 있습니다. WordPress는 특정 빌드 도구와의 통합을 제공하지 않으므로 이를 프로젝트에 통합하는 작업은 전적으로 개발자에게 있습니다.

다양한 목적을 달성하기 위한 다양한 도구가 있습니다. 예를 들어, Webpack, Grunt 및 Gulp와 같은 릴리스를 생성하기 위해 이미지 압축 및 크기 조정, JS 및 CSS 파일 축소, 디렉토리에 파일 복사 작업을 실행하는 빌드 도구가 있습니다. 다른 도구는 프로젝트의 스캐폴딩을 만드는 데 도움이 되며, 이는 Yeoman과 같은 테마 또는 플러그인의 폴더 구조를 생성하는 데 도움이 됩니다. 실제로 도구가 너무 많기 때문에 사용 가능한 여러 도구를 비교하는 기사를 검색하면 우리의 요구에 가장 적합한 도구를 찾는 데 도움이 됩니다.

그러나 어떤 경우에는 프로젝트에 필요한 것을 정확히 달성할 수 있는 빌드 도구가 없으므로 프로젝트 자체의 확장으로 자체 빌드 도구를 코딩해야 할 수도 있습니다. 예를 들어 WordPress에서 서비스 워커에 대한 지원을 추가하기 위해 service-worker.js 파일을 생성하기 위해 이 작업을 수행했습니다.

결론

이전 버전과의 호환성 유지에 대한 강한 강조로 인해 PHP 5.2.4까지 확장된 WordPress는 PHP에 추가된 최신 기능의 이점을 누릴 수 없었고 이 사실로 인해 WordPress는 그다지 흥미롭지 않은 코딩 플랫폼이 되었습니다. 많은 개발자들에게.

다행히도 이 우울한 시대는 곧 끝날 수 있고 WordPress는 다시 한 번 코딩할 수 있는 빛나고 흥미로운 플랫폼이 될 수 있습니다. 2019년 12월부터 PHP 7.0+의 요구 사항은 많은 PHP 기능을 사용할 수 있게 하여 개발자가 보다 강력하고 더 성능이 좋은 소프트웨어. 이 기사에서는 새로 사용 가능한 가장 중요한 PHP 기능과 이를 최대한 활용하는 방법을 검토했습니다.

Gutenberg의 최근 릴리스는 앞으로의 좋은 시기의 신호가 될 수 있습니다. Gutenberg 자체가 커뮤니티에서 완전히 수용되지는 않았지만 최소한 최신 기술(예: React 및 Webpack)을 코어에 통합하려는 의지를 보여줍니다. . 이 사건의 전환은 나를 궁금하게 만든다. 프론트엔드가 그러한 변신을 할 수 있다면 백엔드로 확장하지 않는 이유는 무엇입니까? WordPress에 PHP 7.0 이상이 필요하면 최신 도구와 방법론으로의 업그레이드가 가속화될 수 있습니다. npm이 JavaScript 패키지 관리자가 된 만큼 Composer를 공식 PHP 종속성 관리자로 만들지 않겠습니까? 블록이 프론트엔드에서 사이트를 구축하기 위한 새로운 단위인 경우 백엔드에 기능을 통합하기 위한 단위로 PHP 구성 요소를 사용하지 않는 이유는 무엇입니까? 마지막으로 Gutenberg가 WordPress를 교체 가능한 백엔드 CMS로 취급한다면 WordPress가 사이트 자체가 아니라 사이트 종속성임을 이미 인식하지 못하는 이유는 무엇입니까? 나는 당신이 숙고하고 숙고할 수 있도록 이러한 열린 질문을 남겨두겠습니다.