WordPress 유지 관리를 원활하게 하는 10가지 팁

다양한 유형의 프로젝트를 수행한 WordPress 개발자로서 기존 WordPress 웹사이트를 편집하거나 버그 수정하면서 개인적으로 겪었던 몇 가지 문제점에 대해 이야기하고 싶습니다. 이 기사에 나열된 팁과 제안은 이러한 고통을 최소화하거나 없애기 위한 것입니다.

적절한 WordPress 유지 관리가 중요한 이유

대부분의 경우 웹 사이트는 "한 번만 설정한 후 그대로 두는" 문제가 아니며 이는 WordPress 사이트뿐만 아니라 모든 사이트에 해당됩니다. 때때로 편집, 업데이트 또는 버그 수정을 처리해야 하며, 이를 좋아하는 개발자가 처리합니다. 그러나 어떤 경우에는 웹사이트의 전체 수명 동안 다양한 개발자에게 의존해야 할 수도 있습니다.

후자의 경우, 특히 이전 개발자가 유지 관리 작업을 처리할 때 모범 사례를 준수하지 않은 경우 들어오는 개발자에게 일이 순조롭게 진행되지 않는 경우가 많습니다.

다음 개발자의 삶을 더 쉽게 만들고 사이트에서 작업하는 것을 좋아하게 만들 수 있도록 WordPress 프로젝트에 대한 향후 유지 관리 작업에서 고려해야 할 몇 가지 중요한 사항을 살펴보겠습니다. 분명히, 개발자의 작업을 더 쉽게 만드는 것은 프로세스에서 약간의 시간과 돈을 절약할 수 있습니다. 이는 항상 잠재 고객에게 좋은 판매 포인트입니다.

1. 백업!

너무 당연하게 들릴 수 있지만 가장 먼저 해야 할 일이 있습니다! WordPress 사이트를 적절하고 정기적으로 백업해야 합니다.

이것은 현재 사이트를 변경하지 않는 경우에도 수행해야 하는 가장 기본적인 작업 중 하나입니다. 모든 파일과 데이터베이스 덤프를 가져와 안전한 장소에 저장하여 수동으로 수행하거나 WordPress 백업 플러그인을 통해 자동 백업 옵션을 사용할 수 있습니다. WordPress 플러그인 저장소에서 찾을 수 있는 무료 및 유료 플러그인이 많이 있습니다. 대부분의 호스팅 제공업체가 백업 옵션을 제공하므로 서버 수준에서 백업 옵션을 잘 활용할 수도 있습니다. 이는 호스팅 제공업체에 확인해야 하는 사항입니다.

정기적인 백업을 사용하면 충돌이나 실수 후에도 사이트가 다시 가동되고 실행될 것이므로 안심할 수 있습니다. 또한 새로운 개발자가 큰 번거로움 없이 문제를 해결하는 데 도움이 될 수 있습니다. 특히 과거에 유지 관리 중에 발생한 것으로 의심되는 버그를 수정하려는 경우에는 더욱 그렇습니다. 정기적인 백업은 새 개발자가 프로젝트를 인수하기 몇 달 또는 몇 년 전에 발생한 문제를 식별하고 해결하는 데 도움이 됩니다.

2. WordPress 사이트를 로컬에 설치

나는 초창기 나 자신이 이 실수를 저질렀다는 것을 인정하는 것을 자랑스럽게 생각하지 않습니다. 그 이후로 많은 개발자들이 원격 서버에서 직접 편집을 수행하는 것을 보았습니다. 민감한 데이터와 모든 사이트 파일이 개발자에게 맡겨지는 것이 걱정되지 않는 한 이 실수를 영원히 피해야 합니다. 편집할 때마다 개발자의 로컬 컴퓨터와 서버 사이를 오가는 것은 매우 비효율적입니다.

