WordPress 개발자가 저지르는 가장 일반적인 실수 10가지

우리는 인간일 뿐이며 인간의 특성 중 하나는 실수를 한다는 것입니다. 다른 한편으로, 우리는 또한 자기 교정을 하고 있습니다. 즉, 우리는 실수로부터 배우는 경향이 있고 희망을 갖고 같은 실수를 두 번 하지 않도록 할 수 있습니다. WordPress 영역에서 내가 저지른 많은 실수는 솔루션을 구현할 때 시간을 절약하려는 시도에서 비롯됩니다. 그러나 이들은 일반적으로 이 접근 방식의 결과로 문제가 발생할 때 고개를 숙일 것입니다. 실수는 피할 수 없습니다. 그러나 다른 사람의 감독(물론 자신의 감독도 포함)으로부터 배우는 것은 능동적으로 취해야 하는 길입니다.

일반적인 실수 1번: 디버깅 끄기

내 코드가 제대로 작동할 때 디버깅을 사용해야 하는 이유는 무엇입니까? 디버깅은 모든 PHP 오류, 경고 및 알림(사용되지 않는 기능 등에 대한)이 표시되도록 하는 WordPress에 내장된 기능입니다. 디버깅을 끄면 볼 수 없는 중요한 경고나 알림이 생성될 수 있지만 제때 처리하지 않으면 나중에 문제가 발생할 수 있습니다. 우리는 코드가 사이트의 다른 모든 요소와 잘 작동하기를 원합니다. 따라서 WordPress에 새 사용자 지정 코드를 추가할 때 항상 디버깅을 켜고 개발 작업을 수행해야 합니다(그러나 사이트를 프로덕션에 배포하기 전에 비활성화해야 합니다!).

이 기능을 활성화하려면 WordPress 설치의 루트 디렉토리에 있는 wp-config.php 파일을 편집해야 합니다. 다음은 일반적인 파일의 스니펫입니다.

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

이것은 사용할 수 있는 구성 옵션의 전체 목록은 아니지만 이 제안된 설정은 대부분의 디버깅 요구 사항에 충분해야 합니다.

일반적인 실수 2: wp_head Hook을 사용하여 스크립트 및 스타일 추가하기

내 헤더 템플릿에 스크립트를 추가하는 데 어떤 문제가 있습니까? WordPress에는 이미 많은 인기 있는 스크립트가 포함되어 있습니다. 여전히 많은 개발자가 wp_head 후크를 사용하여 추가 스크립트를 추가합니다. 이로 인해 동일한 스크립트가 생성될 수 있지만 다른 버전이 여러 번 로드됩니다.

여기에서 대기열에 넣으면 우리 웹사이트에 스크립트와 스타일을 추가할 수 있는 WordPress 친화적인 방법입니다. 플러그인 충돌을 방지하고 스크립트에 있을 수 있는 종속성을 처리하기 위해 대기열에 추가합니다. 이것은 내장 함수 wp_enqueue_script 또는 wp_enqueue_style 을 사용하여 스크립트와 스타일을 각각 대기열에 추가함으로써 달성됩니다. 두 함수의 주요 차이점은 wp_enqueue_script 를 사용하면 스크립트를 페이지 바닥글로 이동할 수 있는 추가 매개변수가 있다는 것입니다.

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

스크롤 없이 볼 수 있는 부분의 콘텐츠를 렌더링하는 데 스크립트가 필요하지 않은 경우 스크롤 없이 볼 수 있는 부분의 콘텐츠가 빠르게 로드되도록 스크립트를 바닥글로 안전하게 이동할 수 있습니다. 대기열에 추가하기 전에 먼저 스크립트를 등록하는 것이 좋습니다. 이렇게 하면 다른 사람들이 플러그인의 핵심 코드를 수정하지 않고 자체 플러그인의 핸들을 통해 스크립트를 등록 취소할 수 있기 때문입니다. 이에 더하여, 등록된 스크립트의 핸들이 대기열에 추가된 다른 스크립트의 종속성 배열에 나열되는 경우 해당 스크립트는 강조 표시된 대기열에 넣은 스크립트를 로드하기 전에 자동으로 로드됩니다.

