Blog - Page 9 of 9 - GeoDirectory

Advanced Custom Fields 는 수백만 명이 사용하는 훌륭한 플러그인으로, WordPress를 풀스택 CMS로 변환하여 무제한의 커스텀 필드 그룹과 유형을 생성하고 모든 종류의 커스텀 포스트 타입에 추가할 수 있게 해줍니다.

하지만 Advanced Custom Fields의 확장성 한계에 대해 아는 사람은 많지 않습니다.

GeoDirectory가 리스팅의 커스텀 필드를 관리하는 데 Advanced Custom Fields를 사용하는지 묻는 질문을 꽤 자주 받습니다.

하기로 했냐고 의아해합니다.

저희에게 그 답은 명확합니다. Advanced Custom Fields는 디렉토리를 구축하는 데 있어 확장성이 상당히 제한적입니다.

사용자로서, 내부에서 어떤 일이 일어나는지, 그리고 웹 디렉토리가 제기할 수 있는 확장성 문제를 인식하지 못할 수도 있다고 생각했습니다.

그러던 중 얼마 전, 저희는 Facebook의 인기 WordPress 그룹를 투표하는 선택지에는 GeoDirectory, 인기 마켓플레이스에서 제공되는 몇 가지 다른 디렉토리 테마, 그리고 ACF + FacetWP.

결과를 보고 저희는 적잖이 당혹스러웠습니다. ACF + FacetWP가 예상보다 훨씬 많은 표를 받았기 때문입니다.

투표한 사람들은 단순한 일반 사용자가 아니라 웹사이트 개발자와 WordPress 전문가들이었습니다.

이러한 이유로, 저희는 Advanced Custom Fields를 디렉토리에 사용하는 것이 왜 좋지 않은 생각인지 설명할 때가 됐다고 판단했습니다.

그리고 왜 웹 개발자들은 고객에게 지속적으로 성장 가능한 빠르고 확장성 있는 솔루션을 제공하는 것에 관심이 없지 않는 한, 그 솔루션을 누구에게도 제안해서는 안 되는지도 설명하고자 합니다.

WordPress 커스텀 필드 확장성의 한계

WordPress는 기본적으로 wp_postmeta 데이터베이스 테이블을 사용하여 커스텀 필드 데이터를 저장하며, 게시물에 사용된 각 커스텀 필드마다 1개의 행을 생성합니다.

그 외에도 WordPress는 각 게시물에 대해 이 테이블에 많은 추가 데이터를 저장하며, 각각 테이블의 1개 행을 차지합니다.

SQL 쿼리 최적화에 시간을 투자해 보셨다면, 디렉토리나 필터링 같은 기능에는 그것이 이상적인 구조가 아님을 아실 것입니다.

실제로 기본 데이터베이스 구조는 게시물과 커스텀 필드가 많은 웹사이트에 잠재적으로 심각한 병목 현상을 일으킬 수 있습니다.

이는 WordPress의 약점 중 하나로 꼽힙니다.

커스텀 필드로 게시물을 필터링하려면 쿼리에서 wp_post 테이블과 wp_postmeta 테이블을 조인해야 하기 때문입니다.

테이블이 커질수록 쿼리 속도는 느려집니다.

더 심각한 문제는, 두 개의 메타 값으로 필터링하려면 하나의 쿼리에서 post_meta 테이블을 두 번 조인해야 한다는 점입니다.

이는 시스템 메모리를 과도하게 소모하여 소규모 디렉토리가 아닌 경우 성능을 크게 저하시킬 수 있습니다.

Advanced Custom Fields 확장성의 한계

Advanced Custom Fields 플러그인은 게시물, 페이지, 커스텀 필드 수가 적거나 보통 수준인 웹사이트에는 완벽한 솔루션입니다.

그러나 극히 드문 경우를 제외하면, 디렉토리는 정반대의 특성을 가집니다.

디렉토리는 게시물 수가 매우 많고 커스텀 필드 수 역시 매우 많을 수 있습니다.

Advanced Custom Fields의 주요 확장성 문제는 리스팅에 추가된 각 커스텀 필드마다 데이터베이스의 wp_postmeta 테이블에 2개의 행을 생성한다는 것입니다.