사이트의 약간의 텍스트를 변경하기 위한 약간의 편집과 같이 아주 작은 변경일지라도 개발자는 FTP 클라이언트에서 해당 파일/폴더로 이동해야 합니다(파일 업로드에 FTP를 사용하는 경우). 파일을 업로드하고 간헐적인 FTP 연결 실패가 없기를 바랍니다. 일부 WordPress 웹 사이트에는 너무 많은 시간과 대역폭을 낭비하지 않고 실제로 이동할 수 있는 데이터가 너무 많다는 것을 잊지 마십시오. 그리고 모든 것이 성공적으로 업로드되면 브라우저로 이동하여 페이지를 새로 고쳐야 합니다. 이 페이지는 당시 네트워크/서버의 속도와 상태에 따라 다릅니다. 변경할 때마다 절약할 수 있는 시간이 몇 분에 불과한 것처럼 보일 수도 있지만 프로젝트가 진행되는 동안 이러한 시간이 몇 시간의 불필요한 작업을 추가할 수 있습니다.

개발자가 로컬 컴퓨터에 사이트를 설치한 경우 편집이 훨씬 더 빠릅니다. 편집을 수행하고 페이지를 새로고침하면 완료됩니다. 인터넷에 연결되지 않은 동굴 안에 살고 있더라도 나중에 작업하고 변경 사항을 업로드할 수 있습니다.

우려되는 민감한 데이터가 있거나 모든 데이터를 개발자와 공유하지 못하게 하는 법적 이유가 있는 경우 어떻게 하시겠습니까? 이 경우 특별히 이 목적을 위해 일부 더미 데이터를 준비할 수 있습니다. 또한 향후 유지 관리를 위해 이 데이터를 따로 보관할 수도 있습니다.

3. 힘내세요

소프트웨어 개발 세계에서 가장 좋은 일 중 하나는 온라인 버전 관리의 여명입니다. 파일을 처리하기 위해 전통적인 cPanel/FTP 방식으로 여전히 실행 중인 사이트가 많이 있기 때문에 이 점을 언급합니다. 버전 제어가 얼마나 좋은지 모르거나 알지만 초기 설정 노력으로 인해 구현을 주저합니다. 그러나 실제로는 그렇게 많은 작업이 아니며 어려운 작업에 불과합니다.

버전 제어는 다양한 작성자의 변경 사항 추적, 편집을 쉽게 되돌리기, 각 작업의 변경 사항이 다른 작업을 방해하지 않도록 각 독립 작업에 대해 별도의 분기를 갖는 기능을 포함하여 파일 관리와 관련하여 많은 이점을 제공합니다.

대부분의 경우 호스팅 공급자가 미리 설치하는 외부 서버에 Git을 설정해야 합니다. 리포지토리를 시작하고 워크플로를 설정하려면 서버에 대한 전문 지식이 있는 사람이 필요할 수 있습니다. 이 작업은 이 기사의 범위를 벗어나므로 여기에서 논의하지 않겠습니다.

말할 것도 없이, 분기를 사용하지 않는다면 실제로 "git'ing"이 아닙니다! 개발자가 개발 브랜치에서 모든 작업을 수행하고 사이트를 테스트한 다음 모든 것이 정상이면 프로덕션 브랜치로 푸시하여 라이브 사이트에서 아무 문제가 없는지 확인하도록 개발 및 프로덕션을 위해 최소 두 개의 브랜치를 만드십시오.

4. 불필요한 파일, 코드 및 플러그인 제거

더 이상 필요하지 않은 파일과 플러그인은 남겨두는 것이 일반적입니다. 파일이 웹 사이트의 수명 주기 동안 시간이 지남에 따라 누적되면 이는 고통이 됩니다. 개발자가 시간이 지남에 따라 추가된 원치 않는 파일을 제거하는 데 신경 쓰지 않았다면 파일의 출처와 현재 사이트의 일부에서 사용 중인지 여부를 추적하기 어렵습니다. 의심스러운 항목을 제거한 후 아무 것도 손상되지 않았는지 확인하기 위해 사이트를 다시 한 번 테스트해야 하므로 이로 인해 추가적인 골칫거리가 발생합니다.

이것은 작업한 해당 개발자가 원하지 않는 파일을 즉시 제거하여 제거할 수 있습니다. 모든 개발자에게 이 관행을 강조할 수 있습니다.

