Gutenberg: 코드에서 Gutenberg 편집기를 비활성화하는 방법?

또한보십시오:

• https://github.com/WordPress/gutenberg/blob/master/docs/faq.md#will -i-be-able-to-opt-out-of-gutenberg-for-my-site
• https://wordpress.org/plugins/classic-editor/

안녕하세요 @aduth 가 더 이해하기 위해 제목을 업데이트했습니다. 코드 옵션을 찾고 있습니다. :) 감사합니다.

이것은 많은 개발자들에게 매우 유용한 기능이 될 것이라고 생각합니다. 사실 나는 구텐베르크가 워드 프레스 버전 5.0으로 업그레이드하는 사이트에서 활성화되기보다는 버전 5.0 인 워드 프레스의 신규 설치에서만 활성화되어야한다고 생각합니다.

이것이 코드에서 활성화 / 비활성화하는 방법과 결합 된 경우 개발자는 준비가되면이를 켤 수 있습니다.

코드를 통해이를 달성해야하는 이유에 대해 자세히 설명해 주시겠습니까?

클라이언트 가시성 / 제어 문제인 경우 항상 위에서 언급 한 플러그인을 "Must Use Plugin"으로 설치할 수 있습니다. https://codex.wordpress.org/Must_Use_Plugins

코드 변경이 빠르고 쉽기 때문에 플러그인을 활성화하는 것은 1) 내 코드가 아니고 2) 일부 코드를 추가하는 것만 큼 간단하지 않습니다. 종속성 목록에 추가하는 것은이 문제에 접근하는 실용적이거나 현명한 방법이 아닙니다.

상수를 정의하는 것은 여러분의 코드 일 수 있지만, 상기 상수에서 작동하는 로직은 공식적으로 유지되는 "Classic Editor"플러그인만큼 여러분의 코드가 아닙니다.

나는 논쟁을 벌이려는 것이 아니라 이러한 접근 방식이 매력적인 이유를 더 잘 이해하고, 충분한 옵션이 존재하는지 확인하면서 유지 관리에 과도 할 정도로 많은 것을 제공하지 않도록해야합니다.

플러그인 기능이 핵심의 일부가 될 수없는 이유는 무엇입니까? 궁금해서 물어봐요 :)

Gutenberg 편집기를 켜고 끄는 기능에 대한 필요성을 반영하고 싶습니다. 내 특별한 상황은 내 WordPress 사이트 중 하나가 사용자 정의 편집기가있는 테마 (예 : Enfold 테마의 Avia 편집기)를 기반으로 구축된다는 것입니다.

Gutenberg가 활성화되면 편집자의 워크 플로가 변경됩니다. 모든 게시물> 또는 페이지>로 이동하여 "클래식 편집기"를 클릭 한 다음 편집하려는 페이지에서 "편집"을 누르는 대신 테마 내장 편집기를 호출하는 고급 레이아웃 편집기의 버튼을 눌러야합니다. , 또는 미리보기 페이지에서. 이 편집기가 필요합니다. 사이트의 모양과 느낌이 해당 편집기로 만든 템플릿을 중심으로 표준화 되었기 때문입니다.

프로세스는 대부분 사소한 것처럼 보이지만 수십 명의 편집자의 워크 플로 변경으로 인해 지원 문제가 발생할 수 있습니다.

내 2 센트.

차이점은 "심리적"일 뿐이라고 생각합니다. Core에 있다는 것은 우리가 그것을 무기한으로 가질 것이라는 것을 의미하며, 플러그인으로 사용한다는 것은 우리가 얼마 동안 지원할 것이라는 것을 의미하고 (Matt가 몇 년 동안 말했다고 생각합니다) 어느 시점에서 우리가 중단 할 것이라는 것을 의미하는 Gutenberg 채택을 저해합니다.

이것이 별도의 문제로 분리되어야하는지 여부는 모르겠지만 WordPress 5.0의 새 설치에 대해서만 Gutenberg를 활성화한다는 표명 하고 다음과 같이 제공합니다. 업그레이드시 사용자에게 제공되는 옵션 (클래식 편집기 플러그인 또는 기타 "비활성화"기능이 사용되지 않는 경우).

이 글을 읽고 싶으 시다면 제가 작성한 블로그 게시물 에 저의 이론적 근거가 나와 있습니다. 이는 제 클라이언트를위한 사용자 인터페이스의 엄청난 변화와 구텐베르크를 제대로 지원하는 데 필요할 수있는 코드 변경의 조합입니다. 내 고객의 경우 예산이 없을 수 있습니다).

구텐베르크가 WordPress를 처음 사용하는 사람들이 새 블로그를 설치하고 진행하는 데 유용 할 것 같습니다. 그리고 업그레이드하고 "Yay-새로운 편집자-내가 가져다 줄게"라고 생각하는 사람들에게 좋을 것입니다. 그러나 다른 사람들에게는 큰 충격이 될 것입니다. 일부 사용 사례에서는 GB가 사용자 지정 게시물 유형을 편집하는 데 좋은 인터페이스가 아니거나 "블록"이 편집중인 정보에 대한 좋은 데이터 모델이 아닐 수 있습니다.

또한이 주제에 대해 개발자와 중소기업 소유자의 목소리를들을 필요가있는 것 같습니다. 저는 많은 작은 WordPress 개발 상점을 알고 있으며이 변경 사항은 제 블로그 게시물에 설명 된 모든 이유 때문에 고통 스러울 것입니다. 한 개발자 나 소규모 대행사가 업데이트 된 사이트에 대해 GB를 자동으로 활성화하는 것이 좋은 생각이라고 말하는 것을 들어 본 적이 없습니다. 나는 그 아이디어에 대해 많은 반발을 들었다.

이런 종류의 워드 프레스 사용자 (그리고 저와 같은 개발 상점은 워드 프레스의 큰 지지자이자 지지자입니다. 그래서 우리는 여러분이 들어 주셨으면합니다) 사용자를 잘 이해하고 있습니다. 우리는 워드 프레스에서 무엇을 구축했는지 여부와 그 여부를 깊이 알고 있습니다. 수정없이 GB 사용자 인터페이스에 잘 맞으며 고객을 대신하여이 변경 사항을 관리 할 수있는 능력이 필요합니다.

클래식 편집기 플러그인을 설치할 수 있다는 것을 알고 있으며 클라이언트가 GB를 직접 활성화 할 가능성을 제거하기 위해 여전히 설치해야 할 수도 있습니다. 업그레이드 된 사이트에서 GB가 선택 사항 인 것으로 판명되면 자연스럽게 코어에서 비활성화하는 코드가 필요합니다. 그래서 @ smp303 (및 코어에서 비활성화하는 방법을 원하는 다른 사람들)도 행복하게 만들 것입니다!

코어로의 합병 계획이 만들어지면서 개발자들과 저와 같은 소규모 워드 프레스 기업들의 의견을들을 수 있기를 바랍니다. 우리의 생계는 이러한 변화의 영향을받을 수 있으며, 일부 사람들은 이러한 변화가 너무 빨리 그들에게 강요되고 있다고 느낍니다. 전환을 관리하기위한 더 많은 옵션을 제공하고 GB가 코어에 처음 추가 될 때 모든 사람에게 적합한 것은 아니라는 점을 고려하십시오.

WP 코어의 필터 또는 wp-config.php의 상수 는 두 가지 확실한 옵션처럼 보입니다.

위에 링크 된 @rosswintle 과 그의 훌륭한 블로그 게시물을 반향합니다. 우리는 사용자 정의 필드, 메타 박스 (특히 ACF)를 사용하여 정말 풍부한 편집 경험을 제공하는 많은 대행사 중 하나입니다. "플랫폼으로서의 워드 프레스"는 약속이었고 우리 모두가 지난 몇 년간 해왔 던 일입니다.

구텐베르크를 원하지만 원하지 않는 사람들에게는 적용하지 않는 방법이 있어야합니다. 나는 이것이 코드에서 또는 플러그인을 통해 발생하는지에 대해 합리적으로 쉽습니다. 실제로 관리 콘솔을 사용하여 50 개 이상의 WordPress 사이트를 유지 관리하는 사람은 Gutenberg를 비활성화하는 대량 플러그인 설치가 더 실용적 일 것입니다. 그러나 meh, 할 수있는 한. 대시 보드의 설정 옵션도 괜찮을 것입니다. IMO-기본값 인 "Gutenberg : off"가 더 좋습니다.

구텐베르크와 함께 후방 피팅 사이트에 대한 Ross의 요점도 유효합니다. 고객을 위해 구축하는 거의 모든 사람은 대다수가 출시에 예산을 지출하고 그 이후에는 예산이 없다는 것을 알고 있습니다. 구텐베르크 개조, 클라이언트 재교육, 다른 인터페이스-개발자와 비즈니스 소유자를 제외하고 누구나 비용을 지불 할 것이라고 생각하는 것은 환상의 땅입니다.

@ smp303 , @dmje 및 @rosswintle의 감정을 반영하는 것과 같습니다.

구텐베르크를 비활성화하기 위해 functions.php에 간단한 동작을 넣을 수 있다는 것은 가장 간단하고 명백한 일처럼 보입니다.

나는 구텐베르크를 우회하는 데 필요한 것보다 조금 더 어렵게 만들기 위해 플러그인 접근 방식을 취했다고 생각하지만 어쩔 수 없다.

핵심 팀이 구텐베르크에 많은 노력을 기울 였다는 것을 알고 있지만 성공 여부는 구텐베르크를 피하는 능력을 줄이는 것이 아니라 장점에 따라 결정되어야합니다. 또한 WP 개발자가 완전히 새로운 편집기를 개발하고 반응을 배우고 레거시 항목을 개발하고 유지해야하는 경우를 생각해보십시오. 오버 헤드는 엄청납니다.

이것도 반향하고 싶습니다. 플러그인이 아닌 코드를 통해 Gutenberg 편집기를 비활성화하는 옵션도 원합니다.

생성되어 이제 wontfix 로 마감 된이 Trac 티켓도 참조하십시오 : # WP43068

https://core.trac.wordpress.org/ticket/43068#comment의 @ dd32 당 : 6

나는 우리가 이것을 위해 상수를 지원할 것이라고 생각하지 않고, 대신 단순히 사람들을 플러그인으로 안내하고 아마도 mu-plugin 래퍼로 만들 것입니다. 단순히 기존 플러그인이 스위치가 아니기 때문입니다. 사용되는 코어에없는 코드를 포함합니다.

WordPress는 나중에 변경하기가 매우 어렵 기 때문에 상수에서 벗어나려고 노력해 왔습니다. "오, 구텐베르크가 왜 비활성화 되었습니까? 오, 내 임의의 SEO 플러그인 (또는 전 개발자)은 내가하지 않을 것이라고 생각했습니다. 원하고 강제로 비활성화했습니다. 이제 누가이 문제를 해결할 수 있습니까? "(최종 사용자)

일부 사람들이 비활성화하려는 이유는 알 수 있지만 그런 방식으로 수행해야 할 필요성은 알 수 없습니다.

나중에 변경 될 수있는 wontfix 로 안전하게 닫을 수 있다고 생각합니다 (그때 다시 방문 할 것입니다).하지만 그렇게 될 것으로 예상하지는 않습니다.

여러분, 피드백 감사합니다. 블록 편집기를 완전히 비활성화하기 위해 클래식 편집기 플러그인을 요구하는 결정에 대해 논란이 있음을 알고 있으므로 다양한 옵션이 무엇인지 이야기하고 싶습니다.

앞으로 몇 년 동안 사이트 데이터 관리를위한 "차단"개념은 데이터에 대해 생각하고, 배치하고, 상호 작용하고, 편집하는 주요 방법이 될 것입니다. 워드 프레스 5.0에 출시되는 블록 편집기는 그 방향의 첫 번째 주요 단계이며, 올해 구텐베르크 사용자 정의 초점은 구텐베르크 테마와 함께 다음 단계입니다.

물론 WordPress 5.0이 출시 될 때 모든 사람이 블록 편집기를 100 % 사용할 수있는 것은 아닙니다. 그것은 모두가 알고있는 실제 현실이며, 우리는 사람들에게 WordPress 5.0으로 업그레이드 할 수있는 실행 가능한 방법을 남기고 싶지 않습니다. 이를 염두에두고 특정 사용 사례에 따라 구텐베르크를 비활성화하는 몇 가지 방법이 있습니다.

블록 편집기에서 작동하지 않는 메타 상자를 등록하면 해당 메타 상자를 호환되지 않는 것으로 쉽게