또한 자체 설정에 속하는 여러 postmeta 행도 추가합니다.

즉, 기본 WordPress 커스텀 필드 시스템을 사용할 때에 비해 데이터베이스의 wp_postmeta 테이블에 두 배 이상의 행을 추가하게 됩니다.

이 문제를 좀 더 명확하게 설명하기 위해 간단한 테스트를 진행했습니다.

새로운 WordPress 웹사이트를 만들고, hello world 게시물과 샘플 페이지를 삭제한 뒤 Advanced Custom Fields를 설치했습니다.

1개의 그룹과 5개의 커스텀 필드를 만들고, 5개의 커스텀 필드를 사용하는 게시물 3개를 발행했습니다.

그 결과, wp_postmeta 테이블의 행 수가 이미 83개에 달했습니다.

정말 말도 안 되는 수치입니다.

300,000개의 리스팅과 5개의 커스텀 필드가 있는 디렉토리의 행 수를 상상해 보세요.

ACF를 사용하면 wp_postmeta 테이블의 행 수가 최소 3,000,000개가 됩니다

GeoDirectory는 어떻게 확장될까요?

매우 간단합니다. 각 커스텀 포스트 타입마다 별도의 커스텀 테이블을 생성합니다.

예시: wp_gd_gd_place_detail

이 테이블에는 모든 커스텀 필드와 해당 데이터를 각 포스트마다 한 행으로 저장합니다.

또한 WordPress가 기본 wp 데이터베이스 테이블을 쿼리하기 위한 자체 PHP API를 갖추고 있는 것처럼, 저희도 커스텀 테이블을 쿼리하기 위한 자체 PHP API를 구축했습니다.

이는 GD가 대부분의 경우 포스트 테이블과 저희 테이블만 조인하면 된다는 것을 의미합니다.

그런 다음 임의의 커스텀 필드로 결과를 필터링할 수 있습니다.

20개의 커스텀 필드로 필터링할 수 있는 반면, ACF는 facetWP(속도를 높여주지만 여전히 핵심적인 한계가 있음)를 사용하더라도 하나의 쿼리에서 동일한 작업을 수행하기 위해 여러 테이블을 반복해서 조인해야 하며, 동일한 쿼리에 훨씬 더 많은 서버 메모리를 사용하게 됩니다.

결론

GeoDirectory와 WordPress 또는 WP + Advanced Custom Fields를 비교하면 다음과 같습니다:

WordPress
1) 필터링하려는 커스텀 필드마다 추가적인 테이블 JOIN이 필요합니다.
2) wp_postmeta가 빠르게 커져서 쿼리 속도가 느려집니다

WP + ACF

1) 필터링하려는 커스텀 필드마다 추가적인 테이블 JOIN이 필요합니다.
2) wp_postmeta가 WordPress 단독 사용 시보다 두 배 더 커집니다

GeoDirectory

1) 조인이 필요하지 않습니다
2) GD는 wp_postmeta에 데이터를 추가하지 않으므로 불필요한 용량 낭비가 발생하지 않습니다.
3) 리스팅 데이터를 저장하는 데이터베이스는 포스트당 1개의 행만 사용합니다

WordPress는 데이터를 저장하는 방식에 이러한 한계가 있는 것으로 잘 알려져 있습니다. 대부분의 경우 이 시스템은 문제없이 작동하지만, 대규모 디렉토리를 다룰 때는 적합한 솔루션이 아닙니다.

바로 그렇기 때문에 GeoDirectory를 사용하면 수백만 개의 리스팅이 있는 디렉토리를 만들 수 있는 반면, WP + Advanced Custom Fields로는 심각한 성능 문제가 나타나기 전에 겨우 수백 개의 리스팅으로 디렉토리를 만드는 것도 운이 좋아야 가능합니다.

이것이 바로 Advanced Custom Fields의 확장성 한계로 인해 저희가 GeoDirectory에 이를 사용하지 않기로 결정한 이유이며, 여러분도 사용하지 않아야 하는 이유입니다.

궁금한 점이 있으시면 아래 댓글에 자유롭게 질문해 주세요.

