고급 WordPress 개발자가 저지르는 12가지 최악의 실수

게시 됨: 2022-03-11

WordPress는 사이트를 빠르게 시작하고 실행할 수 있는 매우 인기 있는 방법입니다. 그러나 많은 개발자들이 서두르다가 결국 끔찍한 결정을 내립니다. WP_DEBUG 를 true 로 설정하는 것과 같은 몇 가지 실수는 저지르기 쉽습니다. 모든 JavaScript를 단일 파일로 묶는 것과 같은 다른 것들은 게으른 엔지니어만큼 일반적입니다. 어떤 실수를 저지르든 계속 읽으며 초보 개발자와 노련한 개발자가 저지르는 가장 일반적인 12가지 WordPress 실수를 알아보세요. 이러한 실수 중 하나를 저지르고 있는 자신을 발견하더라도 절망하지 마십시오. 각 실수는 배울 수 있는 기회입니다.

1. 워드프레스 테마 자바스크립트 코드를 하나의 메인 파일에 넣기

한번은 클라이언트 웹사이트에 대한 페이지 속도 최적화를 수행하는 동안 사용자 지정 코드를 포함하여 사용하던 모든 라이브러리가 main.js , theme.js 또는 custom.js 라는 단일 파일에 포함된 프리미엄 테마를 사용하고 있다는 것을 알게 되었습니다. . 이 관행은 다음과 같은 이유로 좋지 않습니다.

파일은 시간이 지나면서 활발하게 개발되고 있는 테마에 따라 기능이 증가하고 때로는 1MB 크기의 파일을 볼 수 있으므로 정말 커질 수 있습니다. 일부 페이지에서 파일 코드의 10%만 필요한 경우에도 파일이 사이트 전체에 로드됩니다. 이렇게 하면 페이지를 다운로드하는 데 시간이 더 오래 걸리고 렌더링 속도가 느려집니다. 특히 페이지의 헤드 섹션 내에서 차단 코드를 렌더링하는 경우 더욱 그렇습니다.
페이지 속도를 향상시키거나 발생할 수 있는 다른 JavaScript 코드와의 충돌을 방지하기 위해 일부 페이지에서 일부 코드를 언로드하는 wp_dequeue_script() 와 같은 함수를 사용할 수 없기 때문에 파일 내부의 코드를 관리하기가 더 어려워집니다. 활성 플러그인 중 하나에 의해 로드됩니다. 물론, 파일을 여러 파일로 분할하고 WordPress에서 대기열에 넣을 수 있지만 나중에 웹 사이트 관리자가 테마의 main.js 파일 업데이트를 수행하면 전체 프로세스를 처음부터 다시 시작해야 합니다.

2. 변수, 함수, 상수 또는 클래스에 너무 일반적인 이름 사용

플러그인을 개발할 때 같은 이름을 사용하는 다른 플러그인이 있을 경우 코드 충돌을 방지하는 명명 규칙을 사용하는 것이 좋습니다. 그렇기 때문에 많은 개발자가 변수와 함수 이름에 고유하고 플러그인 자체와 관련된 접두사를 붙입니다. 코드 충돌을 제거하는 것 외에도 많은 플러그인을 활성화했을 때 쉽게 찾을 수 있습니다.

반면에 PHP 네임스페이스를 사용하여 항목을 캡슐화하고 라이브러리 및 애플리케이션 작성자가 클래스 또는 함수와 같은 재사용 가능한 코드 요소를 생성할 때 직면하는 두 가지 문제를 해결하는 것을 선호하는 개발자가 있습니다.

생성한 코드와 내부 PHP 또는 타사, 클래스, 함수 또는 상수 간의 이름 충돌
첫 번째 문제를 수정하거나 소스 코드의 가독성을 개선하기 위해 설계된 Extra_Long_Names 의 별칭(또는 단축) 기능. 이것은 코드가 많은 테마나 플러그인을 자주 개발하기 때문에 제가 가장 좋아하는 것입니다. 이렇게 하면 긴 고유 이름에 대해 크게 걱정할 필요 없이 코드를 쉽게 읽고 관리할 수 있습니다.

