wp-config.php 파일에 대한 개발자 고급 가이드
게시 됨: 2022-09-28
wp-config 를 얼마나 잘 알고 있습니까? 이 몇 줄의 PHP에는 놀라운 힘이 있습니다! 이 기사는 당신이 몰랐을 수도 있지만 실제로는 알아야 하는 wp-config 의 일부를 둘러보는 것입니다.
wp-config.php 파일에 대해 알아야 할 모든 것을 알고 있습니까? 그것에 대한 WordPress 문서 페이지 전체 를 읽었습니까? 끝까지?
wp-config 의 기본 사항에 이미 익숙하다면 공식 WordPress 문서를 읽는 것이 아마도 적절한 스누즈 축제가 될 것입니다.
주제별로 잘 분류되고 "몇 가지 PHP 상수에 대한 완전히 불필요한 열의"라고만 부를 수 있는 내용을 제공하는 실제 개발자 취급을 원하신다면 계속해서 wp-config.php 를 멋지게 만드십시오.
목차
- 누가 이것을 읽어야 할까요?
- 왜 이것을 읽어야 하는가?
- 기초
- wp-config 상수 보기
-
wp-config.php로딩 프로세스 분해- wp-config를 위로 이동할 수 있습니다.
- wp-config.php 파일이 없으면 설정 화면이 로드됩니다.
- wp-config.php가 매우 일찍 로드됨
- wp-config.php를 엉망으로 만들지 마십시오!
- wp-config.php 파일 확인/린팅
- wp-config.php로 워드프레스 보호하기
- 웹사이트 방문자로부터 wp-config.php 보호
- 회전 열쇠/염
- 물건 옮기기 및 숨기기
- 파일 편집기 비활성화
- 자동 업데이트 비활성화
- 외부 HTTP 요청 방지
- 물건 옮기기
- 사용자 및 사용자 메타 테이블 이동
- 콘텐츠, 업로드 및 플러그인 디렉토리 이동
- 콘텐츠 관련 설정
- 사이트 및 대시보드 URL 변경
- 게시물 설정
- 수정 후
- 자동 저장 간격 변경
- 마무리
누가 이것을 읽어야 할까요?
이 기사는 이미 wp-config.php 파일을 편집하는 방법을 알고 있고 여기에 넣을 수 있는 일부 구성 설정을 알고 있는 개발자와 고급 사용자를 대상으로 합니다.
FTP나 cPanel을 사용하여 파일을 편집하는 방법이나 MS Word를 사용하여 편집하면 안 되는 이유에 대해서는 설명하지 않겠습니다.
데이터베이스를 구성하는 방법이나 2013년에 사용했지만 실제로 더 이상 필요하지 않은 레거시 설정을 검토하는 방법에 대해서는 설명하지 않겠습니다. 그리고 대부분의 호스트는 어쨌든 기본 사항을 처리합니다.
wp-config.php 를 처음 사용하는 경우 기본 정보를 제공하는 가이드가 부족하지 않으며 언제든지 공식 문서를 살펴볼 수 있습니다.
왜 이것을 읽어야 하는가?
네, 네, 잘 들었습니다. 이 기사에 넣을 수 있는 내용에 대한 기본적인 세부 사항이 다른 곳에서 모두 다루어지고 호스트가 대부분의 기본 사항을 처리한다면 왜 이 기사를 읽어야 합니까? 그리고 사실, 나는 왜 그것을 쓰는 데 시간을 할애하고 있습니까?
글쎄, 당신이 wp-config.php 편집에 만족하고 그것이 하는 일의 기본을 알고 있다면, 당신은 아마도 적어도 중급 WordPress 개발자일 것입니다.
당신은 아마도 클라이언트에 대한 대규모 사이트 호스팅에 대해 적어도 부분적으로 책임이 있을 것입니다. 따라서 긴급 상황에서 이 파일을 사용할 수 있는 방법을 알아야 합니다. 그리고 이 파일을 충분히 이해하기 위해 편집하더라도 잘못된 작업을 하지 않을 것입니다.
또한 호스트에서 자동으로 구성할 수 있는 것 이상으로 WordPress의 특정 기능을 잠그고 싶을 것입니다.
wp-config.php 로 할 수 있다는 것조차 모르는 일이 있을 수 있습니다! 일부 "아하!" 가질 수 있는 순간들.
이 문서는 WordPress의 내부 구성 요소 중 일부를 구성하는 데 유용한 참조 지점입니다. 따라서 계속 읽고, 북마크하고, 친구 및 동료와 공유하십시오.
기초
나는 이것이 초보자의 기사가 아니라고 말했지만 우리가 같은 출발점에 있는지 확인하기 위해 기본 사실을 확립해야합니다.
wp-config.php 파일은 WordPress 설치의 루트에 있고(다른 위치에 있을 수 있지만 여기에서 다루겠습니다) WordPress 초기화의 일부로 로드되며 WordPress 코어를 구성할 수 있습니다.
워드프레스 실행에 필수적입니다. 다음을 지정할 수 있는 상수 집합을 저장합니다.
- WordPress가 사용하는 데이터베이스 연결 및 테이블 접두사.
- 솔트 및 인증 키와 같은 보안 정보.
-
WP_CACHE및WP_DEBUG와 같은 WordPress 코어의 다른 기능에 대한 설정입니다. - 파일에 자체 옵션을 추가할 수 있는 플러그인에 대한 설정입니다.
- 고유한 구성 옵션.
결정적으로 wp-config.php 는 환경별 파일입니다. 그 내용은 사이트마다 다를 수 있습니다(그리고 그래야 합니다!). 동일한 사이트의 로컬, 스테이징 및 라이브 사본이라도 파일에서 다른 값을 갖습니다.
WordPress에는 WordPress가 작동하는 데 필요한 최소한의 세부 정보가 포함된 wp-config-sample.php 파일이 함께 제공됩니다. 설치의 일부로 이것을 자신의 wp-config.php 에 복사할 수 있지만 요즘에는 일반적으로 수행됩니다.
마지막으로, 기존 사이트에서 wp-config.php 파일을 열 때 업그레이드 실행을 위한 기본 파일 권한 및 FTP 자격 증명과 같은 레거시 기능에 대한 일부 오래된 PHP 상수를 볼 수 있다는 점에 유의하십시오. 당신이 그것들을 사용할 필요가 없을 것 같기 때문에 우리는 여기에서 그것들을 다루지 않을 것입니다.
wp-config 상수 보기
원격 서버에 SSH로 접속하여 파일을 열지 않고도 WordPress 상수 값을 빠르게 확인할 수 있는 몇 가지 방법이 있습니다.
WordPress 코어의 사이트 상태 기능을 사용하면 도구 -> 사이트 상태 -> 정보 -> WordPress 상수로 이동하여 몇 가지 기본 값을 볼 수 있습니다. 데이터베이스 상수는 같은 페이지의 "데이터베이스" 섹션에서도 볼 수 있습니다.
쿼리 모니터 플러그인에는 일반적으로 사용되는 wp-config 상수를 볼 수 있는 "환경" 패널이 있습니다.
WordPress 명령줄 인터페이스인 WP-CLI에는 wp-config.php 에서 상수를 가져오고 설정하는 데 사용할 수 있는 wp config 명령이 있습니다. 이렇게 하려면 일반적으로 먼저 SSH를 수행해야 하지만 WP-CLI 구성에서 별칭을 설정하면 원격 wp-config 파일에서 상수를 보고 수정할 수 있는 빠른 바로 가기를 만들 수 있습니다.
wp-config.php 로딩 프로세스 분해
wp-config.php 파일이 로드되는 시점을 아는 것이 유용합니다. 이 파일로 수행할 수 있는 작업과 수행할 수 없는 작업이 결정되기 때문입니다. 로딩 프로세스를 추적하는 것은 좋은 연습입니다.
WordPress는
index.php파일로 로드를 시작합니다. 이를 위해서는wp-blog-header.php파일이 필요합니다.wp-blog-header.php가 가장 먼저 하는 일은wp-load.php를 로드하는 것입니다.다음으로
wp-load.php는 ABSPATH 상수(기본 WordPress 코어 디렉토리)를 설정하고wp-config.php를 로드하기 전에error_reporting()을 초기화합니다.
이 로딩 과정과 특히 wp-load.php 의 코드는 우리에게 몇 가지 흥미로운 사실을 가르쳐 줄 수 있습니다. 다음은 해당 코드입니다.
/* * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit * of avoiding cases where the current directory is a nested installation, eg / is WordPress(a) * and /blog/ is WordPress(b). * * If neither set of conditions is true, initiate loading the setup process. */ if ( file_exists( ABSPATH . 'wp-config.php' ) ) { /** The config file resides in ABSPATH */ require_once ABSPATH . 'wp-config.php'; } elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) { /** The config file resides one level above ABSPATH but is not part of another installation */ require_once dirname( ABSPATH ) . '/wp-config.php'; } else { // A config file doesn't exist. // [Code here to load the setup screen for in-browser configuration] }여기서 무엇을 볼 수 있습니까?
wp-config.php를 위로 이동할 수 있습니다.
첫째, 주석은 "WordPress 루트"에 wp-config.php 를 넣을 수 있음을 알려줍니다. 언급하지 못한 것은 "루트"가 실제로 wp-load.php 가 있는 ABSPATH 위 의 디렉토리일 수 있다는 것입니다.
dirname( ABSPATH ) . '/wp-config.php' 을 찾는 elseif 에서 이 추가 검사를 볼 수 있습니다. dirname( ABSPATH ) . '/wp-config.php' . elseif 의 추가 조건은 주석에 설명되어 있습니다.
wp-config.php 파일이 없으면 설정 화면이 로드됩니다.
둘째, 설정 파일이 존재하지 않으면 설정 화면을 불러오는 것을 볼 수 있습니다.
이전에 이 화면을 본 적이 없을 수도 있습니다. 웹 기반 사용자 인터페이스에서 데이터베이스 자격 증명과 같은 초기 구성 정보를 입력할 수 있습니다.
이것은 알아야 할 WordPress의 기능입니다. 공개적으로 사용 가능한 웹 서버에 WordPress 코어 파일을 저장했지만 wp-config.php 파일을 만들지 않은 경우 다른 사람(또는 봇일 가능성이 더 높음)이 와서 WordPress 를 설정할 수 있습니다. 호스팅을 손상시킬 수 있습니다.
wp-config.php가 매우 일찍 로드됨
세 번째로 주목해야 할 점은 wp-config.php 가 WordPress의 시작 시퀀스에서 매우 일찍 로드된다는 것입니다. 이는 다음을 의미합니다.
wp-config.php에서 할 수 없는 일이 많이 있습니다. 예를 들어, 여기에 후크(액션 또는 필터)를 추가할 수 없습니다. 이를 수행하기 위한 함수와 데이터 구조가 아직 로드되지 않았기 때문입니다. 그리고 우리는 WordPress의 내부 기능, 개체 및 API에 액세스할 수 없습니다.우리는 다음에 일어날 일에 대해 많은 통제권을 가지고 있습니다. 파일이 너무 일찍 로드되기 때문에 WordPress에 많은 영향을 미칩니다. 이것은 좋기도 하고 나쁘기도 합니다. WordPress를 완전히 죽게 만들 수 있습니다. 그러나 우리는 또한 WordPress의 거의 모든 곳에서
wp-config.php에 정의된 모든 것에 액세스할 수 있습니다.
wp-config.php를 엉망으로 만들지 마십시오!
이 과정에서 우리가 마지막으로 배운 것은 이 큰 힘에는 큰 책임이 따른다는 것입니다.
wp-config.php 파일의 맨 아래에는 다음 행이 있습니다.
/* Add any custom values between this line and the "stop editing" line. */ /* That's all, stop editing! Happy publishing. */ /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php';여기에 몇 가지 지침이 있지만 "편집 중지" 줄이 중요합니다. 이 줄 다음은 WordPress 초기화 시퀀스의 연속입니다. 잘못된 위치에 새 코드를 추가하면 새 코드가 아무 효과가 없는 결과만 나올 수 있습니다. 그러나 안전을 위해 다음 지침을 따르는 것이 좋습니다. 그들은 거기에 이유가 있습니다.
wp-config.php 파일 확인/린팅
프로덕션에서 작업하는 경우 wp-config.php 파일에 오류를 넣고 싶지 않을 것입니다. 여기에서 오류가 발생하면 웹사이트가 손상될 수 있으며 그럴 경우 유용한 오류 메시지가 표시되지 않을 수 있습니다.
-l ("lint") 옵션을 사용하여 명령줄에서 php 를 실행하여 치명적인 PHP 구문 오류가 있는지 wp-config.php 파일을 확인할 수 있습니다.
$ php -l wp-config.php 구문 분석 오류: 구문 오류, 9행의 wp-config.php에 있는 예기치 않은 토큰 "require_once" wp-config.php 구문 분석 오류
쉘 스크립트를 작성할 수도 있습니다.
-
wp-config.php를 임시 파일에 복사하고, - 임시 파일을 편집하고,
- 임시 파일을 린트하고
- 구문 오류가 없는 경우에만 다시 복사하십시오.
명령줄에 만족한다면 wp config set <name> <value> 와 같은 WP-CLI 명령을 사용하여 수동으로 수행하는 것보다 안전하게 값을 설정하는 것이 더 안전합니다.
WP-CLI를 사용하여 구성 값을 나열할 수도 있습니다(이것은 일부 항목이 제거된 샘플입니다. 아이디어를 얻었습니다!):
$ wp 구성 목록 +---------------------+------------------------------ --------+----------+ | 이름 | 가치 | 유형 | +---------------------+------------------------------ --------+----------+ | 루트 디렉토리 | /Users/smithers/sites/snpp | 변수 | | webroot_dir | /Users/smithers/sites/snpp/public | 변수 | | table_prefix | wp_ | 변수 | | WP_HOME | https://snpp.test | 상수 | | WP_SITEURL | https://snpp.test/ | 상수 | | DB_NAME | snpp | 상수 | | DB_USER | 루트 | 상수 | | DB_PASSWORD | 몽고메리 | 상수 | | DB_호스트 | 127.0.0.1 | 상수 | | DB_CHARSET | UTF8mb4 | 상수 | | DB_COLLATE | | 상수 | | DB_PREFIX | wp_ | 상수 | | WP_DEBUG | 1 | 상수 | | WP_DEBUG_LOG | 1 | 상수 | | WP_DEBUG_DISPLAY | | 상수 | | WP_ENVIRONMENT_TYPE | 개발 | 상수 | | DISABLE_WP_CRON | | 상수 | | DISALLOW_FILE_EDIT | 1 | 상수 | +---------------------+------------------------------ --------+----------+
이 두 가지 기술을 사용하면 번거로움을 덜고 실수로 중요한 파일의 잘못된 위치에 세미콜론을 넣는 것을 막을 수 있습니다.
wp-config.php로 WordPress 보안
보안은 WordPress에서 끊임없이 뜨거운 주제입니다. wp-config 파일에서 변경할 수 있는 일부 설정은 보안 도구 상자에 더 많은 도구를 추가합니다.
wp-config 파일의 이러한 부분은 분명히 좋은 WordPress 보안을 달성하기 위해 사용해야 하는 유일한 것은 아닙니다. 다음 섹션의 정보 외에도 웹 사이트 보안을 완전히 이해해야 합니다.
웹사이트 방문자로부터 wp-config.php 보호
wp-config 파일은 기본적으로 웹 사이트의 루트 디렉토리에 있으며 데이터베이스 로그인 세부 정보 및 암호 솔트와 같은 중요한 정보가 포함되어 있습니다. 이 정보가 공개적으로 사용되는 것을 원하지 않으므로 wp-config 파일이 웹 사이트 방문자로부터 보호되는지 확인해야 합니다.
호스팅 회사에서 종종 이 작업을 수행합니다. 도메인 바로 뒤에 /wp-config.php 를 추가하여 브라우저에서 파일에 액세스하여 확인할 수 있습니다. 파일을 이동한 경우 이 URL이 다를 수 있습니다.
웹사이트의 루트 디렉토리 위의 디렉토리에 wp-config 파일을 배치했다면 볼 수 없어야 합니다. 다른 대부분의 경우 어쨌든 파일을 방문하려고 할 때 PHP 오류 메시지가 표시되므로 일반적으로 여기에서 할 일이 없습니다. 그러나 적절하게 보안을 유지하려면 웹 서버(Apache 또는 nginx) 구성을 수정하여 액세스를 차단하면 됩니다.
마지막으로 웹사이트의 파일을 Git에 저장하는 경우 wp-config 파일을 Git 저장소에 저장 하지 않는 것이 중요합니다. 그렇게 하면 사이트에 대한 중요한 정보가 누출될 수 있지만 또한 어쨌든 각 환경에서 이 파일의 다른 버전을 원할 수 있습니다. 따라서 .gitignore 에 추가하고 각 환경의 파일을 수동으로 관리하는 것이 좋습니다.
회전 열쇠/염
열쇠/소금이란 무엇입니까?
키 및 솔트 섹션은 wp-config 의 가장 신비한 부분 중 하나입니다. 이 이상하게 보이는 상수 집합은 쿠키 및 임시 항목과 같은 항목을 암호화하는 데 도움이 됩니다. WP 엔진이 있는 것처럼 세부 사항에 들어가지 않고 소금과 키를 모르는 경우 암호를 해독하기 더 어렵게 만드는 추가 계층을 무작위로 추가합니다.
키/솔트를 "회전"해야 하는 이유는 무엇입니까?
먼저, "회전"은 "변화"에 대한 멋진 단어입니다. 왜 "회전"을 사용하는지 모르겠습니다. 우리가 같은 키 세트로 다시 돌아오지 않는 것과 같습니다!
키와 솔트가 여전히 비밀이라고 보장할 수 없기 때문에 사이트가 해킹된 경우 키와 솔트를 변경해야 합니다. 그러나 암호를 사용하는 것처럼 암호를 정기적으로 회전하여 암호가 무엇인지 아무도 모르게 하고 싶을 수도 있습니다.
키/솔트 회전 문제
열쇠와 소금을 바꾸는 것은 고통이 없는 것이 아닙니다. 쿠키 세트를 가지고 있는 사람은 누구든지 잃게 됩니다. 따라서 로그인한 사람은 모두 부팅되고 WooCommerce 카트가 있는 사람은 카트가 비워집니다.
키/솔트 회전 방법
내 말은, wp-config 파일 을 편집하고 이전 문자 위에 임의의 새 문자를 입력할 수 있습니다. 그러나 이것은 지루할 것이고 인간은 무작위성에 그다지 능숙하지 않습니다.
그래서 wp-config 에서 새로운 키/솔트를 설정하는 몇 가지 방법을 알려드리겠습니다.
- 생성기에서 수동으로 키 추가: wordpress.org 생성기를 사용하여 필요한 코드를 얻을 수 있습니다. 이전 값 대신
wp-config파일에 복사하여 붙여넣기만 하면 됩니다. - 플러그인 사용: Sucuri Security, iThemes Security 및 Malcare와 같은 많은 보안 플러그인에는 모두 이 기능이 있습니다. 그리고 Salt Shaker는 일정에 따라 이 프로세스를 자동화하는 전용 플러그인입니다.
- WP-CLI를 사용합니다. 우리는 아직 WP-CLI가 얼마나 멋진지 말했습니까? 우리는 했습니까? 확인. 글쎄, 우리는 그것을 다시 말하고 있습니다! 그리고
wp config shuffle-salts명령을 사용하여 몇 초 만에 이 작업을 수행할 수 있습니다.
물건 옮기기 및 숨기기
보안 담당자는 "불분명한 보안"이 전혀 보안이 아니라고 말할 것이지만 일부 사람들은 여전히 해커에 대한 추가 장벽을 설정하기 위해 WordPress 항목을 숨기고 싶어합니다.
wp-config 파일은 이 작업을 수행하기 위한 여러 옵션을 제공하며 나중에 항목 이동 및 파일 편집 끄기에 대한 섹션에서 이에 대해 설명합니다.
파일 편집기 비활성화
WordPress에는 관리 대시보드 내에서 테마 및 플러그인의 파일을 편집할 수 있는 편리한 기능이 있습니다. wp-config.php 를 편집하면 이러한 파일 편집기를 끌 수 있습니다! 어떤 사람들은 마음의 평화를 위해 비활성화하는 것을 좋아합니다.
이제 누군가가 이 편집기를 사용하는 데 필요한 사이트에 대한 관리자 액세스 권한이 있으면 플러그인을 업로드하고 원하는 대로 할 수 있다는 보안 주장이 있다는 것을 압니다. 이러한 편집기를 활성화한다고 해서 해커가 이미 가지고 있는 것보다 더 많은 권한을 제공하는 것은 아닙니다.
그러나 이러한 기능을 꺼서 보안이 실제로 향상되지 않을 수도 있지만 실제로 수행하는 실제 이유는 실제로 관리자로 승인된 사람들이 사용하지 못하도록 하기 위함입니다. 대행사라면 고객이 모든 테마 파일을 편집할 수 있다는 사실을 알리고 싶지 않을 것입니다. 그렇죠?
많은 호스트는 기본적으로 이 기능을 비활성화합니다. 그러나 그것들을 사라지게 하려면 다음을 추가하는 것만 큼 간단합니다.
define( 'DISALLOW_FILE_EDIT', true ); 또는 정말로 파일 시스템을 잠그고 싶다면 DISALLOW_FILE_MODS 가 있습니다. 이에 대해서는 다음 섹션에서 다룰 것입니다.
자동 업데이트 비활성화
당신이 그들을 좋아하든 싫어하든 WordPress의 자동 업데이트는 WordPress 생태계에 긍정적인 영향을 미쳤으며 무시하기 어렵습니다. 그러나 모든 사람이 자신의 소프트웨어가 스스로를 돌보는 것을 원하지는 않습니다!
따라서 wp-config 를 사용하면 다음과 같이 설정할 수 있는 간단한 자체 설명 상수 세트를 사용하여 자동 업데이트 프로세스를 제어할 수 있습니다.
# Disable all core updates: define( 'WP_AUTO_UPDATE_CORE', false ); # Enable all core updates, including minor and major: define( 'WP_AUTO_UPDATE_CORE', true ); # Enable core updates for minor releases (default): define( 'WP_AUTO_UPDATE_CORE', 'minor' ); 더 극단적인 것을 원하면 DISALLOW_FILE_MODS 할 수 있습니다.
define( 'DISALLOW_FILE_MODS', true );그러나 이렇게 하면 WordPress가 코어, 테마, 플러그인 또는 번역과 관련된 모든 것을 디스크에 쓰는 것을 중지하고 사소한 업데이트에 대한 이메일 알림을 비활성화합니다. 핵심 기고자는 "자신이 무엇을 하고 있는지 정확히 알지 못하면 사용하기에는 미친 듯이 어리석다"고 설명했습니다.
약간 덜 극단적인 것은 AUTOMATIC_UPDATER_DISABLED 입니다. 이렇게 하면 플러그인과 테마를 설치할 수 있지만 이들 또는 핵심 소프트웨어는 업데이트되지 않습니다. 그것은 또한 번역 업데이트를 비활성화합니다.
define( 'AUTOMATIC_UPDATER_DISABLED', true );보다 세밀한 제어를 위해 필터를 사용하는 것과 같은 다른 옵션을 포함하여 wordpress.org에 이 모든 것에 대한 자세한 가이드가 있습니다.
마지막으로, 귀하의 사이트가 버전 제어되는 경우 WordPress가 귀하를 위해 업데이트를 비활성화했을 가능성이 높습니다. 예를 들어, 사이트의 루트(또는 다양한 다른 위치에 있는 다양한 다른 파일)에 .git 디렉토리가 있으면 wp-config 에 아무것도 추가할 필요 없이 자동 업데이트가 비활성화됩니다.
HTTPS 구성
HTTPS를 구성하는 것은 종종 어려운 일이었습니다. LetsEncrypt 및 Cloudflare와 같은 곳에서 무료로 제공되는 신뢰할 수 있는 보안 인증서의 출현으로 많은 호스트가 몇 번의 클릭만으로 이를 설정할 수 있습니다. 이 설정은 아마도 레거시로 간주되어야 하지만 여전히 무언가를 위해 필요할 수 있습니다.
FORCE_SSL_ADMIN 상수는 WordPress에 로그인 페이지와 WordPress 대시보드에 항상 SSL을 사용하도록 지시합니다. 이렇게 하면 보안 자격 증명과 쿠키가 암호화되지 않은 상태로 전송될 수 없습니다.
그러나 내가 말했듯이 좋은 호스팅 회사는 어쨌든 귀하의 사이트에서 HTTPS 설정을 간단하게 만들 것이므로 그냥 하십시오.
외부 HTTP 요청 방지
마지막으로 보안에서 외부 HTTP 요청을 차단할 수 있습니다. 즉, WordPress는 API 호출 또는 업데이트 다운로드와 같은 작업을 수행하기 위해 인터넷의 다른 장소에 연결할 수 없습니다.
WordPress가 HTTP를 통해 외부 서비스에 연결하도록 허용하는 것은 일반적으로 업데이트를 받고, 플러그인 및 테마를 설치할 수 있고, HTTP 요청을 끄면 많은 플러그인이 중단되기 때문에 좋은 생각입니다.
그러나 WordPress 코어와 많은 플러그인 및 테마는 "원격 측정" 또는 "사용 데이터"를 중앙 서버로 다시 보냅니다. 이것은 좋을 수 있습니다. 플러그인 및 테마 개발자가 소프트웨어를 사용하는 사람과 방법을 알 수 있도록 도와줍니다. 그러나 특히 민감한 데이터가 있는 사이트가 있는 경우 이 기능을 비활성화할 수 있습니다. 그리고 다음과 같이 할 수 있습니다.
define( 'WP_HTTP_BLOCK_EXTERNAL', true );연락할 수 있는 호스트의 허용 목록을 갖고 싶다면 그렇게 할 수도 있습니다.
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );액세스 가능한 호스트 목록은 쉼표로 구분된 목록이며 와일드카드 하위 도메인이 허용됩니다. 또한 Log HTTP Requests 플러그인을 사용하여 어떤 호스트에 연락하는지 모니터링할 수 있습니다.
물건 옮기기
모든 WordPress 설치가 동일하지는 않습니다. 일부 호스트 또는 프레임워크는 보안상의 이유로 디렉토리를 이동하거나 사이트별 코드 및 자산을 WordPress 코어와 분리하여 유지하기를 원합니다. Git 및 Composer를 사용하여 WordPress를 관리하는 방법에 대한 내 기사에서는 이 접근 방식의 몇 가지 이점을 다룹니다.
그렇다면 WordPress는 더 나은 용어가 필요한 "움직이는 물건"에 대해 어떤 옵션을 제공합니까?
데이터베이스 접두사 변경
WordPress는 기본적으로 데이터베이스 테이블 이름 접두사 wp_ 를 사용합니다. 이 접두사는 모든 데이터베이스 테이블 이름에 추가되며 옵션 테이블의 <prefix>user_roles 옵션 및 <prefix>capabilities 사용자 메타 항목과 같은 다른 위치에서도 사용됩니다.
해커나 공격자는 공격에 기본 접두사를 사용하여 데이터베이스 테이블을 검색하거나 수정하려고 할 수 있습니다. 따라서 일부 사람들은 기본값에서 변경하는 것이 좋습니다.
wp_config 옵션 $table_prefix 를 사용하면 이 작업을 수행할 수 있으며 밑줄이 붙은 짧지만 임의의 문자열로 설정해야 합니다.
$table_prefix = 'b4F8az_'; 이것은 WordPress에 b4F8az_posts 대신 wp_posts 와 같은 테이블 이름을 사용하도록 지시합니다.
이 변경 사항을 수용하기 위해 코드를 업데이트할 필요는 없지만(코드가 매우 잘못 작성된 경우 제외), 기존 사이트에서 이를 변경하는 경우 데이터베이스를 일부 업데이트해야 합니다. 테이블!
일부 보안 플러그인이 이 작업을 수행하며 이 작업도 수행할 수 있는 플러그인이 있습니다. 이 작업을 수행하기 전에 데이터베이스를 백업하는 것이 좋습니다. 기본이 아닌 테이블 접두사를 선택하는 것이 사이트가 이동 중일 때 변경할 때가 아니라 WordPress를 설치할 때 가장 잘 수행된다는 점에 유의하십시오.
여기서 흥미로운 점은 $table_prefix 가 상수가 아니라 변수라는 것입니다. WordPress가 제공하는 샘플 구성 파일에 정의된 유일한 변수입니다! 그리고 여전히 궁금한 점이 있다면: 예, WP-CLI의 wp config 명령은 사용자가 알 필요도 없이 이를 처리합니다!
사용자 및 사용자 메타 테이블 이동
나는 이것을 한 적이 없으며 이 기사를 작성할 때만 수행할 수 있다는 것을 배웠지만 사용자 및 usermeta 테이블의 이름을 완전히 변경할 수도 있습니다.
이것이 "SELECT * FROM wp_usermeta;"를 시도하는 SQL 주입 공격을 방지하는 데 도움이 된다고 생각하지만, 그렇게 하는 다른 이유를 듣게 되어 기쁩니다.
CUSTOM_USER_TABLE 및 CUSTOM_USER_META_TABLE 상수가 필요합니다.
define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' ); define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );이러한 상수를 사용하기 전에 알아야 할 몇 가지 주의 사항이 있습니다. 이 기능을 사용하기 전에 공식 문서를 확인하십시오. 그리고 사용자 정의 테이블 접두사를 사용하는 것과 마찬가지로 이는 나중에 수정하는 것보다 새 사이트를 설치할 때 확실히 가장 잘 수행됩니다.
콘텐츠, 업로드 및 플러그인 디렉토리 이동
전체 wp-content 디렉토리, uploads 디렉토리, themes 및 plugins 디렉토리를 이동할 수도 있습니다. 참고 사항:
- 이러한 경우에 URL과 디렉토리를 설정해야 합니다.
- 전체 경로 또는 적절한 상대 경로를 사용하는 데 주의해야 합니다.
- 이러한 설정에는 후행 슬래시가 없어야 합니다.
자세한 내용은 공식 문서를 참조하십시오. 여기에서 모든 내용을 반복하지는 않겠습니다.
마지막으로 잘못 코딩된 플러그인이나 테마를 변경하면 엉망이 될 수 있습니다. 이런 일은 절대 일어나서 는 안되지만 알아둘 가치가 있습니다.
플러그인 또는 테마 개발자라면 이러한 경로가 변경될 수 있음을 기억하는 것이 중요합니다. 따라서 디렉토리나 URL에 대한 경로를 하드 코딩하지 않도록 하십시오. 유용한 기능은 다음과 같습니다.
wp_upload_dir
plugins_url
plugin_dir_url
plugin_dir_path
get_stylesheet_directory
get_stylesheet_directory_uri
get_template_directory – 하위 테마의 경우 상위 테마의 위치를 반환합니다.
get_template_directory_uri
WordPress 개발자 핸드북에 이와 같은 기능에 대한 보다 완전한 목록이 있습니다.
마지막으로 WordPress 설치 내에서 파일을 이동하는 것 외에도 wp-admin 위치를 이동하거나 사이트 위치를 변경할 수도 있습니다. 그리고 wp-config.php 도 도움이 될 수 있습니다.
콘텐츠 관련 설정
WordPress는 결국 콘텐츠 관리 시스템입니다. 따라서 컨텐츠 옵션을 제어하기 위해 wp-config.php 에서 사용할 수 있는 일부 상수를 예상할 수 있습니다. 우리가 무엇을 할 수 있는지 살펴보겠습니다.
사이트 및 대시보드 URL 변경
이것들은 항상 나를 혼란스럽게 했습니다.
사이트의 URL을 설정하려면 WP_HOME WP_SITEURL 를 사용해야 합니다.
WP_SITEURL 상수는 사이트의 URL을 변경하지 않습니다.
혼란스러운?
WP_SITEURL 이 하는 일에 대한 공식 설명은 "워드프레스 코어 파일이 있는 주소"입니다. 이것은 디렉토리가 아니라 URL이기 때문에 혼란스럽습니다.
이 일에 대해 나를 비난하지 마십시오. 나는 단지 그 날의 여행 가이드일 뿐입니다!
WP_HOME 및 WP_SITEURL 설정은 wp_options 데이터베이스 테이블의 home 및 siteurl 항목을 재정의합니다. 그래서 적어도 의미가 있습니다.
// NOTE: These must not have trailing slashes define( 'WP_HOME', 'https://helfish.media' ); define( 'WP_SITEURL', 'https://hellfish.media/wordpress` );사이트를 새 URL로 이동한 후 이러한 상수를 사용하여 데이터베이스를 올바르게 수정하는 동안 사이트를 시작하고 실행할 수 있습니다. 나중에 제자리에 두도록 선택할 수도 있습니다.
WP_SITEURL 설정은 핵심 WordPress 파일을 다른 디렉토리로 이동한 경우에도 사용할 수 있습니다.
또한 이를 사용하면 데이터베이스 쿼리 한두 개를 실행하여 옵션 테이블에서 값을 가져오는 것을 방지할 수 있으므로 성능이 약간 향상될 수 있습니다. 객체 캐싱을 수행하는 경우 그 이득은 아마도 무시할 수 있습니다.
공식 문서에 좀 더 자세한 내용이 있으며 사이트 URL 변경에 대한 전체 지원 문서도 있습니다. 또한 이 기사에는 이 기사를 조사하기 전에는 들어본 적이 없는 wp-config.php 에 대한 모호한 RELOCATE 상수가 포함되어 있습니다.
마지막으로, 사이트를 이동할 때 변경해야 하는 것은 이것만이 아니라는 점에 유의하십시오. URL 문자열에 대한 전체 데이터베이스 검색 및 바꾸기가 권장됩니다.
게시물 설정
게시물과 관련하여 수정할 수 있는 몇 가지 설정이 있습니다. 대부분은 수정 후 또는 자동 저장 기능과 관련이 있습니다.
수정 후
WordPress의 기본 동작은 게시물과 페이지에 대한 모든 수정 사항을 저장하는 것입니다. 이것의 장점은 이전 버전으로 쉽게 되돌릴 수 있다는 것입니다. 단점은 이러한 모든 개정이 데이터베이스의 공간을 차지하고 데이터베이스 쿼리 속도를 저하시켜 사이트 성능에 영향을 줄 수 있다는 것입니다.
wp-config.php 파일에서 WP_POST_REVISIONS 값을 수정하여 포스트 개정판을 완전히 비활성화할 수 있습니다. 기본값은 true입니다. 개정판을 끄려면 대신 false로 설정할 수 있습니다.
define( 'WP_POST_REVISIONS', false );: WP 엔진을 포함한 일부 호스트는 기본적으로 사후 개정을 비활성화합니다. 변경하기 전에 호스팅 제공업체에 확인하는 것이 좋습니다. 이것은 호스트마다 다르지만 WP 엔진을 사용하는 경우 서버 수준에서 덮어쓰기 때문에 wp-config 를 통해 개정을 활성화할 수 없습니다 .
호스트가 이것을 제어하고 변경하려고 하면 반드시 무언가를 깨뜨리지는 않겠지만 시간을 낭비할 수 있습니다.
수정 후 데이터베이스 쿼리 속도가 느려지 는 것이 우려되는 경우 WordPress가 저장하는 수정 수를 제한하는 것이 더 나은 옵션일 수 있습니다. 이것은 WP_POST_REVISIONS 상수에 의해 제어되며, 유지하려는 최대 개정 수로 설정할 수 있습니다.
define( 'WP_POST_REVISIONS', 5 );자동 저장 간격 변경
자동 저장이 실행되는 빈도를 줄일 수도 있습니다. 기본값은 60초마다이지만 원하는 대로 변경할 수 있습니다. 편집증이 있는 경우 대신 20초 또는 30초로 설정하는 것이 좋습니다.
자동 저장에 걸리는 시간을 염두에 두는 것이 중요합니다. 너무 자주 발생하여 중복되는 것을 원하지 않으므로 이 값을 예를 들어 1초로 설정하지 마십시오. 자동 저장이 기본값인 60초 이상 걸릴 가능성은 거의 없지만 요청을 저장하려면 간격을 늘릴 수 있습니다.
define( 'AUTOSAVE_INTERVAL', 120 ); // Seconds마무리
잠금 해제를 기다리고 있는 wp-config 에는 많은 가능성이 있습니다. 이 투어가 가능한 것 중 일부를 강조하는 데 도움이 되었기를 바랍니다. 향후 기사에서는 다중 사이트 설치 및 디버깅을 포함하여 wp-config 고유의 고급 기능에 대해 자세히 알아볼 것입니다. 또한 메모리 제한, CRON 문제 및 환경 유형을 조정하는 방법을 포함하여 성능을 살펴볼 것입니다.
공식 문서에 숨어 있는 다른 보물이 발견되기를 기다리고 있다는 것은 의심의 여지가 없습니다. wp-config 사용에 대한 어떤 팁을 찾았습니까? 의견에 알려주십시오.