일반적인 실수 3: 하위 테마 피하기 및 WordPress 핵심 파일 수정

테마를 수정할 계획이라면 항상 자식 테마를 만드십시오. 일부 개발자는 상위 테마 파일을 변경하여 테마를 업그레이드한 후 변경 사항이 덮어써져 영원히 손실되었음을 발견하게 됩니다.

자식 테마를 만들려면 style.css 파일을 자식 테마 폴더의 하위 디렉터리에 다음 콘텐츠와 함께 배치합니다.

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

위의 예는 기본 WordPress 테마인 Twenty Sixteen 을 기반으로 자식 테마를 만듭니다. 이 코드의 가장 중요한 줄은 "Template"이라는 단어가 포함된 줄로, 자식을 복제할 부모 테마의 디렉터리 이름과 일치해야 합니다.

워드프레스 코어 파일에도 동일한 원칙이 적용됩니다. 코어 파일을 수정하여 쉬운 길을 택하지 마십시오. WordPress 업그레이드 후 변경 사항을 덮어쓰지 않도록 WordPress 플러그인 기능 및 필터를 사용하여 추가 노력을 기울이십시오. 플러그형 기능을 사용하면 일부 핵심 기능을 재정의할 수 있지만 이 방법은 서서히 단계적으로 사라지고 필터로 대체되고 있습니다. 필터는 동일한 최종 결과를 얻고 출력을 수정할 수 있도록 WordPress 기능의 끝에 삽입됩니다. 여러 플러그인이 이 래퍼 없이 동일한 플러그형 기능을 재정의하려고 하면 치명적인 오류가 발생하므로 플러그형 기능을 사용할 때 트릭은 항상 if ( !function_exists() ) 로 기능을 래핑하는 것입니다.

일반적인 실수 4: 하드코딩 값

종종 코드 어딘가에 값(예: URL)을 하드코딩하는 것이 더 빠르게 보이지만 그 결과로 발생하는 문제를 디버깅하고 수정하는 데 소요되는 시간은 훨씬 더 큽니다. 해당 함수를 사용하여 원하는 출력을 동적으로 생성함으로써 코드의 후속 유지 관리 및 디버깅을 크게 단순화합니다. 예를 들어, 하드코딩된 URL을 사용하여 테스트 환경에서 프로덕션으로 사이트를 마이그레이션하는 경우 갑자기 사이트가 작동하지 않는다는 것을 알게 될 것입니다. 이것이 우리가 파일 경로와 링크를 생성하기 위해 아래 나열된 것과 같은 기능을 사용해야 하는 이유입니다.

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

하드코딩의 또 다른 나쁜 예는 사용자 지정 쿼리를 작성할 때입니다. 예를 들어 보안 조치로 기본 WordPress 데이터 테이블 접두사를 wp_ 에서 wp743_ 와 같이 조금 더 고유한 것으로 변경합니다. 환경 간에 테이블 접두사가 변경될 수 있으므로 WordPress 설치를 이동하면 쿼리가 실패합니다. 이를 방지하기 위해 wpdb 클래스의 테이블 속성을 참조할 수 있습니다.

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

테이블 이름에 wp_users 값을 사용하지 않고 대신 WordPress가 이를 처리하도록 합니다. 테이블 이름을 생성하기 위해 이러한 속성을 사용하면 올바른 결과를 반환하는 데 도움이 됩니다.

일반적인 실수 5: 사이트의 색인 생성을 중단하지 않음

검색 엔진이 내 사이트의 색인을 생성하는 것을 원하지 않는 이유는 무엇입니까? 인덱싱이 좋죠? 글쎄, 웹사이트를 구축할 때, 당신은 구축을 완료하고 영구 링크 구조를 확립할 때까지 검색 엔진이 당신의 사이트를 인덱싱하는 것을 원하지 않을 것입니다. 또한 사이트 업그레이드를 테스트하는 스테이징 서버가 있는 경우 Google과 같은 검색 엔진이 이러한 중복 페이지를 인덱싱하는 것을 원하지 않습니다. 구분할 수 없는 콘텐츠가 여러 개 있는 경우 검색 엔진에서 검색어와 더 관련성이 높은 버전을 결정하기가 어렵습니다. 이러한 경우 검색 엔진은 중복 콘텐츠가 있는 사이트에 불이익을 주게 되며 이로 인해 귀하의 사이트는 검색 순위에 영향을 받게 됩니다.