네임스페이스는 종종 잘못된 방식으로 사용될 수 있으므로 사용하기 전에 네임스페이스를 잘 이해하는 것이 좋습니다.

맡게 될 프로젝트에 따라 작업이 기존 코딩 스타일과 대부분 분리되지 않는 한 기존 코딩 스타일을 고수해야 할 가능성이 큽니다. 이미 WordPress용 PHP 코딩 표준을 따르는 기존 플러그인이나 테마를 확장해야 하는 경우 일관된 스타일을 유지하여 코드가 깨끗하고 읽기 쉽도록 유지하는 것이 가장 좋습니다. 일부 규칙은 코딩 스타일을 무시하고 성능 향상을 위해 보편적으로 적용됩니다. 예를 들어, 문자열에서 아무 것도 평가하지 않는다면 항상 작은 따옴표(큰 따옴표 대신)를 사용하는 것이 가장 좋습니다. 또한 코드를 읽기 위해서는 들여쓰기를 해야 합니다. 특히 코드에 내포된 코드가 있는 경우(예: IF 내 IF 내, 내포 FOREACH 내 및 FOR ).

3. 기존 WordPress 핵심 기능을 진정한 잠재력으로 활용하지 않음

WordPress에는 플러그인 및 테마에서 호출할 수 있는 정기적으로 업데이트되는 라이브러리 모음이 함께 제공되므로 기존 핵심 기능을 최대한 활용하는 것이 가장 좋습니다. WordPress 핵심 파일(예: jQuery 또는 Color Picker)에 이미 있는 파일이 자산 디렉토리에 있는 WordPress 테마 및 플러그인을 보았습니다. 패키지가 더 커지고 네트워크를 통해 로드하는 데 시간이 더 오래 걸린다는 사실 외에도 모든 타사 라이브러리가 정기적으로 업데이트되는지 확인해야 합니다. 이는 처리해야 할 또 다른 문제입니다.

라이브러리는 이미 WordPress 개발 핵심 팀에서 업데이트되었으며 가볍고 유지 관리하기 쉬운 프로젝트를 가질 수 있으므로 WordPress가 이미 제공하는 것을 활용하십시오. 정기적으로 WordPress 업데이트를 수행하면 더 많은 기능(플러그인, 테마 또는 대시보드가 지속적으로 개선됨에 따라 WordPress 코어 자체)에 액세스할 수 있으며 이전 코드 릴리스에서 취약점이 발견되는 경우 웹사이트를 더욱 안전하게 만들 수 있습니다.

4. 액션과 필터를 통해 플러그인이나 테마를 변경하기 쉽게 만들지 않음

물론 해당 패키지 개발에 직접 참여하고 해당 코드에 기여하지 않는 한 WordPress 플러그인이나 테마를 직접 편집하는 것은 좋지 않습니다. 플러그인이나 테마에 자동 업데이트가 수행되면 패키지에 대한 직접적인 변경 사항이 손실되고 파일을 처음부터 다시 편집해야 합니다.

그렇기 때문에 상위 테마나 플러그인 자체를 편집하지 않고도 기존 기능을 변경할 수 있기 때문에 작업 및 필터를 사용하고 하위 테마(상위 테마를 확장함)를 만드는 것이 테마를 수정하는 가장 효과적인 방법입니다. 또한 WordPress.org에서 플러그인을 무료로 다운로드할 수 있도록 제공하고 나중에 상위 플러그인에 종속되는 프리미엄 확장을 만들고 싶다면 다음과 같은 방식으로 무료 플러그인을 개발해야 합니다. 쉽게 확장하고 프리미엄 확장을 추가할 수 있습니다.

5. `WP_DEBUG` 로 개발하기 `false` 로 설정

기본적으로 WP_DEBUG 상수는 'false'로 설정되어 PHP 오류, 경고 및 주의 사항이 인쇄되지 않습니다. 라이브 환경에서는 보안상의 이유로 개인 서버 경로와 스크립트를 공개 보기에서 숨겨지므로 권장되는 선택입니다. 그러나 개발 단계에서는 코드의 오류를 알려주므로 'true'로 설정하는 것이 가장 좋습니다. 오류가 기능에 직접적인 영향을 미치지 않더라도 더 나은 코드를 작성하고 더 나은 코딩 습관을 개발해야 하는 경우가 많습니다. 그것은 나에게 일어났다. 이렇게 하면 개발한 플러그인 또는 테마가 WordPress 설치에서 PHP 오류를 생성하지 않도록 할 수도 있습니다.

