WordPress의 핵심: 개발자의 관점

개발자는 플랫폼이 마음에 들지 않음에도 불구하고 WordPress와 같은 CMS를 사용하게 되는 경우가 점점 더 많아지고 있습니다.

숙련된 개발자는 특히 프로그래밍에 능숙한 개발자인 경우 맞춤형 솔루션을 선호하는 경우가 많습니다. 맞춤형 솔루션을 사용하면 잘 작동하는 매우 품격 있는 애플리케이션을 만들 수 있습니다. 그러나 개발자는 플랫폼을 매우 싫어하더라도 WordPress와 같은 CMS를 사용하게 됩니다.

이 문서는 이러한 개발자를 대상으로 하며 WordPress(WP)로 작업할 때 발생하는 많은 문제를 해결합니다. 이러한 어려움이 무엇인지 설명하고 제안도 제공합니다. Plesk는 세계에서 가장 사랑받는 CMS인 WordPress의 주요 비판을 고려하는 데 실제로 도움이 되는 WP 툴킷을 제공합니다.

개발자가 WordPress를 사용하는 이유

실수하지 마세요. WordPress는 아주 좋은 이유로 시장에서 가장 인기 있는 CMS입니다. 이 섹션에서는 실제로 자신의 코드를 작성할 수 있는 숙련된 개발자들 사이에서도 CMS가 인기 있는 이유를 설명합니다.

첫째, WordPress는 설치가 매우 쉽습니다. 표준 LAMP/LEMP 환경(Linux, Apache/Nginx, PHP 및 DBMS인 MySQL/MariaDB)만 있으면 됩니다. 가지고 있다면 WordPress 설치를 시작할 수 있습니다.

WP CMS에는 프런트 엔드 룩앤필을 사용자 정의하는 테마와 기능을 추가하는 플러그인을 포함하여 다양한 추가 기능이 함께 제공되기 때문에 사용자 정의도 쉽습니다. 자신만의 테마를 만드는 것도 가능하고 숙련된 개발자도 자신만의 플러그인을 만들 수 있지만 이 과정은 더 복잡합니다.

아마도 WordPress가 인기를 얻은 가장 큰 이유는 비기술적인 사용자가 액세스할 수 있다는 사실일 것입니다. WP를 설치하면 제대로 실행되기 위해 코딩 경험이나 소프트웨어에 대한 이해가 필요하지 않습니다. 초보 사용자는 작업 직후 웹 사이트를 게시하고 WordPress 인스턴스를 설정할 수 있습니다.

WordPress의 문제점은 정확히 무엇입니까?

음, 세계에서 가장 인기 있는 CMS에는 고려해야 할 문제가 많습니다. 우리는 WordPress 문제에 대해 소란을 피울 의도가 없지만 다음은 솔직한 토론이며 이 믿을 수 없을 정도로 인기 있는 CMS의 개발 팀이 다음 사항을 긍정적인 비판으로 받아들이기를 바랍니다. WordPress가 개발자에게 실망스러운 이유는 다음과 같습니다.

광범위하게 유능하지만 탁월하지는 않음

워드프레스의 시작은 단순했습니다. WP는 블로그를 작성하고 게시하려는 사람들을 위한 플랫폼으로 탄생했습니다. CMS는 수년에 걸쳐 완전히 바뀌었고 이제는 겸손한 시작과 다릅니다. 어떤 사람들은 그것을 전체 사이트를 관리하는 기본 시스템으로, 온라인 상점을 위한 플랫폼으로, 심지어 정적 사이트를 생성하는 방법으로 사용합니다.