마찬가지로 CPT (# 2457)에 유사한 플래그를 추가하는 방법에 대한 논의가있어 블록 편집기 기능이 필요하지 않은 CPT가이를 옵트 아웃 할 수 있습니다.

이는 블록 편집기를 비활성화하는 두 가지 주요 장기 사용 사례입니다. 작동하지 않거나 사용 패턴에 맞지 않는 상황입니다.

이러한 점을 염두에두고 향후 몇 년 동안 WordPress가 잠재적으로 어떻게 발전 할 것인지 생각해 봅시다 (여기에서 수정 구슬을 주시하고 있습니다.이 목록에있는 일이 반드시이 순서, 기간 또는 어쨌든-WordPress 5.0 릴리스가 어떻게 끝나는 지에 따라 크게 달라지는 잠재적 시나리오 일뿐입니다).

• Customiser는 모든 것에 블록 개념을 사용합니다. 99 %의 새로운 사이트에서 블록은 전체 사이트를 만드는 데 필요한 유일한 것입니다. 블록 조작은 사이트가 구축되는 방식입니다.
• 새로운 테마는 전적으로 블록에서 사이트를 구축하는 것을 중심으로 발전 할 것입니다. 표준 WordPress 사용자 경험은 블록으로 구축됩니다.
• 동시에 wp-admin은 Gutenberg가 가져 오는 JavaScript-app 인터페이스를 채택하기 시작합니다. 물론 클래식 편집기로 전환하는 것은 가능하지만 나머지 WordPress 인터페이스와 일치하지 않습니다.

나는 이것이 몇 년에 걸친 과정임을 반복 할 것이며, 구형 인터페이스를 복원하기위한 클래식 편집기와 같은 플러그인이있을 것이지만, 이러한 인터페이스가 Core에서 유지되는 것이 반드시 가능하지는 않을 것입니다. WordPress 5.0에서 블록 편집기를 비활성화하는 것이 합리적인 옵션이지만, WordPress 5.5 또는 6.0을 사용하고 여전히 클래식 편집기를 사용하고 있다면 클라이언트에게 큰 피해를 입힐 것입니다. 하나의 예를 선택하기 위해 사이트 레이아웃 모범 사례가 테이블 레이아웃에서 CSS 레이아웃의 여러 반복, 그리고 이제 그리드 레이아웃으로 발전한 것처럼 WordPress 개발 모범 사례도 발전합니다.

따라서 원래 질문으로 돌아 가기 위해 블록 편집기를 비활성화하는 단일 코드 기반 옵션은 실행 가능한 장기 솔루션이 아니며 향후 WordPress Core 개발을위한 적절한 옵션을 제공하도록 확장 할 수 없습니다. 이 옵션을 만들려면 여기있는 모든 사람에게 그러나 클래식 편집기 플러그인은 미래의 패러다임에 맞도록 계속 발전 할 수 있습니다. 전체 WordPress 세계의 일반적인 요구 사항에 맞출 필요가 아니라 요구하는 사람들의 요구를 충족하도록 특별히 개발할 수있는보다 편안한 환경을 제공합니다.

구텐베르크 편집자의 문제는 블록이나 블록의 개념이 아니라 편집자 자체가 좋지 않다는 것입니다. 현재는 기존 편집기보다 훨씬 더 혼란 스럽습니다. 그 자체로는 완벽하지 않습니다. 그리고 우리가 시간이 가까워지고 (4 월에 예상되는 것 같네요?) 사람들이 점점 더 많은 우려를 표명함에 따라 피드백은 결코 "당신이 옳습니다. 우리가 그 문제를 해결할 계획입니다." 위의 "글쎄, 이런 일이 일어나고 있으니 탑승하는 것이 좋습니다."

적어도 내 관심사는 구텐베르크 비활성화에 대한 관심은 블록 대 위젯의 미래와 커 스터 마이저의 장기적인 로드맵이 아닙니다. 실제 편집기가 정말 짜증나는 것입니다. 나는 그것을 사용하고 싶지 않습니다. 내 고객은 사용하고 싶지 않습니다. 사용하기 좋은 것은 아닙니다. 그리고 그다지 좋지 않은 이유는 모든 단락과 텍스트가 "블록"이라는 기본 개념이고 우리 모두는 그것을 싫어하기 때문입니다.

이것이 우리가 이것을 끄고 싶은 이유입니다. 구텐베르크에가는 것은 많은 사람들에게 매우 불쾌한 경험이며 고객과 개발 모두에게 깊은 문제입니다.

미래의 로드맵은 신경 쓰지 않습니다. 나는 내 고객과 사업을 잃는 것에 관심이 있으며 지금까지 Gutenberg 팀의 어느 누구도 그러한 우려를 공유하지 않는 것 같습니다. 우리 소득의 핵심 플랫폼이 우리가 가고 싶지 않은 방향으로 전진 할 때 우리는 무엇을해야합니까? 그리고 "미래 로드맵"이라는 이름으로 우리의 우려가 사라질 때 우리는 무엇을해야합니까?

나는 위젯, 삽입물 및 단축 코드를 범용 블록 시스템으로 대체하는 데 모두 사용됩니다. 그것은 좋은 생각이라고 생각합니다-나는 그 뒤에 있습니다. 사용자에게 사이트 레이아웃에 대한 더 많은 제어 권한을 부여하는 것을 좋아합니다. 그 이유는 무엇입니까?

실제 콘텐츠 제작 도구는 현재 내 고객 (300 명 이상) 중 한 명도 사용하고 싶어하지 않는 뜨거운 엉망이되어 걱정됩니다. 그들은 실제로 그것을 공포로 봅니다. 그리고 모든 멋진 유튜브 데모와 비디오, 그리고 녹화 된 워드 프레스 강연은 그들이 얼마나 싫어하는지 보여줍니다.

그들은 블록으로 쓰기를 원하지 않습니다! 그들은 블록 기반 편집기를 원하지 않습니다! 그들은 모두 그것을 싫어합니다. MS Word 또는 Google Docs처럼 작동하기를 원합니다. 왜냐하면 그것이 그들이 일반적으로 물건을 쓰는 데 사용하는 것이기 때문입니다. 그것이 그들이 원하는 것입니다.

워드 프레스가 원하는 모든 블록을 목구멍에 밀어 넣는 것인데 어떻게 줄 수 있습니까?

내가 가진 유일한 대안은 구텐베르크를 끄는 것입니다. 그래서 믿을 수있는 방법을 원합니다. 최소한이 개발 과정이 감각에 도달하고 블록 메커니즘이 아니라 실제 편집자로서 실제로 사용할 가치가있는 무언가를 만들기 전까지는 말입니다.

텍스트가 블록을 기반으로하지 않는 기능적인 편집기가 필요합니다. 구텐베르크는 언제 그것을 제공할까요? 대답하면 구텐베르크를 비활성화 할 방법이 더 이상 필요하지 않다고 말씀 드리겠습니다. 그때까지 수백만 명의 워드 프레스 사용자와 기업에 대한 실질적인 공감과 관심을 갖고 우리가 신뢰할 수있는 구텐베르크를 끌 수있는 방법을 제공하세요. 이는 다른 플러그인이 아니라 코드를 의미합니다.

코드 수준에서 Gutenberg를 비활성화하는 방법이 필요합니다. 그 예의를 지키십시오. 또 다른 평범한 대답을하지 마세요. 모든 것이 옆으로 간다면 그 망할 일을 끌 수있는 방법을 알려주세요.

@pento , 수년 동안 사용자 당 tinymce를 끌 수있는 쉬운 옵션이 있었으며 많은 개발이 tinymce에 특화되어 있었지만 아무도 옵션 제거를 제안하지 않았습니다.

구텐베르크의 일부로 해당 옵션을 제거하라고 제안하는 사람을 아직 듣지 못했습니다. 현재 tinymce를 계속 사용하지 않고도 구텐베르크에서 텍스트 기반 편집기로 이동할 수 있다는 것은 저에게 별 의미가 없습니다. tinymce는 여전히 텍스트 위젯 및 wp_editor API의 일부로 지원되어야한다는 점을 염두에두고, 적극적으로 유지 관리되는 핵심 API를 노출하기 위해 사람들이 플러그인을 설치하도록 강요하는 개발이나 UI는 의미가 없습니다.

어떤 이유로 든 구텐베르크 관련 설정을 포함하도록 해당 사용자 옵션을 변경하지 않으려는 경우에도 소프트웨어 개발 POV에서 구텐베르크 해제를 지원하는 한, 구텐베르크의 일부이고 다음과 같이 유지 관리되는 API 여야합니다. 개발의 일부입니다. 임포터 플러그인에서 알 수 있듯이 "코어"플러그인조차도 동기화되지 않고 주로 실제 코어 개발의 일부가 아니기 때문에 사용할 수 없게됩니다.

이러한 API를 핵심의 일부로 유지하는 것을 거부한다는 것은 아마도 2018 년에 출시 될 5.1 버전에서도 사람들이 구텐베르크를 비활성화하도록 허용하겠다는 약속이 없음을 의미합니다. 사람들이 이러한 API를 사용하여 중기 계획을 세울 수있을 것으로 기대할 수 없습니다. 불확실성.

@pento 길고 상세한 답변에 감사드립니다. 나는 이것이 구텐베르크를 비활성화하는 방법에 대한 문제가 아니라 기본적으로 활성화되는지 여부와 방법에 관한 문제라고 생각합니다. 나는 당신의 대답이 둘 다 포함한다고 생각하지만 그것은 나를 괴롭 힙니다.

저는 여기와 다른 곳에서 모두 클래식 편집기가 WP에서 제거 되고 "클래식 편집기"플러그인이 다시 추가 할 것이라는 의미에 매우 놀랐습니다. 이것이 올바른 이해입니까? 이것은 나에게 정말 나쁜 생각처럼 보이지만 지금은 그 이유를 분명히 할 수 없습니다.

@markkap 은 또한 텍스트 위젯과 wp_editor API에 대해 좋은 지적을합니다. TinyMCE가 제거되면 어떻게 코어에 유지됩니까?

그리고 구텐베르크로드를 방지하기 위해 meta_box / CPT 코드를 편집하는 것은 좋지만 실제로는 클라이언트를 위해 약 60-80 개의 사이트를 구축하는 고독한 프리랜서입니다. 나는 그 모든 코드를 편집하러 갈 생각이 아니며 많은 소규모 고객들이 그렇게하는 데 비용을 지불하고 싶지 않을 것입니다. 옵트 아웃보다 옵트 인을 선호합니다. 구텐베르크는 지원을 선언 할 때 켜야합니다. 여기서 기본값은 다시 거꾸로입니다. 당신은 사람들이 변경 / 파괴를 방지하기 위해 변경을 강요하고 있습니다 (필요한 경우 이에 대해 별도의 문제를 제기하게되어 기쁩니다).

WordPress 5.5 또는 6.0을 사용하고 여전히 Classic Editor를 사용하고 있다면 클라이언트에게 큰 피해를 입힐 것입니다.

(또한 수정 구슬 사용) 나는 이것에 반드시 동의한다고 생각하지 않습니다. 구텐베르크와 블록이 앞으로의 모든 사용 사례에 대해 더 나은 편집 경험이 될 것이라고 말하기는 불가능하다고 생각합니다.

또한 여기에서 "블록"의 본질에 대해 약간 혼란스러워하고 있습니다. 이것은 아마도 용어 일 수 있지만 다음 중 하나 이상이 사실임을 의미합니다.

• 패러다임의 변화가 있습니다. 제가 만들기 위해 고군분투하고 있거나 뭔가를 잘못 이해했습니다.
• 새로운 패러다임이 잘 전달되지 않고 있습니다.
• 클라이언트 용 콘텐츠 관리 도구를 구축하기 위해 저와 같은 개발자가 WordPress를 사용하는 방식은 잘 알려져 있지 않습니다.
• 클라이언트 용 콘텐츠 관리 도구를 구축하기 위해 저와 같은 개발자가 WordPress를 사용하는 방식은 잘 이해되고 있으며 무시되고 있습니다.

당신은 말했다 :

앞으로 몇 년 동안 사이트 데이터 관리를위한 "차단"개념은 데이터에 대해 생각하고, 배치하고, 상호 작용하고, 편집하는 주요 방법이 될 것입니다.

이것은 나를 조금 무서워하고 다시 돌아올 것입니다.

https://wordpress.org/gutenberg 의 Gutenberg 페이지는이 설명에 동의하지 않는 것 같습니다. 블록을 "콘텐츠 블록"이라고하며 다음과 같이 설명합니다.

[블록]은 콘텐츠 스타일을 통합하는 방법입니다.

_ 참고 : 저는 백엔드 개발자이며 데이터 측면에서 매우 많이 생각합니다 : 시스템에 존재하는 데이터, 속성 데이터 항목이 갖는 것, 데이터 항목이 관련되는 방식, 데이터가 쿼리되고 조작되는 방식 ._

내 이해는 "블록"은 게시물, 페이지 등을 구성하는 데 사용할 수있는 콘텐츠 섹션입니다. 이들은 주로 하위 호환성을 위해 HTML 주석을 사용하여 데이터베이스의 게시물 콘텐츠 내에 저장되지만 post_meta와 같은 다른 위치에 데이터를 저장하도록 블록을 구성 할 수도 있습니다. (참고 :이 _ 느낌 _은 나 같은 사람들이 메타 데이터를 블록에 넣는 것에 만족하도록 만드는 해킹과 같은 느낌입니다. 블록의 특성에 대한 신중한 설계 결정처럼 느껴지지 않습니다.)

당신이 말하는 것에 대한 당신의 의미는 블록이 _ 모든 것을 _ 구동한다는 것입니다. "사이트 데이터"가 관리되는 방식입니다. 이것과 당신이 말한 다른 것들은 블록이 단순히 콘텐츠의 섹션이 아니라 사이트 옵션, 사용자 정의, 게시물에 대한 메타 데이터, 위젯, 메뉴, 사용자 프로필 필드, 모든 것.

그래서 저는 "블록"의 본질에 대한 설명이 필요하다고 생각합니다.

당신이 암시하는 것이 맞다면 WordPress가 저와 같은 사람들이 어떻게 사용하는지에 대한 근본적인 오해를 나타냅니다. 그리고 저는이 접근 방식이 제가 WordPress 열차에서 벗어나 일부 프로젝트에 대한 대체 CMS를 찾도록 유도 할 것이라고 생각합니다. WordPress는 블로그와 잡지를위한 것이지만 사용자 지정 게시물 유형에서 제공하는 많은 기회는 사라질 것입니다.

WordPress의 메타 데이터는 데이터에 대한 데이터입니다. 콘텐츠 항목에 추가 속성을 제공하는 정보입니다. 메타 데이터는 콘텐츠가 아닙니다. 그리고 IMO는 내가 이해하기 때문에 "블록"에 배치하는 데 적합하지 않습니다. 내가 만든 게시물 유형 중 일부는 제목 이외의 내용이 없습니다. 속성 / 필드 / 메타 데이터 만 있습니다.

여기에 설명 된 내용이 사실이라면 게시 상태가 블록이 아닌 이유가 궁금합니다. 카테고리 및 태그가 차단되지 않는 이유는 무엇입니까? 발췌문이 블록이 아닌 이유는 무엇입니까?

나는 개인적으로 이것이 내용이 아니라 내용에 대한 정보이기 때문에 이해하기 때문에 "블록"이라고 생각하지 않습니다. UI에서의 위치가 중요합니다. 사용자가 이러한 정보와 상호 작용하는 방식이 중요합니다.

내가 만든 post_meta 중 일부는 동일합니다.

나는 구텐베르크를 좋아하고 게시물과 페이지를 만드는 블록을 좋아합니다. 그러나 내가 "블록"을 오해하거나 프로젝트가 사람들이 "블록"에 적합하지 않은 데이터를 사용하는 방법을 잘못 이해했습니다.

나는 이것을 명확히하게되어 기쁘고 기꺼이 설득 할 것입니다. 그러나 블록을 "데이터에 대해 생각하고, 배치하고, 상호 작용하고, 편집하는 기본 방법"으로 사용하는 것은 WordPress에서 구축 한 것과 맞지 않는 것 같습니다.

그리고 이것을 주요 문제로 되돌려 놓았습니다. 이것이 바로 클래식 편집기가 코어에서 제거되어야한다고 생각하지 않는 이유입니다. 그리고 이것이 제가 사용자를 v5로 업그레이드 할 때 자동으로 구텐베르크를 켜는 것을 원하지 않는 이유입니다. .0.

@rosswintle 당신은 모든면에서 완벽하게 완벽하게 요약했으며 내가 말한 거의 모든 개발자는 같은 방식으로 느낍니다. 누군가가 이러한 우려에 귀를 기울이고 모두를위한 해결책을 찾을 수 있기를 바랍니다.

구텐베르크를 새로 설치하는 경우에만 기본 편집 환경으로 만들기 위해 +1을 추가합니다.

@rosswintle 이 말했듯이 클래식 편집기로 되 돌리는 데 시간을 지불하는 데 관심이없는 클라이언트를 가진 수십만 명의 WP 개발자가 있습니다. 기존 사이트를있는 그대로 유지하고 (물론 새 편집기를 사용할 수 있도록하지만 예상 한대로가 아닌 경우 다시 전환) Gutenberg를 새로 설치합니다.

WP 사이트가있는 모든 중소기업 소유자를 생각해보십시오. 몇 년 전에 개발 된 사이트로 새로운 개발없이 멋지게 진행되고 있습니다. 갑자기 이러한 사용자들은 구텐베르그를 강요하고 있으며 새로운 인터페이스를 배워야 할뿐만 아니라 (이들 사용자들은 처음에는 기술에 정통하지 않을 수 있으며 구텐베르크는 그들에게 더 직관적 일 수도 있고 아닐 수도 있습니다) 사이트 콘텐츠를 편집 할 수 없습니다.

고려해야 할 WordPress의 명성도 있습니다. 우리는 여전히 WP에 보안 취약성이 가득하다는 의견을 떨쳐 내려고 노력하고 있습니다. @wpmark 와 나는 심지어 주 초에 누군가와 무작위로 대화를 나눴는데, 그들이 우리가 WordPress로 개발 한 것을 알았을 때 그들이 처음 언급 한 것 중 하나는 "사이트를 어떻게 보호합니까?"였습니다.
사용자가 사이트가 손상되거나 작업하기 어려울 수있는 위험이 있습니까? 앞으로 몇 년 동안 WP의 명성에 어떤 영향을 미칠까요?

새로운 사이트는 구텐베르크를 사용할 수 있어야한다고 생각합니다. 이것은 5 분 동안 설치하는 동안 옥상에서 큰 소리로 외치는 큰 기능 일 수 있지만 기존 사이트는 그대로 유지하십시오.

나는 새로운 설치를 위해 구텐베르크를 켜는 질문이 비활성화의 용이성에 대한 유효한 우려로 인해 길을 잃기를 원하지 않았습니다. 여기에 대한 구체적인 문제가 있습니다 https://github.com/WordPress/gutenberg/issues/4423

그것에 대한 생각, 투표 및 피드백을 추가하십시오. @joffff @wpmark @rosswintle @markkap @dmje

@rosswintle에 있습니다.

구텐베르크에 대한 지원을 선언 할 때 켜야합니다. 여기서 기본값은 다시 거꾸로입니다. 당신은 사람들이 변경 / 파괴를 방지하기 위해 변경을 강요하고 있습니다 (필요한 경우 이에 대해 별도의 문제를 제기하게되어 기쁩니다).

내가 시도하면 더 이상 동의 할 수 없습니다. 나는 구텐베르크를 밀어 붙이는 남자와 여자들이 이것을 이해하지 못한다고 생각합니다.

Ross가 엔터프라이즈 관점에서 말한 것에 덧붙여서 (그는 작은 프리랜서 측면을 잘 다뤘습니다) : 제가 다국적 PLC를 위해 관리하는 사이트는 유조선과 같습니다. 이와 같은 근본적인 변경 사항은 구현하는 데 매우 오랜 시간이 걸립니다. 테스트를 통해 수행해야하며, 그 후에도 세부 코드 검토 및 승인 프로세스의 일부인 주간 릴리스 일정에 맞춰야합니다.

이것은 저와 제 팀에게 엄청난 골칫거리가 될 것입니다. 사실, 우리는 5.0.0에 대한 최종 RC가 출시 된 후 구텐베르크의 영향을 완전히 확인할 수있을 때까지 4.9.x를 유지하게 될 것입니다. 이것은 몇 주 또는 몇 달이 걸릴 수 있습니다. 이것은 빠른 수정이 아닙니다.

또한 여기에서 "블록"의 본질에 대해 약간 혼란스러워하고 있습니다. 이것은 아마도 용어 일 수 있지만 다음 중 하나 이상이 사실임을 의미합니다.

• 패러다임의 변화가 있습니다. 내가 만들기 위해 고군분투하거나 무언가를 잘못 이해했습니다.
• 새로운 패러다임이 잘 전달되지 않고 있습니다.
• 클라이언트 용 콘텐츠 관리 도구를 구축하기 위해 저와 같은 개발자가 WordPress를 사용하는 방식은 잘 알려져 있지 않습니다.
• 클라이언트 용 콘텐츠 관리 도구를 구축하기 위해 저와 같은 개발자가 WordPress를 사용하는 방식은 잘 알려져 있으며 무시되고 있습니다.

나는 그것이 후자라고 절대적으로 느낍니다. 구텐베르크 팀의 사람들은 대부분의 전문 개발자가 WordPress를 사용하여 사이트를 구축하는 방법을 알고 이해합니다.

그러나 그 접근 방식은 WordPress를 사이트 구축 자 접근 방식으로 옮기는 완전히 호환되지 않으며, Automattic은 WordPress.com이 Squarespace와 같은 경쟁을 계속하기 위해이를 필요로합니다. Wix et al.

워드 프레스는 사이트 빌더이자 전문 CMS가 될 수 없습니다. 그것은 할 수 없습니다. 둘 사이의 미세한 선을 따라 사용자가 플러그인을 통해 양방향으로 이동할 수 있습니다. (Beaver Builder, Divi 등을 사용하여 사이트를 구축하고 ACF 및 CMB와 같은 플러그인을 사용하는 전문 CMS를 향해). 그러나 이제 CMS가 사이트 빌더의 방향으로 확고하게 움직이고 있음이 분명합니다. 사용자 정의 필드를 사용하는 사이트는 망할 수 있습니다.

마지막으로, 블록과 데이터베이스에 대한 귀하의 요점이 있습니다.

구텐베르크와 같은 것을보기 전에 WordPress 팀이 먼저 해결해야 할 문제가 많다고 생각합니다.

• 최소 버전의 PHP 업데이트
• 네이티브 시맨틱 데이터 (사용자 정의 필드를 통해)를 구현하고이를 설명하기 위해 DB 구조를 수정합니다.

마지막으로 Statamic의 직원들은 새로운 Bard 필드 유형으로 이것이 어떻게 처리되어야하는지 보여주었습니다. Gutenberg와 동일한 문제를 해결하지만 훨씬 더 지능적이고 방해가 적은 방식으로 해결하는 선택적 편집기 인터페이스입니다.

내 의견을 반복 할 필요가 없으며 이미 위에 언급 된 내용입니다. 저는 일반적인 합의에 동의합니다. 4.x에서 5.0으로 이동하는 데 필수가 아닌 Gutenberg를 활성화하는 옵션을 고려해야합니다.

여기에있는 대부분의 개발자로서 저는 많은 고객에게 서비스를 제공합니다. 일부는 기술에 정통하고 일부는 그렇지 않지만이 방향으로 밀어 붙이는 것은 대다수에게 혼란을 야기 할 뿐이라고 생각합니다.

깨질 수있는 모든 것; 고객의 관점에서 그들은 이미 제공된 솔루션에 대한 예산을 만들고 지출했습니다. 그들은 지원을 위해 또 다른 예산이 필요할 수 있거나 자신이나 내가 만든 것이 아닌 문제로 인해 발생하는 문제를 해결하기 위해 감사하지 않을 것입니다.

신중하게 고려 된 솔루션의 개발자 / 디자이너 또는 공급자 사이에서 클라이언트와 공급자 는 필수 사항을 준수

그냥 밖으로 던져 버려. WordPress가 의미 론적 버전 관리 방식을 엄격하게 따르지는 않지만 버전 5.0.0은 주요 변경 사항입니다.

Automattic이 Gutenberg에 관한 전략을 변경하지 않으려는 경우 – 솔직히 말해서 그것이 올바른 일입니다 – 유일한 다른 옵션은 4.9를 LTS 버전으로 만드는 것입니다.

이렇게하면 보안 패치가 4.9에 5 년 동안 적용될 수 있습니다. 웹 사이트 개발자가 사이트를 구텐베르크로 마이그레이션하거나 WordPress에서 완전히 마이그레이션 할 수있는 충분한 시간입니다 (가장 인기있는 옵션이 될 것 같습니다).

글쎄, 모두가 여기에 긴 댓글을 쓰는 것을 좋아합니다. 😉 저에게는 저녁이므로 모든 문제를 다루지는 않겠지 만 몇 가지 문제를 다루고 싶습니다.

저는 여기와 다른 곳에서 모두 클래식 편집기가 WP에서 제거되고 "클래식 편집기"플러그인이 다시 추가 할 것이라는 의미에 매우 놀랐습니다. 이것이 올바른 이해입니까?

정답이 아닙니다. 이전 댓글에서 메타 상자와 CPT가 자동으로 클래식 편집기로 대체 될 수 있다고 언급했습니다. 클래식 편집기 코드가 제거되면 그렇게 할 수 없습니다. 🙂

TinyMCE는 Gutenberg에서 편집 가능한 텍스트 블록을 강화하는 데 사용됩니다. wp_editor() 와 같은 기능은 플러그인으로 이동하지 않고도 Core에서 비교적 쉽게 유지 관리 할 수 ​​있습니다. 계속해서 무기한으로 작동 할 것으로 기대합니다.

당신이 말하는 것의 의미는 블록이 모든 것을 운전한다는 것입니다. "사이트 데이터"가 관리되는 방식입니다. 이것과 당신이 말한 다른 것들은 블록이 단순히 콘텐츠의 섹션이 아니라 사이트 옵션, 사용자 정의, 게시물에 대한 메타 데이터, 위젯, 메뉴, 사용자 프로필 필드, 모든 것.

그게 바로 제가 말하는 것입니다. 메타 데이터는 블록이 아니지만 블록이 사용되거나 표시되는 방법을 알려줄 수 있습니다.

그래서 저는 "블록"의 본질에 대한 설명이 필요하다고 생각합니다.

확실한. 블록은 다른 블록과 함께 맞는 HTML 덩어리입니다. 블록 작업을 멋지고 쉽게 만들어주는 API가 많이 있지만 그게 전부입니다.

블록은 _ 아님 _ :

• post_content에 저장된 HTML 덩어리 (일부 블록은 해당 저장 방법을 사용함).
• 정적 (일부 블록이 있음).
• 동적으로 생성됩니다 (다른 블록도 있음).

@rosswintle , 당신은 메타 데이터를 몇 번 언급

여기에 설명 된 내용이 사실이라면 게시 상태가 블록이 아닌 이유가 궁금합니다. 카테고리 및 태그가 차단되지 않는 이유는 무엇입니까? 발췌문이 블록이 아닌 이유는 무엇입니까?

제안 일 뿐이며 테마 옵션인지 여부는 확실하지 않지만 대부분의 새로 개발 된 기능이 과거에 있었기 때문에 add_theme_support () 아래에 있지 않은 이유는 무엇입니까?

이렇게하면 보안 패치가 4.9에 5 년 동안 적용될 수 있습니다.

워드 프레스 3.7이 출시 된 지 3 년이 조금 넘었고 가장 최근의 보안 출시가 6 주 전이라는 점을 감안할 때 워드 프레스 4.9가 앞으로 오랫동안 보안 패치를받을 것이라고 가정하는 것이 합리적이라고 생각합니다.

@eirichmond : add_theme_support() 은 Gutenberg Customization 포커스에 필요할 수 있지만 대부분의 테마는 수정없이 블록 편집기 기반 콘텐츠를 지원합니다.

add_theme_support ()는 Gutenberg Customization 포커스에 필요할 수 있지만 대부분의 테마는 수정없이 블록 편집기 기반 콘텐츠를 지원합니다.

@pento Gutenberg Customization 초점은 정확히 무엇입니까? 그게 무슨 뜻입니까? _most_ 테마가 블록 기반 콘텐츠를 지원한다고 말씀 하셨는데, 테마가 지원하지 않는 이유를 말씀해 주시겠습니까?

특정 블록을 지원하지 않는 사이드 바가있는 테마는 블록이 전체 너비 (예 : 표지 이미지)임을 나타 내기 때문입니다.

Gutenberg Customization 초점은 정확히 무엇입니까? 그게 무슨 뜻입니까?

Matt는 State of the Word에서 이에 대해 말했습니다. 올해의 세 가지 초점은 다음과 같습니다.

• 구텐베르크 편집자
• 구텐베르크 사용자 정의
• 구텐베르크 테마

구텐베르크 편집기는 워드 프레스 5.0에서 제공되는 것입니다. 구텐베르크 사용자 지정이 이제 막 시작되고 있으며 사이트 사용자 지정과 이것이 블록 패러다임에서 어떻게 작동하는지 살펴보고 있습니다. 구텐베르크 테마는 올해의 기본 테마가 될 것이며 연말에 진행될 것입니다.

그렇다면 테마가 지원하지 않는 이유를 나타낼 수 있습니까?

바라건대 모든 테마가 제대로 작동하기를 바랍니다. 🙂 일부 블록에는 일부 CSS가 연결되어 있으므로 (표지 이미지가 좋은 예입니다), 정확히 옳지 않은 것이있을 가능성이 있습니다. 하지만 테마가 작동을 멈추게하는 것은 없습니다.

구텐베르크가 Automattic 프로젝트가 아니라는 것을 사람들에게 상기시킬 수 있습니까? 기여하는 비 Automatticians의 노력과 작업을 평가 절하하지 말아야합니다.

플러그인이 왜 충분하지 않은지에 대해서도 아직 명확하지 않습니다. 제가 본 모든 주장은 사람들이 구텐베르크를 좋아하지 않는다거나 워크 플로가 이미 설정되어 있고 이전에 언급 된 모든 문제가 해결되었다고 주장합니다. 클래식 편집기 플러그인을 설치하고 활성화하여

링크 플러그인에도 선례가 있음을 명심하십시오.

그러나 어쨌든 건설적이어야합니다.

WP 5.0으로 업그레이드했고 Gutenberg가 내 사용자 정의 편집기를 대체했습니다 / 좋지 않습니다 / 클라이언트와 더 많은 시간이 필요합니다.

어떡하죠?

클래식 편집기 플러그인을 설치하고 활성화하면 문제가 해결되었습니다. 이제 Gutenberg가 4.9에있는 클래식 편집기로 대체되었습니다.

단점?

최신 구텐베르크 기능은 제공되지 않으며 향후 새로운 기능은 클래식 편집기에서 의미가 없을 수 있습니다. 예를 들어 행 및 열 블록이 5.1에 도착한 경우 클래식 편집기에서 어떻게 의미가 있는지 알 수 없습니다.

클라이언트 사이트가 많지만 모든 사이트에 설치 및 활성화하지 않습니다. 클라이언트가 비활성화되면 어떻게됩니까?

MU 플러그인으로 사용 :

• 플러그인 폴더를 wp-content/mu-plugins 에 넣으십시오.
• 다음을 포함하는 파일을 mu-plugins 폴더에 넣으십시오.

<?php
require( 'classic-editor/classic-editor.php' );

이제 플러그인은 항상로드되며 비활성화 할 수 없습니다. 파일 배치 이외의 추가 단계는 필요하지 않습니다. 그런 다음 파일과 폴더를 모든 사이트에 한 번만 업로드하면 다시 걱정할 필요가 없습니다.

클래식 편집기 플러그인의 교훈

이 플러그인에는 Gutenberg가 활성화되었는지 감지하는 것과 같은 많은 유용한 기능이 있으며, 대부분은 실제로 후크를 제거하고 교체하는 것입니다.

심지어 '클래식 편집기 링크'를 선택할 수있는 옵션이있는 설정 영역을 추가하여 구텐베르크를 대체하는 대신 게시물 화면에서 '클래식 편집기'링크를 활성화 한 구텐베르그 플러그인으로 표시되는 내용을 얻을 수 있습니다. 2 가지가 아닌 3 가지 옵션을 제공합니다.

나는 사람들이 실제로 플러그인을보고, 테스트하고, 어떻게 만들어 졌는지 볼 것을 강력히 권장합니다.

우리는 Automattic 제품 팀의 주제가 아니라 커뮤니티라는 것을 기억하십시오. 고장 나면 전체 WP 릴리스주기를 통해 테스트하고 수정합니다. 이 스레드에서 플러그인을 수정할 수있는 기술을 보유한 많은 이해 관계자가 있습니다. 정말 그렇게 큰 거래라면 코어에서 일하는 사람들이 한 단계 올라간 것처럼 누군가가 한 단계 올라갈 것이라고 확신합니다.

@rosswintle , 당신은 메타 데이터를 몇 번 언급

@pento 물론입니다.

국가 예 :

이름 (제목), 설명 (내용) 및 다음이있는 "국가"게시물 유형 :

• 인구
• 깃발 이미지의 URL
• 순위 (및 어떤 방식 으로든 인코딩 될 수있는 기타 요소)
• 관련 "커뮤니티"(다른 유형의 게시물과의 관계)

참조 : http://peoplesunderthreat.org

부동산 예 :

다음을 포함하는 "속성"유형 :

• 가격
• 유형
• 객실 수
• 건설 일
  기타

이벤트 예 :

다음을 포함하는 "이벤트"유형 :

• 데이트
• 시각
• 반복 세부 정보
• 위치
  기타

많이있다.

이 기능을 활성화하고 사용하면서 몇 가지 중요한 문제가 있습니다. 지금은 주요 문제에 집중하겠습니다.

WooCommerce는 제품을 편집 할 때도없는 것처럼 완전히 깨집니다. 그리고 더 많은 플러그인도 완전히 중단 될 것이라고 생각합니다. 그렇다면 커뮤니티가 양립 할 수 있도록 돕는 계획은 무엇입니까? 그리고 우리는 얼마나 걸릴까요?

@tomjn

내가 본 모든 주장은 사람들이 구텐베르크를 좋아하지 않는다거나 이미 설정된 워크 플로를 가지고 있다고 주장합니다.

"좋지 않음"은 잘못된 용어 일 수 있습니다. 사람들은 구텐베르크가 WordPress의 많은 사용 사례에 적합하지 않다고 좋은 주장을하고 있다고 생각합니다. 취향이나 취향의 경우가 아니라 적합성의 경우입니다.

개발자는이를위한 옵션을 원합니다. 디버깅, 코드 편집기, 다중 사이트, 자동 업데이트 및 wp-config.php의 포스트 개정과 같은 다른 주요 기능을 전환 할 수 있습니다. 일부 기능은 add_theme_support 사용하여 지원하는 테마에서만 사용할 수 있습니다. 개발자가 이러한 주요 변경 사항에 적합한 워크 플로를 사용할 수 있도록 동일한 방식으로 Gutenberg를 전환하는 코드 내 옵션을 사용할 수없는 이유는 무엇입니까?

여기서 문제 중 하나는 개발자 (필수는 아니지만 다른 사람들)가 구텐베르크에 대한 우려를 표명 할 때 자신이 듣고 있다고 느끼지 않는다는 것입니다. 이것을 토큰 제스처로 추가하면 도움이 될 것입니다. 자신의 철학적 이유 때문에 그것이 옳은 일이라는 것에 동의하지 않더라도, 그것을 행복하지 않은 개발자에게 제공 할 수있는 올리브 가지로 간주하십시오.

링크 플러그인에도 선례가 있음을 명심하십시오.

링크 플러그인은 여기서 나쁜 예입니다. 코어를 사용하는 경우 기존 기능을 유지하고 새로 설치하는 경우 (또는 사용하지 않는 경우) 기능 만 제거했습니다.

나는이 선례를 좋아한다.

이것이 # 4423에서 주장되고있는 것입니다.

저를 진정으로 얻는 것은 핵심 개발자와 Matt가 전 세계가 의심의 여지없이 "Blocks"개념과 Gutenberg 편집자를 완전히 채택 할 것이라고 가정하고 있다는 것입니다. 나는 그것이 모두 훌륭하고 훌륭하다고 생각하지만 그들이 Gutenberg와 함께 사용하는이 "우리 방식 또는 높은 방식"접근 방식은 사용자 친화적 일뿐만 아니라 전체적으로 WordPress의 상태에 심각한 영향을 미칠 수 있습니다.

그저 대중에게 받아 들여지지 않았기 때문에 집착하지 못한 정말 대단한 아이디어가 시대에 걸쳐 많이있었습니다. Betamax는 훨씬 뛰어난 형식 이었지만 VHS가 이겼습니다. 구텐베르크와 블록이 달라 붙지 않으면 어떨까요? 그러면 WordPress는 어떻게 되나요?

그런 다음 신뢰 요인이 있습니다. 대다수의 WordPress 사용자는 WordPress가 무엇인지 이해하지 못합니다. 그들은 WordPress가 인기있는 브랜드이기 때문에 그것을 사용합니다. 대부분의 사람들에게 WordPress는 브랜드 일뿐입니다. 브랜드는 소비자의 신뢰에 의해 살아가고 죽습니다.

5.0 업데이트가 마침내 출시되고 백만 개의 워드 프레스 사이트가 갑자기 이것을 극적으로 바꾸면 워드 프레스 세계에 대해 아무것도 팔로우하지 않는 최종 사용자가 어떻게 반응할까요?

대부분의 고객은 "간신히 컴퓨터를 켤 수 있습니다"라고 말하거나 지불 한 금액이 약속대로 작동하기를 원합니다. 이들은 워드 프레스가 약속 한 일을하도록 신뢰 한 사람들입니다. 언젠가는 사이트 콘텐츠를 관리하는 완전히 새로운 형식으로 인해 그 약속이 깨지면 갑자기 변경됩니다. 그러면 워드 프레스에 대한 신뢰가 무너지고 사람들은 더 이상 신뢰하지 않으면 무언가를 포기할 것입니다.

이것이 개발자가 가진 대부분의 우려가 발생하는 곳이라고 생각합니다. 우리는 고객이 원하는대로 정확하게 작동하는 훌륭한 맞춤형 WordPress 사이트를 구축하고 있으며 이제는 구텐베르그로 인해 모든 것이 "고장"될 수 있으며, 엄청난 재앙이 될 수있는 것을 방지 할 수있는 옵션이 제공되지 않습니다.

Gutenberg의 유일한 목적은 WordPress Marke 점유율을 높이는 것이지만 그 반대의 경우 매우 쉽게 할 수 있습니다. 실제로 사람들을 WordPress에서 멀어지게 할 수 있습니다. 구텐베르크는 워드 프레스의 새로운 콜라가 될 수 있으며 워드 프레스는 콜라처럼 복구 할 수있는만큼 크지 않습니다. 사람들은 다른 것으로 넘어 가서 뒤를 돌아 보지 않을 것입니다.

당신은 계속해서 "구텐베르크 입양의 미래에 영향을 미칠 것입니다. 어쩌구 저쩌구 저쩌구"에 대해 계속 이야기하지만, 정말 간단합니다. 모두가 그것을 좋아하고 코드 나 플러그인을 통해 제거 할 필요가 있거나 관련이없는 것이 무엇이든간에 Gutenberg는 Press This와 같이 아무도 실제로 사용하지 않는 이상한 기능이 될 것입니다.

현재로서는 구텐베르크가 성공하거나 전체적으로 워드 프레스가 실패 할 수 있다는 방향이 취해질 것입니다. 우려되는 개발자 인 우리는 콘텐츠 관리를위한 훌륭한 도구를 완전히 엉망으로 만들지 않으려 고 노력하고 있습니다. 우리는 고객이 WordPress에 접근하고 사용하는 방법을 누구보다 잘 알고 있습니다. 핵심 개발자와 Matt는 통계와 시장 점유율 만보고 있습니다. 그게 무엇인지 알고 있습니까? Ghostbusters가 재부팅됩니다.

우리는 정말 당신과 함께 일하고 싶어요.하지만 의심하지 않는 사용자들에게 강요하는 것보다 이것이 세상에 어떻게 소개되는지 제어 할 수 있다면 더 좋을 것입니다. 우리가 요구하는 것은 고객을 새로운 편집기로 쉽게 만드는 방법입니다. 정말로 요청할 것이 많지 않습니다.

구텐베르크가 실제로 약속 한 혁신이 될 것이라면 훌륭합니다! 모두 구텐베르크 기차를 타십시오. 그렇지 않다면 우리는 그것을 큰 재앙으로 만들지 않는 옵션을 요청합니다.

그것은 잘 받아 들여지지 않을 것이라는 것을 알고 있고 이것이 성공할 수있는 유일한 방법은 모든 사람에게 강요당하는 것 뿐이라고 생각할 정도로 이것을 너무 심하게 만들고 싶어합니다. 그것은 정치인들이 실제로 슈퍼 부자 만이 실제로 혜택을받을 때 모든 사람에게 혜택을 줄 세금 법안이 통과되는 방식에 대해 대담한 거짓말을하는 것과 같습니다.

위대한 닥터 콕스가 한때 말한 것과 같습니다.

도와주세요.도와주세요.도와주세요.도와주세요.

WooCommerce는 제품을 편집 할 때도없는 것처럼 완전히 깨집니다. 그리고 더 많은 플러그인도 완전히 중단 될 것이라고 생각합니다. 그렇다면 커뮤니티가 양립 할 수 있도록 돕는 계획은 무엇입니까?

@ smp303 이 문제를 논의 할 곳은 아니지만, 현재 WooCommerce 개발자 블로그를 주시하십시오.

아마도 "New Coke"보다 더 나은 비유는 Windows 8 일 것입니다.

그것은 너무 많은 기본 사용 가정을 변경했기 때문에 끔찍한 역효과를 낸 더 많은 모바일 컴퓨팅 사고 방식에 대한 대담한 새로운 비전이었습니다. 예, 사용자는 설정 깊은 곳에서 이전 Windows 경험의 상당 부분을 되 찾을 수 있지만 기술 저널에 올라 오지 않는 한 사용자는이를 수행하는 방법을 몰랐습니다. 그 결과 Windows에 재앙이 생겼습니다.

구텐베르크는 같은 길을 매우 빠르게 가고 있습니다. 커뮤니티가 아니라 회사에 의해 완전히 주도되는 엄청난 변화를 일으키고 있으며, 외부 플러그인을 통해 상당히 모호한 경로를 떠나 (내가 볼 수있는) 상당히 모호한 경로를 떠나고 있습니다. 이 새로운 방법론을 좋아하지 않는 사람.

Automattic / WordPress가 수백만 명의 일반 WordPress 사용자에게 Gutenberg를 비활성화하는 방법을 설정에 제공하지 않으면 깊이 후회할 것입니다. 구텐베르크는 엄청난 변화입니다. 사용자로부터 많은 푸시 백이있을 것입니다.

이 스레드에서 우리는 이것에 대해 경고하고 외부 플러그인으로는 충분하지 않을 것이라고 조언합니다. 사용자에게 조정 기간 만 허용하더라도 구텐베르그에 "아웃"을 제공해야합니다. 코드를 통해 기존 테마로 활성화 할 수 있다면 재난을 막을 수 있습니다.

우리는 여기를 돕기 위해 필사적으로 노력하고 있습니다. 외부 플러그인으로는 충분하지 않습니다. 클래식 편집기로 되 돌리는 옵션이 내장되어 있어야합니다. 릴리스의 일부로 수행하거나 테마에 빌드 할 수있는 코드를 통해 수행 할 수있는 방법을 제공하십시오.

논리적 인 관점에서 저는 개발자가 add_meta_box () 내에서 메타 박스를 선언하여 Gutenberg를 지원하지 않도록 허용하는 철학을 이해하려고합니다. 그러면 메타 박스가 사용되는 모든 곳에서 편집기 화면이 "클래식 버전"을 표시하게됩니다. 편집기 화면의. 그렇다면 일부 개발자가 wp-config.php 파일에 정의 된 상수에 반대하는 이유는 무엇입니까? 구텐베르크 항목을 코드의 한 영역에서 사용하지 않는다고 선언 할 수 있다면 현재 정의 문을 설정 한 것처럼 다른 영역에서 사용하도록 선언 할 수없는 이유는 무엇입니까?

상수를 위해 클래식 편집기 플러그인은 WordPress와 함께 사용자 정의 로더와 함께 번들로 제공되어야하며 영구적으로 유지되어야합니다. 구텐베르크가 대체되는 것이 무엇이든 등장하는 10 년, 15 년 후에도 여전히 존재할 수 있습니다.

그럼에도 불구하고 두 편집기가 필요하거나 원하는 사람들을 위해 어쨌든 플러그인은 여전히 ​​필요합니다.

Gutenberg가 도착할 것을 예상하여 v4.9에서 플러그인을 계속 설치하고 설정할 수 있다는 것을 잊지 마십시오.

Automattic / WordPress가 제공하지 않으면

@robmcclel Automattic은 WordPress, WordPress.org가 아닙니다! = WordPress.com, 하나는 오픈 소스 커뮤니티이고 다른 하나는 유료 타사 서비스입니다. Automattic은 WordPress 버전을 출시하지 않으며 WordPress는 내부 Automattic 제품이 아니며 Gutenberg도 마찬가지입니다. Automattic 이외의 작업을 수행하는 비 Automattic 기여자, 릴리스 리드 등이 많이 있습니다.

"그런데도 두 편집기를 모두 필요로하거나 원하는 사람들에게는 플러그인이 여전히 필요합니다."

실제로 여기와 다른 곳에서 논의 된 내용에서 사용자 지정 게시물 유형 또는 메타 박스가 구텐베르크를 지원하지 않는다고 선언하면 편집기 화면이 자동으로 폴백됩니다 ... "클래식 편집기"플러그인이 필요하지 않습니다. 이것은 구텐베르크 프로젝트의 현재 상태에 대한 많은 문제 중 하나이며, 특정 상황에서 일어나는 일에 대한 많은 의견 / 진술이 있으며 이러한 진술 / 의견은 다른 경우와 여러 번 다릅니다.

상수를 위해 클래식 편집기 플러그인은 WordPress와 함께 사용자 정의 로더와 함께 번들로 제공되어야하며 영구적으로 유지되어야합니다.

@tomjn 잠깐! 그래서 전체 메타 박스 시스템이 코어에서 벗겨지고 있다는 말입니까?

아니요, 메타 박스에 대해서는 전혀 언급하지 않았습니다. 하지만 메타 박스가 구텐베르크에 존재한다는 점을 명심하십시오. 메타 박스가 제거되었다는 것은 구텐베르크를 테스트하지 않았 음을 의미하며 생태계의 상당 부분이 여기에 의존하고 있음을 무시합니다. 그것은 wordcamp.org, wordpress.org 등에 게 큰 문제가 될 것입니다.

참고로 저는 구텐베르크 팀의 일원이 아니며 단순히 상식을 관찰하고 적용합니다. 내가 Automattic에서 일한다고해서 구텐베르크와 특별한 힘이 있다는 의미는 아닙니다. 나는 여기에있는 다른 모든 사람들과 마찬가지로 많은 발언권을 가지고 있으며, 내가 그것을 바꾸고 싶다면 다른 사람들과 마찬가지로 코드를 제공하고 문제를 수정함으로써 그것을 할 것입니다.

@tomjn 그래서 당신이 말한 것은 나에게 의미가 없습니다. "클래식 편집기"는 기본적으로 메타 상자와 저장 기능 등이있는 관리자 페이지입니다. 즉, 구텐베르크와 클래식 사이를 전환하려면 두 가지 옵션을 허용하는 코드가 코어에 내장되어 있어야하며 클래식 기능에 대한 모든 코드가 그대로 유지되어야합니다.

따라서 클래식 플러그인은 스위치를 트리거하는 방법 일뿐입니다. 플러그인을 빌드하고 유지하는 것보다 코어에서 상수 또는 테마 지원 유형을 빌드하는 것이 더 쉬울 것 같습니다.

Classic의 모든 것이 여전히 핵심이라면 플러그인을 활성화하기 위해 왜 만드나요?

그리고 그것이 제자리에 있어야한다면 어떨까요? WordPress 코어에는 이미 많은 오래되고 사용되지 않는 코드가 있습니다. 내장 된 클래식 트리거는 웅장한 계획에 큰 차이를 만들지 않습니다.

여기서 솔직하지 말자 Tom. Automattic은 구텐베르크의 원동력입니다. Automattic 직원으로부터 나오는 '하지만 그렇지 않습니다'는 맑은 날 하늘의 태양만큼 분명하다는 사실을 바꿀 것입니다.

Gutenberg는 Matt의 아기입니다. Automattic도 마찬가지입니다. 그는 프로젝트를 주도했습니다. 그는 가장 큰 치어 리더였습니다.

Gutenberg는 Automattic에 대해 심각한 운영상의 이점을 가지고 있습니다. 즉, 가장 큰 경쟁자들과 플레이 느낌을 평준화하는 제품을 제공합니다. 나머지 지역 사회에 대해서도 마찬가지입니다.

예, 많은 WordPress 사용자가 플러그인을 통해 페이지 빌더를 사용합니다. 그러나 또 다른 큰 부분은 ACF 및 CMB (및 많은 포크)와 ​​같은 플러그인을 통해 사용자 정의 필드를 많이 사용합니다. 커뮤니티의 해당 부분은 WordPress 프로젝트가 사용자 정의 필드를 기본 기능으로 구현할 것을 수년 동안 외쳐 왔습니다.

그러나 자금 지원이 이루어지지 않았기 때문에 결실을 맺지 못했고 그것이 제기 될 때마다위원회 별 죽음에 대한 토론이라는 아주 흔한 오픈 소스 문제에 시달렸습니다.

다른 많은 긴급 문제도 동일한 운명을 겪었습니다. 예를 들어 min-PHP 버전을 7 년 넘게 수명이 다한 적이없는 무언가에 부딪 혔습니다.

이는 프로젝트의 기본 자금 지원자가 지원하지 않았기 때문에 아직 달성되지 않았던 몇 년 전에 수행되어야했던 일의 몇 가지 예일뿐입니다.

Automattic은 주로 Matt가 운전석에 앉은 직접적인 결과로 Gutenberg에 무게를 두었습니다. 이를 실현하기 위해 엄청난 수의 업무 시간을 투자했습니다. 이는 WordPress 프로젝트의 주요 자금 지원자 인 Automattic의 직접 자금 조달로 해석됩니다.

이것이 티켓과 어떤 관련이 있는지 모르겠습니까?

@rosswintle 이것은 매우 관련이 있습니다. 구텐베르크를 끌 수있는 쉬운 방법을 원하는 개발자가 많이 있습니다. 권력자들이 우리에게 이것을주지 않고 구텐베르크를 끄는 것을 가능한 한 불편하게 만들고 싶어한다는 것은 꽤 분명합니다.

이 결정의 원동력은 DIY 웹 사이트 공간에서 시장 점유율을 높이려는 Matt와 Automattic의 의제입니다. 프로젝트에 대한 Matt 및 Automattic의 영향으로 인해 커뮤니티 문제가 해결되지 않고 있음이 분명합니다. 구텐베르크에 대한 커뮤니티의 불만이 100 % 발생하는 곳입니다.

Gutenberg 프로젝트의 방향은 Matt와 Automattic의 영향을 많이 받았기 때문에 프로젝트에 대한 모든 토론에서와 마찬가지로이 토론에서도 관련이 있습니다.

@tomjn

Gutenberg와 이번 릴리스에서 WordPress는 Automattic의 제품입니다. 다른 것을 믿는 것은 어리 석음입니다. .Com 또는 .Org는 중요하지 않습니다. WordPress 프로그램은 이제 Automattic의 제품입니다. 개발자와 그 작업을 수행하는 사람들은 Automattic의 무급 인턴에 지나지 않습니다.

커뮤니티는 Gutenberg를 플러그인으로 원합니다. Matt는 그렇지 않습니다. Matt는 Automattic의 책임자입니다. Matt는이 릴리스의 자체 지정 책임자입니다. Gutenberg의 개발을 이끄는 사람들은 Automattic 직원입니다. Matt가 이것을 강요하고 있습니다. 다른 결정이나 논쟁은 없습니다. 그는 51 %의 득표율을 가지고 있으며 그것을 행사하고 있습니다.

WordPress가 어떤 식 으로든 민주적 또는 커뮤니티 제품을 형성하거나 형성한다고 생각하지 마십시오. 현재는 Automattic의 제품이지만 과거에 프레임 화되거나 마케팅되었으며 이제는 개발 초점, 속도 및 결정을 지시하고 있습니다.

@rosswintle , 커뮤니티가 구텐베르크를 끄는 방법을 요청하고 있으며 구텐베르크 팀은 커뮤니티가 무엇이든 상관없이 플러그인이 그렇게 할 수있는 유일한 방법이 될 것이라고 응답하고 있다는 점에서 티켓과 관련이 있습니다. 큰 전체가 요구하고 있습니다.

Matt와 Automattic은 이에 대한 권한을 행사하고 있습니다. 우리의 목소리는 동정을 전달하고 우리에게 환기 할 수있는 장소를 제공하는 것 외에는 더 이상 관련이 없기 때문에이 티켓과 다른 모든 사람들이 좋아하는 것을 닫는 것이 좋습니다. 이 티켓은 존재하지 않을 수도 있습니다.

Automattic이이를 담당하는 것이지 커뮤니티가 아닙니다. 이런 일이 일어나고 유일한 오프 램프는 Classic Editor Plugin이며 심지어는 약간의 자선 활동이기 때문에 우리는 그것을 직면하고 충격에 대비해야합니다. 다른 것은 없을 것입니다.

나는 개인적으로 여기서 누가 결정을 내리고 있는지 논의하는 것이 문제를 진전시키는 데 어떻게 도움이되는지 모르겠습니다. 그것은 오픈 소스 프로젝트로 개발되고 있으며, 이는 여러분이 목소리를 낼 수 있다는 것을 의미합니다. 저는 사람들이이 옵션을 구현하기위한 옵션과 근거를 개발하도록 도와줌으로써 그들의 목소리를 건설적으로 사용하도록 권장합니다.

요청의 주제에 관한 마지막 게시물은 @tomjn이었고 , @wpstudio 및 @jawittdesigns의 관련 질문이 이어 졌습니다.

상수를 위해 클래식 편집기 플러그인은 WordPress와 함께 사용자 정의 로더와 함께 번들로 제공되어야하며 영구적으로 유지되어야합니다. 구텐베르크가 대체되는 것이 무엇이든 등장하는 10 년, 15 년 후에도 여전히 존재할 수 있습니다.

상수가 더 이상 사용되지 않는 적이 있습니까? (진짜 질문) WPLANG이 v4.0에 있었을 것 같습니까? 이것은 상수의 본질에 대한 철학적 인 것입니까? 필터가 더 좋을까요? @ smp303에 필터가 허용

그럼에도 불구하고 두 편집기가 필요하거나 원하는 사람들을 위해 어쨌든 플러그인은 여전히 ​​필요합니다.

왜 그런 겁니까?

@jawittdesigns 올바른 질문 :

Classic의 모든 것이 여전히 핵심이라면 플러그인을 활성화하기 위해 왜 만드나요? 그리고 그것이 제자리에 있어야한다면 어떨까요? WordPress 코어에는 이미 많은 오래되고 사용되지 않는 코드가 있습니다. 내장 된 클래식 트리거는 웅장한 계획에 큰 차이를 만들지 않습니다.

@pento 는 대부분의 제거를 거의

TinyMCE는 Gutenberg에서 편집 가능한 텍스트 블록을 강화하는 데 사용됩니다. wp_editor ()와 같은 함수는 플러그인으로 이동할 필요없이 Core에서 비교적 쉽게 유지 관리 할 수 ​​있습니다. 계속해서 무기한으로 작동 할 것으로 예상합니다.

드디어:

Gutenberg가 도착할 것을 예상하여 v4.9에서 플러그인을 계속 설치하고 설정할 수 있다는 것을 잊지 마십시오.

우리 모두는 이것을 알고 있습니다. 우리는 워크 플로가 다른 개발자에게 옵션을 제공하는 다양한 방법을 옹호하려고합니다.

@rosswintle – 궁극적으로 누가 결정을

그러나 예,이 특정 문제가 논의하기에 적합한 장소가 아니라는 점에서 귀하가 맞습니다. 그러나 우리의 요청에 대한 결정을 거부하는 것은 결정을 주도한 사람들에 비해 우리가 약한 위치에 있다는 사실을 나타냅니다.

어쨌든. 마지막 게시물에서 좋은 점을 몇 가지 작성했습니다. 사실, 당신의 견적을 받아 보겠습니다.

상수를 위해 클래식 편집기 플러그인은 WordPress와 함께 사용자 정의 로더와 함께 번들로 제공되어야하며 영구적으로 유지되어야합니다. 구텐베르크가 대체되는 것이 무엇이든 등장하는 10 년, 15 년 후에도 여전히 존재할 수 있습니다.

일단 구텐베르크를 대체하는 것이 나오면 우리는 다시는 똑같은 논의를하지 않을 것이라고 가정해야합니까? WordPress의 큰 USP는 항상 경쟁 업체와 비교하여 하위 호환성에 대한 헌신이었습니다. 지금까지는 잘 작동했습니다. 우리 모두가 지적했듯이 구텐베르크는 그것을 깨뜨립니다. 우리가 현재 가지고있는 것을 그대로 유지할 수있는 선택의 여지가 거의 없습니다. 사실상 공식적인 승인 된 해킹을 제외하고 말입니다.

사실, 코드는 모두 여전히 핵심입니다. 수백 줄의 코드로 끝나는 별도로 유지 관리해야하는 플러그인에 대해 상수 (한 줄의 코드)를 사용할 수 있도록하는 것이 훨씬 더 스마트하고 적격 한 접근 방식입니다.

사실, 코드는 모두 여전히 핵심입니다. 수백 줄의 코드로 끝나는 별도로 유지 관리해야하는 플러그인에 대해 상수 (한 줄의 코드)를 사용할 수 있도록하는 것이 훨씬 더 스마트하고 적격 한 접근 방식입니다.

이것이 내 요점입니다 ...이게 필요한 사람들의 틈새 시장이 아닙니다. 구텐베르크가 현재 엄청난 양의 플러그인과 테마 등을 제대로 중단한다는 사실로 인해 ... 또 다른 플러그인은 수정이 아니라 해킹, 의존성입니다. 최고의 WordPress 사이트를 만드는 사람들의 핵심을 몰아 낼 수있는 문제를 해결하는 올바른 방법이 아닙니다.

나를 가장 두렵게하는 다른 옵션은 사람들이 4.9를 고수하고 사이트를 업그레이드하지 않는다는 것입니다. 그런 다음 불안정 해지고 해킹에 개방되어 WordPress의 이름을 무너 뜨립니다.

이것에 대해 충분한 생각이 들어갔다는 느낌이 들지 않으므로 플러그인이 최종 솔루션 인 이유는 무엇입니까?

TinyMCE가 특정 블록에 대해 계속해서 구텐베르크 "아래"에있을 경우 다음과 같은 상황에 접근하지 않는 이유는 무엇입니까?
5.0 이전 버전 (현재 WordPress에서 제공하는 사이트)은 Gutenberg를 쉽게 활성화 할 수 있도록 필터 / 상수를 사용하여 기본적으로 비활성화되었습니다.
5.0+ (5.0 이상에 설치된 WordPress 사이트라고도 함)에서는 Gutenberg가 기본적으로 필터 / 상수로 활성화되어 쉽게 비활성화 할 수 있습니다.

이런 식으로 구텐베르크를 사용하려는 사람은 누구나 쉽게 선택할 수 있으며 구텐베르크를 사용할 준비가되어 있지 않거나 (어떤 이유로 든) 기꺼이 사용할 의사가없는 사람도 쉽게 선택할 수 있습니다. 좀 더 실용적인 (단기적으로) 해결책이있을 때 구텐베르크 언덕에서 죽어가는 입장을 원하는 경우가 있습니다.

@wpstudio 이것은 # 4423이 요구하는 것입니다.

@rosswintle 처럼, 나는 그것을 만든 사람들을 위해이 문제를 제자리로 되 돌리는 것이 중요하다고 생각합니다. 존경심으로 토론 해주신 분들께 감사드립니다.

하지만 회사와 그 동기에 대해 느끼는 것이 무엇이든 많은 사람들이 많은 다른 회사에서 구텐베르크를 위해 일하고 있습니다. WordPress와 마찬가지로 이것은 하나의 회사가 아닌 커뮤니티 기여로 이루어집니다. 전면적 인 진술을하는 것은 이것에 대해 일하는 사람들에게 공정하지 않습니다. 이 문제를 시작하고 해결책을 원하는 사람들에게도 불공평합니다.

이 문제가 정상으로 돌아가서이 문제의 요점에 대해 정중하게 토론하기를 바랍니다.

@karmatosed , @ntwb , @tomjn 및이 스레드의 다른 사람, 위의 작은 폭언이 불쾌감을 주면 사과드립니다. 이것은 매우 중요한 주제이며 토론할만한 가치가 있습니다. 만약 우리가 정말로 그것에 대해 토론한다면.

위의 스레드를 보면 다른 구성 요소가 Core의 일부로 남아 있어야하므로 구텐베르크가 코어에서 비활성화 될 수 있다는 것이 꽤 분명하다고 생각합니다. 현재 플러그인으로 존재하고 많은 사이트에서 잘 실행할 수 있기 때문에 의미가 있습니다. 따라서 지금까지 제시되지 않은 기술적 이유를 제외하면이 결정은 기술적 결정이 아니라 철학적 결정임을 의미합니다.

그리고 그것이 진짜 핵심입니다. 나는 커뮤니티 전체가 이것에 대해 하나의 마음이라고 생각하지 않습니다. 근처에도 안. 이것이 Matt가 결정을 내리는 이유입니다 (내가 "비난"이 아니라 "배치"라고 말 했음). Matt가 그 뒤에있는 원동력 인 것처럼 보이기 때문입니다. 그리고 분명히 Gutenberg를 Core 및 5.0 릴리스의 일부로 만들기로 한 확고한 결정 뒤에 있습니다.

질문은 "왜?"입니다.

구텐베르크가 Core에 들어가도록 강요 한 이유를 확실히 알 수 있습니다. "블록"은 미래의 생존과 WordPress, .org 또는 .com의 광범위한 사용에 매우 중요하다고 생각합니다. 나는한다. 나는 "블록"100 % 뒤에 있습니다.

그러나 나는 구텐베르크 자체가 그 "블록"의 전달 방법으로서 잘 생각 된 시스템이라고 생각하지 않습니다. 이 스레드에서 3 가지 사용 사례 (me, @rosswintle 및 @ smp303 )가 있으며 Gutenberg는 우리 중 누구도 만족하지 않는 것으로 보입니다. 사실, 그것은 우리, 우리의 비즈니스 및 사용자들에게 상당한 우려를 불러 일으키고 있습니다.

Gutenberg를 Core에 넣기로 한 결정은 Automattic에게 합리적입니다. Automattic은 모든 플러그인 개발자가이를 채택하고 함께 작동하도록 플러그인을 다시 작성해야하기 때문입니다. 이것은 WordPress.com에 매우 좋으며 아마도 WordPress.org에도 좋습니다. 그러나 일부 사용 사례는 블록의 이점을 얻지 못하지만 블록의 존재가 블록을 해치지 않기를 바랍니다.

그러나 이것은 매우 소수의 사람들이 매우 많은 사람들을 위해 매우 강력한 경제 및 비즈니스 결정을 내리고 있음을 의미합니다. 나에게만 블록으로 변경하는 것은 수백 시간과 수천 달러에 달하며 시스템의 중요한 부분을 점검하기 위해 계획된 목표 (제가 서비스하는 커뮤니티가 실제로 원하는)에서 자원을 빼앗아가는 개발 시간 손실이 있습니다. 알려지지 않은 의사 결정자들의 요구를 충족시키기 위해 (다시 말하지만 Matt가 그 의사 결정 그룹의 상당 부분이라고 가정합니다).

구텐베르크가 나를 위해 문제를 해결했다면 나는 이것에 대해 그렇게 나쁘게 느끼거나 솔직히 그렇게 두려워하지 않을 것입니다. 그러나 그렇지 않습니다. 지금까지 그것은 내 삶을 훨씬 더 악화시키고 있습니다. 상황이 개선 될 수는 있지만 개발 방향에 큰 변화는 보이지 않습니다. 사용, 구현, UI / UX, 수단 및 방법에 대한 결정의 95 %는 많은 토론이나 의견없이 다른 소수 그룹에 의해 모두 결정된 것으로 보입니다.

WordPress는 전체 인터넷의 25 % 이상을 지원합니다. 이는 수백만 개의 사이트, 수십억 개의 웹 페이지, 그리고 아마도 수 천억 달러로 해석됩니다. New York Times에서 내 네트워크에있는 소수의 도서 블로거에 이르기까지. 방대한 전자 상거래 사이트에서 내가 서비스하는 저자가 판매하는 개별 서명 책에 이르기까지. 그것은 방대합니다. 실질적으로 전 세계적인 유틸리티입니다.

그러나이 모든 것 (수백만 명의 사람들에게 영향을 미치는)에 대한 토대 중 상당 부분을 다시 작성하기로 한 결정은 논쟁없이 이루어진 것 같습니다. 인터페이스에서 REACT에 대한 의존에 이르기까지 모든 것 (매우 약탈적인 것으로 입증 된 Facebook에 의해 제어 됨, SnapChat에 문의). 이러한 모든 결정은 대체로 일방적으로 이루어졌습니다.

이것이 모두 JetPack의 모듈에 전원을 공급하는 것이라면 아무도 신경 쓰지 않을 것입니다. 그것이 WordPress.com 사업입니다. 그러나 그렇지 않습니다. 그것은 전체 인터넷의 토대를 바꾸고 있습니다.

지금 바로 여기로 연결됩니다. 이 스레드의 커뮤니티 구성원 인 커뮤니티는 오픈 소스와 공개적으로 사용 가능한 WordPress.org 코드를 사용하여 구축 한 제품 및 비즈니스에 대한 제어권을 요청하고 있습니다. 우리는 우리 자신과 사용자를 보호 할 수있는 능력을 요구하고 있으며 그렇게 할 수있는 유일한 방법은 구텐베르크를 끄는 방법을 요청하는 것입니다. 우리는 구텐베르크를 추가하는 것이 Core의 일부가되는 것처럼 Core의 일부가 될 수있는 능력을 요청하고 있습니다.

구텐베르크를 끄는 기능을 Core에 추가 할 수 있습니까? 그 결정을 내리고 리드를 지시하는 사람은 누구입니까? 그 질문을하는 메커니즘은 무엇입니까? 논쟁의 여지가 있습니까? 투표를 할 것인가? 댓글 처리가 있나요? 그렇다면 어디?

그리고 @karmatosed , Github의 "문제"섹션이이 토론을하기에 가장 좋은 곳이 아니라는 점에서 100 % 맞습니다. 나는이 저장소가 구텐베르그 플러그인과 직접 관련된 기술적 문제를 식별하고 해결하기 위해 의도 된 목적에 크게 맡겨 져야한다는 데 동의합니다.

안타깝게도이 토론을 할 수있는 다른 장소는없는 것 같습니다. Gutenberg Plugin의 Reviews 섹션이 있지만, 이런 종류의 대화를위한 매우 제한된 포럼입니다.

구텐베르크를 논의 할 수있는 사이트가 있습니까? 구현뿐만 아니라 인터페이스에 대해 의견을 말하고 논의하려면? 출시 일정? (예를 들어, Gutenberg 및 WP5.0이 "완료"되고 출시 준비가되었는지 여부를 결정하는 기준은 무엇입니까? 누가 결정합니까? ") Gutenberg 인터페이스에 대한 사용자 테스트가 있습니까? @ 에서 데이터와 피드백을 수집하는 방법이 있습니까?

유튜브에 사람들에게 Gutenberg를 사용 해보고 직관적인지 평가 해달라고 요청하는 흥미로운 비디오가있었습니다 (링크 : https://youtu.be/7iWRBLCP-l0)-이와 비슷한 다른 동영상이 있습니까? 구텐베르크를 테스트하기위한 대규모 노력이 있습니까? 그렇다면 해당 데이터는 어디에 보관됩니까? 그 데이터는 어떻게 공유됩니까? 커뮤니티에서 볼 수 있습니까? 설계를 추진하는 데 사용되고 있습니까?

우리가 지금 구텐베르크와 직면하고있는 문제는 – 그리고 실제로이 스레드의 원동력입니다 – 커뮤니티가이 과정으로부터 매우 고립되어 있다고 느낀다는 것입니다. 우리는 그것이 우리에게 일어나는 것처럼 느낍니다. 실제로 그것은 우리에게 강요되고 있습니다. 의견과 토론을위한 프로세스를 열고 인터페이스, 데이터 공유 및 사용자 통찰력과 같은 것에 대한 새로운 목소리와 아이디어를 허용하는 것은 이러한 두려움과 우려를 완화하는 데 큰 도움이 될 것입니다.

그리고 블록을 핵심 기능으로 만들지 만 구텐베르크를 플러그인으로 유지하면 모든 것이 훨씬 덜 무섭고 커뮤니티 전체가 훨씬 더 좋아할 수 있습니다. 개인적으로 좋아합니다. 커뮤니티에 구텐베르크에 대한 대안 적 접근 방식 (다른 인터페이스 및 사용 사례)을 탐색하고 개발할 시간을 주되 여전히 블록의 개발과 미래를 장려하십시오.

그래서 그것은 꽤 길었지만 다시, 우리는 여기서이 논쟁을 제외하고 어디에서해야할까요? 그리고이 논쟁은 매우 중요합니다. 영향을받는 사람과 기업의 수를 고려할 때 현재 인터넷에서 가장 중요한 토론이 될 수 있습니다.

이것에 대해 약간의 조사를 해본 결과, mu-plugin 파일에서 내가 뭔가를 놓친 경우가 아니라면 코드로 구텐베르크를 비활성화하는 데 필요한 것은 다음과 같습니다.

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

컨텍스트를 위해 Gutenberg 플러그인이 활성화되어 있고 mu-plugins 폴더의 파일에 위 코드가 있습니다. 이제 모든 포스트 편집 화면에서 클래식 편집기를 사용합니다.

이에 대해 몇 가지 유의해야 할 사항 :

• gutenberg_can_edit_post_type 은 (는) 최종 필터 이름이 아닙니다. gutenberg 이름은 Core에 병합되기 전에 이름이 변경됩니다.
• 이 필터는 "블록 편집기를로드하지 않음"을 의미하며 "클래식 편집기 사용"을 의미하지 않습니다. 현재는 작동하지만 미래에 작동한다는 보장은 없습니다. 클래식 전용 코드 (예 : edit-form-advanced.php )가 클래식 편집기 플러그인으로 이동하면 클래식 편집기로의 폴 백이 중지되고 사용자가 자신의 편집기를로드 할 것을 명시 적으로 예상합니다.

@rosswintle : 지난주 스레드를 따기 :

이에 대해 생각하는 가장 쉬운 방법은 "데이터가 <body> 에서 </body> 사이에 나타나면 내용이며 궁극적으로 블록에 맞을 것입니다"입니다. 워드 프레스 5.0의 경우 조금 더 제한적입니다. <article> 와 </article> 사이에있는 것만 블록입니다. 😉

예를 들어 부동산 게시물 유형을 예로 들어 보겠습니다. 가격은 postmeta에 저장되지만 내용입니다. "Property Lede"라는 블록이있을 수 있습니다. 여기에는 가격, 주소, 건물 유형, 침실 / 욕실 / 차고 수 등 작성해야 할 몇 가지 항목이 있습니다. 검사 시간, 기능, 사진, 평면도, 에이전트 등 다른 블록도있을 수 있습니다. 블록 템플릿을 사용하여 property 게시물 유형을 편집 할 때 블록 편집기를 설정하고, 블록이 이미 있으며 이동할 수 없습니다. 최종 사용자를위한 워크 플로는 기존 메타 박스 기반 워크 플로의 현재 모습과 다르지 않지만 최종 출력과 훨씬 유사합니다.

다소 긴 시간 이었지만, 데이터가 저장되는 위치 또는 프런트 엔드에 표시되기 전에 어떻게 조작 또는 형식화 될 수 있는지에 관계없이 콘텐츠 _is_ 콘텐츠처럼 보이는 모든 장면을 설정합니다. 일부 블록은 데이터를 post_content 에 저장할 수 있지만, 그것이 콘텐츠를 만드는 특징이 아닙니다. 프런트 엔드에 표시되는 것이 콘텐츠를 만드는 것입니다.

그렇다면 프런트 엔드에 표시되지 않는 정보는 어떻습니까? 주인의 이름? 약속보기와의 관계? 그게 "내용"입니까? 그것이 "블록"에 들어가야합니까?

카테고리 / 태그 / 분류는 프런트 엔드에 표시되거나 표시되지 않을 수 있습니다. 그들은 "블록"입니까?

게시 상태는 프런트 엔드에 표시 될 수 있지만 이것은 확실히 블록이 아닙니다.

이전에 다음과 같이 말씀하셨습니다.

메타 데이터는 블록이 아니지만 블록이 사용되거나 표시되는 방법을 알려줄 수 있습니다.

괜찮습니다. 그런데 왜 개발자들은 미래에 블록 인터페이스를 사용하여 메타 데이터를 편집해야한다고 들었을까요?

이것은 나에게 진정한 혼란입니다. 구텐베르크 블록이 body 태그 사이에있는 내용을 편집하는 데 유용한 이유는 알지만 해당 태그 사이에없는 다른 데이터를 편집하는 데 블록이 좋은 이유는 이해하지 못합니다.

개발자가 Gutenberg를 끄고 싶어하는 것은 이러한 혼란 때문인 것 같습니다. WordPress 사용 중 일부에는 프런트 엔드에 표시되지 않는 많은 정보가 있지만 앞으로는 프런트 엔드 편집기가이 데이터의 인터페이스로 사용해야한다는 말을 듣고 있습니다.

이것이 혼란을 전달하기를 바랍니다.

비활성화하는 방법에 대해 ...?

@pento 해당 함수에 대한 문서 블록은이 필터가 임시적임을 전혀 나타내지 않습니다.

/**
 * Filter to allow plugins to enable/disable Gutenberg for particular post types.
 *
 * <strong i="7">@since</strong> 1.5.2
 *
 * <strong i="8">@param</strong> bool   $can_edit  Whether the post type can be edited or not.
 * <strong i="9">@param</strong> string $post_type The post type being checked.
 */

설명 된대로 수행하지 않을 경우 해당 필터의 목적은 무엇입니까?

또한 이것 에 대해

이 필터는 "블록 편집기를로드하지 않음"을 의미하며 "클래식 편집기 사용"을 의미하지 않습니다. 현재는 작동하지만 미래에 작동한다는 보장은 없습니다. 클래식 전용 코드 (예 : edit-form-advanced.php)가 클래식 편집기 플러그인으로 이동함에 따라 클래식 편집기로의 대체가 중지되고 사용자가 자신의 편집기를로드 할 것을 명시 적으로 예상합니다.

게시물 유형이 show_in_rest => false 선언하거나 게시물 편집 화면의 메타 상자가 '__block_editor_compatible_meta_box' => false, 선언하면 클래식 편집기가로드된다고 여러 곳에서 들었습니다. 위에서 보았을 때 이것이 코어의 일부가 아니라고 말하는 것 같습니다. 따라서 클래식 편집기 플러그인을 활성화하지 않은 경우 어떻게 될 수 있습니까?

클래식 편집기로 대체하려면 구텐베르크를 지원하지 않는 무언가가 감지되면 반드시 클래식 편집기가 코어의 일부로 남아 있어야합니다. 따라서이 기능을 호출하는 데 플러그인이 필요하지 않습니까?

그렇다면 프런트 엔드에 표시되지 않는 정보는 어떻습니까? 주인의 이름? 약속보기와의 관계? 그게 "내용"입니까? 그것이 "블록"에 들어가야합니까?

물론 메타 정보를위한 공간도 있습니다. # 3330에서 논의됩니다. 제가 주목하고 싶은 것은 "메타 데이터"라고하는 많은 것들이 실제로 콘텐츠라는 것입니다.

카테고리 / 태그 / 분류는 프런트 엔드에 표시되거나 표시되지 않을 수 있습니다. 그들은 "블록"입니까?

글쎄, 그들은 게시물에 대한 메타이지만 사이트에 대한 콘텐츠 일 수 있습니다. Gutenberg Customization의 초점에는 해당 메타 데이터를 사용하여 콘텐츠를 생성하는 블록이 포함될 것입니다. 🙂 블록 편집기의 블록이 콘텐츠로 사용할 가능성은 거의 없으므로 분류가 블록이 아닌 사이드 바에있는 이유는 무엇입니까?

괜찮습니다. 그런데 왜 개발자들은 미래에 블록 인터페이스를 사용하여 메타 데이터를 편집해야한다고 들었을까요?

모든 메타 데이터가 블록 인터페이스에 적합하다고 말하는 것은 아닙니다. 일부는 할 수 있지만 반드시 그럴 필요는 없습니다. 요점은 _ 대부분의 _ 기존 메타 박스 사용이 블록 인터페이스에 적합하다는 것입니다. 구분하는 가장 쉬운 방법은 프런트 엔드에 표시되는지 여부를 생각하는 것입니다. # 3330에서는 메타 데이터 편집 개념에 대해 자세히 설명합니다.

메타 데이터는 블록 편집기 인터페이스에서 편집 할 필요가 _ 없습니다 _. 콘텐츠가 아니거나 어떤 식 으로든 콘텐츠와 관련이없는 경우 해당 메타 데이터를 편집하기위한 인터페이스를 삽입 할 다른 위치가 있습니다.

비활성화하는 방법에 대해 ...?

사이트를 구축하는 경우 클래식 편집기 플러그인을 사용하십시오. 플러그인을 빌드하는 경우 CPT 및 메타 상자 호환성 플래그를 사용하십시오. 🙂

사이트를 구축하는 경우 클래식 편집기 플러그인을 사용하십시오. 플러그인을 빌드하는 경우 CPT 및 메타 상자 호환성 플래그를 사용하십시오. 🙂

이것은 우리가 앞으로 구축하는 사이트 또는 우리가 "책에있는"클라이언트를 가지고 그들의 사이트를 돌보는 경우에 좋습니다. 그러나 우리가 과거에 사이트를 구축하고 잘 작동하는 클라이언트, 자동 업데이트 등의 클라이언트는 어떻습니까? 그들은 아마도 WordPress v5.0으로 업데이트를 클릭 할 것입니다.

이러한 사이트에는 클래식 편집기 플러그인이 설치되어 있지 않으며 구텐베르크가 없을 때 코딩 되었기 때문에 해당 메타 상자 / CPT에 플래그가 없습니다. 이러한 사이트에는 문제가 발생하고 소유자가 혼란스럽고 솔직히 매우 짜증이납니다. 내가 틀렸다면 나를 바로 잡으십시오.

@wpmark 가 그것을 못 박았습니다.

나중에 필요한 경우 클래식 편집기 플러그인을 사용할 것입니다. 나중에 필요한 경우 CPT 및 메타 박스 호환성 플래그를 사용할 것입니다. 하지만 이미 사이트를 만든 수십 개의 개인, 기업, 자선 단체 / 비영리 단체가 있습니다. 그들 중 일부는 여전히 작업 관계가 있습니다. 다른 사람들은 계속해서 사이트를 직접 운영하거나 다른 개발자와 함께 일하거나 전혀 개발자가 없습니다.

필요한 모든 사이트에 코드 변경이나 플러그인 설치를 기대하는 것은 비현실적입니다.

이것은 정말로 # 4423 영토입니다.

모든 중요한 대화에 대해이 티켓에는 레이블이나 소유자가 없습니다. 그것이 일어나지 않을 것이라면 그것을 열어 두어야 할 이유가 있습니까?

gutenberg_can_edit_post_type (또는 Core에서 호출되는 모든 항목) 및 '__block_editor_compatible_meta_box' => false 는 WordPress 5.0의 클래식 인터페이스로 대체됩니다. 그러나 향후 WordPress 릴리스는 이러한 동작을 변경할 수 있습니다.

gutenberg_can_edit_post_type 는 블록 편집기를로드할지 여부 만 플래그 지정합니다. 현재 블록 편집기를로드하지 않을 때의 기본 동작은 클래식을로드하는 것이지만 해당 필터의 가정은 블록 편집기를로드하지 않는 경우 고유 한 인터페이스를 제공한다는 것입니다. 클래식 편집기 플러그인 일 수도 있고 사용자 정의 인터페이스 일 수도 있습니다. 그러나 향후 WordPRess 릴리스에서는 클래식 코드가 클래식 편집기로 이동 될 것으로 예상됩니다.

__block_editor_compatible_meta_box 플래그에 대해서도 유사한 상황이 존재합니다. 지금은 클래식 인터페이스로 돌아가지만 WordPress의 향후 릴리스에서는 기본 동작이 변경되어 블록 편집기에 유지되고 메타 상자가있는 위치에 경고를 표시 할 수 있습니다.

물론 이러한 변경은 조사와 사이트 소유자 모두에게 연락하지 않고는 일어나지 않을 것입니다. 내 요점은 이러한 설정이 주로 구텐베르크로 전환하기위한 목적으로 존재한다는 것입니다. Classic Editor 플러그인은 Classic 인터페이스를 강제로 사용하기위한 안정적인 옵션입니다.

이러한 문제에 대한 자세한 내용은 # 3902를 참조하세요.

사이트 소유자에게 알리는 주제에 대해 WordPress 5.0은 진공 상태로 출시되지 않습니다. 사이트 소유자에게 향후 변경 사항을 알리고 사이트가 작동할지 여부를 알리는 데 사용할 수있는 많은 도구가 있습니다. 향후 WordPress 4.9.x 릴리스에는 블록 편집기에 대한 정보가 포함될 예정이며, 플러그인 호환성 (자동화 및 크라우드 소싱 모두-# 4072)에 대한 데이터를 수집 할 계획이 진행 중이며 사이트 소유자가 알 수 있도록 다른 옵션에 개방되어 있습니다. 오는 것.

모든 중요한 대화에 대해이 티켓에는 레이블이나 소유자가 없습니다. 그것이 일어나지 않을 것이라면 그것을 열어 두어야 할 이유가 있습니까?

이 토론을하는 동안 열어 두는 데 문제가 없었지만 지금은 더 이상 열어 둘 필요가 없다고 생각합니다. 원래 질문을 해결하기 위해 클래식 편집기로 돌아가는 코드 기반 옵션이 카드에 없습니다.

@pento 왜 이것을 닫았습니까? 문제는 아직 해결되지 않았습니다.

당신은 이것을 닫아 커뮤니티가 듣지 않는다는 점을 증명하고 있습니다.

다시 열어야한다고 생각하므로 이에 대한 해결책을 찾을 수 있습니다.

해결책은 아니 었습니다. 코드에서 Gutenberg를 비활성화하는 방법을 사용할 수 없습니다. 플러그인에 의존해야합니다.

완전히 불행하고 불만족 스럽지만 적어도 나는 시도했습니다.

해결책은 아니 었습니다. 코드에서 Gutenberg를 비활성화하는 방법을 사용할 수 없습니다. 플러그인에 의존해야합니다.

언제 어디서 일어 났습니까? 여기에는 결정에 대한 언급이 없습니다.

아니면 듣는 척하고 종료하는 전형적인 핵심 팀 반응입니까?

이 시점에서 어떤 종류의 해결책을 원하십니까?

상수를 사용하여 구텐베르크를 비활성화하려는 경우에는 발생하지 않습니다. 우리는 귀를 기울 였고 아이디어는 거부되었습니다.

이 토론을하는 동안 열어 두는 데 문제가 없었지만 지금은 더 이상 열어 둘 필요가 없다고 생각합니다. 원래 질문을 해결하기 위해 클래식 편집기로 돌아가는 코드 기반 옵션이 카드에 없습니다.

@pento에서 -이것이 닫힌 이유입니다.

글쎄, 나는 그들이 적어도 업데이트 전에 플러그인을 릴리스하여 사용자 경험이 중단되지 않도록 설치하고 활성화 할 수 있기를 바랍니다.

내 말은 메타 박스 지원이 2.0에서 여전히 깨졌고이 시점에서 작동 할 것이라고 확신하지 못한다.

플러그인이 이미 존재합니다 : https://wordpress.org/plugins/classic-editor/

@ smp303 의 원래 질문에 대답합니다.

1. wp-config.php에서 추가

define( 'ENABLE_GUTENBERG', false );

1. 파일에서 호출 my-hacks.php 에서 mu-plugins 사용자가 코드를 생성 할 수 있습니다 폴더,

<?php // (C) Bobbing Wide 2015-2018
if ( defined( "ENABLE_GUTENBERG" ) && !ENABLE_GUTENBERG ) {
    add_filter( 'gutenberg_can_edit_post_type', '__return_false' ); 
}   

소품 @tomjn @wpmark

Gutenberg 또는 클래식 편집기를 설치하지 않고도 오늘 이 작업을 수행 할 수 있습니다.
그러나 코드가 코어에 병합되면 필터 이름이 변경 될 수 있습니다.
...이 시점에서 누군가가 문서를 작성하고 다른 줄을 추가 할 수 있습니다.

참고 : my-hacks.php 라는 파일은 2003 년에 도입되었으며 200x에서는 더 이상 사용되지 않습니다.
그러나 mu-plugins 에서 필수 플러그인으로 구현하는 것을 막을 수는 없습니다.

관련 옵션 필드를 포함하여 사용되지 않는 코드를 제거하는 것이 얼마나 어려운지 확인하려는 경우
WordPress TRAC # 33741 -my-hacks.php 및 hack_file 옵션에 대한 참조 제거 참조

더 쉽게 ... wp-config.php에서

$_GET['classic-editor'] = true;

블록의 개념이 틀렸다고 생각합니다. 제 생각에는 블록은 게시물이어야합니다. 따라서 게시물에 여러 콘텐츠가 필요한 경우 하위 게시물을 가질 수 있어야합니다. 트위터처럼 많은 독립적 인 트윗으로 페이지가 만들어집니다.

게시물 안에 텍스트 편집기 만 있으면됩니다.

모든 페이지를 업데이트 할 예산이 없습니다. wp가 장기적인 호환성을 제공하지 않는 경우, 많은 사용은 새로운 회사에 문이 열리기 때문에 앞으로 더 안정적인 커뮤니티로 변경 될 것입니다.

이제 워드 프레스는 커뮤니티 덕분에 멋집니다. 5.0은 0에서 시작하는 것을 의미합니다. 따라서 다른 프레임 워크처럼.

두 줄의 개발은 비활성화하는 대신에 좋은 아이디어가 될 수 있습니다. WP normal 및 WP Gutenberg. 적어도 향후 5 년 동안. 그런 다음 구텐베르크는 WP처럼 안정적이고 커뮤니티도 가질 시간이있을 것입니다.

개발자로서 많은 분들이 문제를 가지고 있으면 좋을 것입니다.
Github는 문제를 해결하기위한 작업 방법을 제안하는 티켓과 함께 현재 구텐베르크 프로젝트로 솔루션을 구축하는 데 도움이되지 않는 이유를 끝없이 작성하는 대신에 작성합니다.

문제 해결을 돕기 위해 프로그래밍 기술을 가져 오십시오.

저는 비주얼 디자이너이며 현재 두 명의 고객이 편집 프로세스를 구텐베르크로 이동하도록 도울 계획을 세우고 있으며 현재 유지 관리 할 수없는 20 년 이상 된 사이트를 가진 고객을 위해 새 사이트를 설계하고 구축하고 있습니다.

사이트 구축 도구로서 WordPress.org를 앞으로 나아가도록 도와주세요.

@TomDesign 에서 토론을 읽어 보셨나요? GB 팀은 플러그인의 일부로 기능을 원하지 않으므로 "문제 해결을 위해 프로그래밍 기술 가져 오기"에서 누군가 자신의 계정을 해킹하여 원하지 않는 코드를 추가해야한다는 뜻이 아니라면 코드 작성 방법을 잘 모르겠습니다. 여기서는 원격으로 관련이 있습니다.

@tomdesign # 4981에서 실행 가능한 마이그레이션 계획이 있어야한다는 요구 사항을 제기했습니다.
많은 작업이 될 것이라고 지적했습니다. 그리고 그것은 내가 필요하다고 느끼는 것입니다.

원활한 마이그레이션을 보장하기 위해 프로그래밍 기술을 사용할 수 있기를 원하는 개발자가 꽤있을 것입니다. 그러나 우리는 거부 당할 무언가를 개발하는 데 시간을 낭비하고 싶지 않습니다. 제 생각에 마이그레이션은 각각의 요구 사항이 논리적으로 평가되는 프로젝트 자체에 적합합니다. 장기적으로 우리를 얻을 수 있도록 잘 문서화 된 제안을 갖는 것이 중요합니다.

Simon의 원래 요청은 장기적인 문제에 대한 단기 수정이었습니다.
콘텐츠 마이그레이션 프로세스는 몇 년 동안 지속될 것이라고 생각합니다.

안녕하세요 여러분,
댓글을 읽으면 이것이 구텐베르크에 대한 좋은 플러그인을 공유하기에 적합한 장소라고 생각합니다.
구텐베르크 편집기를 관리 할 수있는 무료 플러그인을 소개합니다.
Gutenberg Manager라고하며 다양한 게시물 유형 (페이지 및 게시물 포함)에서 편집기를 활성화 / 비활성화 할 수 있습니다. 더 많은 기능이 있지만 나는 당신에게 맡깁니다.

우리는 WP 5.0의 코어 내에서 구텐베르크의 향후 구현에 대해 불평하는 수많은 게시물을 읽었으며 이로 인해 간단한 해결책을 찾게되었습니다.

Gutenberg Manager는이 문제를 해결하고 예를 들어 WP 5.0 이후에도 Elementor, Visual Composer, Siteorigin Builder 또는 Cornerstone을 문제없이 계속 사용할 수 있습니다.
WP.org에 대한 첫 번째 사용자 피드백에서 플러그인이 과소 평가 된 것 같습니다. :)

이런 이유로 Gutenberg Manager-> https://wordpress.org/plugins/manager-for-gutenberg/ 를 소개합니다.

플러그인은 몇 가지 유용한 후크 덕분에 개발자가 자신의 테마와 플러그인에서 사용할 수 있습니다. 플러그인 옵션 패널을 숨기는 후크가 있으므로 최종 사용자는 WP 백엔드에서이를 볼 수 없습니다 (프로젝트에 Gutenberg Manager를 포함하려는 개발자를위한 훌륭한 기능).

우리는 또한 파트너십과 협력을 활성화하기 위해 가장 유명한 빌더 팀과 협의하고 있습니다. 이런 식으로 우리는 구텐베르크로의 전환이 약간 덜 충격적이기를 희망합니다!

관심을 가져 주셔서 감사합니다.
잘 했어.

@unCommonsTeam 예를 들어 설정 화면에서 옵션을 선택한 경우 플러그인에서 Gutenberg 편집기를 비활성화하는 방법을 물어볼 수 있습니까?

물론 @wpmark ,

79 행-> https://github.com/unCommonsTeam/gutenberg-manager/blob/master/inc/core.php를 살펴보십시오.

베스트

@unCommonsTeam 나에게 돌아와 주셔서 감사합니다. 나는 아마도 여기에서 틀렸을 것입니다.하지만 플러그인이 Gutenberg 플러그인에 의해 추가 된 모든 것을 제거하는 것처럼 보입니다. 이것은 위에서 다음을 사용하여 제안한 것입니다.

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

그러나 @pento 는 편집기를 WordPress에 다시 넣기 때문에 강력한 솔루션이 아니라는 정보를 https://github.com/WordPress/gutenberg/issues/4409#issuecomment -357912790 참조

@wpmark yes 해당 함수는 Gutenberg 플러그인에 의해 추가 된 모든 것을 제거하지만이 함수는 모든 백엔드가 아닌 특정 백엔드 페이지에서만 호출됩니다. 예를 들어 페이지에서 Gutenberg 편집기를 비활성화하기로 결정했지만 Posts .. 그래서 괜찮은 것 같아요.

베스트

@unCommonsTeam 훌륭한 플러그인처럼 보이지만 WordPress에 편집기를 다시 추가해야한다는 점에서 내 솔루션과 동일한 문제가 발생할 것이라고 생각합니다.

@pento 가 말한

@pento가 말했듯이 :

이 필터는 "블록 편집기를로드하지 않음"을 의미하며 "클래식 편집기 사용"을 의미하지 않습니다. 현재는 작동하지만 미래에 작동한다는 보장은 없습니다.

따라서 나는 당신의 플러그인이 위의 시도보다 똑같은 일을하고 있다고 생각합니다 (물론 수정 될 것입니다) (물론 훨씬 더 좋고 유연성을위한 많은 멋진 옵션 등).

나는 약이다 생각하고 또 다른 것은 (예를 들어 프로젝트를 핵심으로 병합됩니다 때 주위를 어슬렁 될 것 이름 구텐베르크, 또는 예를 들어 그 기능입니다 gutenberg_init (예)로 변경 될 것) block_editor_init

@wpmark 당신이 맞아요. 우리 는 WP 5에서 클래식 편집기를 그대로두기를

구텐베르크 이름이 맞습니다. 아마도 우리는 후크 이름을 대체하는 플러그인을 수정해야 할 것입니다.

또한 플러그인은 Gutenberg 편집기를 기반으로 한 다른 기능을 제공합니다 (특정 블록, 새 블록 등을 활성화 / 비활성화). 따라서 구텐베르크 편집기를 사용하는 사람들에게도 유용 할 것이라고 생각합니다.

건배

이것은 거의 모든 쟁탈전과 논쟁을 해결할 좋은 아이디어 일 수 있습니다.

구텐베르크가 기본적으로 비활성화 된 상태로 기본 편집기가 여전히 유지되는 경우, 최대 10 억 달러의 워드 프레스 테마 및 플러그인 시장과 엄청난 양의 인터넷을 절약 할 수 있으며 WP를 많이 절약하는 것과 함께 많은 문제, 금전적 손실, 지원 사건을 줄일 수 있습니다. 플랫폼으로서의 명성과 신뢰 상실의.

구텐베르크는 좀 더 현대적인 편집자이지만 WordPress.com 및 WordPress를 사용하여 블로깅 / 호스팅 서비스를 제공하는 유사한 아울렛의 필수품을 위해 제작 된 것 같습니다. 이것은 모두 좋고 좋습니다. 그러나 이것이 생태계의 나머지 부분에 충격과 공을 차게해서는 안됩니다. 방대한 인터넷, 사람들의 웹 사이트, 그들의 생계는 현재의 방향에 영향을받을 것입니다.

WordPress.com은 Gutenberg 기본 설정을 사용할 수 있지만 WP는 기본 설정이 해제되어 있으므로 전체 생태계에 최고의 세계를 제공합니다.

나는 코드 바에 동의해야한다. 구텐베르크는 기본적으로 비활성화되고 클래식 편집기는 계속 유지된다. 저는 현재 정확히 이런 이유로 자동 업데이트를 비활성화했습니다. 다중 사이트 네트워크의 블로거에게 갑자기이 "페이지 빌더"유형의 편집기가 표시되는 것을 원하지 않으며 클래식 편집기가 완전히 대체되는 것도 원하지 않습니다. 구텐베르크와 함께.

최소한 define ( 'DISABLE_GUTENBERG', true); 같은 정의 문으로 구텐베르크를 비활성화 할 수 있어야합니다. 구텐베르크를 비활성화하는 플러그인이있는 한 가지 큰 문제는 필요할 때 플러그인을 유지하고 업데이트하기 위해 개발자에게 의존한다는 것입니다. 개발자가 휴가 중이거나 플러그인을 업데이트하기에 너무 바빠서 플러그인이 작동하지 않는 며칠 또는 몇 주 동안 우리는 무엇을할까요? 플러그인을 사용하는 사람들이 플러그인을 업데이트해야하는 문제도 있습니다.

구텐베르크를 우리에게 강요 한 다음 나중에 그것을 비활성화하는 해결 방법을 찾는 것은 작업을 수행하는 정말 후진적인 방법입니다. 기본적으로 구텐베르크를 비활성화하십시오. 단순한 블로그를 원하는 많은 사람들은 웹 사이트 빌더로 발전하는 것처럼 보이기 때문에 워드 프레스를 사용하는 것이 점점 더 어려워지고 있습니다.

또 다른 참고 사항은 다중 사이트 네트워크의 경우 네트워크 관리자가 네트워크에서 구텐베르크를 사용할 수 있는지 여부를 결정할 수 있어야한다는 것입니다.

@WebTrooper 클래식 편집기 플러그인은 WordPress 개발자 팀 (Core를 유지하는 동일한 사람들)에서 유지 관리하고 Gutenberg Ramp 는 Automattic에서 유지 관리하므로 둘 다 "휴가중인 개발자"또는 "너무 바쁜"요인에 영향을받지 않아야합니다.

VIP는 고객 사이트와 자체 사이트에서 사용되는 Gutenberg Ramp 플러그인에 대한 약속을 가지고 있습니다. 휴가 중이거나 일이 망가 졌을 때 너무 바쁘다는 것은 VIP가 마지막으로 원하는 고객 사이트를 망가 뜨린 것을 의미 할 수 있습니다.

또한 이러한 플러그인은 분기 될 수 있으며, Automattic 및 작성자와 클래식 편집기 플러그인은 해당 플러그인을 빌드 할 수있는 비밀 지식이 없으며 기술적으로 크거나 복잡하지도 않습니다. 두 플러그인 중 하나를 유지 관리 할 수있는 개발자를 보유한 전 세계 수백 개의 에이전시가 있습니다.

제쳐두고, 많은 사람들이 기본적으로 구텐베르크를 비활성화한다고 주장하지만 이러한 주장의 장점에 관계없이 모두 정확히 GB가 기본적으로 켜져 있어야 할 때를 말하지 않습니다. 논리적 인 결론은 영원한 클래식 에디터 상황입니다.

2934 년, 은하계 제국이 300 척의 전투 순양함으로 뛰어 들었습니다. 지역 행성 뉴스 네트워크는 지역 주민들을 위해 보고서를 작성하기 위해 고전 편집자를 해고했습니다. 사이트 구축을 시작하기 전에 아무도 구텐베르크에 대해 말하지 않았습니다.

나는 항상 새로운 설치에 대해 기본적으로 켜져 있다고 제안했습니다.

그러나 기존 설치의 경우 사람들이 Gutenberg에 옵트 인하여 사용해보고, 마음에 들면 그대로 유지하고, 원하지 않으면 클래식 편집기로 되돌릴 수있는 사용자 주도 접근 방식을 제안합니다. 그런 다음 WordPress는 사람들이 변경 사항에 대한 개발 및 문서화를 돕기 위해 다시 전환 할 경우 통계와 피드백을 수집 할 수 있습니다.

활성화 된 활성 사이트의 일부 종류에 도달하면 기본적으로 활성화 할 수 있습니다. 그리고 아니, 나는 공중에서 숫자를 선택하지 않을 것입니다. 그러나 우리는 사용량을 측정하고 적절하게 행동 할 수 있습니다.

또는 2020 년 4 월 12 일이됩니다. 😉

이것은 이전 PHP 버전에서 발생합니다. 워드 프레스는 PHP 5.2의 이전 버전과의 호환성에 지칠 줄 모르고 있습니다. 많은 경우 사람들이 알지 못하거나 신경도 쓰지 않고 사용하기 때문입니다. WordPress는 통계를 신중하게 분석하고 있습니다. 호스트와의 조정에 많은 노력을 기울입니다. 업그레이드 경로로 사람들을 부드럽게 안내합니다. 그리고 아마도 프로젝트는 어느 시점에서 결정을 내리는 데 필요한 사용 데이터에 따라 행동 할 것입니다.

그러나 편집을위한 완전히 새로운 사용자 인터페이스를 사용하면 어떤 사용자가 접근 방식에 대해 알고 관심을 갖고 접근 방식을 강제하는 것입니까?

내가 실제로 구텐베르크를 옹호하기 시작하는 한, 어떤 경우에는 합병 제안이 최종 사용자를 위해 많은 사이트를 관리하는 저와 같이 IT 기술이 부족한 사람들의 우려를 진정으로 받아들이기를 바랍니다. 기술에 자신이 없으며 구텐베르크에 의해 혼란스럽고 방향 감각을 잃을 것입니다.

구텐베르크는 다음과 같은 중요한 이유 때문에 신규 설치도 중단해야한다고 생각합니다.

• 거의 무한한 양의 튜토리얼, 리소스, 방법 및 상상할 수있는 모든 것이 기존 편집기를 기반으로합니다. 이것은 사람들이 WordPress에 매우 쉽게 들어갈 수 있도록합니다.

• 이처럼 쉽게 시작할 수 있기 때문에 사람들은 'WordPress는 쉽다'는 것을 이해하고 플랫폼에 대한 따뜻한 인식, 더 많이 배우는 것에 대한 더 수용적이고 자신감있는 태도를 갖기 때문에 이러한 진입 용이성은 매우 중요합니다.

• 이 모든 것이 'WordPress는 작동합니다'라는 인식으로 결합되어 동료에게 편안하게 추천합니다. 이것이 우리가 인터넷의 30 %를 포함하도록 성장할 수 있었던 방법입니다.

• 정보의 일관성이 중요합니다. 그리고 인터넷상의 모든 리소스가 구텐베르크를 반영하도록 업데이트 될 방법은 없습니다. 심지어 미래에도 마찬가지입니다. 그것은 많은 혼란을 야기 할 것입니다. 그리고 가장 안타깝게도 일반 사용자의 반응은 '내가 설치했지만 작동하지 않습니다'라는 반응이 나올 것입니다. 왜냐하면 사용자는 작업 방법을 찾을 수없고 사용하는 자습서와 동일하지 않기 때문입니다. 실수하지 마십시오. 아무리 많은 업데이트 노력을해도 리소스, 튜토리얼 등에 관한 이러한 혼란을 해결할 수 없습니다.

따라서 구텐베르크는 테마, 기존 페이지 작성기 빌드 콘텐츠 플러그인 등의 측면에서뿐만 아니라 온라인에있는 리소스 측면에서도 '역 호환성'을 유지하기 위해 선택 사항이며 토글 가능해야합니다. 플랫폼은 '그렇게 쉬운'것이 아니고 구글이 다양한 구식 및 최신 리소스가 섞여있을 때 '그냥 설치하고 구글 ...'이라고 말하는 사람들에게 추천 할 수 없습니다. 그리고 SEO 경험이 있다면 그것이 될 것임을 알고 있습니다.

구텐베르크를 통해 우리는 떠오르는 '사이트 빌더'시장 (wix, squarespace 등)과 잠재적 인 '쉬운 블로그'시장 (a la medium 등)을 활용할 수 있습니다. 그러나 그렇게하면서 인터넷의 30 %의 일부 또는 10 억 달러 규모의 테마 / 플러그인 시장을 깰 경우 10 년 안에 회복 할 수없는 엄청난 양의 공이 될 것입니다.

고전적인 PHP 플러그인을 설치할 수 없기 때문에 PHP와의 비교는 관련이 없습니다. 이러한 문제를 해결할 수있는 WP 기반 솔루션이 없어서 중단 될 수있는 수백만 개의 사이트이므로 신중한 분석이 필요합니다. 또한 다음 릴리스에는 클래식 플러그인을 설치하라는 메시지가 표시되므로 사용자에게 Gutenberg 플러그인을 설치하라는 메시지 만 표시되지는 않습니다.

어느 쪽이든이 문제는 종결되었고 결정이 내려졌습니다. 닫힌 문제는 다른 곳에서 계획중인 접근 방식을 변경하려고 시도하기에는 좋지 않습니다.

그러나 Gutenberg 는 토글이 가능하며 활성화 및 비활성화를위한 플러그인이 있습니다. GB가 시작된 지 몇 년이 지났고 지금까지 테스트 할 시간, 클라이언트 교육 시간, 클래식 편집기 플러그인 설치 시간 등이 있습니다. 이것은 밤새 사람들에게 강요되는 새로운 일이 아닙니다.

나는 그 주장의 장점에 관계없이 모두 정확히 GB가 기본적으로 켜져 있어야 할 때를 말하지 않는다는 것을 알았습니다.

그리고, 그러한 주장을하는 사람들이 이것이 언제 일어나야할지에 대해 약간의 제안을했다고하더라도 어쨌든 그것은 기각 될 것 같습니다. 그렇다면 왜 그것을 제기합니까?

마감 된 티켓이 어떻게 작동하는지 알고 있습니다. 당신은 여기에서 꽤 비꼬는 소리를 냈습니다. 그래서 저는 건설적인 것을 제안하려고했습니다.

@tomjn 여기서 @rosswintle을 반향 는 기본적으로 새 설치에만 사용하도록 제안했습니다 -https://github.com/WordPress/gutenberg/issues/4423 . 이것은 또 다른 닫힌 문제로, 요점에 대한 실질적인 논의없이 종료되었습니다.

그들은 기꺼이 듣지 않고 플러그인이 있습니다. blah blah blah, 이것은 닫힙니다. 여기서 볼 수있는 것이 없습니다. .com에 대한 모든 것은 아무도 .org에 관심이 없습니다. Automatic에 대한 돈은 없습니다.

@ smp303 당신은 그들이 누구인지 식별 ​​해 주시겠습니까?

@rosswintle 비꼬는 의도는

그들은 기꺼이 듣지 않고 플러그인이 있습니다. blah blah blah, 이것은 닫힙니다. 여기서 볼 수있는 것이 없습니다. .com에 대한 모든 것은 아무도 .org에 관심이 없습니다. Automatic에 대한 돈은 없습니다.

동의해야합니다. 여기에 있든 WordPress 지원 포럼에 있든 커뮤니티의 많은 사람들이 이것에 반대하더라도 전혀 신경 쓰지 않는 것 같습니다. 워드 프레스는 오픈 소스이기 때문에 누구에게나이 문제에 대한 청원서를 작성하도록 제안하고 싶습니다. 개인적으로 GB는 코어에 병합하기보다는 Jetpack과 같은 플러그인이어야한다고 생각하고 제안합니다.

사이드 노트 : @karmatosed 구텐베르크에 관한 WordPress 포럼의 댓글 중 하나에서 내 질문에 답장하고 답할 수

이 스레드는 Gutenberg를 비활성화하는 코드 기반 옵션이없는 이유를 설명하는 것에서 벗어나 sockpuppet 계정의 묵시적 또는 노골적인 인신 공격으로 전환되었습니다.

일부 사람들이이 주제에 대해 매우 열정적이라고 느끼는 것에 감사하고,이 스레드가 이런 식으로 진행된 것은 유감이지만 결정은 바뀌지 않을 것입니다.

클래식 편집기 플러그인 은 전체 사이트에서 클래식 편집기로 되 돌리는 옵션입니다. 다가오는 WordPress 4.9.8 릴리스에서 WordPress 5.0을 준비하기 위해 지금 설치할 수있는 옵션으로 눈에 띄게 광고되고 있습니다.

클라이언트를 블록 편집기에서 제외하려는 사이트 빌더 인 경우 클래식 편집기 플러그인을 설치 (및 버그 보고서 또는 수정 사항에 기여 )하는 것이 클래식 편집기를 계속 사용할 수 있도록하는 최상의 장기 솔루션입니다.

메타 박스의 경우 이미 블록 편집기 를 gutenberg_can_edit_post_type 필터는 병합 될 때 이름이 변경되지만 (아마도 block_editor_can_edit_post_type 또는 해당 특성의 항목) 코드 기반 옵션으로도 사용할 수 있습니다.

이 스레드가 더 많이 퇴보하지 않도록 잠글 것입니다.

이 토론에 참여한 모든 사람은 구텐베르크가 WordPress 5.0을 준비하는 데 계속 참여하는 것을 환영합니다. 그러나 인신 공격은 절대로 환영하지 않으며 문제가 잠기거나 계정이 금지 될 수 있다는 점에 유의하십시오.