이것은 대부분의 숙련된 개발자가 하는 일이지만 특히 급하게 발생합니다. 작업이 아무리 시급하더라도 개발자는 항상 PHP 모범 사례에 대한 분명한 눈으로 WordPress 코딩 표준을 유지하려고 노력해야 합니다.

6. 페이지가 언젠가는 캐시될 수 있다는 점을 고려하지 않고 PHP 코드 작성하기

이것은 일반적인 PHP 실수이며 이전과 마찬가지로 PHP 코딩 표준을 고수한다면 비교적 쉽게 피할 수 있습니다.

일부 개발자는 PHP 코드가 항상 실행되는 경우에만 유효한 테마 및 플러그인에 PHP 스니펫을 구현하는 습관이 있습니다. 예를 들어, 특정 작업으로 HTTP 사용자 에이전트에 응답하는 PHP 기능(예: 모바일 사용자만을 위한 대기열에 스크립트)을 취하거나 취하지 않아야 합니다.

클라이언트가 테마 또는 플러그인에서 조건을 트리거하지 않고 페이지를 캐시하는 플러그인(예: W3 Total Cache 또는 WP Rocket)을 설치하면 PHP 코드가 쓸모 없게 됩니다. 페이지를 반응형으로 만들려는 의도라면 미디어 쿼리와 JavaScript를 통해 프런트 엔드 측에서 수행해야 합니다. 후자는 정말로 필요한 경우에만 가능합니다. 이상적으로는 사이트를 반응형으로 만들기 위해 JavaScript를 사용하지 않는 것이 좋습니다.

7. Git과 같은 버전 관리 시스템을 통해 전문적인 방식으로 변경 사항을 추적하지 않음

하위 테마 또는 사용자 정의 플러그인과 같이 사용자 정의 코딩된 파일은 이상적으로는 버전 제어 하에 있어야 합니다. Git은 변경된 사항에 대한 기록을 생성하고 개발자가 동일한 WordPress 프로젝트에서 함께 작업하거나 웹사이트에 문제가 발생할 때마다 쉽게 이전 버전으로 되돌릴 수 있도록 합니다. 또한 클라이언트는 Git을 사용하여 특정 프로젝트에 고용된 모든 개발자가 수행한 모든 작업 기록을 추적할 수 있습니다. 특히 대규모의 장기간 WordPress 사용자 정의 웹 사이트인 경우 더욱 그렇습니다.

처음에는 특히 주니어 개발자에게 겁이 날 수 있지만 Git을 이해하는 것은 시간을 할애할 가치가 있으며 SourceTree(내가 가장 좋아하는 것 중 하나)와 같은 Git GUI 소프트웨어는 단순히 Git 리포지토리와 상호 작용하여 전체를 만드는 방법일 것입니다. 학습 곡선이 더 즐겁습니다. 작동 방식을 이해했다면 Git을 사용하는 몇 가지 방법을 더 자세히 설명하는 Toptal 개발자의 Git 모범 사례 및 팁을 확인하십시오.

8. 필요하지 않을 때 CSS 및 JavaScript 파일을 대기열에 추가

HTTP 요청이 많으면 웹사이트 로드 속도가 느려지므로 Google PageSpeed 점수가 낮아 검색 순위에 영향을 미칠 수 있습니다. 플러그인 간의 충돌로 인해 JavaScript 오류가 발생할 수도 있습니다. 예를 들어 공통 jQuery 라이브러리를 사용하는 두 개의 플러그인이 있을 수 있으며 두 번 로드되어 문제가 발생할 수 있습니다. 그리고 실제로 jQuery는 라이브 웹사이트에 여러 번 로드되는 경우가 많기 때문에 이것이 가장 좋은 예입니다. 이것은 잘못 작성된 플러그인이나 테마로 인해 발생할 수 있습니다.

9. 정적 `.css` 및 `.js` 파일 대신 `.php` 파일을 사용하여 CSS 또는 JavaScript 코드 출력