그것은 CMS가 얼마나 적응력이 있는지를 강조하고 우리는 그 말에 동의하지만 너무 유연하다는 문제는 어떤 단일 역할에서 탁월해지기 어렵다는 것입니다. 이것을 깨닫는 한 가지 방법은 플러그인 렌즈를 통해 들여다보는 것입니다: 사용 가능한 수천 개의 WordPress 플러그인은 사람들이 WordPress를 단순히 그렇지 않거나 더 나쁘게 만들고 할 수 없는 일을 하도록 강제하는 방법을 보여줍니다. 아파요. 이런 이유로 우리는 워드프레스를 사용할 때 자주, 그리고 기꺼이 사용할 때 반드시 필요하지 않은 플러그인을 로드하지 않습니다. 그 시점에서 우리는 그것들을 직접 만드는 것을 선호합니다.

분명히 WordPress는 이러한 "자체 제작" 접근 방식을 위해 만들어졌으며 분명히 유연성에는 많은 이점이 있습니다. 그러나 특정 작업에 집중하지 않으면 CMS는 명확한 솔루션을 제공하기 위해 많은 노력을 기울입니다. 모든 사람에게 모든 것이 되려고 하는 이러한 초점은 큰 문제를 야기하고 있습니다. 그러나 우리는 그것을 지적해야 합니다. WordPress는 여전히 블로그와 복잡하지 않은 웹 사이트 및 전자 상거래 사이트를 구축하기 위한 플랫폼으로 잘 작동합니다.

해킹 및 균열: WordPress는 열린 문이 될 수 있습니다.

요컨대, WordPress는 24시간 내내 해킹을 당하며 개발자 세계에서 들은 가장 큰 불만입니다. 부인할 수 없습니다. CMS는 보안 허점으로 가득 차 있으며 결코 끝나지 않습니다. 짧은 담요와 같습니다. 한쪽을 조정하면 다른 쪽이 덮입니다. 부분적으로 해킹의 수는 WordPress의 인기 때문이기도 하지만 WordPress의 오픈 소스 방식 때문이기도 합니다.

누구나 CMS의 오픈 소스 코드를 볼 수 있기 때문에 해커가 코드의 약점을 찾을 수 있습니다. 오픈 소스 코드가 나쁜 접근 방식이라고 말하는 것은 아니지만 WordPress CMS의 오픈 소스 특성이 끝없는 보안 문제에 기여하고 있다고 생각합니다.

분석에 따르면 WordPress 사이트는 인터넷의 XNUMX분의 XNUMX 이상을 차지합니다. WordPress 팀은 이를 알고 있으며 CMS가 안전한지 확인하기 위해 할 수 있는 모든 일을 시도하지만 오늘날 개발 주기가 너무 빠르기 때문에 복잡한 애플리케이션을 완전히 보호하기 어려울 수 있습니다. 그리고 보안 노력이 실패하면 수백만 개의 웹사이트가 위험에 처할 수 있습니다.

물론 확실한 "WordPress 인스턴스 업데이트" 외에는 WordPress 보안 문제에 대한 확실한 해결책이 없습니다. 그럼에도 불구하고 WordPress 릴리스 주기는 독특하고 끝없는 문제를 가져옵니다.

많은 사람들이 WordPress 보안을 관리하는 것이 간단하다고 말하며 대부분 사실입니다. 하지만 문제는 왜 사이트 소유자가 WordPress가 안전한지 확인하기 위해 할 일 목록을 작성해야 하느냐입니다. WordPress의 이 보안 부분이 기본적으로 제공되지 않는 이유는 무엇입니까?

