얼마전 워드프레스 기반의 사이트 하나를 제작하였다. 그러나 워드프레스의 다양한 콘텐츠 기능을 활용하기 보다는 포스트의 아카이브/싱글에만 치우쳤고, 기존 테마들로는 구현하기 어려운 요소들이 너무 많아 아예 밑바닥부터 테마를 만들기로 결정했다. 이런 사이트들은 기존 테마를 억지로 비틀어 맞추는 것보다 처음부터 테마를 만드는 것이 훨씬 만들기되 쉽고 결과물도 좋다.
보통 대문 페이지, 워드프레스에서는 프론트 페이지라고 부르는데, 방문자들이 보통 주소만 치고 들어올 때 보게 되는 대표 페이지이자 사이트의 얼굴이기 때문에 가장 신경을 많이 쓰는 페이지라고 할 수 있겠다. 이 페이지를 어떻게 만들까 생각했었는데, 별 신경 안 쓰고 테마의 front-page.php를 활용해 제작하기로 결정했다.
그런데 나중에 만들고 보니 그것은 썩 좋지 않은 결정이었던 것 같다. 이 포스트에서는 그것이 왜 실수인지, 왜 쓰지 말아야 하는지에 대해 적고자 한다. 이렇게 구구절절히 적었으니 테마 제작시 같은 실수를 반복하지 않기를 바란다.
front-page.php 란 무엇인가?
우선 front-page.php가 무엇인지 간단히 설명하고자 한다. 테마를 제작하면 한번쯤 보게 되는 페이지인데, 테마 계층도라는 것이 있다. 테마의 템플릿 파일은 여러 계층으로 존재해서, 어떤 페이지를 표시하기 위한 파일에 대한 우선 순위를 정하기 위한 규칙이라고 할 수 있다.
여기서 front-page.php는 대문 페이지, 즉 프론트 페이지에 대해 가장 높은 우선순위를 가진 템플릿이다. 즉 어떤 페이지를 생성하고, 설정에서 그 페이지를 대문 페이지로 지정한다 하더라도, 그 설정을 무시하고 front-page.php를 우선적으로 템플릿으로 사용하게 된다.
왜 쓰면 안되는 것인가?
클라이언트의 페이지는 보통 디자인이 딱 고정되어 있어 몇몇의 설정만 가능하면 거의 변경하지 않는다. 그 디자인에 대한 대대적인 수정이 필요한 시점이라면 대개 웹사이트 자체를 개편할 기획을 세우게 된다. 그런 점에서 그냥 front-page.php를 사용하는 것은 나쁘지 않아 보인다. 그럼에도 불구하고 front-page.php는 다음과 같은 단점들이 두드러진다. 제목에 그 심각도를 개인적으로 상, 중, 하로 나누어 말머리를 달았다.
[심각도: 하] 페이지 편집 화면의 재활용 불가
고정된 형태의 메인 페이지를 만드려면 메인 페이지 템플릿을 별도로 만들어 놓고, 새 페이지를 만들되 그 페이지의 템플릿을 메인 페이지 템플릿으로 선택한다. 그리고 설정 > 읽기 > 홈페이지 보기 메뉴에서 메인 페이지를 사용할 페이지를 고르는 편이 좋다.
그렇지 않고 front-page.php를 쓰면, 이 페이지를 위한 ‘테마 설정’ 같은 메인 페이지를 위한 메뉴 페이지를 일일이 만들어야 한다. 기존의 페이지 편집 메뉴를 활용하지 못해 조금 귀찮아진다. 물론 사소한 문제다. ACF 같은 플러그인을 사용하기만 해도 이 문제는 더더욱 별 것이 아니게 된다.
[심각도: 중] 페이지의 복제 불가
front-page.php는 사이트의 유일한 메인 페이지이며, 이 레이아웃은 그 파일 안에 구현되어 있기 때문에 다른 페이지에서 재현이 어렵다. 여기서 문제가 조금 더 심각해진다. 사이트 운영자의 입장에서 메인 페이지의 백업이 존재하지 않는다는 사실은 상당히 불편할 것이다.
예를 들어, 메인 페이지의 콘텐츠를 많이 수정하려 한다. 메인 페이지 업데이트 전에 충분히 테스트를 거치는 것이 좋다. 그러나 front-page.php는 이것을 하기 어렵다.
만약 페이지 방식으로 구현했다면 관리자는 얼마든지 비공개 페이지 같은 것을 생성해서 충분히 페이지의 셋팅을 검토한 후에 여유롭게 관리자 대시보드에서 새롭게 생성한 페이지를 프론트 페이지로 설정하는 것으로 작업을 간단하게 할 수 있다.
게다가 이전에 작업한 프론트 페이지는 백업으로서 계속 보관이 가능하다. 프론트 페이지의 역사를 남길 수도 있다. front-page.php로 메인 템플릿을 만들면 이것이 어렵다.
[심각도: 중상] 페이지 옵션의 전역화
front-page.php는 페이지의 존제가 데이터베이스 테이블의 레코드로서 존재하지 않는다. 이것은 장점이 될 때도 있을지 모르지나, 일반적인 경우라면 단점이 더 많은 것 같다.
프론트 페이지의 레코드가 없으므로 기록해야 할 여러 여러 설정들, 예를 들어 어떤 카테고리의 게시물을 N 개 불러와야 할 때의 N의 숫자, 우선적으로 보여주고 싶은 큐레이션된 포스트의 목록들을 저장할 때는 결국 옵션 테이블에 저장해야 한다. 물론 사이트 전역적인 설정은 당연히 옵션 테이블에 저장해야 한다. 그러나 프론트 페이지를 보여주기 위한 설정은 프론트 페이의 국소 설정이지, 사이트 전역 설정이 아니다.
옵션 테이블에 기록을 저장할 때 보통 autoload를 ‘yes’로 기록할 것이다. 그렇다면 메인 페이지의 설정은 다른 싱글 페이지나 아카이브 페이지를 보여줄 때도 불필요하게 로딩될 것이다. 그렇게 해야 할 이유가 없음에도 불구하고.
이것을 피하려고 테이블을 하나 만든다고? 그냥 페이지를 쓰고 포스트 메타 테이블을 활용하는 게 낫지 않을까?
[심각도: 상] 서드 파티 플러그인의 활용 불가
front-page.php는 실제 레코드에 존재하지 않는 페이지이므로, 이 페이지에 대한 여러 추가 작업이 어려워진다. 서드 파티 플러그인을 설치하면 간단해지는 작업들도 일일이 구현하거나 필터들을 구현해 커스텀해야 한다.
가장 적절한 예는 바로 SEO나 opengraph 태그 편집일 것이다. 보통 오픈그래프를 위해 Yoast 같은 SEO 플러그인을 많이 설치해서 쓴다. SEO를 위한 설정이 적지 않기 때문에 이것을 일일이 구현하기는 어렵기 때문이다. 이 때 이런 플러그인들은 원활한 소셜 공유를 위해 opengraph 메타 태그를 자동 생성하는데, front-page.php들은 페이지 정보가 부족하므로 opengraph 메타 태그가 불완전하게 생성되고, 편집도 할 수 없다.
대부분의 사람들이 가장 중요하게 생성하는 것 중 하나가 og:image 인데, front-page.php는 이 정보를 생성하기 어렵다. 보통 SEO 플러그인은 기본값으로 페이지의 대표 이미지(featured image)에서 이 값을 가져오고, 원하면 변경할 수 있도록 한다. 그러나 front-page.php는 이런 데이터가 없다. 그러므로 og:image 정보는 누락된다. 보통 이럴 때는 HTML 바디를 분석해서 처음 나오는 이미지를 og:image의 대용으로 쓰곤 하는데, 그렇게 되면 사이트 메인 페이지의 대표 이미지가 아닌 엉뚱한 아미지가 사이트를 대표하게 되는 것이다.
그리고 페이지의 편집 화면이 없기 때문에 이 페이지를 위한 여러 SEO 옵션 또한 편집 불가하다. SEO에 민감한 사람에게는 큰 문제일 것이다. 이런 식으로 front-page.php는 여러 문제점을 야기한다.
그럼 적절한 front-page.php의 활용 케이스는?
간단하다. 다음 조건을 만족할 때만 front-page.php를 사용하자.
- 가급적 DB에서 내용을 가져오지 않는 고정된 내용을 사용한다.
- DB에서 내용을 가져와도, 복잡한 설정을 필요치 않는다.
- 원래의 프론트 페이지를 임시로 대체해야 한다.
- 오랜 기간동안 사용하지 않는다.