PHP 파일 및 플러그인 외에도 사용하지 않는 미디어 파일은 시간이 지남에 따라 wp-content 폴더를 채울 수 있으며, 이는 미디어 관련 기능으로 작업할 때 개발자에게 문제를 일으킬 수 있습니다. 이 작업을 단순화하는 다양한 플러그인을 찾을 수 있습니다. 한 가지 예는 미디어 클리너입니다.

플러그인에는 내부 휴지통 기능이 있어 파일이 실제로 사용되지 않는지 확인하기 위해 임시로 파일을 이동합니다. 한 번 확인하면 영구적으로 휴지통에 버릴 수 있습니다. 파일을 정리하기 전에 이 문서의 1번 항목(즉, 백업)을 따라야 합니다.

5. 댓글 달기

아마도 다음과 같은 프로그래밍 밈에 익숙할 것입니다. 코드가 작성되었을 때 코드를 작성한 작성자, 동료 및 신이 이해했습니다. 얼마 후 저자와 신만이 그것이 하는 일을 알았고 이제 저자가 적절한 논평을 추가하지 않는 한 신만이 그것이 하는 일을 알고 있습니다!

일부 개발자는 댓글 작성을 꺼리거나 완전히 게으르지만 좋은 개발 환경에서는 반드시 해야 하는 습관입니다. 새로운 개발자나 심지어 같은 개발자가 특정 코드 블록이 무엇을 하는지 알아내는 데 소비하게 될 편집 및 버그 수정 시간을 줄입니다.

함수/클래스 또는 코드 블록이 명확하지 않을 때마다 주석을 추가해야 합니다. 예를 들어 다음 함수를 사용하세요.

 function stripWhiteSapaces(str) { … Return str; }

위의 함수 이름은 그 자체로 의미가 있으며 사용자가 작동 방식을 보기 위해 함수 내부로 들어갈 필요가 없습니다. 공백을 제거하는 한 가지 작업만 수행하면 됩니다. 따라서 이 경우 주석이 필요하지 않을 수 있습니다.

그러나 예를 들어 여러 매개변수를 허용하고 필터링된 게시물 목록을 반환하는 함수가 있는 경우 이전과 같이 명확하지 않습니다. 매개변수와 해당 유형을 설명하는 주석이 있어야 합니다. 또한 이 함수 내부의 코드 블록을 설명해야 할 수도 있습니다.

빠른 확인을 위해 WordPress 코어에서 파일을 가져와서 WordPress 전문가가 어떻게 주석을 달았는지 확인할 수 있습니다. 또는 자세한 내용은 이를 잘 보여주는 WordPress의 공식 가이드를 참조하세요.

6. 보푸라기

Linting은 우리가 코드를 작성하는 방식에 규칙을 적용하고 때로는 코드 서식 자체를 수정하는 또 다른 멋진 기능입니다. 이는 멋지고 유용합니다. 오늘날 사용되는 대부분의 IDE에는 린트 옵션이 제공되며, 다양한 린트 구성을 추가하여 이 옵션을 더욱 개선하거나 사용자 지정할 수 있습니다.

예를 들어 Visual Studio Code를 IDE로 사용하는 경우 VS Code는 PHP 언어 진단을 위해 공식 PHP 린터( php -l )를 사용합니다. 각 언어(예: PHP, JavaScript, CSS 등)에 대한 규칙/제한을 개별적으로 구성할 수 있습니다. 자세한 내용은 WordPress 코딩 표준을 참조하세요.

• https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
• https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/

린트 구성이 있으면 이를 적용해야 합니다. 현재 및 미래의 모든 개발자는 이 린트 구성을 IDE에 통합하여 코드가 동일한 규칙/제한을 준수하도록 해야 합니다. 그렇지 않으면 많은 노력이 헛될 것입니다.

7. 변수 및 파일 이름 지정

사물의 이름을 다루는 표준을 고안하십시오. 여기에는 함수/클래스 이름, 변수 이름, 파일 이름, 템플릿의 일부인 경우 미디어/이미지 이름도 포함됩니다.

다음과 같은 몇 가지 중요한 사항을 고려하십시오.