• 누군가 WordPress에 실행 파일을 업로드하는 것은 쉬운 일이며 이 옵션은 기본적으로 제한되어야 합니다. 약간 똑똑한 사람이 악성 코드가 포함된 파일을 PHP 스크립트에 업로드하면 사이트가 손상됩니다.
• 현재 파일 시스템에서 옵션을 구성할 수 있습니다. 대신 WordPress는 이를 제거하고 파일 시스템이 "읽기 전용"이라고 가정해야 합니다. WordPress의 핵심은 이 작업을 수행하지만 플러그인은 이 동작 패턴을 따르지 않습니다. 프로덕션 환경에서 구성 파일을 변경하는 플러그인을 발견하면 사용을 중지하세요. 이렇게 하면 쓰기 가능한 파일 시스템을 나타내므로 악의적인 변경을 쉽게 수행할 수 있습니다. 한 가지 해결책은 시스템의 루트에서 wp-config.php 파일을 제거하는 것입니다(WordPress는 어쨌든 작동합니다). 그러나 이것은 완전한 보안을 보장하지 않으며 어떤 경우에도 무의식적인 개발자가 직접 작성한 많은 플러그인의 올바른 기능을 방지합니다. .
• 기본적으로 WordPress에서는 사용자가 원하는 만큼 로그인을 시도할 수 있습니다. 이렇게 하면 해커가 로그인에 성공할 때까지 임의의 암호를 계속 시도하는 무차별 대입 공격의 문이 열립니다. WordPress CMS는 설치 시 무제한 로그인 시도를 비활성화해야 합니다.

이것은 완전한 목록이 아니며 단지 몇 가지 요점입니다. 분명히 대규모 소프트웨어 솔루션, 특히 오픈 소스 솔루션은 공격에 완전히 무적일 수 없습니다. 그러나 우리의 요점은 진지한 개발자들이 WordPress가 너무 취약하기 때문에 정확히 사용하기를 꺼린다는 것입니다. 숙련된 개발자는 알 수 없는 미래의 취약점에 대해 걱정하지 않고 자신의 요구 사항을 우아하게 충족하고 엄격하게 보호할 수 있는 완전히 새로운 애플리케이션을 구축하는 것을 선호합니다.

또는 PLESK 설정을 최대한 활용하고 WordPress에 "권장되지 않음" 또는 "무료" 또는 더 나쁘지만 잘못 작성된 플러그인(판단을 내리려면 현장 경험이 필요함)을 로드하지 않음으로써 여전히 할 수 있습니다. WordPress를 안전 측면에서도 훌륭한 플랫폼으로 만드십시오. 그러나 더 이상 "스스로" 관리하는 것이 아니라 전문가의 손이 필요합니다.

문제의 원인이 되는 플러그인

좋은 개발자는 처음 막혔을 때 플러그인에 의존하지 않습니다. 대신 좋은 개발자는 간단하고 우아한 솔루션을 구축하려고 합니다. 반대로 항상 인터넷에서 플러그인을 검색하거나 커뮤니티에서 제안하는 플러그인에 의존하는 것은 매우 잘못된 생각입니다.

궁극적으로 플러그인을 사용하면 WordPress에 특정 기능을 쉽게 추가할 수 있으므로 WP에 사용할 수 있는 다양한 플러그인이 CMS의 강점이 되지만 위험도 있습니다. 플러그인이 일을 더 쉽고 빠르게 할 수 있는 만큼 플러그인은 많은 보안 위험을 내포하고 동시에 사용할 수 있는 WP 버전을 선택하도록 강요하는 동시에 WordPress 인스턴스를 믿을 수 없을 정도로 팽창시킵니다. 좌절하거나 위기에 처한 온라인 존재, 사이트 여는 속도, 따라서 접근성 및 결과적으로 검색 엔진의 올바른 인덱싱으로 측정하십시오.

플러그인 및 보안

먼저 플러그인이 생성하는 보안 문제를 살펴보겠습니다. 한 보고서에 따르면 알려진 WordPress 보안 문제의 절반 이상이 플러그인에서 비롯된 것으로 나타났습니다. 개발자는 플러그인 제작자가 따르는 모범 사례를 따라야 합니다. 이는 그리 좋지 않을 수 있습니다. 따라서 개발자는 플러그인을 사용하기 전에 철저하게 테스트해야 합니다. 이 심사 과정은 플러그인으로 절약한 시간을 어느 정도 제거할 수 있습니다. 따라서 그 시점에서 사이트에 추가하는 데 필요한 기능을 처음부터 개발하는 것이 좋습니다.

WP 버전 제한