아래와 같이 WordPress 읽기 설정 에는 "검색 엔진이 이 사이트의 색인을 생성하지 못하도록 차단"이라는 확인란이 있지만 "이 요청을 수락하는 것은 검색 엔진에 달려 있습니다"라는 중요한 주의 사항이 있습니다.

검색 엔진은 종종 이 요청을 받아들이지 않는다는 점을 명심하십시오. 따라서 검색 엔진이 사이트를 인덱싱하지 .htaccess 파일 을 편집하고 다음 행을 삽입하십시오.

 Header set X-Robots-Tag "noindex, nofollow"

일반적인 실수 6: 플러그인이 활성화되어 있는지 확인하지 않음

플러그인이 항상 켜져 있는 경우 플러그인 기능이 있는지 확인해야 하는 이유는 무엇입니까? 확실히 플러그인이 활성화되는 시간은 99%입니다. 그러나 어떤 이유로 비활성화 된 경우의 1 %는 어떻습니까? 이런 일이 발생하면 웹사이트에 못생긴 PHP 오류가 표시될 수 있습니다. 이를 방지하기 위해 플러그인의 기능을 호출하기 전에 플러그인이 활성 상태인지 확인할 수 있습니다. 플러그인 함수가 프론트 엔드를 통해 호출되는 경우 is_plugin_active() 함수를 호출하기 위해 plugin.php 라이브러리를 포함해야 합니다.

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

이 기술은 일반적으로 매우 안정적입니다. 그러나 작성자가 기본 플러그인 디렉토리 이름을 변경한 경우가 있을 수 있습니다. 더 강력한 방법은 플러그인에 클래스가 있는지 확인하는 것입니다.

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

작성자는 플러그인의 클래스 이름을 변경할 가능성이 적으므로 일반적으로 이 방법을 사용하는 것이 좋습니다.

일반적인 실수 7: 너무 많은 리소스 로드

페이지용 플러그인 리소스를 선택적으로 로드해야 하는 이유는 무엇입니까? 플러그인이 사용자가 탐색한 페이지에서 사용되지 않는 경우 플러그인에 대한 스타일 및 스크립트를 로드할 타당한 이유가 없습니다. 필요할 때만 플러그인 파일을 로드함으로써 페이지 로드 시간을 줄일 수 있으며, 이는 최종 사용자 경험을 개선할 수 있습니다. 예를 들어 쇼핑 페이지에만 플러그인이 로드되기를 원하는 WooCommerce 사이트를 가정해 보겠습니다. 이러한 경우 팽창을 줄이기 위해 다른 모든 사이트 페이지에 로드되는 파일을 선택적으로 제거할 수 있습니다. 테마 또는 플러그인의 functions.php 파일에 다음 코드를 추가할 수 있습니다.

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

스크립트는 등록된 핸들을 통해 wp_dequeue_script($handle) 함수로 제거할 수 있습니다. 마찬가지로 wp_dequeue_style($handle) 은 스타일시트가 로드되는 것을 방지합니다. 그러나 이것이 구현하기에 너무 어려운 경우 게시물 유형이나 페이지 이름과 같은 특정 기준에 따라 플러그인을 선택적으로 로드하는 기능을 제공하는 플러그인 오거나이저를 설치할 수 있습니다. 변경 사항을 반영하기 위해 캐시를 지속적으로 새로 고쳐야 하는 것을 막기 위해 켰을 수 있는 W3Cache와 같은 캐싱 플러그인을 비활성화하는 것이 좋습니다.

일반적인 실수 8: 관리자 표시줄 유지

모든 사람이 볼 수 있도록 WordPress 관리 표시줄을 그대로 둘 수 없나요? 예, 사용자가 관리 페이지에 액세스하도록 허용할 수 있습니다. 그러나 이러한 페이지는 선택한 테마와 시각적으로 통합되지 않고 원활한 통합을 제공하지 않는 경우가 많습니다. 사이트를 전문적으로 보이게 하려면 관리 표시줄을 비활성화하고 자신만의 프런트 엔드 계정 관리 페이지를 제공해야 합니다.

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

