Changwoo Blog

[태그:] 테마

  • 테마 style.css 파일의 대안 위치가 있었군

    보통 테마는 테마의 루트에 style.css 를 둔다. 그러면 코어는 style.css 파일에서 테마의 정보를 추출한다. 이게 정석이다.

    그러나 오늘 sage라는 테마를 보다 보니, sage/resources 디렉토리에 functions.php 파일과 style.css 파일이 발견되었다. 이게 어떻게 가능한 가 싶어 뜯어 보니, wp-includes/themes.php 파일에 정의된 search_theme_directories() 함수에서 이런 동작을 지원하는 것이었다.

    1. wp-content/themes 의 디렉토리를 찾아, 해당 디렉토리에 있는 style.css 파일을 발견하면 메타데이터를 읽는다.
    2. style.css 파일이 발견되지 않는다면 해당 디렉토리의 하위 디렉토리에서 style.css를 검색한다. 파일이 빌견되면 그렇다면 테마의 루트는 해당 디렉토리가 된다.

    예를 들어 wp-content/themes/foo 라는 테마 루트 디렉토리에 bar라는 하위 디렉토리를 두고 거기에 style.css를 둔다. 그러면 wp-content/themes/foo/bar/style.css로 경로가 만들어질 것이다. 이 때 코어는 wp-content/themes/foo/bar를 테마 루트로 인식하게 된다.

    최근 테마 루트에 composer.json, package.json등 여러 설정 파일들이 존재하게 되고 이것들은 이 디렉토리를 포기할 수 없다. 그런데 이런 설정 파일과 테마의 템플릿이 서로 뒤섞이면 매우 지저분하다. 이것을 의식한 건 아닌가 모르겠다. 아무튼 이렇게 하면 템플릿 코드와 여러 설정 파일을 깔끔히 분리할 수 있어 좋은 방법이라고 생각한다.

  • front-page.php를 쓰지 말아야 할 이유

    얼마전 워드프레스 기반의 사이트 하나를 제작하였다. 그러나 워드프레스의 다양한 콘텐츠 기능을 활용하기 보다는 포스트의 아카이브/싱글에만 치우쳤고, 기존 테마들로는 구현하기 어려운 요소들이 너무 많아 아예 밑바닥부터 테마를 만들기로 결정했다. 이런 사이트들은 기존 테마를 억지로 비틀어 맞추는 것보다 처음부터 테마를 만드는 것이 훨씬 만들기되 쉽고 결과물도 좋다.

    보통 대문 페이지, 워드프레스에서는 프론트 페이지라고 부르는데, 방문자들이 보통 주소만 치고 들어올 때 보게 되는 대표 페이지이자 사이트의 얼굴이기 때문에 가장 신경을 많이 쓰는 페이지라고 할 수 있겠다. 이 페이지를 어떻게 만들까 생각했었는데, 별 신경 안 쓰고 테마의 front-page.php를 활용해 제작하기로 결정했다.

    그런데 나중에 만들고 보니 그것은 썩 좋지 않은 결정이었던 것 같다. 이 포스트에서는 그것이 왜 실수인지, 왜 쓰지 말아야 하는지에 대해 적고자 한다. 이렇게 구구절절히 적었으니 테마 제작시 같은 실수를 반복하지 않기를 바란다.

    (더 보기…)

  • Astra 테마 분석 노트

    아스트라 테마 특징

    • 장점: 엄청나게 많은 부분에 디테일하게 액션과 필터가 정의되어 있어 커스터마이즈 할 수 있는 여지가 풍부하다.
    • 단점: 부분부분 디테일하게 1:1 파트별로 커스터마이즈가 가능하나 지나치면 너무 디테일한 것이 독이 되어 나중에 돌아가는 것 파악이 어려움. 사실 일반적인 테마 커스텀들의 문제점이긴 하지만. 아스트라는 액션 필터가 너무 세밀해서 이 문제가 부각된다.

    아스트라 테마 동작 포인트 노트

    제작자들이 커스터마이즈를 염두에 두고 제작하여 여러 부분들이 흩어져 있다. 이 흐름을 잘 파악하지 않으면 커스터마이즈 개발시 갈피를 잡기 매우 어렵다. 아스트라 테마를 사용한 커스터마이즈시 이 노트를 보고 주요 흐름을 복기하는 것이 중요할 것으로 보인다.

    주요 페이지 진입점은 테마의 기본인 archive.php, index.php, page.php, single.php 이며 여기서부터 테마의 흐름이 시작된다.

    index.php, single.php, page.php 셋은 거의 동일한 구조이다. 단, page.php 의 본 콘텐트 함수는 astra_content_page_loop() 으로 조금 다르다.

    메인 루프를 돌기 전후에 위치한 ‘astra_primary_content_top’, ‘astra_primary_content_bottom’ (액션 태그 이름과 콜백 함수 이름이 동일하다) 두 액션은 커스터마이징 전용으로 보인다. 부모에서는 이 부분에 별도로 정의하는 액션 콜백이 없다.

    astra_content_loop(), astra_content_page_loop() 흐름 노트

    1. 메인 콘텐트를 출력하는 부분인 astra_content_loop, astra_content_page_loop 액션에서 보다 복잡한 레이아웃과 구조를 따라 분기하게 된다. 여기서 테마 UI 설정에서 적용된 여러 옵션을 따라 가게 될 것이다.

    2. astra_content_loop, astra_content_page_loop 둘 다 기본으로 ‘Astra_Loop’이라는 루프 전용 클래스에서 콜백 처리한다. 두 함수 다 Astra_Loop::loop_markup( $is_page ) 함수를 호출한다. 페이지면 $is_page = true 인 차이점 뿐이다.

    3. Astra_Loop::loop_markup() 에서 일괄적으로 main#main 태그를 출력한다. 그리고 페이지/비-페이지에 따라 다른 템플릿 조각을 부른다.

    페이지:
    Astra_Loop::template_parts_page().
    –> template-parts/content-page.php.

    비-페이지:
    Astra_Loop::template_parts_post().
    –> template-parts/content-single.php.

    4. content-*.php 에서 article#post-<post-ID> 태그 출력됨.

    페이지: template-parts/content-page.php 내에서 the_content() 함수가 호출되면서 메인 내용 출력.

    비-페이지:
    astra_entry_content_single() 호출.
    astra_entry_content_single_template() 호출.
    –> template-parts/single/single-layout.php.

    5. the_content() 앞뒤로 astra_entry_content_{before,after}() 호출이 있는데, 이와 관련된 콜백은 아스트라 테마 자체에서는 발견되지 않는다. 커스터마이즈용으로 판단한다.

    기타 사항

    template-parts/blog/blog-layout.php 라는 부분이 있는데, 이것은 검색용 템플릿이다.

    메인 루프를 분석하는 핵심인 클래스는 astra/inc/class-astra-loop.php 에 있는 Astra_Loop 이다. 말하자면 여기가 공략 포인트다.


  • 테마 만지는 거 재밌네

    요즘 내 블로그에 이것저것 건드리는 게 많아졌다. 테마를 TwentyTwenty로 바꾸고 나서 여러 가지 바꾸고 있다. 일단 이 테마, 글씨가 커도 너무 크다. 장난하나? 싶을 정도로 크다. 글씨 크기 좀 조정하고 색상 같은 것 좀 취향에 맞게 바꾸고 스크린샷을 찍었다. 블로그 기념 사진 같은 걸로 해서 남겨 둬야지.

    (더 보기…)

  • 새 워드프레스 운영자에게 보내는 잔소리

    클라이언트에게 답신 메일을 보내다, 장문이 되어버렸다. 그런데 나중에 발췌해서 공유하고자 함이니 고객에 대한 것은 편집해서 공유해 본다. 잘 쓴 글은 아니지만 그래도 나누고 싶다.

    워드프레스를 사용하여 운영을 시작하시는 분들께는 다음과 같은 조언을 드리고 싶습니다.

    (더 보기…)

  • Uncode 테마 + KBoard 게시판은 성능 저하를 일으킬 수 있습니다.

    불타는 금요일을 보내고 토요일 새벽까지 디버깅을 한 결과입니다.
     Uncode 테마와 KBoard 게시판을 사용할 경우 워드프레스의 성능 저하를 유발시킬 수 있습니다. 둘을 따로따로 쓰면 문제가 없지만 같이 사용하는 경우 사이트에 로딩이 생기며, 특히 비주얼 컴포저 사용시 심각한 로딩 시간이 생기게 됩니다.

    원인은 KBoard의 세션과 Uncode 테마의 ‘list_images‘ AJAX 동작 때문에 발생합니다. KBoard의 메인 파일인 kboard/index.php 파일의 초반에는 session_start()로 세션을 시작하는 구문이 있습니다. 그리고 이 세션은 KBoard 곳곳에서 활용됩니다.

    한편 Uncode는 list_images라는 ajax 액션을 통해 uncode_list_images()라는 함수를 동작시킵니다(uncode/core/inc/admin.php: 1086). 이 함수는 무려 모든 이미지 파일을 불러와 그 이미지 파일의 용량을 계산합니다. 그리고 아래와 같은 메시지를 응답으로 넘깁니다.

    The Adaptive Images system is using 87.6M of the 6.29G space left.

    JSON 포맷이 아닌, 그냥 단순 텍스트 응답으로 날아옵니다. 이 응답이 자바스크립트 같은 곳에서 프로그래밍적으로 유의미한지는 확인하지 않았으나, 그렇게 보이지는 않습니다.

    문제는 이미지의 양이 많아질 때 터집니다. 제가 작업 중인 사이트는 이미지 파일만 1만개에 가깝게 유지하고 있습니다. 사이트의 용량만도 기가바이트급입니다. 언코드는 무식하게도 이 1만개에 육박하는 이미지를 매번 관리자 화면 로딩시 별도의 AJAX 요청을 통해 모두 쿼리로 불러와, 용량을 계산하고, 위 메시지를 출력하고 있던 것입니다.  이 계산을 위해 대략 수 초, 심하면 저의 경우처럼 30~40초까지 걸리기도 합니다.

    이제 이 상태에 KBoard가 끼어들면 문제가 정말 심각해집니다.  KBoard는 로딩될 때마다 세션을 실행합니다. 세션에는 한 번에 하나의 연결만 접근할 수 있으므로 둘 이상의 연결을 동시 처리할 수 없습니다. 그런데 언코드는 파일 용량을 계산하는 AJAX를 페이지를 부를 때마다 자동으로 실행합니다. 병목구간이 발생하는 것입니다.

    비주얼 컴포저로 각 위젯을 편집 버튼을 누르면 각 UI 정보는 AJAX를 통해 얻어 옵니다. 그러나 이미 이미지 용량 계산 때문에 다른 AJAX 요청에는 응답할 수 없는 상태입니다. 그래서 꽤 오랫동안 로딩이 걸리게 되는 것입니다. 아마 다른 페이지에 접근할 때도 마찬가지로 로딩이 심하게 발생할 수 있을 것입니다.

    문제를 해결하려면

    1. Uncode와 KBoard를 같이 쓰지 않는다.
    2. 같이 써야 한다면 Uncode의 이미지 계산하는 부분, uncode/core/inc/admin.php 파일의 1086번째 줄 부근의 
      /* AJAX call to load all images */
add_action( 'wp_ajax_list_images', 'uncode_list_images' );

       부분을 주석 처리.

    3. 코어를 건드리는 것은 부담스러우므로 차일드 테마나, 별도의 플러그인을 생성. 
      add_action( 'plugins_loaded', 'my_uncode_kboard_fix' );

function my_uncode_kboard_fix() {
  if( has_action( 'wp_ajax_list_images', 'uncode_list_images' ) {
    remove_action( 'wp_ajax_list_images', 'uncode_list_images' ) ;
  }
}

    매번 이런 용량 계산을 하는 언코드도 문제지만, KBoard도 굳이 세션을 써야 했나 생각이 듭니다.