"버전 제약"으로 알려진 플러그인은 실행할 수 있는 WP CMS 버전을 제한할 수 있습니다. 이제 WordPress는 릴리스 주기가 매우 공격적이므로 정기적으로 새 업데이트를 릴리스하고 실제로 특정 달에 플랫폼에서 여러 개의 작은 버전이나 패치를 릴리스하는 경우가 종종 있습니다. 이는 WP 팀이 지속적으로 공격 벡터를 수정하고 있기 때문에 이해할 수 있습니다. 그러나 이러한 모든 업데이트에는 문제가 있습니다. WP 업데이트로 인해 플러그인이 손상되어 사이트 작동이 중지되거나 충돌이 발생할 수 있습니다.

물론 CMS를 최신 상태로 유지해야 하지만 플러그인에 의한 버전 제약으로 인해 이 작업이 어려울 수 있습니다. 일부 플러그인 개발자는 항상 플러그인을 테스트하고 업데이트하지만 이 작은 "세계"는 프리미엄 플러그인 그것은 다수를 대표하지 않습니다. 이러한 프리미엄 플러그인 외에는 WP 버전 업그레이드로 인해 문자 그대로 사이트가 손상될 수 있는 실질적인 위험이 있습니다.

플러그인 팽창

대부분의 개발자가 과도한 코드를 사용하지 않는 린 프로젝트를 빌드하는 것이 중요하다는 것을 알고 있다고 가정해 보겠습니다. 이제 일부 플러그인은 이 원칙을 준수하지만 많은 플러그인이 사용자가 가질 수 있는 모든 문제를 해결하려고 하기 때문에 매우 비대해집니다. 개발자가 자신의 사이트와 관련이 없는 다른 XNUMX가지 문제에 대한 솔루션을 제공하면서 플러그인이 한 가지 문제를 해결한다는 것을 발견하는 것이 일반적입니다. (테마와 "빌더"는 말할 것도 없습니다).

플러그인은 WordPress 작업 흐름을 방해합니다.

마지막으로, 많은 플러그인이 만드는 또 다른 일반적인 문제는 플러그인이 WordPress의 사용자 경험을 방해할 수 있다는 사실입니다. 팽창 플러그인 워드프레스의. 예를 들어 플러그인은 사이트 전체에서 게시물이 생성되고 배포되는 방식을 완전히 변경할 수 있습니다.

이로 인해 WP 개발자가 매우 일반적으로 직면하는 문제가 발생합니다. 플러그인을 사용하는 것보다 플러그인을 너무 많이 "주위"에서 작업해야 한다고 생각합니다. 필연적으로 개발자는 플러그인이 프로세스 문제를 해결하는 것처럼 보일 수 있기 때문에 플러그인을 우회하는 이 프로세스를 수행합니다(필연적으로 존재하지 않음).

웹 아키텍처가 진화했습니다

우리는 이미 WordPress가 한동안 사용되어 왔다고 언급했습니다. 웹 사이트가 구축되었을 때 개발자들은 웹 사이트가 항상 단일 파일 시스템과 함께 단일 서버를 사용할 것이라고 생각했습니다. 그러나 개발자들은 다중 노드를 활용하는 소위 마이크로 서버 아키텍처를 점점 더 많이 사용하고 있습니다. 이러한 작업 방식이 더 확장 가능하고 유연하기 때문에 그렇게 하는 것입니다. 그러나 복잡한 아키텍처에서 WordPress를 사용하면 문제가 발생할 수 있습니다. 예를 들어 WP CMS 업데이트를 위해 FTP에 거의 독점적으로 의존하는 경우가 있습니다.

현대 개발자는 분명히 FTP를 통한 코드 업데이트가 구식일 뿐이라고 생각할 것입니다. 개발자는 일반적으로 코드가 작동하기 전에 잠재적인 문제를 중지할 수 있도록 특정 워크플로를 사용합니다. 이는 개발이 로컬에서 수행되고 코드가 버전 제어되며 코드도 자동으로 테스트됨을 의미합니다. 모두 지속적인 통합 프로세스를 통해 이루어집니다. 따라서 짧은 루프를 실행하는 환경에 새 코드를 로드하는 것만으로도 문제가 발생할 가능성이 높습니다.