WordPress 현지화 기능을 사용하면 WordPress 언어 파일(po/mo 파일)을 통해 플러그인과 테마를 손쉽게 번역 가능하도록 만들 수 있습니다.

이는 특히 WordPress 3.7 이후 더욱 그러하며, WordPress 4.6.

WordPress의 전체 번역 시스템에 많은 개선이 이루어졌기 때문에, 새로운 포스트가 꼭 필요하다고 느꼈습니다.

WordPress 언어 파일 – 혼란 ( 개발자 편 )

개발자의 경우, 핵심은 번역 파일이 있음을 WordPress에 올바른 방법으로 알리는 것입니다.

개발자로서 우리는 "load_plugin_textdomain()"을 사용하여 플러그인 폴더 내의 언어 파일을 가리키도록 안내받았습니다.

그러나 과거에는 WordPress가 해당 위치만 확인했기 때문에 사용자가 직접 언어 파일을 추가해도, 다음 업데이트 시 파일이 사라져 버렸습니다!

예전에 웹에서 두 번째 호출 방법을 소개하는 글이 있었는데, 이번에는 "load_textdomain()" 함수를 사용하여 WP 언어 폴더의 파일을 가리키는 방식이었고, 많은 사람들이(저희 포함) 그 방법을 사용했습니다.

이를 통해 사용자는 WP 언어 폴더의 지정된 위치에 언어 파일을 저장하면, 플러그인 업데이트 시에도 번역이 사라지지 않았습니다.

WordPress 언어 파일 – 혼란 ( 사용자 편 )

사용자는 플러그인/테마의 커스텀 번역 파일을 어디에 저장해야 하는지 알아야 하는데, 과거에는 여러 위치가 존재할 수 있었다는 것이 문제였습니다.

WP 문서에서는 개발자에게 플러그인 폴더 내 "languages"라는 폴더를 연결하도록 안내하지만, 개발자가 "lang" 폴더를 사용할 수도 있으며 어느 경우든 플러그인/테마가 업데이트되면 해당 파일은 삭제됩니다.

일부 개발자는 개발자가 임의로 선택한 위치, 주로 WP 언어 폴더 내 커스텀 이름의 폴더에 두 번째 확인 경로를 추가하기도 했습니다.

이로 인해 사용자가 커스텀 번역 파일을 안전하게 저장할 위치를 일관되게 파악할 방법이 없었습니다.

올바른 방법으로 언어 파일 불러오기 (2017)

WP 4.6 이후, 사용자와 개발자 모두에게 훨씬 쉬워졌습니다!

개발자라면 이제 아래 WP 문서에 따라 언어 파일을 올바르게 로드하고 있는지만 확인하면 됩니다:

<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
  load_plugin_textdomain( 'my-plugin', false, basename( dirname( __FILE__ ) ) . '/languages' );<br />
}<br />

<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
    load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );<br />
}<br />

이 훅들은 'init' 및 'after_setup_theme' 훅에서 실행된다는 점에 주목하세요. 이렇게 하면 모든 것이 원활하게 로드됩니다.

직접 실행하거나 각 훅보다 먼저 실행하면 일부 문자열이 번역되지 않는 문제가 발생할 수 있으며, WPML과 같이 번역을 조작하거나 다국어 웹사이트를 만드는 플러그인이 전혀 작동하지 않을 수도 있습니다.

사용자 입장에서는 이제 언어 파일을 배치할 수 있는 편리하고 일관된 이름의 위치가 생겼습니다.

플러그인의 경우: /wp-content/languages/plugins/my-plugin-en_US.mo
테마의 경우: /wp-content/languages/themes/my-theme-en_US.mo

'my-plugin'과 'my-theme'은 플러그인/테마의 텍스트도메인입니다 (보통 플러그인의 readme.txt 또는 테마의 style.css 상단에서 확인할 수 있습니다).

이는 기존 방식에 비해 크게 개선된 것으로, 대부분의 경우 업데이트 시 번역이 손실되는 것을 방지해 줍니다.

경우에 따라 플러그인/테마에 wp.org에 저장된 해당 언어의 새 번역이 이미 있을 수 있으며, 이 경우 .mo 파일을 덮어쓸 수도 있지만 대부분의 경우 이는 의도된 동작입니다.