사용자 정의 CSS 코드를 생성하고 인쇄하는 데 사용되는 style.php 와 같은 파일이 있는 테마와 WordPress 플러그인도 보았습니다. 색상, 글꼴 크기 및 요소 주변의 간격과 같은 항목은 테마 설정에서 설정한 다음 데이터베이스에 저장됩니다. 그런 다음 style.php를 읽고(예: <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) 사용자 정의 설정을 기반으로 CSS 코드를 생성합니다. 대시보드에서 업데이트되었습니다.

이것은 WordPress 성능 측면에서 실제로 나쁜 습관입니다. 다음은 함께 제공되는 주요 단점입니다.

CSS 파일이 head 태그 내에서 로드되기 때문에(일반적이고 대부분이 이와 같이 로드됨), 브라우저가 페이지를 렌더링하기 전에 파일을 완전히 다운로드해야 하므로 이에 따른 성능 문제가 있습니다. 일부 플러그인으로 인해 WordPress 환경이 느린 경우 로드 시간이 상당히 지연됩니다. 캐싱 기술을 사용하거나 데이터베이스에서 값을 검색하기 위해 WordPress 환경의 일부만 로드하더라도. 대신 정적 .css 파일을 사용하는 것이 가장 좋습니다.
PHP 파일에서 코드(PHP 변수 및 조건절과 혼합된 CSS 규칙)는 개발자가 무언가를 확인해야 할 때 읽기가 더 어려울 것입니다. 물론, 파일은 브라우저에서 실행할 수 있습니다(인쇄될 때 들여쓰기가 되지 않거나 보기에도 좋지 않음). 그러나 프로젝트의 로컬 복사본이 있고 테마의 코드를 탐색하고 필요한 경우 CSS 또는 JavaScript 구문을 찾으려면(script.php가 사용되는 경우) 가독성이 더 어려워집니다.

솔루션: 플러그인 디렉토리 외부에 사용자 정의 CSS를 저장하십시오. 예: /wp-content/uploads/theme-name-custom-css/style-5.css . 이렇게 하면 테마 또는 플러그인이 업데이트되는 경우 사용자 지정 파일이 손실되지 않습니다.

10. WordPress 플러그인 및 테마에 적합한 아키텍처(코드 구성)를 사용하지 않음

플러그인의 크기와 특성에 따라(예: 독립형 플러그인 또는 WooCommerce와 같이 메인 플러그인이 활성화되어야만 작동하는 플러그인 확장) 적절한 아키텍처와 코드 구성이 설정되어야 합니다.

클라이언트용 단일 목적 WordPress 플러그인을 빌드해야 하고 WordPress 코어, 테마 및 기타 플러그인과의 제한된 상호 작용이 있는 경우 플러그인이 나중에 상당히 확장될 것이라는 확신이 없으면 복잡한 클래스를 엔지니어링하는 것은 효과적이지 않습니다. 켜짐.

플러그인이 많은 코드로 풍부한 기능을 제공하려는 경우 객체 지향 프로그래밍(OOP) 코딩 접근 방식(많은 클래스 포함)을 사용하는 것이 합리적입니다. 예를 들어 단축 코드가 많은 경우 class.shortcodes.php 와 같은 별도의 클래스 파일에 모두 보관하거나 대시보드 및 프런트 엔드 보기 내에 로드해야 하는 CSS 및 JavaScript 파일이 있는 경우 그런 다음 class.scripts.php 와 같은 클래스를 사용하여 enqueue_admin_scripts() 메서드 내에서 관리 영역에 로드할 파일을 대기열에 넣는 동안 enqueue_public_scripts() 와 같은 메서드 내에서 프런트 엔드 파일을 대기열에 넣을 수 있습니다.

HTML과 PHP 코드를 혼합하는 것보다 MVC 패턴을 플러그인과 테마에 구현하여 분리된 상태로 유지하는 것이 좋습니다. 좋은 예는 WooCommerce 플러그인입니다. 로직이 디자인과 분리되어 있기 때문에 테마나 다양한 필터를 통해 쉽게 덮어쓸 수도 있는 다양한 레이아웃에 대한 템플릿이 있습니다. HTML 레이아웃이 포함된 템플릿은 이미 처리된 정보를 인쇄하는 데 주로 사용됩니다. PHP 메소드 내에서 HTML 코드를 갖는 것은 일반적으로 나쁜 습관입니다(물론 작은 HTML 코드는 예외가 있음). 특히 크기가 커짐에 따라 둘 이상의 개발자가 유지 관리하는 플러그인의 경우에는 그렇습니다.