패치 문제보다 더 큰 문제는 우리가 단일 노드에서 단일 파일 시스템으로 작업하고 있다는 단순한 가정입니다. 웹 서버의 다중 노드 클러스터는 하드웨어 오류와 성능을 모두 개선하므로 이 접근 방식이 점점 더 많이 채택되고 있습니다. 그러나 FTP를 통해 테마 또는 플러그인 업데이트를 설치하면 한 번에 하나의 파일 시스템만 업데이트할 수 있다는 점에서 WP에는 장애물이 있습니다. 따라서 다중 노드 클러스터에서는 모든 노드에 대해 이 업데이트를 수행해야 합니다.

개발자는 이 문제를 해결할 수 있지만 쉽게 해결되지 않는 어려움으로 남아 있습니다. 또한 이 프로세스에는 파일 시스템이 쓰기 가능해야 하므로 WordPress의 핵심인 데이터베이스에 주요 보안 문제가 발생합니다.

일반적으로 고아 데이터 및 데이터 구조

처음에 WordPress 데이터 구조는 간단합니다. 그러나 곧 WP 데이터베이스에 중복 테이블이 있음이 드러납니다. 예를 들어 메타데이터를 "wp_posts"와 "wp_postmeta"라는 두 개의 테이블로 분리해야 하는 이유는 무엇입니까? 하나의 테이블에 모든 데이터를 포함하는 것이 좋지 않습니까? 메타데이터에 대한 두 번째 연결된 테이블이 있는 주석 테이블도 마찬가지입니다.

그 결과 데이터베이스 전체에 여분의 데이터가 남아 있게 됩니다. 예, WP에는 고아 데이터의 영향을 줄이는 데 도움이 되는 몇 가지 기능이 포함되어 있지만 수천 행의 행 수를 조작해야 하는 경우 기능이 실패합니다. 기본적으로 WordPress 기능은 서버 시간 초과를 유발하고 메모리 누수로 이어지며 단순히 효과적이지 않습니다.

물론 SQL 쿼리를 직접 작성하여 단순히 고아 데이터를 줄이도록 선택할 수 있습니다. 그러나 올바른 SQL 쿼리를 작성할 수 있도록 테이블이 연결되는 방식을 철저히 이해해야 합니다. WordPress 데이터베이스의 데이터 분리 정도는 불필요한 것으로 판명되었습니다.

WordPress용 Plesk Toolkit이 작업을 개선하기 위해 수행하는 작업

Plesk의 WordPress Toolkit을 사용하면 단일 제어판에서 WordPress 인스턴스를 쉽게 설정하고 사용자 지정할 수 있습니다. 웹 사이트에 설치되어 있는 한 사용할 수 있습니다. 다음은 WordPress Toolkit이 WP를 관리하는 데 도움이 되는 몇 가지 영역입니다.

보안 관리

툴킷을 사용하면 가장 명백한 보안 허점을 자동으로 닫을 수 있습니다. 예를 들어 XML을 RPC 핑백으로 전환하고 "wp-content" 폴더가 안전한지 확인하는 등의 작업을 할 수 있습니다. 툴킷은 사이트의 보안 상태를 표시하고 보안을 개선하기 위한 권장 사항인 "위험" 또는 "경고"로 문제를 표시합니다.

WP 인스턴스 업데이트

Toolkit 3.x 이상에서 애드온 기능으로 사용할 수 있는 스마트 업데이트 기능을 사용하면 사이트 중단 위험 없이 프로덕션 사이트를 계속 실행하고 동시에 업데이트할 수 있습니다. 이 도구는 업데이트로 인해 발생할 수 있는 문제를 확인하고 어떤 종류의 위험이 있는지 알려줍니다.