1. 모호하지 않은 이름 피하기
2. 가능하면 짧게 유지
3. 때로는 파일 이름에 "유형"을 추가하는 것이 정말 유용합니다. 예를 들어 아이콘인 경우 BlackArrowIcon.png와 같은 것을 가질 수 있고 큰 배경 이미지인 경우 FrontYellowBG.jpg와 같은 것일 수 있습니다. 또는 코드 파일인 경우 IDE의 다양한 탭에 열려 있는 여러 파일로 작업할 때 해당 파일이 무엇을 의미하는지 쉽게 알 수 있습니다. 예를 들어 도우미 기능이 있는 클래스가 있는 경우 Helper.php 대신 HelperClass.php로 이름을 지정하면 도움이 됩니다.

자세한 내용은 WordPress 모범 사례 가이드의 명명 규칙 섹션을 확인하세요.

8. 워드프레스 디버깅

디버깅은 상당한 시간이 걸릴 수 있으며, 특히 편집이나 버그 수정과 관련하여 총 개발 시간에서 많은 부분을 차지하는 경향이 있습니다. 즉, 개발자가 가능한 가장 효율적인 방법으로 작업을 수행하고 있는지 확인해야 합니다. 대부분의 개발자는 가장 효율적인 방법이 아닌 웹 페이지의 일부에서 변수를 수동으로 var_dump '하여 이 작업을 수행하는 경향이 있습니다. 이것은 또한 나중에 프로젝트에 참여하는 개발자들에게 골칫거리가 될 수 있습니다. 작업이 완료된 후 디버깅 코드가 제대로 정리되지 않으면 여기 저기에 정크 코드 줄이 남게 될 것이기 때문입니다.

이 디버깅 작업에 도움이 되는 몇 가지 플러그인이 있습니다. 다음은 WordPress용으로 널리 사용되는 디버깅 플러그인의 몇 가지 예입니다.

• 킨트 디버거
• 디버그 바
• 쿼리 모니터

9. 더 나은 CSS 사용

웹 개발에 있어서 CSS를 사용한 스타일링은 가장 기본적인 활동 중 하나입니다. 불행히도 이는 JS, PHP 등에 비해 자주 간과되고 관심을 덜 받는다는 것을 의미합니다. 하지만 믿거나 말거나 CSS는 나중에 무언가를 추가하거나 편집하려고 할 때 제대로 아키텍처가 지정되지 않으면 엄청난 문제를 일으킬 수 있습니다. 귀하의 사이트가 기본적이고 작은 경우가 아니라면.

이 비교적 기본적인 스타일링 기술이 문제가 발생하기 쉬운 이유에 대해 더 알고 싶다면 CSS가 짜증나는 이유를 구글에 검색하거나 CSS로 인해 가장 짜증나는 5가지에 대해 자세히 알아볼 수 있습니다.

다음은 많은 세부 정보 없이 제 쪽에서 제공하는 몇 가지 빠른 팁입니다.

• 좋은 이름 지정 관행을 시행하십시오. BEM(Block Element Modifier)과 같은 명명 방법론 사용
• 인라인 스타일을 피하십시오. 대신 외부 스타일시트를 사용하세요.
• 필요할 때마다 스타일을 늘리지 않고 가능한 한 일반적으로 재사용 가능한 패턴을 생각해 냅니다.
• 웹사이트의 기능이나 영역에 따라 스타일을 여러 파일로 나눕니다. 더 많은 수의 스타일 파일이 로딩 성능에 영향을 미칠 수 있다는 우려가 있는 경우 여러 파일을 하나의 단일 파일로 통합하는 우수한 캐싱 플러그인을 사용하여 이를 극복할 수 있습니다.
• SASS, LESS 등과 같은 CSS 전처리기를 활용하십시오.

10. 현재 개발자로부터 피드백 받기

마지막으로, 목록을 완성하기 위해 개발자가 사이트에서 작업할 때 직면한 문제에 대한 피드백을 얻을 수 있습니다. 그들은 귀하의 사이트에서 손을 더럽힌 사람들이므로 좋은 조언을 줄 수 있습니다. 그들은 또한 이전 개발자가 남긴 결함이나 더러운 코드를 지적할 수도 있습니다.