플러그인이 wp.org에 호스팅되어 있다면 번역에 기여할 수 있으며, 프리미엄 플러그인의 경우 덮어쓰일 가능성이 거의 없습니다.

추가 정보

WordPress는 여러 위치에서 WordPress 언어 파일을 찾으려 시도합니다. 텍스트도메인이 'my-plugin'인 플러그인의 경우 먼저 여기를 확인합니다:

/wp-content/languages/plugins/my-plugin-en_US.mo

해당 위치에서 번역을 찾지 못하고 플러그인이 로컬에서 찾을 위치를 지정한 경우, 다음 위치를 확인합니다:

/wp-content/plugins/my-plugin/languages/my-plugin-en_US.mo

플러그인이 경로를 지정하지 않은 경우 WordPress는 대신 여기를 확인합니다:

/wp-content/languages/my-plugin-en_US.mo

WordPress 문서를 따르는 것이 원칙이지만, 실제로는 WP 4.6부터 로컬 파일을 포함하지 않는 경우(파일이 wp.org 저장소에 저장된 경우) 로컬 파일 경로를 지정하지 않아도 됩니다. 따라서 다음과 같이만 추가하면 됩니다:

<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
  load_plugin_textdomain( 'my-plugin');<br />
}<br />

<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
    load_theme_textdomain( 'my-theme');<br />
}<br />

이 글이 번역에 대한 이해를 높이는 데 도움이 되었으면 합니다. 궁금한 점이 있거나 추가하고 싶은 내용이 있다면 아래에 댓글을 남겨 주세요.

2019년 9월 업데이트

이 기능은 V 2.0.0.67에서 사전 정의된 커스텀 필드로 추가되었습니다. 아래 코드 스니펫은 GeoDirectory V1을 사용하는 경우에만 작동합니다.

문제

오늘 한 회원이 다소 특이한 요청을 해왔습니다. 그는 GeoDirectory를 사용해 지역 축제를 운영하면서 숙박시설 같은 항목들을 리스팅하고 있습니다. 요청 내용은 각 리스팅에서 메인 행사장까지의 거리를 표시하여 사용자들이 각 리스팅에서 행사장까지 얼마나 멀지 명확히 알 수 있도록 해달라는 것이었습니다. 저도 제 사이트 중 한 곳에서 이와 매우 유사한 기능을 사용하고 있습니다. 단일 위치를 대상으로 공항까지의 거리와 주요 도심까지의 거리를 리스팅하는 방식인데, 지금까지는 사용자들이 이 거리를 직접 입력하도록 했습니다. 그런데 입력 값이 틀린 경우가 많아 제가 직접 수정해야 하는 번거로움이 있었습니다.

해결책

이번이 새로운 커스텀 필드를 만들기에 딱 좋은 기회라고 생각했습니다. 이름은 "Distance to"로 하겠습니다. 아래에 코드가 있으며, 이 필드는 두 가지 방식으로 활용할 수 있습니다:
#1 필드를 추가하고 사용자가 GPS 좌표를 직접 입력하도록 하는 방법입니다. 예를 들어 "가장 가까운 공항" 필드로 활용할 수 있으며, 사용자가 자신과 가장 가까운 공항의 GPS 정보를 입력할 수 있습니다.
#2 이 회원의 경우에는 특정 한 장소까지의 거리만 표시하면 되고, 사용자가 해당 필드의 존재조차 알 필요가 없는 상황입니다. 따라서 커스텀 필드를 추가할 때 해당 필드를 "관리자 전용" 필드로 설정하여 프론트엔드에서 사용자에게 보이지 않고 수정도 불가능하게 한 다음, "기본값"을 필요한 GPS 좌표로 설정하면 모든 리스팅에 원하는 정보가 표시됩니다.

코드

이 게시물에서는 Google Maps에서 발생하는 "이 페이지에서 Google Maps를 올바르게 불러오지 못했습니다. 기술적인 세부 사항은 JavaScript 콘솔을 참조하세요." 문제를 해결하는 방법을 안내합니다.