복제

WordPress 사이트의 사본을 만들고자 하는 수많은 이유가 있습니다. 예를 들어 라이브로 전환하기 전에 변경 사항을 테스트할 수 있는 스테이징 사이트가 있을 수 있습니다. 준비가 되면 사이트 콘텐츠를 복사하려고 합니다.

또는 공개 사이트가 있고 대중이 액세스하는 것을 원하지 않는 사이트의 사본을 만들 수 있습니다. 또 다른 예는 WordPress 설치의 모델 사본을 가지고 있고 테마 및 플러그인을 포함하여 자동으로 복제하려는 전문 개발자입니다.

또한 몇 가지 변경 사항으로 사이트가 어떻게 다르게 보일 수 있는지 보여주기 위해 다양한 이유로 사이트 사본을 몇 개만 만들고자 하는 고객도 있습니다.

이유가 무엇이든 WordPress Toolkit의 복제 도구를 사용하면 사이트 파일, 사이트 데이터베이스 및 모든 WP CMS 설정을 포함한 모든 항목을 쉽게 복사할 수 있습니다.

신크로니자지오네

다양한 이유로 두 개의 WordPress 웹사이트가 일치하는지 확인하고 싶을 수 있습니다. WP Toolkit을 사용하면 WP 데이터베이스와 모든 WP 파일을 자동으로 동기화할 수 있습니다.

사이트의 스테이징 복사본이 있는 경우 공개 복사본이 다른 곳에서 실행되는 동안 스테이징 사이트에서 변경한 내용을 WP 라이브 사이트에 복사하려고 하므로 사이트를 동기화할 수 있습니다.

마찬가지로 프로덕션 사이트의 일부 데이터를 스테이징 인스턴스로 복사하여 스테이징 버전에 대한 변경 사항이 라이브 데이터와 잘 맞는지 확인할 수 있습니다. 또는 스테이징 사이트에 대한 변경 사항으로 인해 데이터베이스 테이블이 변경되었으며, 이 경우 툴킷을 사용하면 원하는 경우에만 이러한 변경 사항을 데이터베이스에 동기화할 수 있습니다.

WP Toolkit의 동기화 기능에 대한 또 다른 사용 사례는 개발자가 스테이징 사이트를 WordPress 릴리스 버전으로 업데이트하고 라이브 사이트에서 변경 사항을 미러링하려는 경우입니다.

전체 WP CMS 또는 일부만 동기화할 수 있는 옵션이 있습니다. 따라서 WP의 파일, 데이터베이스 또는 둘 다를 미러링할 수 있습니다. 전체 데이터베이스 동기화, 테이블만 동기화 또는 원본에는 있지만 대상에는 없는 테이블 중에서 선택할 수 있다는 점에서 더 세분화된 기능이 제공됩니다. 개별 테이블을 미러링하는 것도 가능합니다.

WP의 버그 사냥

또한 Plesk WordPress Toolkit을 사용하면 개발자가 디버그 모드를 활성화하여 웹 사이트 소스의 오류를 자동으로 감지하고 수정할 수 있습니다.

결론.

위의 모든 사항을 마친 후 함께 작업할 개발자 또는 귀하를 따를 수 있는 에이전시뿐만 아니라 WordPress에서 귀하의 사이트를 호스팅할 모든 호스팅을 선택하는 것이 매우 중요해진다는 것이 분명합니다. 이러한 것에서도 우리는 전문 호스팅에 다크 사이트가 있다는 것이 무엇을 의미하는지 이해합니다.

WordPress는 다루기 쉬운 "객체"가 아닙니다. 물론, 당신은 개발자가 필요하지 않거나 대행사에 묶여 있지 않다고 생각하고 스스로 할 수 있다는 것이 멋지다고 생각하지만 실제로는 그렇지 않으며 오늘날 보안은 제XNUMX자에 대한 의무와 책임 덕분에 더 이상 부차적인 것이 아니라 일차적인 것입니다.