WordPress Plugin Handbook에 따르면 가능한 아키텍처 패턴은 많지만 크게 세 가지 변형으로 그룹화할 수 있습니다.

기능이 포함된 단일 플러그인 파일
클래스, 인스턴스화된 객체 및 선택적으로 기능을 포함하는 단일 플러그인 파일
메인 플러그인 파일, 그 다음 하나 이상의 클래스 파일

11. 코드를 작성할 때 WordPress 보안을 심각하게 고려하지 않음

많은 초보 개발자가 클라이언트가 원하는 결과에 더 집중하기 때문에 보안은 WordPress 개발에서 심각하게 고려되지 않는 경우가 많습니다. 클라이언트의 웹사이트가 해킹당하거나 WordPress.org에 게시된 플러그인에 취약점이 있어 수천 개의 웹사이트가 영향을 받을 때까지는 아무 문제가 없습니다. 이러한 일은 때때로 발생하며 WordPress 코어조차도 CMS 초기부터 상당한 수의 보안 취약점을 처리했습니다. 가능한 한 보안을 유지하고 문제가 발생하는 경우 즉시 조치를 취하고 견고하고 잘 테스트된 패치를 출시하도록 하는 것은 우리의 책임입니다.

가장 중요한 보안 팁은 다음과 같습니다.

XSS 취약점: 이를 피하려면 데이터 입력을 삭제하고 출력 데이터를 삭제하는 두 가지 작업을 수행해야 합니다. 데이터와 데이터가 사용되는 컨텍스트에 따라 WordPress에는 코드를 삭제하는 몇 가지 방법이 있습니다. 입력 데이터나 인쇄될 데이터를 신뢰해서는 안 됩니다. 데이터 입력을 삭제하는 일반적인 기능 중 하나는 sanitize_text_field() 입니다. 유효하지 않은 UTF-8 문자를 확인하고 단일 < 문자를 HTML 엔티티로 변환하고 모든 태그를 제거하고 줄 바꿈, 탭 및 추가 공백을 제거하고 옥텟을 제거합니다. 데이터 인쇄와 관련하여 링크 출력의 좋은 예는 잘못된 URL을 거부하고 잘못된 문자를 제거하며 위험한 문자를 제거하는 esc_url() 함수입니다.

파일에 대한 직접 액세스 방지: 대부분의 호스트에서 허용하는 대로 파일에 직접 액세스할 수 있습니다. 그러나 이러한 일이 발생하고 이를 처리하기 위해 코드가 제대로 작성되지 않은 경우 잠재적인 공격자에게 유용한 정보가 포함된 일부 오류(예: 누락된 함수 또는 선언되지 않은 변수)가 인쇄될 수 있습니다. 플러그인과 테마에서 자주 볼 수 있는 일반적인 코드 스니펫은 다음과 같습니다.

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

상수 ABSPATH 가 정의되지 않은 경우(WordPress 설치용이어야 함) 스크립트는 종료되고 아무 것도 인쇄하지 않습니다.

Nonce 사용: WordPress 문서에 명시된 바와 같이 nonce는 악의적이거나 기타 특정 유형의 오용으로부터 URL 및 양식을 보호하는 데 도움이 되는 "한 번 사용된 숫자"입니다.

예를 들어 대시보드에 있는 다음 URL은 게시물을 휴지통으로 이동하는 데 사용됩니다. http://example.com/wp-admin/post.php?post=123&action=trash — 이 URL에 액세스할 때 WordPress는 인증 쿠키 정보의 유효성을 검사합니다. 적절한 권한이 있는 경우(예: 모든 권한을 가진 관리자) 해당 게시물은 삭제됩니다.

공격자가 할 수 있는 일은 <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> WordPress에 이 요청을 하면 브라우저는 자동으로 인증 쿠키를 첨부하고 WordPress는 요청이 유효한 것으로 간주합니다.