GeoDirectory를 사용 중이라면 저희 문서를 참조하세요 여기에서 확인하세요.

문제에 대해 더 읽어보고 싶으시다면 여기에서 블로그 게시물을 확인하세요: https://wpgeodirectory.com/google-maps-api-key-and-new-limits/

"이 페이지에서 Google 지도가 올바르게 로드되지 않았습니다. 자세한 기술 정보는 JavaScript 콘솔을 참조하세요."라는 메시지 또는 다음 메시지 중 하나를 보신 적이 있다면:
“Esta página no ha cargado Google Maps correctamente.”
“Google Maps ne s’est pas chargé correctement sur cette page.”
“Google Maps non è stata caricata correttamente.”
“Google Maps wurde auf dieser Seite nicht richtig geladen.”
“При загрузке Google Карт на этой странице возникла проблема.”

The chances are you need this fix, if you are using WordPress then we have created a plugin that should fix this for most users who’s plugin or theme is causing this, you can find it here: GOOGLE MAPS API KEY FIX

WordPress를 사용하지 않는 경우, 소스 코드에서 Google Maps 호출을 찾아 API 키를 추가해야 합니다. API 키 생성에 관한 안내는 여기에서 확인할 수 있습니다. 여기에서 확인하세요. API 키를 받으셨으면, Google Maps 파일 호출에 다음과 같이 추가하세요: maps.google.com/maps/api/js?key=YOUR-API-KEY-HERE

이 글이 도움이 되셨으면 좋겠습니다. 피드백은 언제나 환영합니다.

GeoDirectory 팀 드림.

저희는 Snazzy Maps 의 지원을 발표하게 되어 기쁩니다 Custom Google Maps 애드온 (1.0.5).

Snazzy Maps란 무엇인가요?

Snazzy Maps는 사용자가 Google Maps의 색상, 채도 및 기타 스타일 옵션을 커스터마이즈할 수 있는 온라인 리소스입니다.

커스터마이즈 옵션은 웹 전반에 걸친 다양한 작성자들이 디자인한 여러 지도 스타일 형태로 제공됩니다.

Snazzy Maps로 지도를 편집하는 것 외에도, 사용자는 자신의 웹사이트나 앱에서 사용할 Snazzy Map 스타일을 직접 만들 수 있습니다.

모든 맞춤형 지도는 웹과 모바일 기기 모두에서 고해상도 위성 이미지와 벡터 지원을 제공합니다.

이러한 기능 덕분에 기업과 개발자 모두 코딩 기술 없이도 프로젝트에 시각적으로 매력적인 지도를 만들 수 있습니다.

GeoDirectory에 Snazzy Maps 지원을 추가한 이유는 무엇인가요?

약 일주일 전, 회원 중 한 명인 `Pieter Ravelli`가 이 웹사이트를 저희에게 소개해 주었고, 팀 모두의 공감을 얻어 개발 과제의 최우선 순위로 올라가게 되었습니다.

이것이 바로 GeoDirectory가 추구하는 정신입니다. 회원이 모든 회원에게 도움이 될 만한 제안을 해주신다면, 저희는 기꺼이 그것을 추가할 것입니다.

Snazzy Maps 스타일을 GeoDirectory로 가져오기

Snazzy Maps를 GeoDirectory Custom Maps 애드온에 추가하는 것은 비교적 간단합니다.

먼저, snazzymaps.com으로 이동하여 마음에 드는 스타일을 찾거나 직접 만드세요.
원하는 페이지에서 복사 버튼을 확인할 수 있습니다. 해당 버튼을 클릭하세요.
다음으로, GeoDirectory 설정으로 이동하여 GD>Custom Google Maps>Manage Styles로 이동한 후 변경하려는 지도의 편집 버튼을 클릭하세요.
지도 스타일 편집 화면에서
이제 새로운 지도 스타일이 사이트에 적용됩니다.

GeoDirectory와 함께 Snazzy Maps를 사용하고 계신가요? 그렇다면 어떤 스타일을 사용하고 계신가요? 아래 댓글로 알려주세요.

세계에서 가장 진보하고 확장 가능한 WordPress 디렉토리 플러그인