위의 코드를 테마의 functions.php 파일에 복사하면 사이트 관리자를 위한 관리자 표시줄만 표시됩니다. current_user_can($capability) 함수에 WordPress 사용자 역할 또는 기능을 추가하여 사용자가 관리 표시줄을 보지 못하도록 할 수 있습니다.

일반적인 실수 9: GetText 필터를 사용하지 않음

CSS 또는 JavaScript를 사용하여 버튼의 레이블을 변경할 수 있습니다. 뭐가 문제인가요? 네, 할 수 있습니다. 그러나 대신 gettext 라는 WordPress에서 가장 편리한 필터 중 하나를 사용할 수 있을 때 버튼을 렌더링하는 데 불필요한 코드와 추가 시간이 추가됩니다. 플러그인의 textdomain 과 함께 WordPress가 로드된 모든 번역을 구별할 수 있도록 하는 고유 식별자와 함께 gettext 필터를 사용하여 페이지가 렌더링되기 전에 텍스트를 수정할 수 있습니다. load_plugin_textdomain($domain) 함수의 소스 코드를 검색하면 해당 텍스트를 재정의하는 데 필요한 도메인 이름을 제공합니다. 평판이 좋은 플러그인은 플러그인 초기화 시 플러그인의 textdomain 이 설정되도록 합니다. 변경하려는 테마의 일부 텍스트인 경우 load_theme_textdomain($domain) 코드 줄을 검색합니다. 다시 한 번 WooCommerce를 사용하여 "관련 제품" 제목에 표시되는 텍스트를 변경할 수 있습니다. 테마의 functions.php 파일에 다음 코드를 삽입하세요.

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

이 필터 후크는 위에서 언급한 함수를 통해 textdomain 이 설정되는 한 국제화 함수 __() 및 _e() 에 의해 번역된 텍스트에 적용됩니다.

 _e( 'Related Products', 'woocommerce' );

플러그인에서 이러한 국제화 기능을 검색하여 사용자 정의할 수 있는 다른 문자열을 확인하십시오.

일반적인 실수 10: 기본 영구 링크 유지

기본적으로 WordPress는 게시물 ID와 함께 쿼리 문자열을 사용하여 지정된 콘텐츠를 반환합니다. 그러나 이것은 사용자 친화적이지 않으며 사용자는 URL을 복사할 때 URL의 해당 부분을 제거할 수 있습니다. 더 중요한 것은 이러한 기본 영구 링크는 검색 엔진 친화적인 구조를 사용하지 않는다는 것입니다. "예쁜" 퍼머링크를 활성화하면 URL에 게시물 제목의 관련 키워드가 포함되어 검색 엔진 순위의 성능이 향상됩니다. 특히 사이트가 상당한 기간 동안 운영되고 있고 검색 엔진에서 이미 색인을 생성한 수백 개의 게시물이 있는 경우 영구 링크를 소급하여 수정해야 하는 매우 힘든 작업이 될 수 있습니다. 따라서 WordPress를 설치한 후 영구 링크 구조를 게시물 ID보다 조금 더 검색 엔진 친화적인 것으로 즉시 변경해야 합니다. 나는 일반적으로 내가 구축하는 대부분의 사이트에 대해 게시물 이름을 사용하지만 사용 가능한 영구 링크 구조 태그를 사용하여 원하는 형식으로 영구 링크를 사용자 지정할 수 있습니다.

결론

이 기사는 WordPress 개발자가 범한 실수의 완전한 목록이 결코 아닙니다. 그러나 이 기사에서 한 가지 빼야 할 것이 있다면 절대 지름길을 사용해서는 안 된다는 것입니다(WordPress뿐만 아니라 모든 개발 플랫폼에서도 마찬가지입니다!). 열악한 프로그래밍 방식으로 절약한 시간은 나중에 다시 찾아옵니다. 아래에 댓글을 남겨 과거에 저지른 실수와 더 중요한 것은 배운 교훈을 자유롭게 공유해 주세요.