공격자가 nonce 값(실제로 WordPress에 로그인한 관리자를 위해 생성됨)을 쉽게 얻을 수 없기 때문에 nonce가 발생합니다. 새 요청 URL은 다음과 같습니다. http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

유효한 nonce가 없으면 WordPress에서 "이 작업을 수행하시겠습니까?"라는 잘 알려진 오류 메시지와 함께 403 Forbidden 응답이 브라우저로 전송됩니다.

대부분의 사람들은 WordPress 보안을 심각하게 생각하지 않지만 웹사이트가 해킹당하지 않을 것이라고 생각하고 호스팅(유용할 수 있지만 특정 지점까지만)과 상용 플러그인/테마(종종 매우 안전하다는 가정하에) 해커가 식별하고 악용하기 전에 악용 가능한 취약점을 식별하기 위해 항상 웹 사이트에 대한 침투 테스트를 수행해야 합니다.

웹사이트를 특별히 해킹할 의도로 한 사람이 수행한 것이 아닌 많은 해킹이 있습니다. 종종 일관된 기반으로 WordPress 웹사이트를 자동으로 스캔하는 봇이 있으며 알려진 취약점이 발견되는 순간 악용되고 서버는 스팸, 데이터베이스에서 개인 정보 가져오기, 웹사이트의 특정 페이지 내에 숨겨진 링크 배치에 사용됩니다. 모든 종류의 이상한 웹사이트(예: 포르노, 불법 약물)로 연결됩니다. 때로는 해킹이 너무 잘 숨겨져 있어 웹사이트를 적절히 검사하고 해킹된 코드를 감지하기 위해 특정 파일이 업데이트된 날짜를 확인해야 합니다. 그렇기 때문에 해킹된 파일은 정품 WordPress 코어 파일로 덮어쓰도록 WordPress를 다시 설치하는 것이 좋습니다(예, 마지막 버전이 있는 경우 동일한 버전).

12. WordPress 기능 및 코드 조각을 이해하지 않고 사용하기

종종 개발자가 막혀서 StackOverflow와 같은 곳에서 솔루션을 찾을 때, 그들은 그 코드 뒤에 있는 논리를 이해하는 데 신경쓰지 않고 무언가 작동하도록 관리했다는 사실에 만족합니다. 코드 줄.

코드의 3분의 1만 실제로 사용되는 경우 PHP 스크립트 내에서 코드 조각이 복사되는 경우를 많이 보았습니다.

여기에는 다음과 같은 몇 가지 단점이 있습니다.

코드는 기존 프로젝트 코드와 동일한 스타일을 사용하지 않습니다. 예, 바로 사용할 수 있는 스니펫을 복사하여 붙여넣는 것이 편합니다. 작은 개인 프로젝트에는 문제가 없지만(언젠가는 큰 프로젝트가 될 수 있음) 이 방법은 종종 좋지 않습니다. 스타일의 일관성을 유지해야 하는 상업 작업에 이르기까지.
코드는 제 역할을 하지만 달성해야 하는 작업에 권장되지 않는 비효율적인 기능을 포함할 수 있습니다. 코드가 최적화되지 않은 경우 이 "복사 및 붙여넣기" 방식으로 인해 웹 사이트 유지 관리가 느려지고 어려울 수 있습니다. 특히 프로젝트 내의 다양한 위치에서 둘 이상의 스니펫이 사용되는 경우 더욱 그렇습니다.
코드는 재사용이 허가되지 않을 수 있으며 클라이언트의 프로젝트에 코드를 포함하면 많은 법적 문제가 발생할 수 있습니다.

지속적인 개선

누구나 실수를 하고, 각 실수는 자신을 개선할 수 있는 기회입니다. WordPress 개발자로서 우리 업계는 매우 빠른 속도로 움직이며 일을 하는 "올바른 방법"이 한 가지도 없습니다. 그러나 더 많이 연습하고 배울수록 더 좋아질 것입니다.

내가 지적한 실수에 동의하지 않거나 하나를 놓쳤다고 생각합니까? 댓글로 알려주시면 상담해드리겠습니다.

관련: 내 5가지 최악의 WordPress 개발 실수