Gutenberg: 블록 추가 : 섹션

이 아이디어가 정말 마음에 듭니다! 나는 또한 배경 설정이 있다는 사실을 좋아합니다.

좋은! 차단이 다음 세 가지 '고급'설정을 허용하는 경우 :

• .child_class, .child_class_1 하위에 직렬화 할 클래스 이름을 정의하십시오.
• 선택적 첫 번째 하위 클래스 추가 .child_class, .child_class_1, .child_class_first
• 선택적인 마지막 하위 클래스 .child_class, .child_class_n, .child_class_last

:nth-child 선택자는 마지막 두 가지를 보완 할 수 있지만 모든 어린이에게 클래스를 추가하는 것이 특정 상황에서 유용 할 수 있다고 생각합니다.

이 아이디어를 사랑하십시오. 배경 및 텍스트 색상을 변경할 수있는 경우 링크 색상도 추가하는 것이 좋습니다.

훌륭한 아이디어. 이것은 말 그대로 Gutenberg Editor에 많은 가치를 추가합니다.

많은 문제가있는 Columns 블록보다 훨씬 낫습니다. 멋있는!

이것이 내가 네 스팅이 가능하다는 것을 알았을 때 처음으로 만든 것입니다. 내 버전은 열 블록을 추가 할 것이라고 생각한 것을 제외하고는 비슷합니다.

사용 가능한 코드가 있습니까?

이 블록에 "columns"가 있으면 "columns"블록 만 업데이트해야합니다. 그러나 섹션 블록 내에서 열 블록을 사용하고 섹션 블록을 열없이 유지하는 것은 여전히 ​​가능합니다.

열 블록 안에 열 블록을 넣을 수 없다면 😉

많은 사이트 페이지는 여러 행의 열과 종종 더 큰 열에 중첩 된 열이있는 혼합 콘텐츠가있는 섹션으로 나뉩니다. 다음은 간단한 예입니다.

베어 래퍼처럼 작동하는 섹션 블록이 가장 유연하다고 생각합니다. (열 블록을 중첩 할 수있는 것처럼!)

이번 주에 새로운 사이트 프로젝트를 시작했습니다. 일반적으로 고급 사용자 정의 필드의 유연한 콘텐츠 레이아웃으로 빌드되지만 구텐베르그 만 사용하여 얼마나 멀리 얻을 수 있는지 알아 보겠습니다.

예, 위의 @jvisick 예제와 같은 다중 열 섹션이

이 블록에 모든 자식 블록을 포함하는 내부 컨테이너 (div)가 있으면 좋을 것입니다. 이 컨테이너는 max-width 및 margin-left / right : auto로 스타일을 지정하여 자식 블록을 중앙에 배치하고 전체 너비 배경을 가질 수 있습니다.

더 좁은 레이아웃에 콘텐츠가 포함 된 전체 너비 섹션을 갖는 것이 일반적인 디자인 패턴입니다. 부모 섹션 블록에 구워지지 않고 중첩 된 블록에 의해 제어되는 것이 가장 좋을지 궁금합니다.

섹션 블록은 페이지의 섹션에 매우 유용 할 것이라고 생각하며 열은 섹션 블록에 중첩 될 수있는 별도의 블록 (현재 존재하는 것과 같은)이어야한다는 데 동의합니다. 이것은 Columns 블록과 함께 WordPress 5.0에 병합 된 Gutenberg 버전에 포함되어야한다고 생각합니다. 기존 페이지 빌더 플러그인을 살펴보면 섹션과 열 (분명히)이 많이 사용되므로 초기 코어 릴리스에 섹션을 포함하는 것이 제 생각에 필수적입니다.

(또한 열 블록이 가변 너비 열 및 반응 형 열과 같은 기능을 가져 오는 것이 중요하다고 생각합니다. 핵심 경험을 위해뿐만 아니라 기존 페이지 빌더가 구텐베르크에서 스스로를 쉽게 재조정 할 수 있도록하는 것입니다. 그것은 별도의 문제입니다.)

그것에 대해 좀 더 생각해 보면 Section과 Columns 블록이 같은 것을 갖는 것이 더 합리적이라고 생각합니다. 열 블록에 최소 두 개가 아닌 하나의 열만있는 기능 만 추가하면됩니다. 그런 다음이 제안 된 섹션 블록의 배경 설정을 열 블록에 추가합니다.

단일 Section / Columns 블록을 사용하면 수행해야하는 중첩의 양을 줄일 수 있다고 생각합니다. 현재 제안 된 섹션 블록은 실제로 배경 및 너비 옵션이있는 영역에 지나지 않습니다. 둘 다 Columns 블록에 추가 할 수 있으며 Columns 블록이 단 하나의 열만 가질 수 있도록 허용하면 Section 블록이 필요하지 않습니다.

또한 표준 너비 콘텐츠가있는 전체 너비 섹션을 원하는 경우 다른 섹션 / 열 블록을 전체 너비로 설정된 다른 블록에 중첩하여 수행 할 수 있습니다. 전체 블록의 너비에 관계없이 블록 내용 너비를 변경하도록 검사기의 설정으로 수행 할 수 있습니다.; 이것은 Beaver Builder 행 / 열이 작동하는 방식 또는 Gutenberg에서 이미지 블록이 작동하는 방식과 유사한 가시적 크기 조정 핸들로 추가 될 수도 있습니다.

이 결합 된 블록은 사람들이 찾는 가장 명백한 기능이기 때문에 "열"이라는 이름을 유지하는 것이 효과가 있다고 생각합니다. 인스펙터에서 배경 설정을 찾는 것이 어렵지 않아야합니다 (그리고 별도의 섹션 블록이 있고 인식하지 못한 경우 일부 사람들이 처음부터 볼 것이라고 상상합니다). 열 수를 변경하는 슬라이더를 사용하면 작업 방법을 명확하게 알 수 있기 때문에 단일 열 컨테이너로 블록을 찾기가 어렵지 않아야합니다. 왼쪽 끝까지 드래그하면됩니다.

섹션 및 열 블록 병합에 대한 마음이 바뀌 었습니다. 열을 최대한 유연하게 사용하려면 각 열이 고유 한 블록 인 열 블록이되도록하는 것이 가장 합리적입니다. 이렇게하면 개별 열의 설정을 쉽게 제어 할 수있을뿐만 아니라 한 행에서 다른 행으로 열을 끌 수 있습니다. 물론 열이 왼쪽에서 오른쪽으로 이동하기 때문에 (대부분의 레이아웃 시스템에서 줄 바꿈) 해당 부모 블록이 해당 수평 방향으로 콘텐츠를 삽입하고 줄 바꿈 (표준 수직 방향이 아님)이있는 블록이어야합니다. 부모 블록은 열 블록 만 삽입 할 수 있습니다. 이 블록은 행이됩니다. 이 두 블록은 Columns 블록을 대체합니다. 그러나 여러 행 (종종 내부에 다른 수의 열이 있음)이 동일한 배경 / 컨테이너에 있기를 원하는 상황은 다루지 않습니다. 이는 Section 블록이 수행하는 작업입니다. 물론 Section 블록은 배경, 패딩, 너비 옵션이있는 컨테이너에 지나지 않으며 모든 블록을 삽입 할 수 있습니다. 더 복잡한 레이아웃의 경우 단면 블록을 기둥 블록에 삽입 할 수 있습니다.

# 6461을 참조하십시오.

실제로 최소 1 개의 열 아이디어가 나쁜 해결책이 아니라고 생각합니다. 사실, 관리자를 사용하여 슬라이더의 "min"속성을 1로 변경하고 하나를 선택하면 예상대로 작동합니다.

그러나 의미 상 섹션 블록은 어쨌든 더 의미가 있습니다. 내부 콘텐츠 (즉, 전체 포함 섹션 내의 최대 너비 섹션)는 두 섹션, 즉 전체 너비 내부의 콘텐츠 너비를 중첩하여 얻을 수 있습니다.

배경색 아이디어는 좋지만 ... 약간 구체적 일 수 있습니다. 좀 더 일반적인 접근 방식은 섹션에서 사용자 지정 클래스를 사용하는 것입니다. 프론트 엔드 CSS는 그것과 모든 자식을 직접 잡을 수 있습니다.

# 6461에서 약간의 논의를 거친 후, 내 행 블록 + 열 블록 아이디어가 올바른 방법이 아니라고 결정했습니다. # 5351 (주석)에 있는 것과 유사한 레이아웃 블록은 아마도 훨씬 덜 혼란스럽고 훨씬 더 유연 할 것입니다. 어떤 경우이든 섹션 블록이 있어야하며 WordPress 5.0 릴리스 전에 반드시 추가해야한다고 생각합니다.

배경색 옵션은 섹션에 배경 옵션이있는 것이 완벽하다고 생각합니다. 클래스 옵션 만있는 것은 약간 제한적인 것 같습니다. 종종 섹션 블록에서 중첩의 전체 포인트는 여러 항목이 배경을 공유하는 것입니다. 또한 일반 단색 배경 대신 종종 원하는 배경 이미지 및 그라데이션 배경과 같은 다른 배경 옵션이 구현 된 경우 선호합니다. 중첩 된 섹션 블록을 사용하면 단일 블록에 배경색을 적용 할 수도 있습니다. 즉, 단락 블록의 배경색 옵션이 더 이상 필요하지 않을 수 있습니다.

2 개의 개별 너비 설정 대신 섹션 블록을 중첩하는 경우 작동 할 수 있다고 생각합니다. 내가 가질 수있는 가장 큰 관심사는 섹션 블록을 중첩하여 추가되는 추가 패딩의 양에 대한 것이며, 이는 패딩 옵션으로 이어집니다.

섹션 블록이 사용하는 패딩의 양을 사용자 정의하거나 최소한 기본 패딩을 제거하는 기능이 있어야한다고 생각합니다. 물론 이것은 다른 블록이 중첩 될 때 Section 블록을 선택하는 방법에 대한 질문을 제기합니다. 이 문제는 # 6471과 같은 개선과 try/alternate-hover-approach 지점에서 작업중인 항목으로 해결 될 것이라고 생각합니다.

: +1 :

특히 너비 설정이있는 일반적인 행 / 컨테이너 블록이 필요합니다.

이상적으로는 "배경색"및 "텍스트 색상"과 같은 다른 설정이 모든 블록의 "추가"설정 탭 아래에 있어야한다고 생각합니다 (일반적으로 적용 할 수있는 여러 CSS 설정에 추가).

응답성에 관해서 는 "Responsive"블록을 추가 해야한다고 생각합니다.

배경색과 텍스트 색상의 문제는 간단합니다. 어디에서 끝날까요? 이미이 스레드에만 링크 색상을 제안하는 사람이 있습니다. 테두리 색상, 두께 및 스타일은 어떻습니까? 솔직히 말해서 패딩과 여백이 가장 의미가 있습니다. 그림자, 배경 이미지, 위치 옵션 및 디스플레이 모드는 어떻습니까? 글꼴 스타일 및 크기, 줄 높이 및 최소 높이? 수백 개의 CSS 속성이 있으며 필요한 속성은 디자인에 따라 다릅니다.

하위 요소를 포함한 모든 항목의 스타일을 지정하는 데 사용할 수있는 클래스이거나 테마 div가 원하는 항목을 연결하고 추가 할 수 있도록 필터링 가능한 CSS 속성 목록이어야합니다.

@tmdesigned 웹 페이지의 스타일, 서식 및 레이아웃에 대한 기능이 완벽하고 직관적 인 WYSYWIG 제어로 끝납니다. 이것이 구텐베르크의 목표가 아닙니까?

구텐베르크는 신선하고 잘 계획된 최첨단의 템플릿 화 가능하며 확장 가능한 웹 콘텐츠 WYSYWIG를 세상에 제공하고 있습니다 ... 우리는 지금 그것을 얼마나 활용하고 싶은지 알아 내야합니다. 그렇지 않으면 배를 놓칠 것입니다.

결국 아이디어는 CSS 작성이든, 엉뚱한 CSS 오버라이드 작성이든, 반복적 인 콘텐츠 작업이든 우리가 지금하고있는 작업량을 줄이는 것입니다.

모든 것이 클래스로 정의 될 수 있거나 정의되어야하는 것은 아닙니다. 특히 대상이 잘못 지정된 클래스이거나 재정의 할 수없는 속성 인 경우에는 더욱 그렇습니다.

예를 들어 사용자 정의 숫자 설정을 사용하십시오. 각 값에 대해 클래스를 정의하는 것은 고통스럽고 블록 개발자는 값을 style 속성에 직접 주입하려는 유혹을받을 수 있습니다.

블록으로 존재하고 사용자 정의 CSS 스타일을 적용 할 수있는 경우 키 / 값 쌍 텍스트 상자의 패널이더라도이를 수행하기위한 통합 및 표준화 된 수단이 있어야합니다.

원하는 경우 우려 사항을 해결하는 방식으로이 작업을 수행 하기 위해 읽을 수 있습니다.

API에 대한 귀하의 제안을 읽었으며 키 값 쌍을 추가 할 수 있도록 추가 된 후크에 대해 제가 말한 것과 멀지 않았습니다.

그러나 내 원래 요점은 여전히 ​​유효하다고 생각합니다. 내가 말했듯이 수백 개의 속성이 있으며 일부는 더 일반적이지만 이러한 목록은 빠르게 증가 할 것입니다. 우리는 그 길을 가고, Classic에 포함되거나 제거 된 TinyMCE 기능과 같은 "좋은 타협"을 찾으려고 노력할 수 있습니다. 그러나 여기에는 훨씬 더 많은 속성이 있으므로 도전이 될 것입니다.

그러나 더 중요한 것은 직접 블록 수준 스타일을 추가하는 아이디어는 축소하면 단일 블록을 고려하지 않고 깨집니다. 한 페이지 또는 여러 페이지에 유사한 블록이 여러 개있는 경우 해당 값을 모두 다시 입력하고 싶지는 않을 것입니다. CSS 클래스와 같은 추상화를 원할 것입니다.

개별 블록 수준 스타일링을 허용하거나 권장하는 것은 재사용 할 수 없기 때문에 이상적이지 않습니다. 모든 것이 클래스로 추상화되어야하는 것은 아니지만 CSS는 이유 때문에 개발되었으며 그렇게 빨리 바람에 던져서는 안된다고 말하는 것이 옳습니다.

@tmdesigned 귀하의 의견에 감사드립니다. 혼란을 이해 한 것 같아 명확히하겠습니다.

목표는 CSS 클래스의 양을 제거하거나 줄이는 것이 아닙니다.

특히 목표는 사용자 정의 블록 스타일 설정을 단일 UI 또는 최소 단일 API로 통합하는 것입니다.

웹 개발자, 블록 개발자, 테마 개발자는 모두 스타일 블록에 CSS 코드를 작성하고 블록에는 여전히 클래스, 속성 및 ID가 있으므로 개발자가 스타일을 지정할 수 있습니다.

그들은 지금과 똑같은 클래스를 갖게 될 것이고 지금과 똑같은 레이아웃을 갖게 될 것입니다.

그러나

블록 개발자가 사용자 가 구성 할 수있는 / 구성해야하는 CSS 속성이 있다는 것을 깨닫는 순간 ... 그때 Gutenberg가 이러한 스타일이 주입되고 잠재적으로 제어되는 방식을 인수하고 결정합니다.

이것은 웹 페이지 콘텐츠의 일반적인 스타일 기반 구성을 비 프로그래밍 방식으로 제어 할 때 단일 공통 인터페이스 (개발자와 사용자 모두)를 생성합니다.

이를 통해 사용자와 개발자 모두 블록 스타일을보고, 추가하고, 제거하고, 수정하고, 재정의 할 수있는 일관된 단일 수단을 제공하며, 결국에는 모두 단순한 CSS 속성으로 귀결됩니다.

이 스레드에 너무 많은 소음을 일으켜 죄송합니다. 관련 문제에 대해 더 논의해야 할 것 같습니다.

메모 편집 :

추상화에 대한 요점을 언급하는 것을 잊었습니다.

사용자가 똑같은 스타일을 똑같은 블록에 두 번 적용해야하는 순간은 CSS 클래스 (해당 블록에 대해)에 대해 사용자 정의 스타일 설정 을 포기

다시 말해, 사용자 정의 스타일 설정은 사용자가 블록을 고유 한 일회성 (정상적으로)이든 매 페이지마다 100 번이든 원하는대로 블록을 사용자 정의 할 수있는 일관된 메커니즘을 제공하며 구조화 방법을 선택합니다. 그것은 여전히 ​​전적으로 당신에게 달려 있습니다.

나는 우리가 대부분 동의한다고 생각합니다. 첫 번째 게시물에서 내 제안은 컨트롤을 추가 / 제거하는 후크를 갖는 것입니다. 블록 수준의 스타일 사용자 지정에 반대하는 것이 아니라, 목록이 기하 급수적으로 증가하지 않고 "일반 섹션 블록에서 기본적으로 가질 가치가있는 항목"을 선택하기가 어렵습니다. 특히 다른 컨트롤을 추가 할 수있는 경우 최소한 몇 개만 있으면 좋습니다. 어쨌든 나는 여백과 패딩이 섹션 블록의 배경색보다 보편적으로 도움이되지 않는다는 것에 놀랐습니다.

FWIW, 생성 된 클래스가 출력이되는 아이디어가 마음에 들기 때문에! important를 사용하지 않고도 여전히 재정의 할 수 있습니다.

@rchipka @tmdesigned 저는 이것이 2 주 전이

이전 대화를 기반으로이 블록을 다시 살펴 보았습니다.

내 아이디어를 공유하는 가장 쉬운 방법은 프로토 타입을 사용하는 것입니다. https://wp.invisionapp.com/share/PQJPPAX4JZW

몇 가지 참고 사항 :

• 빠른 설문 조사에 따르면 https://wordpress.slack.com/archives/C02QB2JS7/p1527283199000343 이름을 _Section_에서 _Container_로 변경했습니다.
• @jvisick에 의해 설명 된 것처럼 사람들이 특정 섹션 내에서 열 레이아웃을 혼합하여 일치시키고 싶어하는 것이 합리적이므로 열 설정을 제거했습니다.
• 배경색 외에도 배경 이미지 지원을 추가했습니다. 설정은 Core의 기존 배경 이미지 기능을 기반으로합니다.
• 사람들이 컨테이너 블록에 컨테이너 블록을 중첩시킬 수 있도록해야합니까?

@melchoyce 멋지네요 !

제가보고 싶은 멋진 기능 중 하나는 검사기에서 블록의 HTML 요소를 <aside> , <div> 및 <section> 입니다.

제 생각에는 컨테이너를 중첩하는 기능은 확실히 허용되어야합니다. 위에서 제안한 HTML 요소 제안을 사용하여 단일 의미 섹션 내에서 다른 색상 영역을 갖는 컨텍스트에서 유용 할뿐만 아니라 단일 블록에 배경이없는 경우 배경을 제공하려는 상황에서도 유용합니다. 배경색 옵션 자체.

또 다른 멋진 기능은 그라데이션 배경입니다. 일부 디자인에서는 꽤 인기가있는 것 같습니다.

@melchoyce +1은 컨테이너를 중첩 할 수 있습니다.

@SuperGeniusZeb 는 HTML 요소를 변경할 수 있다는

@jvisick 예, 그게 제가 생각했던 것입니다. Beaver Builder와 Elementor는 모두 행 / 섹션에 대해 이와 같은 설정을 가지고 있습니다.

@melchoyce 컨테이너는 무한히 중첩 될 수 있어야한다고 생각합니다. 이를 통해 사용자는 다른 컨테이너를 포함하여 모든 블록 주위에 사용자 정의 클래스 (또는 사용자 정의 CSS)를 래핑 할 수 있습니다.

일반 컨테이너 블록에 중첩 제한을 추가 할 이유가 없습니다.

시맨틱 HTML 요소의 가치를 이해하지만, 고급 사용자를위한 옵션으로 사용할 수 있도록 해당 기능을 플러그인에 위임하는 방법이 있는지도 궁금합니다.하지만 일반 사용자는 이에 대해 생각할 필요가 없습니다. 추가하는 순간, 기능을 제공 할뿐만 아니라 사용자에게 의미 론적 의미에 대해 교육하는 책임이 있습니다. 이는 종종 상황에 따라 달라집니다.

@chriskmnds 좋은 지적입니다. 나는 이것이 컨테이너 태그를 설정하는 잘못된 장소라고 생각합니다.

컨테이너 블록은 의미 론적 의미없이 일반 컨테이너로 작동해야합니다.

의미 론적 의미는 (향후) 블록 템플릿 기능에 의해 제공되어야합니다. 그래야 <aside> 콘텐츠가 템플릿의 한 부분이되고 <section> 다른 부분이 될 수 있습니다.

이러한 방식으로 사용자는 의미 론적 의미에 영향을주지 않고 원하는대로 (모든 깊이 수준에서) 컨테이너에서 콘텐츠를 구성 할 수 있습니다.

나는 HTML 요소를 교체 할 수있는 것이 대부분의 사람들에게 약간 진보 된 것처럼 보이며 아마도 기본 Gutenberg 설정에 속하지 않는다는 데 동의합니다.

의미 론적 의미는 (향후) 블록 템플릿 기능에 의해 제공되어야합니다. 그래야 <aside> 콘텐츠가 템플릿의 한 부분이되고 <section> 다른 부분이 될 수 있습니다.

이것은 확실히 탐험하기에 좋을 것입니다.

기본 UX를 단순하게 유지하기위한 요점에 동의하지 않지만 <section> , <nav> , <header> 등을 어디에 추가 하시겠습니까? 본질적으로 래퍼 요소 인 일반 컨테이너 블록은 자연스러운 선택처럼 보입니다. 이러한 경우 각각에 대해 중복 블록보다 선호 될 수 있습니다. 기본값은 <div> 있으며 사용자는 필요하지 않는 한 설정을 터치 할 필요가 없습니다.

HTML 요소에 대한 옵션이 테마 또는 플러그인에서 지원되는 요소의 배열을 설정할 수있는 alignwide / full 설정과 유사하게 작동하면 어떻게됩니까?

@jvisick 이상적으로 이러한 래핑 요소는 페이지 / 포스트의 "블록 레이아웃 템플릿"으로 생성됩니다.

블록 레이아웃 템플릿을 사용하여 여러 기본 컨테이너 블록을 설정하고 컨테이너 블록의 생성 된 태그 이름이 무엇인지에 대한 설정 (코드에서)을 제공 할 수 있습니다.

@rchipka 사용자에게 콘텐츠 관리를위한 사전 정의 된 영역을 제공하는 레이아웃 템플릿을 사용하여 어디에서

즉, 컨테이너 블록의 초기 실행에는 HTML 요소 설정이 필요하지 않다는 @melchoyce에 동의하지만 다음 '페이지 빌더'단계에서 살펴볼 가치가 있다고 생각합니다.

섹션은 기본적으로 1 열입니다. 음, 열입니다.

3.0.0 Columns (베타) 블록은 슬라이더에 1 열을 허용하지 않습니다.

열 블록 만 사용하고 이러한 구현을 결합하는 것이 더 나은지 확실하지 않습니다. 단점은 무엇입니까?

추가하기 좋은 한 가지는 컨테이너 (섹션)가 전체 너비 여야하는지 아니면 포함되어야하는지 여부를 토글하는 것입니다. 포함 된 경우 테마 (# 5650)에 설정된 content_width 준수해야하며, 그렇지 않으면 전체 너비 여야합니다. 대부분의 페이지 빌더가이 기능을 가지고 있다고 생각합니다.

네, 저의 마지막 모형의 빠른 도구 모음에 포함되어 있습니다.

@melchoyce 섹션 / 컨테이너 블록 자체는 전체 너비 여야하지만 섹션 / 컨테이너 블록 내부의 내용은 그렇지 않아야하는 상황이 있음을 명심하십시오. 이것은 어떻게 처리됩니까?

기본적으로 컨테이너 자체가 전체 너비가 될 수 있다고 생각했지만 기본적으로 전체 너비를 지원하지 않는 모든 콘텐츠 (이미지 / 커버 블록 등)는 여전히 편집기 너비로 제한됩니다.

@melchoyce 내가 올바르게 이해했다고 가정하면 컨테이너 블록의 너비 제어가 컨테이너의 배경에만 영향을 미치고 콘텐츠에는 영향을 미치지 않는다는 의미입니까? 말이 되네요. 명확히 해주셔서 감사합니다. : +1 :

그래, 그게 내가 생각하는거야!

논의되었는지 확실하지 않지만 섹션은 "섹션"HTML 요소가 될 수 있고 "기사", "div"또는 다른 것이 될 수도 있습니다. 맞습니까? 선택할 수 있으면 좋을 것 같습니다
이것은 또한 "행"블록을 불필요하게 만들 수 있습니다.

플러그인에서 구현

var el = wp.element.createElement,
    registerBlockType = wp.blocks.registerBlockType,
    InnerBlocks = wp.editor.InnerBlocks;

registerBlockType( 'nbrummerstedt/section', {
    title: 'Section',
    icon: 'universal-access-alt',
    category: 'layout',
    attributes: {},
    edit: function( props ) {   
        return el( 'section', {className: props.className},
            el( InnerBlocks )
        );
    },
    save: function( props ) {
        return el( 'section', {className: props.className }, 
            el( InnerBlocks.Content )
        );
    }
} );

@eddr 이것은 논의되었습니다 : https://github.com/WordPress/gutenberg/issues/4900#issuecomment -392925877

여전히 사용 된 HTML 태그를 선택하는 드롭 다운이 좋은 생각이라고 생각합니다. 너무 유사한 블록을 만들지 않고 <aside> 및 <section> 와 같은 의미 론적 HTML 요소를 통합하는 가장 쉬운 방법 인 것 같습니다.

@nbrummerstedt 초기 기본 구현은 이제 컨테이너 블록이라고하며 요소로 <div> 를 사용해야합니다. 이상적으로는 (위와 이전 주석에서 언급했듯이) HTML을 변경할 수 있습니다. <div> 에서 <section> , <aside> 및 <article> 입니다.

다음은 구현의 수정 된 버전입니다.

( ( blocks, editor, element ) => {
    const el = element.createElement,
        { registerBlockType } = blocks,
        { InnerBlocks } = editor;

    registerBlockType( 'nbrummerstedt/container', {
        title: 'Container',
        icon: 'universal-access-alt',
        category: 'layout',
        attributes: {},
        edit: ( props ) => {    
            return el( 'div', {className: props.className},
                el( InnerBlocks )
            );
        },
        save: ( props ) => {
            return el( 'div', {className: props.className }, 
                el( InnerBlocks.Content )
            );
        }
    } );
} )( window.wp.blocks, window.wp.editor, window.wp.element );

이것이 WordPress 5.0 마일스톤 @mtias에서 제거 된 이유는 무엇입니까? 이것은 단순히 그것이 얼마나 유용하고 단순하기 때문에 초기 릴리스에 포함되어야 할 것 같습니다. 많은 블록에는 컨테이너 블록을 사용한다고 가정했기 때문에 배경 설정이 없습니다. 이 블록을 구현하는 것도 그렇게 어렵지 않습니까? 왜 이것이 WordPress 5.0 이후 릴리스로 푸시되어야하는지 모르겠습니다.

또 다른 메모에서, 저는 최근에 Oxygen을 확인하고 있었고 Flexbox 기반 레이아웃 시스템에 깊은 인상을 받았습니다. 컨테이너 블록이 이러한 기능 중 일부를 구현하면 어떻게됩니까? 정말 강력하고 Columns 블록 이외의 레이아웃을 가질 수있는 대체 방법을 제공 할 수 있다고 확신합니다. 어쩌면 Columns 블록을 불필요하게 만들 수도 있습니까?

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

나는 이것을 확인하는 것이 좋습니다. 사실 저는 산소를 완전히 살펴 보는 것이 좋습니다. 다른 모든 페이지 빌더 플러그인과는 매우 다르며 구텐베르크가 사용할 수있는 좋은 아이디어가 많이 있다고 생각합니다.

나는 확실히 동의합니다. 이것은 5.0 릴리스에 있어야하며 열 블록을 사용하는 해키 솔루션을 피하기 위해 컨테이너가 필요합니다.

이 블록은 조만간 사용 가능해야한다고 생각합니다. 많은 WordPress 개발 대행사가 Gutenberg와 함께 구축하기 전에이 블록을 기다리고 있습니다.

@ dingo-d 및 @ericvalois 예, 반응 형 열, 너비가 같지 않은 열 및 컨테이너 블록의 세 가지가 부족하기 때문에 블로그 게시물 외에는 구텐베르크를 사용하지 않았습니다.

산소가하는 일을 채택한 컨테이너 블록에 대해 앞서 말한 내용을 자세히 설명하기 위해 컨테이너 블록이 중첩 된 블록의 흐름 방향을 기본 수직에서 수평으로 변경할 수있는 옵션이있을 수 있다고 생각합니다. 산소가 가지고있는 것과 같은 수직 및 수평 정렬 옵션이있을 수도 있습니다. 특히 대부분의 페이지 빌더 플러그인이 허용하는 것과 같이 반응 적으로 이러한 옵션을 변경하는 기능과 결합되면 특히 강력합니다.

물론 Flexbox 기반 정렬 / 레이아웃을 사용하는 컨테이너 블록은 부동 정렬 블록이 그 안에 직접 중첩되는 것을 허용하지 않는다는 주목할만한 문제가 있습니다. 하지만 이에 대한 간단한 해결책이 있다고 생각합니다. 컨테이너가 표준 CSS display: block 레이아웃 또는 Flexbox 레이아웃을 사용하도록하는 기능을 추가합니다. 표준 display: block 모드는 루트 문서가 사용하는 것이기 때문에 기본값이됩니다. Flexbox 디스플레이 모드를 활성화하면 모든 깔끔한 정렬 옵션이 인스펙터에 나타납니다. 또한,보다 사용자 친화적으로 만들기 위해 검사기에서 2 개의 레이아웃 모드에 다른 이름을 지정하고 싶을 것입니다. 하지만 당신이 그들을 무엇이라고 부를지 모르겠습니다. "표준"과 "유연"일까요?

컨테이너 블록이 플로트를 지원하는 모드 또는 더 나은 정렬 / 레이아웃 옵션이있는 모드를 사용하도록 허용하면 정말 유용 할 것입니다. 컨테이너 블록을 중첩하여 필요한 경우 두 종류의 레이아웃을 모두 사용할 수 있습니다. 이를 컨테이너 블록이 가질 수있는 다른 기능에 추가하면 (배경 옵션, 사용자 정의 HTML 블록에 의존하지 않고 의미 론적 의미를 추가하기 위해 HTML 태그를 선택할 수있는 기능 등) 컨테이너 블록이 가장 중요한 기능 중 하나가됩니다. 핵심 WordPress의 유용한 블록.

특히 두 개의 레이아웃 모드가있는 컨테이너 블록이 너무 많은 기능처럼 들리면 (실제로 문제가되지 않을 것 같음) 두 개의 개별 블록이있을 수 있습니다.

• 플로트를 지원하지만 모든 고급 정렬 / 레이아웃 옵션이없는 표준 컨테이너 블록
• Flexbox 레이아웃을 사용하고 모든 깔끔한 옵션을 제공하는 고급 컨테이너 (또는 고급 레이아웃 또는 유연한 레이아웃 또는 사용자가 부르는 모든 것) 블록

이 Oxygen 문서화 비디오를 확인하여 레이아웃 시스템이 어떻게 작동하는지 확인하는 것이 좋습니다. 정말 인상적입니다.

https://www.youtube.com/watch?v=NnSfR-YFcQI

저는 여기에 구텐베르크를 매우 강력 하게 만들 많은 잠재력이 있다고 생각합니다. 물론 초기 구현의 경우 컨테이너 블록에 백그라운드 옵션, 사용 된 HTML 요소를 변경하는 기능 및 컨테이너를 전체 너비로 만드는 옵션 만있을 것으로 예상합니다 (컨테이너 내부의 콘텐츠는 아님). 어쩌면 배경 옵션 일 수도 있습니다.

실제로 옵션이없는 컨테이너 블록 만 있으면 CSS를 통해 블록 그룹의 스타일을 쉽게 지정할 수 있으므로 여전히 유용합니다.

구텐베르크에 대해 5.0 이후 중단하는 것뿐만 아니라 생각하는 것이 중요합니다. 이것은 정말 유용한 블록이며 살펴 보 겠지만 1 단계에서는 편집에 집중할 필요가 없습니다. 프로젝트가 단순한 편집을 넘어 레이아웃으로 확장 될 때 솔루션이 필요하다는 것은 의심의 여지가 없습니다. 아무도 이것이 만들어지지 않을 것이라고 말하지 않습니다. 그것은 편집자가 무엇인지, 그리고 2 단계로 들어가는 것에 우선 순위를 두는 문제입니다.

그러나 문제는 대부분의 사람들이 게시물 작성이 아닌 레이아웃 목적으로 구텐베르크를 사용하고 있다는 것입니다.

사람들은 단어 문서와 같은 게시물을 작성하는 데 익숙하므로 게시물 페이지에서 구텐베르크를 비활성화하고 있습니다.

그러나 문제는 대부분의 사람들이 게시물 작성이 아닌 레이아웃 목적으로 구텐베르크를 사용하고 있다는 것입니다.

이 가정의 기반이되는 데이터 소스는 무엇입니까?

나는 베오그라드의 WCEU에서 여러 사람들과 이야기를 나눴습니다. 그들은 모두 Gutenberg에 게시물을 작성하는 것이 이상하다고 생각하고 Posts에서 그것을 비활성화하고 있습니다.

@ dingo-d가 본 것과는 달리 저는 게시물에 구텐베르크 만 사용합니다. 사실 저는 구텐베르크에서 클래식 에디터보다 포스트 메이킹 경험이 훨씬 더 좋습니다. 부분적으로는 더 모듈화 된 성격과 상황에 맞는 컨트롤 때문이고 부분적으로는 더 이상 보이지 않는 <p> 태그가 어디에나 삽입되지 않았기 때문입니다. 그것은 항상 나를 짜증나게했다.

Gutenberg를 페이지 구축에 사용하려면 컨테이너 블록 (옵션이없는 블록이라도)과 적절한 열 블록 (또는 다른 레이아웃 블록)이 필요합니다. Columns 블록이 일종의 기본 응답 성을 갖게 될 것 같습니다 (# 6048 참조). 따라서 더 많은 컨텍스트에서 Gutenberg를 사용하는 것을 차단하는 컨테이너 블록이 부족하다는 의미입니다.

컨테이너 블록이 분명히 어느 시점에 추가 될 것이라는 것을 알고 있지만 (아마도 WordPress 5.1보다 늦지 않을 것입니다), WordPress 5.0이 나오기 전에 추가해야한다고 강력하게 믿습니다. 게시물 작성의 맥락에서도 컨테이너는 의미를 추가하기 위해 <aside> (HTML 요소 선택 드롭 다운 기능이있는 경우)와 같은 것에 유용 할 수 있습니다. 지금 당장은 의미를 추가하기 위해 다른 HTML 요소에 내용을 래핑하려면 사용자 정의 HTML 블록을 사용해야합니다. 즉, 해당 사용자 정의 HTML 블록의 단락에 대해 단락 블록의 기능을 활용할 수 없습니다. 해당 사용자 정의 HTML 블록의 이미지에 대한 이미지 블록의 모든 기능 등

뿡 빵뀨

아무도 이것이 만들어지지 않을 것이라고 말하지 않습니다. 그것은 편집자가 무엇인지, 그리고 2 단계로 들어가는 것에 우선 순위를 두는 문제입니다.

제 생각에는 컨테이너 블록은 절대적으로 1 단계에 속하는 것입니다.

이상한 점은 Columns 블록이 WordPress 5.0에 들어갈 수있는 것처럼 보인다는 것입니다 (아마도 "(Beta)"레이블이있을 수 있지만 컨테이너 블록은 그렇지 않을 수 있습니다.) 지금 초점이 글쓰기에 있어야하는 경우 Posts, 그렇다면 왜 Columns 블록은 추가되었지만 Container 블록은 없습니까? 내 생각에 Container 블록은 Columns 블록보다 게시물 컨텍스트에서 훨씬 더 유용합니다. 물론, 그것은 또한 많은 이점을 가지고 있습니다. 페이지 구축의 맥락.

컨테이너 블록이 WordPress 5.0에 포함되지 않으면 5.1까지 나오지 않아 대부분의 사람들이 몇 달 동안 사용할 수 없게됩니다. 구텐베르크가 성공하기를 바라며, WordPress 5.1까지 컨테이너 블록과 같은 기본적인 것의 출시를 보류 할 이유가 없다고 생각합니다. 좋은 첫인상을 위해 WordPress 4.9.8 콜 아웃 전에 추가하는 것이 좋습니다.

사람들이 제안한 모든 기능이있을 것으로 기대하지는 않습니다. 그 단순한 존재만으로도 열 슬라이더를 수동으로 1로 설정 한 열 블록을 사용하는 다소 엉뚱한 솔루션을 제외하고는 현재 다루지 않는 많은 일반적인 사용 사례를 해결할 수 있습니다. 그런 다음 배경색 옵션과 같은 옵션 하나만 있으면됩니다. 훨씬 더 유용하게 만들 것입니다.

나는 이것이 멋지고 유용한 블록이라는 데 동의하지만, 항상 프로젝트의 2 단계에 관한 것이었고 우리는 정말로 집중해야 할 필요가 있거나 우리는 배송하지 않을 것입니다. 추상화를 올바르게하고 사람들이 사용자 지정 레이아웃 블록을 구축 할 수 있도록 허용하여 이와 같은 실제 코어 블록이 덜 중요하기 때문에 중첩 블록 인프라를 구축했습니다. 초점은 일반적으로 중첩 및 하위 UI를 올바르게 가져 오는 데 있습니다 (_Columns_를 기니피그로 사용).

이 문제는 현재 5 개월 동안 공개되었으며 색상, 너비, 블록 방향 대 중첩 열, 커버 이미지와의 겹침 등과 같은 것을 포함하는 확실한 구현 제안이 없었습니다. 우리가해야 할 다른 범용 작업과 WordPress의 임박한 "시도"알림보다 우선 순위를 지정하지 마십시오. 그렇다고해서 컷이되지 않는다는 의미는 아닙니다. 특히 누군가 코드에 제안을 제출하려는 경우에는 더욱 그렇습니다.

또한 저에게 가장 큰 문제는 구현에 투입하는 데 이상적인 사용자 경험이 무엇인지 명확하지 않다는 것입니다. html 태그 노출과 같은 것은 일반 사용자에게는 명백히 복잡하고 직관적이지 않은 것 같습니다. 컨테이너의 개념 자체는 이것이 최상의 레이아웃 추상화인지 확인하기 위해 더 광범위한 테스트가 필요한 것입니다. 이것은 다시 다음 초점 단계에서 알아 내야하는 것이 었습니다. 또한 그러한 블록이 스타일을 임의의 블록으로 캐스케이드하는 방법에 대해 알려지지 않은 몇 가지 사항이 있습니다. 코어 블록을 고려하는 것은 비교적 간단하지만 임의의 블록은 고려하지 않습니다.

동시에 사용자 정의 블록을 제공하려는 개발자는 InnerBlocks 를 사용하여 원하는 태그와 함께 (위에 표시된 스 니펫처럼) 쉽게 조합하고 사용자 피드백을 수집해야합니다. 따라서 이러한 블록이있는 코어에 대한 압력이 적습니다 (그리고이를 유지해야 함). 즉, 누구나 PR을 통해 자유롭게 제안하고 사용자 테스트를 도와야합니다. 5.0에서 제거 될 수 있다는 개념과 함께 "실험적"으로 플러그인에 추가해도 괜찮습니다.

@SuperGeniusZeb 산소는 꽤 멋지다! 이러한 탐험 중 일부를 확실히 살펴 봐야합니다.

호기심에서 테마와 플러그인이 자신의 섹션 블록을 추가하고 사용자가 플러그인을 비활성화하거나 테마를 변경하면 어떻게됩니까? 어떤 종류의 대체가 있습니까? 아니면 사용자가 콘텐츠를 잃어 버리나요?

@tomusborne 그런 상황에 대한 문제가 있습니다 : # 7811.

아! 나는 이것이 여기서 논의되는 것을 몰랐다. 그래서 필요에 따라 플러그인도 만들었습니다.

https://github.com/marcusig/gutenberg-section-block

나는이 스레드를 지켜보고 있으며 그것에 대한 모든 생각에 감사드립니다. 최근 여백, 패딩, 컨테이너 너비, 배경 이미지 및 색상 옵션이있는 Atomic Blocks 플러그인 의 컨테이너 블록 을 출시했습니다. 이 정보가 도움이 되길 바라며 나중에 코어 블록이 도착할 때까지 우리를 붙잡을 수 있기를 바랍니다!

이번 호에 이어 .. 기둥의 구조 와 기타 옵션을 선택할 수있는 "컨테이너"블록을 만들었습니다.
"열"블록을 개선하거나 코어에 새 블록을 만드는 데 도움이 될 수있는 경우 다음 위치에 있습니다. https://github.com/MarieComet/WP-container-block/

@MarieComet 깔끔하지만 블록은 2 개의 다른 블록으로 분할되어야한다고 생각합니다. 첫 번째는 모든 기둥 기반 구조 레이아웃 옵션이있는 기둥 블록이어야합니다. 두 번째는 배경 옵션과 열 기반이 아닌 레이아웃 옵션이있는 컨테이너 블록입니다. 예를 들어 flex를 사용하여 자식을 세로가 아닌 가로로 레이아웃하고 CSS Flex 속성에 해당하는 옵션을 사용하여 정렬하고 양쪽을 맞출 수 있습니다.

또한 컨테이너 블록을 사용하여 개별 열 블록을 대체 할 수도 있지만 섹션에서는 의미가없는 열에 대해 원하는 옵션이있을 수 있습니다.

HTML 및 CSS로 레이아웃을 만드는 미래는 대부분의 페이지 빌더처럼 열을 항상 사용하는 것이 아니라 CSS Flex 및 Grid를 사용하여 <div> s 이하로 콘텐츠를 표시하는 것임을 알게되었습니다. 더 유연하고 깔끔한 스타일링이 가능합니다. 저는 주로 산소가하는 일에서 영감을 받았습니다. 나는 이 코멘트 에서 산소에 대해 이야기

이 문제는 지금 열 블록을 교체하는 것이 아닙니다. 이 문제에 관한 섹션 블록에 계속 초점을 맞추는 것이 중요합니다.

@karmatosed @melchoyce 말하자면이 문제의 이름을 바꾸면 안 되나요? <section> 요소와의 혼동을 피하기 위해 "섹션"이라고 부르는 것을 중지하고 "컨테이너"로 전환했습니다.

이름은 정해지지 않았기 때문에 우리 모두는 잠시 그대로 남겨 두는 것이 좋습니다.

현재 구텐베르크 편집자와 함께 테마를 구현하려고합니다.

웹 사이트의 레이아웃에는 배경이 다른 여러 영역이 있으며 단락이나 목록과 같은 여러 항목이 포함되어 있습니다. 이것은 레이아웃과 탐색을위한 것입니다. 섹션 / 컨테이너 블록은 앵커로 작동해야하며 고유 한 CSS ID를 가져야합니다.

나는 자신의 블록을 만들어 "구텐베르크를 해킹"하지 않고는이 테마를 끝낼 수 없다. 대신 코어 블록으로이 작업을 수행 할 수 있습니다. 평범한 텍스트와 단순한 레이아웃에만 구텐베르크 편집기를 사용하지 않을 것입니다. 미래의 레이아웃 / 디자인은 구텐베르크의 테마 및 블록 시스템과 함께 수행되어야합니다.

이 주제에 더 높은 우선 순위 가 주어지기를 정말로 바랍니다

열 블록과 함께 제 3 자 컨테이너 블록 (예 : 원자 블록)을 모든 곳에서 사용하고 있습니다. 그들은 매우 유용했고 가장 인기있는 블록이었습니다. 나중에 나중에 또는 추가 기능으로 간주되는 것이 이상합니다. 핵심에 있어야합니다.

그렇지 않으면 HTML보기에서 컨테이너를 수동으로 빌드하지만 HTML보기는 추가 메뉴 클릭 거리이기 때문에 성 가시고 비효율적입니다. HTML보기에 대한 키보드 단축키가 있습니다 ... shift + option + cmd + M ... yeesh. 그리고 그것은 앞뒤로 토글하지도 않습니다. 바로 가기를 다시 누르면 아무 작업도 수행되지 않습니다. WYSIWYG보기로 돌아가려면 메뉴를 거쳐야합니다. 메인 툴바의 크고 두툼한 토글 스위치는 웅장 할 것입니다.

누구든지 카탈로그를 작성했거나 현재 야생에서 구현 목록을 유지하고 있습니까? "옳고 그른 일"이라는 일종의 매개 변수 매트릭스도 필요하다고 생각합니다. 예를 들어 관련 패딩 / 여백 (잘못)에 대해 하드 코딩 된 단위 (px)를 지정하고, 단위가 사용자에게 남겨진 선택 (오른쪽) 등으로 지정되어야합니다.

https://editorblockswp.com/library/ 는 카탈로그에 일부가 있지만,이 문제를 앞으로 나아 가기 위해서는 섹션 / 컨테이너에 특정한 일이 발생해야하는 것처럼 보입니다.

제 생각에는 기본 컨테이너 블록에는 최소한 다음 옵션이 있습니다.

• 배경 이미지
• 배경색
• 이미지에 배경색을 오버레이하고 불투명도를 제어하는 ​​기능
• 4 방향 모두에 대한 패딩 및 여백 옵션, 각 값에 대해 개별적으로 사용되는 단위 전환 기능
• 왼쪽 부동, 오른쪽 부동, 와이드 및 전체 정렬 지원
• 포함 된 블록의 최대 너비를 어떻게 든 제어하는 ​​기능
• 컨테이너에서 사용하는 html 요소를 선택하는 기능

또한 다음 항목도 선호합니다.

• CSS 플렉스 레이아웃 옵션 : 콘텐츠 흐름 방향을 위에서 아래로, 왼쪽에서 오른쪽으로, 오른쪽에서 왼쪽으로, 아래에서 위로 설정하는 기능; 콘텐츠의 수직 및 수평 정렬 설정 기능
• 물론 플렉스 옵션을 사용하는 것은 플로트 정렬과 호환되지 않으므로 블록에는 표준 및 플렉스의 두 가지 레이아웃 모드가 있어야합니다. 그렇지 않으면 별도의 플렉스 컨테이너 블록이 있어야합니다.
• 컨테이너의 콘텐츠에 대한 기본값을 설정하고 포함 된 모든 블록에 대해 개별적으로 설정하지 않아도되는 글꼴 크기 및 색상 옵션

Felix Arntz는 방금 섹션 블록 구현에 관한 블로그 게시물을 게시했습니다.
반응 형 배경 이미지가 마음에 듭니다.
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

지난 몇 주 동안 나는 Marc Lacroix의 구현을 실험 해 왔지만 정상적으로 작동하지만 gutenberg 3.9.0에서 중단 된 것 같습니다 https://github.com/marcusig/gutenberg-section-block

나는 이것에 대해 한동안 생각하고 있습니다. 이를 위해 많은 구현이 등장했다는 사실은 매우 가치가 있으며 코어가 단편화를 피하기 위해 일관된 메커니즘을 제공하는 것이 더 낫다는 것을 의미합니다. 내 주된 걱정은 사용자에게 "섹션"블록의 복잡성입니다.

저는 컨테이너 (단일 InnerBlocks 영역), 넓고 완전한 정렬, 배경색 설정 (이미지 없음 등-이를 위해 "커버"가 있음)으로 매우 간단하게 시작할 것을 제안합니다.

5.0에서 원한다면 할 시간이별로 없습니다.

@mtias 컨테이너 블록을 최종 사용자에게 노출하는 것이 문제가되는 경우 모든 블록에는 기본적으로 컨테이너 또는 컨테이너 설정 만 있어야합니다.

그런 다음 최종 사용자에게 배경 이미지와 같은 특정 항목을 갖기 위해 컨테이너에 무언가를 포장해야한다고 가르치는 것에 대해 걱정할 필요가 없습니다.

나는 이것이 실제로 좋은 생각이라고 생각한다. 왜냐하면 임의의 블록을 확장하거나 감싸고 자하는 사람들은 그렇게 할 수있는 명확한 장소를 가지게 될 것이고 최종 사용자는 그것이 모든 블록에 있기 때문에 그것에 익숙해 질 것이기 때문이다.

"컨테이너 설정"은 "차단 설정"옆에있는 탭일 수 있습니다. 이것은 개발자가 배경 이미지 설정, 너비 설정 등과 같은 항목을 드롭 (또는 필터링) 할 수있는 (확장 가능한) 장소입니다.

이는 또한 개발자가 반응 형 / 중단 점 제어와 같이 거의 모든 블록에 적용 할 수있는 더 복잡한 설정을 배치 할 수있는 공간을 제공합니다.

@rchipka 기술적으로 대부분의 블록은 부모 div로 래핑되며 설명하는 블록 수준 설정의 종류는 현재 블록이 가능한 것입니다.

컨테이너의 힘은 정확히 단일 블록에있는 것이 아니라 컨테이너 내부에 다른 블록을 추가하여 더 복잡한 레이아웃, 섹션 및 페이지 구조를 만들 수있게합니다.

@mikemcalister 좋은 지적, 최종 사용자는 블록 트리를 시각적으로 그룹화 / 구성하는 방법이 여전히 필요합니다.

그래도 철학은 동일하다고 생각합니다. 편집기에 트리 스타일 블록 그룹화 메커니즘이있는 경우 (예 : "컨테이너 블록"인터페이스가없는 경우) 하위 블록의 "컨테이너 설정"은 해당 그룹의 설정 (예 : 트리의 해당 수준)을 미러링합니다.

다시 말하지만,이 아이디어의 유일한 요점은 최종 사용자와 관련된 단계 수를 줄여 학습 곡선을 줄이고 검색 가능성을 높이는 것입니다.

주요 문제는 현재 구텐베르크가 표준 게시물 / 페이지 콘텐츠로 매우 제한되어 있다는 것입니다. 섹션 / 컨테이너 블록이 없으면 사용자가 모든 종류의 콘텐츠가 포함 된 전체 너비 섹션 (배경 단색 / 그라데이션 색상 또는 전체 너비 배경 이미지 포함)이있는 전면 페이지를 만들 수 없습니다 (중첩 된 블록을 통해).

섹션 / 컨테이너 블록은 여기에서 완벽합니다. 테마 / 플러그인에 의해 더 많은 컨트롤로 확장 될 수있는 기본적인 것조차. 거기에 더 많은 정렬 설정을 얻고 싶습니다. 우리는 이미 페이지에서 의사 페이지 빌더를 갖기 위해 CMB로 뭔가를하고 있지만, 구텐베르크가 모든 사람에게이 모든 것을 더 유연하게 만들 수 있기를 바랍니다.

@JiveDig 구텐베르크 팀을 포함한 누구도 일종의 블록 컨테이너 메커니즘에 반대한다고 생각하지 않습니다.

Gutenberg 팀 (이 경우 및 기타 여러 팀)이 주저하는 것은 UI / UX 관점에서 핵심 인터페이스를 Squarespace 수준의 복잡성으로 낮추는 것입니다.

이를 핵심으로 구현하기 위해서는 최종 사용자에게 추가 부담을주지 않고이를 표현할 수있는 방법을 찾는 것이 주요 문제인 것 같습니다.

제 생각에는 별것 아닌 것 같지만 "컨테이너 블록" 은 그 목적과 사용법에 대한 지식을 요구함으로써 최종 사용자에게 작은 부담을줍니다.

이것이 제가 최종 사용자를위한 "컨테이너"에 대한보다 접근하기 쉬운 비유로 "그룹화"개념을 제안한 이유입니다.

최종 사용자는 블록을 컨테이너로 묶는 관점에서 생각하지 않고 대신 블록을 함께 그룹화하는 관점에서 생각합니다.

이렇게하면 최종 사용자가 블록을 그룹화하고 해당 그룹에 설정을 적용하기 위해 미리 알 필요가 없습니다.

물론 이러한 "그룹"은 내부적으로 컨테이너 블록과 똑같이 작동하며 더 통합되고 직관적 인 프런트 엔드 인터페이스 일뿐입니다.

@rchipka 접근하는 매우 쉬운 방법은 하나 이상의 블록을 선택하고 "추가"메뉴에서 "선택한 블록을 컨테이너 블록으로 이동"옵션을 클릭하는 것입니다. 이렇게하면 차단에 _additional_ 설정 패널이 필요하지 않습니다.

예, 섹션 블록이 코어에 있어야합니다. HTML에서 간단한 div를 렌더링하는 것으로 충분합니다. 하지만 제공 할 수있는 속성은 말 그대로 수백 개이므로 대신 제공해야하는 두 가지 속성은 CLASS와 ID (ID가 가장 덜 중요 함)라고 강력하게 제안합니다. 이렇게하면 CSS에서 요소가 있어야하는 위치에 스타일을 지정할 수 있습니다.

-
Wes 모드
아메리칸 리버 피플의 비밀 역사
http://peoplesriverhistory.us

내 Apple에서 보냄] [e

2018 년 10 월 12 일 오전 8:09에 Matias Ventura [email protected] 은 다음과 같이 썼습니다.

나는 이것에 대해 한동안 생각하고 있습니다. 이를 위해 많은 구현이 등장했다는 사실은 매우 가치가 있으며 코어가 단편화를 피하기 위해 일관된 메커니즘을 제공하는 것이 더 낫다는 것을 의미합니다. 내 주된 걱정은 사용자에게 "섹션"블록의 복잡성입니다.

컨테이너와 배경색 설정 (이미지 없음 등-이에 대한 "커버"가 있음)만으로 매우 간단하게 시작할 것을 제안합니다.

5.0에서 원한다면 할 시간이별로 없습니다.

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하십시오.

다시 모든 블록은 클래스 속성을 설정할 수 있어야합니다. 유형에 관계없이.

-
Wes 모드
아메리칸 리버 피플의 비밀 역사
http://peoplesriverhistory.us

내 Apple에서 보냄] [e

2018 년 10 월 12 일 오전 8시 40 분에 Robbie Chipka [email protected] 은 다음과 같이 썼습니다.

@mtias 컨테이너 블록을 최종 사용자에게 노출하는 것이 문제가되는 경우 모든 블록에는 기본적으로 컨테이너 또는 컨테이너 설정 만 있어야합니다.

그런 다음 최종 사용자에게 배경 이미지와 같은 특정 항목을 갖기 위해 컨테이너에 무언가를 포장해야한다고 가르치는 것에 대해 걱정할 필요가 없습니다.

나는 이것이 실제로 좋은 생각이라고 생각한다. 왜냐하면 임의의 블록을 확장하거나 감싸고 자하는 사람들은 그렇게 할 수있는 명확한 장소를 가지게 될 것이고 최종 사용자는 그것이 모든 블록에 있기 때문에 그것에 익숙해 질 것이기 때문이다.

"컨테이너 설정"은 "차단 설정"옆에있는 탭일 수 있습니다. 이것은 개발자가 배경 이미지 설정, 너비 설정 등과 같은 항목을 드롭 (또는 필터링) 할 수있는 (확장 가능한) 장소입니다.

이는 또한 개발자가 반응 형 / 중단 점 제어와 같이 거의 모든 블록에 적용 할 수있는 더 복잡한 설정을 배치 할 수있는 공간을 제공합니다.

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하십시오.

클래스 속성을 할당 할 수있는 한 그룹화 방법을 반대하지는 않지만, 그런 방식으로 빌드하려는 경우 컨테이너 블록도 있으면 좋을 것입니다.

-
Wes 모드
아메리칸 리버 피플의 비밀 역사
http://peoplesriverhistory.us

내 Apple에서 보냄] [e

2018 년 10 월 12 일 오전 10시 50 분에 Chris Van Patten [email protected] 은 다음과 같이 썼습니다.

@rchipka 접근하는 매우 쉬운 방법은 하나 이상의 블록을 선택하고 "추가"메뉴에서 "선택한 블록을 컨테이너 블록으로 이동"옵션을 클릭하는 것입니다. 이렇게하면 블록에 추가 설정 패널이 필요하지 않습니다.

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하십시오.

@chrisvanpatten 동의하지만이 솔루션은 컨테이너 또는 섹션의 개념을 최종 사용자에게 노출하려는 @mtias 의 원래 관심사를 적절하게 해결하지 못합니다.

@mtias 가 제기 한 문제는 블록을 컨테이너에 넣는 물류에 관한 것이 아니라 최종 사용자에게 해당 인터페이스를 직관적으로 제시하는 것입니다 (추가 블록 유형을 노출하지 않음).

"컨테이너에 블록을 넣는 방법"에 대한 논의가 필요합니다. 그러나 사용자에게 지나치게 복잡하다고는 볼 수 없습니다. 많은 사용자가 사용하지 않거나 적어도 홈페이지 외부에서 사용하지 않습니다. 많은 고객 및 테마 고객이 섹션 블록에 적합한 시각적 용어로 웹 사이트의 요구 / 필요를 표현합니다. "예쁜 이미지가있는 큰 전체 너비 {bar / area / section / block / panel / span}를 원합니다."다음에 "그리고 해당 섹션에 {여기에 콘텐츠 요청 삽입}"이라고 말합니다. 섹션 자체 (컨테이너)가 내부 콘텐츠와 분리되어 있음을 시각적으로 이해합니다.

물론 UI를 통해 수행하는 방법을 알아 내야하지만 위의 요점이 이해되기를 바랍니다.

@chrisvanpatten 내 이전 진술은 전적으로 블록 유형의 의미론을 기반으로합니다.

내가 여기서 의미론을 주장하는 유일한 이유는 @mtias 대신에 이러한 의미론을 노출하는 복잡성으로 인해 문제가 발생했기 때문입니다.

귀하의 제안이 마음에 들지만 제 비유를 따르는 경우 "Group selected block (s)"이라는 의미를 변경할 것입니다.

@rchipka 는 내가 그의 의견을 해석 한 방법이 아닙니다. 제안 된 블록이 단순해야하지만 여전히 그 자체가 블록이어야 함을 의미한다고 생각했습니다 (InnerBlocks 영역 인 경우 포함되어야 함). 블록). 아마도 삽입 기에서 그것을 숨기고 여러 블록을 선택하고 "컨테이너에 배치"옵션을 제공함으로써 생성 된 컨테이너 블록 만 가질 수있는 방법이있을 것입니다. 그러나 여전히 전용 블록을 의미하는 시스템에 대한 나의 이해를 기반으로합니다.

그것은 내가 틀렸다는 것이 행복하다고 말했습니다. :)

@JiveDig 나는 매우 동의합니다 ....

그러나 구텐베르크 팀은 구텐베르크 코어의 최종 사용자에게 이러한 정보를 노출하는 데 매우 민감한 것으로 보입니다.

이것이 이러한 주장을 제기하고 이러한 아이디어를 제시하는 유일한 근거입니다.

다시 말하지만, 나라면 우리는 망할 컨테이너 블록을 가지고있을 것입니다.

컨테이너 블록은 UI를 어지럽히 기 때문에 실제로 의미가 없다고 생각합니다. Microsoft Word에서 인라인으로 표시되는 "섹션 나누기"마커와 같은 것을 보겠습니다. 섹션 나누기를 추가하면 섹션의 클래스 이름, 배경색, 텍스트 색상, 드롭 섀도우 등 섹션을 스타일 적으로 정의하는 모든 스타일 옵션이 검사기에서 제공됩니다. 그것은 어떤 블록처럼 삽입되고 다른 블록처럼 움직일 수 있습니다.

@rwrobe 그 아이디어는 중첩 컨테이너에서는 작동하지 않습니다.

저는 현재 Gutenberg와 함께 사이트를 구축하고 있으며 marcusig 섹션 블록의 수정 된 버전을 많이 사용했습니다. 이것은 경험을 바탕으로 배운 것입니다.

• "섹션"은 블록의 가장 좋은 이름입니다. 그 의미는 개발자와 최종 사용자에게 명확하며 <section> 블록을 논리적으로 사용하여 마크 업 / 옵션을 복잡하게 만드는 것을 방지합니다.

• 필요한 유일한 컨텍스트 메뉴 옵션은 alignnormal / wide / full입니다 (실제로 alignfull 만 사용합니다). 정렬은 내부 블록에 영향을주지 않으며 자체 정렬 옵션이없는 한 일반 정렬 내에 있습니다. 주요 사용 사례는 현재는 불가능한 매우 일반적인 디자인 패턴 인 일반 정렬 텍스트 블록을 포함하는 alignfull 배경색을 만드는 것입니다.

• 필요한 유일한 사이드 바 블록 설정은 배경색 및 배경 이미지 (관련 고정 / 불투명 옵션 포함)입니다. 추가 사용자 정의는 사용자 정의 CSS 클래스로 처리 할 수 ​​있습니다. (배경 이미지 옵션을 포함하면이를 훨씬 더 유용한 커버 블록 버전으로 바꾸는 부작용이 있습니다.) (하지만 @mtias 가 옳다면 배경색 옵션 만 포함하여 대화를 피하는 것이 문을 더 빨리, 그럼 내가 전부입니다.)

• 사용성은 간단합니다. 한동안 주변에 있었던 Columns보다 쉽습니다. 유일한 잠재적 인 문제는 섹션이 처음 추가 될 때 포커스가 섹션 내부의 단락으로 전환되어 마우스를 가져갈 때까지 섹션이 방금 추가되었음을 알기 어려울 수 있다는 것입니다. 이에 대한 한 가지 가능한 해결책은 기본적으로 밝은 회색 배경색을 사용하는 것입니다.

@ZebulanStanphill 당신은 칼럼에 대해 이야기하고 있습니까? 수직으로 분리 된 콘텐츠에 대한 작업을 수행하는 "섹션"블록을 볼 수 있습니다. 이전 섹션의 스타일을 상속하기위한 토글이있을 수도 있습니다.이 옵션을 사용하면 섹션 내부에 스타일 변형을 "중첩"할 수 있습니다.

가로 구성은 열과 같이 구텐베르크가 전체 너비 블록에서 위에서 아래로 페이지를 작성하는 방식으로 인해 필연적으로 더 어려워 보입니다.

@mikedance 나는 그것이 정확히 필요한 것이라고 생각합니다. IMO를 통해 배경 이미지 옵션이 중요합니다. 아마도이 블록이 커버 블록을 대체 할 수 있을지도 모르지만, 이름이 기본 텍스트가있는 배경 이미지만을 원하는 사람들에게는 도움이되지 않을 수도 있습니다. 기능에 약간의 겹침이 있지만 bg 이미지 지원을 추가하지 않고 섹션 블록에 대한 많은 사용 사례를 제거합니다.

@rwrobe 수평으로 배치 된 블록을 가질 수 있다는 점에 유의해야합니다. 열 ( "s"가 없음) 블록은 바로 그것입니다. Columns 블록은 이들을 수평으로 배치합니다. UI는 일부 영역에서 개선 될 수 있지만 블록은 전체 너비 또는 수직 레이아웃으로 제한되지 않습니다.

뿡 빵뀨

"섹션"은 블록의 가장 좋은 이름입니다. 그 의미는 개발자와 최종 사용자에게 명확하며 논리적으로 사용하여 마크 업 / 옵션을 복잡하게 만들지 않습니다.

블록.

때문에 <section> 요소에 연결된 의미를 가지고 당신이 사용하도록 선택할 수 있다면, 그것은 가장 좋은 것입니다 <div> 보다는 <section> , 많은 경우에 당신이 랩을 원하기 때문에 여러 블록이지만 의미 상 섹션의 일부는 아닙니다. 실제로 <aside> 또는 <header> 와 같은 요소를 사용하도록 선택할 수 있다면 더 좋을 것입니다. 후자는 페이지 작성에서 배경이있는 머리글에 의미를 추가하는 데 특히 유용합니다.

또 다른 메모에서 컨테이너 블록에 사용할 수있는 배경 이미지 옵션이 있으면 매우 유용 할 것이라고 생각합니다. 물론 Cover block 개념과의 겹침은 분명해집니다. Cover 블록을 더 유연하게 만들면 어쨌든 기본적으로 Container 블록으로 바뀌므로 Cover 블록 개념이 존재할 필요가 없습니까? 컨테이너 블록은 거의 모든 작업을 수행 할 수 있습니다. Cover 개념은 재사용 가능한 블록 템플릿 일 수 있습니다.

@ZebulanStanphill 동의합니다. 섹션, 헤더, aside 또는 div (기본값) 중에서 선택할 수있는 고급 구성이 유용합니다. 예, 대부분의 사용자는 해당 옵션을 사용하지 않을 수 있지만 좋은 웹 개발을 지원하는 옵션입니다.

테마는 어떻게 통합 할 수 있습니까? 테마가 블록에 "변형"을 추가 할 수 있습니까?이 경우
섹션 블록과 사용자가 ilst에서 직접 하나를 선택하고 적용된 결과 스타일을 볼 수 있습니까?
또한 섹션 블록에 필터 또는 후크를 추가하여
테마는 스타일링에 때때로 필요한 래퍼 및 기타 요소를 추가합니다.

@ZebulanStanphill @wmodes 포함하는 요소를 선택하는 옵션을 포함하는 것이 핵심 개발자를 지나칠 것이라고 의심합니다. 너무 복잡합니다. 특정 관점에서 볼 때 <section> 요소는 사용자가 블록을 생성하여 이미 "섹션"으로 정의하고 있기 때문에 가능한 한 의미가 있습니다. 제목처럼 책임감있게 사용하는 것은 그들에게 달려 있습니다. 그러나 의미 론적 인수를 피할 수 있다면 <div> 사용에 문제가 없습니다.

@mikedance 동의합니다. <div> 사용해야합니다. 시맨틱 레이아웃이 문제라면 컨테이너 블록에 대한 확장으로 처리하는 것이 가장 좋습니다.

@strarsis 테마는 기존 블록 스타일 API를 사용하여 블록에 스타일을 추가 할 수 있습니다. (핵심 Button 및 Quote 블록에는 기본적으로 여러 스타일 변형이 포함되어 있습니다.) 안타깝게도이 기능에 대한 문서를 찾을 수 없습니다. (현재 문서 부족을 추적하는 여러 문제가 있습니다 : https://github.com/WordPress/gutenberg/milestone/500)

뿡 빵뀨

특정 관점에서

요소는 사용자가 블록을 생성함으로써 이미 "섹션"으로 정의하고 있기 때문에 가능한 한 의미 적입니다.

나는 당신이 말하는 것을 이해한다고 생각하지만 나는 동의하지 않습니다. 대부분의 경우 컨테이너 블록은 자체 배경 (또는 다른 스타일) 옵션이없는 두 개 또는 하나의 블록에 배경색을 추가하는 데 사용됩니다. 배경색을 지정하고 강조 표시하기 위해 컨테이너에 래핑 된 목록 블록은 목록이 자체 섹션에 있음을 의미하지 않습니다.

그러나 예, <div> 은 의미 론적 의미가 없기 때문에 가장 중립적 인 선택입니다. HTML 요소를 변경할 수있는 옵션이 코어에 없을 경우 <div> 이 최선의 선택입니다.

내가 HTML 태그를 선택할 수있는 기능을 원하는 주된 이유는 사용자 지정 HTML 블록이나 사용자 지정 블록을 추가하는 플러그인에 의존하지 않고도 시맨틱 페이지와 게시물을 더 쉽게 만들 수 있기 때문입니다. 지금 Gutenberg에서 <section> 태그를 사용하려면 해당 섹션의 모든 항목을 사용자 정의 HTML 블록에 넣어야하므로 단락, 목록 등과 같은 항목에 대한 시각적 편집 기능이 손실됩니다. 그렇지 않았을 것입니다. 태그 스위처가 인스펙터의 고급 그룹 아래에 표시 될 수 있습니까?

트윗 담아 가기

확장 성 https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block -style-variations에서 핸드북에 Block Styles 을 추가하는 문서를 찾을 수 있습니다.

@ajitbohra 감사합니다! 그 페이지를 여러 번 확인했지만 어떻게 든 그 섹션을 계속 놓쳤습니다. :웃음:

@ajitbohra : 감사합니다! 구텐베르크 블록 스타일 변형 btw에 대한 데모가 있습니까?

헉

예, 코어 button 및 quote 블록을 확인합니다.

https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/button
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/quote

@strarsis pullquote , table 및 separator 블록에도 스타일 변형이 있습니다.
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/pullquote
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/separator
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/table

생성 된 조직 블록의 일부를보고 싶습니다. Columns의 현재 문제는 콘텐츠를 그룹화하기 위해 (예 : 공유 배경색, 비디오 또는 이미지 목적으로) 단일 열 블록을 만드는 것이 직관적이지 않다는 것입니다. 내가 이상적으로, 같은 편집기 등이 콘텐츠를 만들 수 있던 단계에 도달 볼 것 이 에디터 내에서 거의 엄격하게.

5.1 릴리스를 위해 임시로 이동하므로이 블록을 표시하는 방법을 정의하는 데 시간이 좀 더 걸립니다.

제가 생각하는 동안 ... 이것과 커버 블록 사이에 겹침이 있기 때문에 커버 블록이 "구성"에 가깝다면 그 블록을 추가 할 때 실제로 제목이있는 사전 구성된 섹션 블록을 추가합니다. 또는 그 안에 중첩 된 텍스트 / 단락 블록?

뿡뿡

커버 블록이 그 블록을 추가 할 때 실제로 내부에 중첩 된 제목 또는 텍스트 / 단락 블록이있는 미리 구성된 섹션 블록을 추가한다는 점에서 "구성"에 더 가깝다면 어떨까요?

그것은 나에게 독립형 블록으로 삽입되는 재사용 가능한 블록과 매우 흡사합니다. 아마도 코어에는 기본적으로 이와 같이 재사용 가능한 여러 블록 템플릿이 포함될 수 있습니다. 재사용 가능한 블록을 독립형으로 더 쉽게 삽입 할 수 있도록 UI를 개선해야합니다. # 8403을 참조하십시오.

새로운 섹션 / 컨테이너 블록을 테스트하기위한 포크가 있습니까? 나는 그것을 가지고 놀고 그것을 테스트하는 데 관심이 있습니다.

컨테이너 / 섹션 블록은 매우 유용합니다.
현재 고급 구텐베르크 블록 컨테이너 블록.
그리고 섹션 / 컨테이너 블록을 쉽게 표시하고 선택할 수 있도록하는 것이 중요합니다.

부분적으로는 섹션 블록이 템플릿 개발에 매우 ​​유용하다는 점을 언급했습니다.

코어에있는 대신 사용자 정의 섹션 블록을 생성했으며 블록이 동일하지만 속성이 변경되는 경우 블록 속성이 업데이트되지 않는 문제를 발견했습니다.

이는 PR # 12406 (위)에서 해결되었습니다.

섹션 블록은 5.1 (2019 년 2 월 21 일 대상) 이상에서 계속 고려됩니까?

섹션 블록 플러그인을 작성했는데,이 플러그인은 몇 가지 프로젝트에서 사용했으며 플러그인 저장소에 좀 더 일반적인 것으로 출시되기를 희망합니다. innerblocks 영역 내에 포함 된 항목의 형식을 지정하기 위해 테마별로 정의 된 클래스뿐만 아니라 배경색과 이미지 또는 비디오를 설정할 수 있습니다.

내 사용 사례에서 클라이언트가 "항목"을 쌓을 수있는 내부 블록 영역 위에 미리 정의 된 (선택적) 제목 및 설명 필드를 갖는 것이 더 쉬웠습니다. 내 사용 사례에서는 다른 블록으로 만든 의사 위젯이었습니다. 유형. 그러나 이것은 첫 번째 섹션 블록에 제목, 단락 및 항목을 포함하는 또 다른 섹션 블록이 포함 된 간단한 중첩 섹션이 될 수 있습니다.

섹션은 구텐베르크가 _ 반드시 _ 디스플레이가 flex 설정된 섹션을 적절하게 처리하고 직계 자식의 flex 속성을 적절하게 렌더링 할 수 있음을 의미합니다.

내 섹션을 JS로 렌더링하지만 코드에는 내가 해킹이라고 생각하는 것이 많이 있습니다. PHP로 렌더링하는 것은 케이크 조각이 될 것입니다 ... 내부 블록 콘텐츠를 PHP로 보내는 것은 여전히 ​​해결되지 않은 것입니다.

열 블록에 의해 구현 된 열은 열을 수동으로 큐 레이션해야하므로 모바일 친화적이지 않고 세트에서 다른 항목을 추가하거나 제거하는 것이 매우 번거롭기 때문에 완전히 작동하지 않는 솔루션입니다.

섹션의 "열"은 단순히 플렉스 기반 선언이며 쉽게 행이 될 수 있고 있어야하며 항목의 실제 컨테이너가 아니라 단순히 흐름 방식에 대한 정의입니다. 섹션의 개념을 항목에 대한 컨테이너로 열과 유사한 것으로 손상시키지 마십시오.

섹션에 설정된 속성은 해당 섹션에 포함 된 블록으로 쉽게 검색되어야합니다. 부모가있는 경우 부모의 선택에 현명하게 응답 할 수있는 블록 유형을 만들 수 있어야합니다. 그렇기 때문에 1400 줄의 코드를 작성하지 않고 부모의 속성에 대해 어떤 것도 발견하기가 어렵습니다.

블록의 부모 / 자식 컨텍스트는 표시 및 편집 방법에 필수적이기 때문에 블록이 중첩됩니다. 문맥이 존재하지 않는 척하는 것은 최악의 이상주의입니다.

중첩 된 블록은 기본적으로 상위 속성을 쉽게 참조 할 수 있어야합니다. 드문 경우를 제외하고 서버 측에서 블록을 렌더링하지 않는 것이 목표 인 경우 컨텍스트 정보의 전달은 _ 발생해야합니다 _. 그렇지 않으면 render() 은 새롭고 유용한 것으로 return null 의 황무지가 될 것입니다. 하지만 복잡한 블록이 나타납니다.

([아직 실험적인] CSS columns 속성을 구현하면 columns 블록이 더 유용 할 것이라고 생각합니다. 기본적으로 section 의 특수 유형이 될 것입니다. 그 안에있는 항목과 인스펙터에 정의 된 열 속성을 통해 이동합니다. column-width , column-count , column-rule 등)

이 블록 유형 (블록 추가 : 섹션)에 대한 릴리스 날짜가 있습니까?

@JQOz 아니요.이 문제는 다음 시장 버전에 대한 로드맵에 있지만 사람들이 작업중인 공개 풀 요청은 없습니다. 이 블록에 대한 아이디어 나 기능이 있으면 여기에서 추가 할 수 있습니다.

안녕하세요,

한 번만 생각하지 않습니다. 섹션은 전체 너비 컨테이너 여야합니다. 섹션 내의 컨테이너에 거터를 추가하고 add_theme_support('alignwide') 처럼 작동하도록 할 수 있습니까?

케이스의 경우 :

https://tech.cornell.edu/

다양한 섹션이 있습니다. 그들 중 일부는 컨테이너에 살아 있습니다. 일부는 그렇지 않습니다. 그러나 그들 모두는 단일 컨테이너가 필요합니다.

Gutenberg 컬럼 블록은 너무 중첩 된 클래스이며 많은 도움이되지 않습니다. 그리드 구조를 따르고 부모> 자식 클래스를 사용하여 계속 작동해야합니다.

https://www.luminasolar.com/ 개발을 할 때 구조를 유지하기 위해 template 키로 감싸 야합니다.

페이지 레이아웃 전략의 일환으로 페이지 빌더의 타사 테마 및 플러그인 개발자에게 후크 / API를 제공하여 자체 인터페이스와 종소리를 추가 할 수 있다고 생각하는 것이 좋습니다.

WPTavern 에서이 항목을 따라

CoBlocks, Kadence (또는 자신이 가지고있는 모든 것)가 재정의 할 수있는 공통 표준 레이아웃이 있으면이 문제를 해결할 수 있습니다. 플러그인 또는 테마를 변경하면 최소한 콘텐츠는 동일한 기본 레이아웃을 유지합니다.

이것은 기본적으로 내 사이트에서 요소를 유지하는 유일한 기능입니다.

WPTavern 에서이 항목을 따라

CoBlocks, Kadence (또는 자신이 가지고있는 모든 것)가 재정의 할 수있는 공통 표준 레이아웃이 있으면이 문제를 해결할 수 있습니다. 플러그인 또는 테마를 변경하면 최소한 콘텐츠는 동일한 기본 레이아웃을 유지합니다.

예, 예, 예! 나는 유연한 섹션 블록이 구텐베르크에서 가장 큰 누락 된 기능이라고 생각합니다. 향후 릴리스에 대한 계획을 듣고 기쁩니다. 그러나 지금 아무도 작업하지 않는다는 점에 실망했습니다. 이것이 없으면 사용자는 여전히 일반적인 페이지 형식을 레이아웃 할 수 없으며 테마 개발자는 사용자가 실제로 합리적으로 일반적인 페이지 레이아웃을 구축 할 수있는 위치에 도달하기 위해 독점 기술에 의존해야합니다.

섹션 블록은 최종적으로 더 복잡한 페이지를 레이아웃하고 테마를 전환 할 수있는 문제를 해결하기 위해 핵심 Gutenberg에 있어야합니다 (그리고 테마별로 구성 및 확장 가능).

물론, 테마 디자이너로서 내 테마에 맞게 여백과 패딩을 제어하고, 일치시킬 이미지 형식을 지정하고, 이러한 모든 종류의 테마별 "디자인"항목을 지정하기 위해 나만의 색상 팔레트를 추가하고, 사용자는 모든 워드 프레스 테마로 전환 할 수 있어야하며 적어도 기본적으로 동일한 레이아웃 (그룹화 된 섹션, 열 등)에서 콘텐츠를 보존하고 구텐베르그 블록으로 편집 할 수 있어야합니다 (사용자 정의 HTML 블록으로 전환 할 필요 없음).

초기 버전의 작업이있는 섹션 블록 플러그인이 있으며 이번 주 후반에 업데이트하여 저장소에 제출할 예정입니다. 그것은 블록의 무한 중첩을 허용합니다 (내 말은, 이유 내에서). 플러그인을 사용하면 테마 또는 플러그인이 원하는 경우 자체 섹션 스타일을 정의 할 수 있으며 사용자가 선택할 수 있습니다. 원하는 경우 테마별로 비활성화 할 수있는 몇 가지 기본 스타일 만 포함 할 계획입니다.

인스펙터 패널

• _Background._ 내 플러그인을 사용하면 이미지 배치, 블렌딩, 채도 감소 및 색상 오버레이에 대한 컨트롤을 사용하여 원하는 경우 배경 색상 및 / 또는 이미지를 설정할 수 있습니다.
• _Dimensions, Padding, Margins._ 기본적으로 섹션은 내용에 맞게 자동 높이가 지정되고 전체, 너비 및 가운데 정렬을 따르며 왼쪽과 오른쪽은 45 %입니다. 즉, 지정된 너비 및 / 또는 높이를 허용하는 컨트롤을 추가하고 InnerBlocks 주변의 패딩과 블록 주변의 여백을 추가 할 것입니다. _ 그러나 구텐베르크와 관련된 문제는 아래를 참조하십시오 ._
• _Columns ... and Rows._ flex를 사용하여 많은 실험을 한 후, 열 기반 레이아웃을 사용하는 경우 직계 자식을위한 CSS _grid_를 사용하는 것이 가장 좋습니다. 그리드를 사용하는 것은 토글입니다. 그렇지 않으면 아이들은 그냥 정상적인 블록입니다. (솔직히, 행은 가능하지만 새 행을 시작해야 할 때 작업중인 섹션 아래에 새 섹션을 추가하여 가장 잘 처리 할 수있는 편집 인터페이스에 많은 복잡성을 추가합니다.) 그리드가 더 우수합니다. flex (열만 수행하는 경우에도) flex _ 필요한 특정 높이가 컨테이너 또는 하위 항목에 설정되어야하므로 많은 유연성이 제거됩니다.

변하기 쉬운
그리드를 사용하는 섹션 플러그인의 한 가지 문제는 정의 된 모바일 중단 점에서 그리드에 발생하는 일입니다. 사용자 (또는 테마 작성자)는 섹션이 3 개 항목을 표시하는시기에서 2 개 항목을 가로 질러 1 개 항목을 표시하는시기를 정의 할 수 있어야합니다.

중단 점은 테마에 의해 정의 될 수 있어야하며 블록 자체에 속한 것처럼 느껴지지 않아야합니다. 이는 또 다른 큰 검사자 선택 세트를 추가하기 때문이며 아마도 중단 점이 게시물과 페이지에서 일관 적이기를 원할 것입니다. . 그러나 그리드 옵션을 사용할 때 블록은 중단 점에 대해 알아야하며 사용자 (또는 테마)가 섹션 레이아웃이 이에 적응하는 방식을 지정하도록 허용해야합니다.

이 작업을 수행하는 우아한 방법이 있다고 확신하지만, 단기적으로 편의를 위해 블록이 구성을 통해 중단 점에 대해 "학습"하도록 허용 한 다음 정의 된 값에 대해 쉼표로 구분 된 값 목록을 사용합니다. 중단 점 (여기에서 스크린 샷을 상상해보십시오) :

Columns:        3,2,1,1
Column 1 width: 70%,50% 

기타 (분명히 단일 열은 100 %이며 지정할 필요가 없습니다).

테마 및 플러그인 고려 사항
테마 (또는 플러그인)는 모든 속성을 사용하여 섹션을 정의하고 이러한 모든 속성을 사용자로부터 숨겨 혼란을 방지하거나 테마가 사용자가 수정할 수 있도록 원하는 것만 노출 할 수 있습니다. (예 : 선택한 실제 배경 이미지). 테마 또는 플러그인은 섹션 유형을 지정하기 위해 스타일 시트를 사용하여 번성 항목을 자유롭게 추가 할 수 있습니다 ... 실제로 모든 관리자 상자를 무시하고 사용자로부터 모든 관리자 패널을 숨기고 시트로 모든 스타일을 지정할 수 있습니다. 그러나 이는 사용자가 섹션을 그대로 유지 한 상태에서 테마 이동에서 살아남을 가능성을 제거합니다.

사용자 고려 사항
테마가 멋지게 재생되고 내 블록 내에서 사용할 수있는 다양한 경로를 사용하여 섹션과 해당 속성을 "제대로"정의했다고 가정하고, 테마가 변경되면 해당 속성이 모두 유지되고 지금까지 테마가 사용자에게 숨겨 졌다면 다시 노출. 이는 "사전 스타일 섹션"선택기의 최상위 선택 항목이 "사용자 지정"이므로 사용자가 모든 것을 수정할 수 있으며 이전에 선택한 스타일을 더 이상 사용할 수없는 경우 블록이 기본값으로 설정되기 때문입니다. 직접 스타일 시트 선택이 아닌 테마가 만든 모든 설정은 그대로 유지됩니다.

그렇다고해서 섹션이보기 좋은 방식으로 유지된다는 보장은 없습니다 (초광각 레이아웃이있는 테마가 있고 레이아웃이 좁은 테마로 이동했을 수 있으므로 6 열 섹션이 더 이상 최선의 선택이 아닐 수 있음) ...하지만 여전히 그대로 유지됩니다. 사용자는 해당 레이아웃을 재사용 가능한 블록으로 저장할 수 있습니다.

섹션 스타일을 선택할 때 미리 정의 된 섹션에서 사용자 정의로 이동하면 미리 정의 된 섹션의 관리자 속성이 따르므로 사용자가 테마에서 해당 섹션의 정의를 수정하지 않고도 미리 정의 된 섹션을 수정할 수 있습니다. 플러그인.

구텐베르크 문제
따라서 Gutenberg는 다음을 제대로 수행하지 않습니다.

• 세로로 서로 맞대어 야하는 블록, 때로는 섹션을 이미지화 할 수 있어야합니다.
• 무언가를 flex 또는 grid로 표시하는 모든 종류의 호출. 편집기의 div 수프 때문에 내부 블록 래퍼에서 grid 또는 flex 에 대한 CSS 호출을 설정 해제하고 편집기 블록 중 하나에서 재설정해야합니다.
• 왼쪽 정렬 및 오른쪽 정렬. 이에 대해 버그를 제출했지만 구텐베르크가 왼쪽 또는 오른쪽 블록의 부동을 왼쪽 또는 오른쪽 (또는 가운데)의 데이터 속성을 갖는 블록의 직계 자식으로 만 제한하지 않기 때문에 모든 후속 중첩 블록은 왼쪽 또는 권리.
• 새 블록을 추가하는 것은 종종 삽입 될 완전한 수수께끼입니다 ... 섹션의 맨 아래에 있다고 생각하고 새 내부 블록을 원하고 대신 편집기가 문서 맨 아래에 하나를 삽입합니다.
• 이동 블록에 대한 구텐베르크 드래그 / 드롭 모델은 수평 위치를 가질 수있는 블록에서 안정적으로 작동하지 않습니다.

그것을 시도
누군가가 관심이 있다면 살펴볼 가치가 있다고 생각하는 github에 버전을 드롭하면이 스레드에 링크를 게시 할 것입니다. 나는 이것에 대해 몇 달을 보냈고 아마도 여전히 좋지는 않지만 뭔가입니다.

나는 글꼴, 제목 크기 등과 같은 것은 섹션 블록이 직접 말해야하는 것이 아니라는 것을 강력하게 믿고 있다고 덧붙여 야합니다. 내가 설정하고있는 인스펙터 속성은 테마에서 테마로 섹션의 "큰 그림"속성을 유지하거나 플러그인 제거가 사이트의 외관을 완전히 지루하게하는 것을 방지하는 데 필요한 기본과 같은 느낌을줍니다.

@rogerlos Kadence Blocks를 살펴 보는 것이

나는 글꼴, 제목 크기 등과 같은 것은 섹션 블록이 직접 말해야하는 것이 아니라는 것을 강력하게 믿고 있다고 덧붙여 야합니다.

나는 이것에 전적으로 동의합니다. 한 가지 예외는 섹션 수준 "글꼴 색상"설정입니다. 글꼴이 주로 어두운 사이트는 어두운 배경 이미지 / 오버레이가있는 섹션 내에서 충분히 대비되지 않기 때문에 필요합니다.

다음은 Kadence의 행 레이아웃 블록이 블록 도구 모음의 "정렬 모드"를 재사용하여 세 가지 다른 내부 콘텐츠 너비, 조정 가능한 열 너비, 조정 가능한 위쪽 / 아래쪽 행 여백, 배경 및 텍스트 색상 설정을 허용하는 방법에

이러한 "콘텐츠 섹션 최대 너비"설정은 허용 된 글꼴 색상, 열 거터 크기 등과 같이 전역 적으로 상속 된 구성 요소 제한을 제외하고 섹션 블록이 고려해야하는 거의 유일한 전역 반복 (따라서 테마 정의) 패턴입니다. )

웹 에이전시 경험을 바탕으로받은 디자인에는 콘텐츠 섹션 너비가 3 개 이하입니다. 이 세 가지 너비를 벗어나는 것은 의도적으로 반복되지 않는 방식으로 테마의 디자인 패턴에서 벗어나는 콘텐츠 별 변형 인 경향이 있습니다.

좋은 섹션 블록은 사용자를 테마 정의 기본값 (원래 디자인의 패턴에 따라)으로 안내하지만 때때로 합리적인 방식으로 해당 패턴에서 벗어날 수 있습니다.

모든 화면 크기에서 일관되고 예측 가능한 레이아웃을 적용하기 위해 설정의 루트 수준에서는 "텍스트 지향"블록이 허용되지 않습니다.

모든 비 이미지 / 포함 블록은 루트 수준에서 "섹션"(케이던스 행 레이아웃)에 포함되어야합니다. 이는 테마의 콘텐츠 섹션 너비를 적용하는 동시에 전체 너비 배경뿐 아니라 열 수에 관계없이 완전히 사용자 지정 가능한 행을 허용합니다. 옵션 등

컨테이너 요소는 스택 (Z- 색인)을위한 레이어 요소도 허용해야합니다.
예를 들어 비디오 요소 또는 슬라이더를 배경 또는 시차 효과로 사용할 수 있습니다.

@strarsis 좋은 생각입니다.

이상적으로 섹션 블록은 z-index를 사용하여 전환 가능한 전경 / 배경 편집 모드를 제공합니다.

이렇게하면 섹션 블록 자체가 내장 된 커버 이미지 블록에서 모두 사용할 수있는 배경 이미지 / 오버레이 항목을 재창조하지 않습니다.

배경 콘텐츠는 너비에 의해 제한되지 않으므로 테마 개발자는 섹션 배경에 들어갈 수있는 블록을 정의 할 수 있어야합니다. 전경 콘텐츠의 너비는 테마에서 제공하는 특정 수의 최대 너비로 제한됩니다.

사용자가 특정 콘텐츠가 주어진 경우 기본 너비에서 벗어나야하는 경우 다음으로 큰 너비의 섹션을 선택하고 그에 따라 측면을 채울 수 있습니다.

전경 콘텐츠가 섹션의 최대 너비를 벗어나 시각적으로 분리되어야하는 인스턴스는 해당 특정 블록에서 음의 여백을 조정하는 스타일 변형 으로 등록해야합니다.

그 이유는 사용자가 패딩 값을 조정하는 것은 매우 안전하지만 음수 여백이 사용자 정의 된 것이되는 것을 원하지 않기 때문입니다.

편집기에서 정의 음의 여백을 허용하는 것은 다양한 화면 크기, 콘텐츠 섹션 측면 패딩, 특정 중단 점의 거터 너비 등에 응답 할 때 엉망이 될 수 있으므로 테마 / 코드와 밀접하게 결합되고 상위 수준 추상화로 노출되어야합니다. 최종 사용자에게.

개발자 제어 관련 : "하드"컨테이너를 제공하는 메시 플러그인 이 있습니다.
주제에 의해 강제되어야합니다.
테마는 때때로 전체 페이지의 왼쪽 상단 모서리와 같이 사용 가능한 영역을 제한해야합니다.
구텐베르크는 페이지 편집기 내에서 이러한 "하드"컨테이너를 설정하기위한 테마 메커니즘을 제공해야합니다.

@strarsis 제 생각에 the_content() 영역 밖에서 일어나는 일은 구텐베르크 편집자 내부에서 아무 일도하지 않습니다.

이러한 "영역"은 페이지 콘텐츠가 아닌 페이지 템플릿 의 일부이므로 다른 곳에서 처리해야합니다.

페이지 콘텐츠 대 페이지 템플릿 (/ 레이아웃)

에디터 내부의 콘텐츠 / 섹션은 주변 레이아웃이 존재하지 않는다고 가정하고 (편집 중), 대신 특정 레이아웃 (프론트 엔드) 내부에 배치 할 때 적절하게 반응 할 수 있도록 준비해야합니다.

다음과 같은 경우 요소는 페이지 템플릿 ( 페이지 콘텐츠 아님)의 일부입니다.

1. 요소는 전체적으로 the_content() 영역의 구조, 경계 또는 위치를 정의하거나 이에 따라 달라집니다.
2. 요소가 반복되는 패턴의 일부입니다 (예 : 두 개 이상의 영구 링크에서 볼 수 있음).

경험 기반 배경

반복 템플릿 / 레이아웃 요소는 일반적으로 사용자 지정 게시물 유형에 따라 다르며 콘텐츠 히어로, 콘텐츠 사이드 바 및 콘텐츠 바닥 글을 포함합니다.

모든 경우에서 이러한 레이아웃 요소 내의 콘텐츠는 블록 수준이 아닌 포스트 수준에있는 사용자 지정 필드, 분류법 또는 기타 설정에있는 정보에서 충분히 파생된다는 것을 발견했습니다.

그리고 모든 경우에서 구텐베르크 편집기 내에서 이러한 섹션을 블록으로 구현했다면 이러한 섹션을 대량 수정하거나 스타일을 다시 지정하는 것은 놀라운 작업이 될 것이라는 내 믿음을 강화했습니다.

그래서 마침내

섹션의 정의 (및 최종 구현)는 the_content() 와 관련된 테마 디자인 패턴의 요구를 처리 할 수있을만큼만 확장되어야합니다.

"내용"이 아닌 "템플릿"에 속하는 모든 것은 섹션 블록 외부 및 구텐베르크 편집기 외부에서 처리해야합니다 (현재).

나는 구텐베르크가 다른 모든 사람들처럼 콘텐츠와 함께 템플릿 인라인을 할 수 있기를 원하지만 아직 거기에 있지 않은 것 같고 템플릿을 적절하게 처리하기 전에이 섹션 블록을 확실히해야합니다.

며칠 전에 기본 레이아웃을 만들고 싶었고 이것이 필요했습니다. 그래서 나는 플러그인 A를 설치하는 것으로 시작했고 시도했지만 버그가있었습니다. 제거, 플러그인 B 발견, 설치, 섹션 블록 시도, baaad. 다음 플러그인 C 버그, 플러그인 D는 그것을 컨테이너라고 불렀고 그것은 meh였습니다. 다음 플러그인 E, F .........
현재 구텐베르크의 "생태계"는 페이지를 만들고 콘텐츠를 작성하려는 경우 매우 실망 스럽습니다.
여기 사람들이 계속해서 "플러그인 X를보세요", "이 기능을 원한다면 플러그인 Y를 설치하세요"등을 말하는 것은 사람들이 이것을 필요로한다는 분명한 표시입니다. 그들은 그것을 원하지 않습니다. 그들은 그것을 필요로 합니다. 현재 컨테이너 / 섹션 / whatever-you-wanna-call-it의 자체 구현이있는 12 개의 플러그인이 있습니다.
구텐베르크가 태양 아래 모든 기능을 추가해야한다고 말하는 것은 아니지만 이것은 기본적인 기능입니다. 거기에 있어야합니다. 생각할 수있는 모든 옵션을 가질 필요는 없지만 기본이 있어야하며 필요한 경우 개발자가 확장 할 수 있습니다.
우리는 기본 컨테이너에 대해 20 가지 다른 구현이있을 것이고 그들 중 어느 것도 제대로 작동하지 않을 것입니다 (물론 개인적인 의견).

쉬운 대안으로 단순히 열 블록을 사용하고 열 수를 1로 설정했습니다 (슬라이더는 2와 6 사이로 제한되지만 입력 필드에 1을 입력 할 수 있습니다). 그 후 관리자에서 CSS를 수정해야합니다.

//Allow single columns
add_action('admin_head', 'gutenberg_allow_single_columns');
function gutenberg_allow_single_columns() {
    ?>
    <style type="text/css">
    <strong i="6">@media</strong> (min-width: 600px) {
        .wp-block-columns.has-1-columns > .editor-inner-blocks > .editor-block-list__layout > [data-type="core/column"] {
            flex-basis: 100% !important;
            flex-grow: 0; } }
    </style>
    <?php
}

물론 프런트 엔드에서도 동일하게 설정해야하지만 이는 테마 문제입니다. 단일 열 레이아웃을 허용하면 기본 컨테이너 옵션에 충분할 것이라고 생각하며 일반적으로 스타일링 목적으로 필요합니다. 그 밖의 모든 것 (배경, Z- 색인, 시차 설정 등)은 플러그인 imo로 수행해야합니다.

그리고 테마 (개발자)에 대한 수단을 추가하여 사용되는 래퍼의 수와 수를 제어하십시오.
일부 디자인에는 하나 이상의 요소 만 필요합니다. 현재 컨테이너 요소에 대해 다른 플러그인을 사용한 다음 스타일링을 위해 컨테이너 콘텐츠를 추가 래퍼 요소로 래핑하기 위해 PHP 파서를 사용하여 전체 콘텐츠를 구문 분석해야합니다.

@strarsis 이것은 확실히 처음부터해야 할 일입니다.

게시물 콘텐츠의 적절한 스타일링을 수행하려면 각 루트 수준 자식을 일관된 행 / 섹션에 배치해야합니다.

예를 들어, 각 행을 래핑하지 않고 너비가 다른 섹션 (특히 전체 너비 섹션)을 수행하는 것은 어렵고 엉망입니다.

PHP 구문 분석 옵션도 고려했지만 콘텐츠 편집기에서 특정 콘텐츠가 어떤 유형의 섹션에 있는지 제어 할 수 없다는 것을 깨달았습니다.

대신 설정에서 모든 게시물 / 페이지 / 게시물 유형에 대해 루트 수준에서 단일 컨테이너 블록 만 허용하도록 Gutenberg 편집기의 모든 인스턴스를 강제합니다.

루트 컨테이너 블록은 내부에 추가 할 수있는 제한된 블록 하위 집합을 적용합니다.

텍스트 또는 전체 너비가 아닌 블록을 추가하려면 먼저 Kadence Row Layout을 삽입해야합니다.이 경우 기본 섹션 래퍼 요소 역할을합니다.

간단한 확장 가능한 컨테이너 블록은 코어 내에서 필요한 모든 것입니다. 스타일링과 관련하여이 블록을 확장하는 것은 플러그인 / 테마 개발자에게 맡겨야합니다. 또한 자체 컨테이너 블록을 구축하려는 개발자에게 폴백 변환 상태를 제공해야합니다.

내가 테스트 한 컨테이너 / 섹션 / 행을 제공하는 기존의 모든 타사 플러그인은 콘텐츠 잠금과 관련하여 중요한 문제가 있습니다. 이러한 플러그인을 비활성화하면 내부 블록 콘텐츠에 더 이상 편집기 내에서 액세스 할 수 없으며이를 변환하면 HTML이 제거됩니다. 사용자가 완전히 알고 있어야하는 것.

보다:
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

확인. 나는 Gutengerg를 테스트했지만 좋지만 예, 확실히 섹션이 부족합니다.
사실, 많은 블록에는 CSS 클래스를 추가 할 수있는 컨테이너가 있으며 스타일이 지정됩니다. 그러나 주요 내용은 컨테이너없이 작성되므로 클래스도 아니므로 스타일을 지정할 수 없습니다. 그리고 주요 내용은 다른 모든 블록과 동일한 단계에서 작성되기 때문에 다른 블록과 다르게 상자를 만들기가 매우 어렵습니다.

다시 말해, 클래식으로 돌아가서 섹션을 제공 할 때까지 기다릴 것입니다.

감사합니다.

네, 맞습니다. 현재 개발중인 다른 모든 블록보다 훨씬 더 중요하다고 생각합니다. @youknowriad 더 우선 순위를 줄 수 없습니까?

이미 2 단계 범위 https://github.com/WordPress/gutenberg/issues/13113에 있습니다.

@youknowriad 저는 개발자가 아닙니다. 하지만 이미 개발이 진행 중이 었음을 기억합니다. Wordpress 5가 출시되기 직전에 이미 매우 진보 된 PR이있었습니다. 아직 명확히해야 할 세부 사항이 있었지만 거의 준비가되었습니다. 불행히도 더 이상 PR을 찾을 수 없습니다. 그게 어디인지 아는 사람 있나요?

예, 이해합니다.

여기에 PR이 있습니다. https://github.com/WordPress/gutenberg/pull/10562

나는 그것이 오픈 소스 프로젝트이며 자원 봉사를 기반으로 함을 분명히하고 싶었습니다. 나는 글로벌 방향을 제시하고 도움을 요청할 수 있지만 사람을 배정하지는 않습니다. 사람들은 다르게 생각하는 경향이 있습니다.

이 문제가 더 빨리 발생하는 것을보고 도움을 받고자하는 개발자가 있다면 Core Slack # core-editor 채널 (및 회의)의 주간 회의에 오신 것을 환영하며 토론 / 협업 / 도움을 요청합니다.

Ahhh 그래 그게 다야! 큰! 당신은 개요가 있습니다 !!!

예, 그것은 사실이며 비난해서는 안됩니다. 내가 스스로에게 간단히 물었던 것 : 중요하고 더 중요한 작업이 없습니까? 50 명이 RSS 블록이 필요하지만 1000 명이 컨테이너 블록이 필요하다면 전체를보다 구체적으로 집중하는 것이 좋습니다. 컨테이너 블록은 이제 이국적이지 않습니다. 나는 이것이 모든 디자인의 기본이라고 생각합니다.

오해하지 마십시오. 당신은 훌륭한 일을하고 있습니다. 그리고 2 단계 리더로서 당신은 일류 일을하고 있습니다. 집중 문제에 관한 것입니다. 다음 슬랙 채팅에서 건배 할게요 ... ;-)

다시 한번 감사드립니다!

감사하고 명확히 해 드리겠습니다. 나는 그들에게 개인적으로 동일한 중요성을 부여합니다. 2 단계의 중간 단계는 위젯 화면에서 블록을 사용하는 것입니다. 따라서 사람들이 RSS 블록을 요청하지 않더라도 위젯 화면 (2 단계의 중요한 단계)에서 블록을 사용하게되면 사람들이 사용하는 RSS 위젯을 찾지 못하면 그것에 대해 불평합니다.

이 두 작업은 모두 복잡성 측면에서 "중간"작업이며 기능 측면에서는 중요하지만 프레임 워크 측면에서는 중요하지 않습니다. 현재 제 개인적으로 가장 우선 순위가 높은 것은 2 단계 목표 (위젯 화면의 블록, post_content 외부의 편집기)를 가능하게하는 프레임 워크입니다. 이러한 콘셉트 문제는 조만간 실험하고 명확히하는 데 중요하기 때문입니다.

확인. 나는 Gutengerg를 테스트했지만 좋지만 예, 확실히 섹션이 부족합니다.
사실, 많은 블록에는 CSS 클래스를 추가 할 수있는 컨테이너가 있으며 스타일이 지정됩니다. 그러나 주요 내용은 컨테이너없이 작성되므로 클래스도 아니므로 스타일을 지정할 수 없습니다. 그리고 주요 내용은 다른 모든 블록과 동일한 단계에서 작성되기 때문에 다른 블록과 다르게 상자를 만들기가 매우 어렵습니다.

다시 말해, 클래식으로 돌아가서 섹션을 제공 할 때까지 기다릴 것입니다.

감사합니다.

이것이 새로운 블록 편집기가 형성 될 때까지 이것과 다른 단점에 대해 제가 취하고있는 입장입니다. 새 편집기에 좋은 측면이 있기 때문에 이런 일이 발생하기를 바랍니다.

섹션 블록은 굉장 할 것입니다. 백엔드 개발 기술이 부족하더라도 무엇을 도울 수 있습니까?

지금은 많은 블록 플러그인이 있지만 내가 원하는 유일한 블록은 섹션 또는 컨테이너 블록이므로 하나가 추가되는 것을보고 싶습니다.

워드 프레스 코어는 블록 편집기를위한 섹션, 행, 열 레이아웃 구조의 자체 구현, 표준 및 모든 타사 플러그인, 테마 및 페이지 빌더에서 사용할 수있는 구조를 포함해야합니다. 이전에 여러 번 언급했듯이 API가 제공되어야 자체 인터페이스, 종소리 및 휘파람을 추가 할 수 있습니다. 이러한 타사 솔루션을 끄면 페이지 구조가 그대로 유지됩니다.

모든 방향에서 오는 섹션 / 행에 대한 타사 솔루션이 있지만 기본 코어 블록과 타사 블록에서 혼합을 시작하면 많은 불일치와 블록이 충돌하고 해결해야하는 것을 볼 수 있습니다. 레이아웃에 대한 이러한 솔루션을 제공하는 사람들의 노력을 비판하고 싶지는 않지만 필요한 기능을 채우고 있습니다. 그들 중 많은 것이 좋지만 전반적인 경험에 대해 뭔가 옳지 않습니다.

저는 핵심 블록 편집기를 단순하게 유지하여 제 3자가 추가 기능과 정교함을 추가 할 수 있도록했지만, 실제로 강화해야합니다. 그렇지 않으면 수용에 대한 관심을 얻는 것이 매우 쉽게 달성되지 않을 것입니다.

여기서 큰 질문은 누가 그것을 처리하는지입니다. 그것을 할 시간과 에너지가있는 개발자가 몇 명 있지 않습니까?

예, 예, 예! 나는 유연한 섹션 블록이 구텐베르크에서 가장 큰 누락 된 기능이라고 생각합니다.

아직 존재하지 않는 다니 믿을 수가 없어 ...

대안은 열 블록에 단 하나의 열만 포함하고 배경색을 열로 설정하는 것입니다. TA-DA : 섹션 블록.

글쎄요, 누군가에게 도움이된다면 : 우리는 얼마 전에 우리 프로젝트를 위해 Block 섹션을 썼습니다. 나는 그것이 어떤 시점에서 예쁘게 될 수 있다고 확신하지만 좋은 출발점이 될 수 있습니다.

https://github.com/Impuls-Werbeagentur/impuls-section-block

이 작업에 손을 올릴 것입니다. 다음 주 중순부터 시작할 수있을거야

@chrisvanpatten- 전에 이것에 대해 정말 좋은 진전을 그냥 제가 이걸 받아도 괜찮은지 확인하고 싶었나요?

플러그인에서 일부 컨테이너 블록을 사용했습니다. 주요 요구 사항은 컨테이너의 배경을 변경하기 위해 넓고 완전한 정렬, 플로트 및 컨트롤을 지원하는 것입니다. 첫 번째 버전으로 제공하는 것을 목표로하면 추가 개선을위한 좋은 기반이 될 것입니다.

첫 번째 개선은 모든 블록 외부에 더 많은 래퍼를 추가하는 것입니다.

예를 들면 :

<div class="wp-block-paragraph">
  <div class="wp-block-paragraph__container">
    <InnerContent />
  </div>
</div>

현재 많은 요소가 직접 삽입되어 래퍼를 만들기 위해 스타일링을 적용하는 것을 방지합니다.

<ol>
  <li></li>
</ol>

그것에 래퍼를 추가 할 수 있습니다.

<div class="wp-block-listing">
  <div class="wp-block-listing__container">
    <ol>
      <li></li>
    </ol>
  </div>
</div>

그런 다음 컨테이너 세트를 적용하여 일치 상태를 유지할 수 있습니다.

// Example
#content > * > * {
  max-width: 1280px;
  padding: 0 20px;
}

@talldan 은이 문제에 대해 관심을 대체 '상태를 제공하기 위해 Core Container 블록이 필요하다는 의견을받는 것이 좋습니다.
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

섹션 블록은 굉장 할 것이지만 의미 론적 마크 업 만 만드십시오! 의미 론적 HTML 구조로 유지하면 가장 불가지론적인 코드 기반이 생성됩니다.
<section>, <article>, <header> 가 <div class="wp-section"> 또는 무엇이든 훨씬 낫습니다.

@talldan 귀하의 의견을 놓쳐서 미안합니다. 그러나 나는 당신이 이것을 받아들이는 것에 대해 100 % 괜찮습니다 🙌 나는 당신이 그것을 흔들 것이라고 확신합니다!

또한 텍스트 및 미디어 블록 # 10925의 초점을 사용할 수 있으면 좋을 것입니다. 물론 이것은 이미지 배경이있는 경우에만 의미가 있습니다.

그건 그렇고, 많은 페이지 빌더도 가지고있는 대단한 일입니다. 또는 적어도 다음과 같습니다.

초점 선택기가 여기에 훌륭하다는 데 동의했습니다. 커버 블록에서 정말 잘 작동합니다!

이를 염두에두고 섹션 블록에 대한 이전 모형을 업데이트했습니다. 조정 가능한 배경색과 이미지가있는 순전히 컨테이너 요소로 작동합니다.

미리보기 :

여기서 프로토 타입을 확인할 수 있습니다 .

몇 가지 추가 참고 사항 :

• 시작하려면 배경 이미지없이 배경 / 텍스트 색상 만 시작해야한다고 생각합니다. 그것을 밀어 내면 다음으로 배경 이미지를 만들 수 있습니다. 이것은 기존 패턴을 사용하여 신속하게 처리하고 여전히 수많은 사용 사례를 다루어야합니다.
  
  
  
  • 첫 번째 버전을 병합하면 텍스트 블록에서 배경과 텍스트 색상을 잠재적으로 사용하지 않을 수 있습니다. 대신 단락 블록에 인라인 색상 옵션 / 강조 옵션을 사용할 수 있습니다. 이것은 단락에 대해 전반적으로 더 나은 패턴 인 것 같습니다.
  
  
• 이 블록은 항상 컨테이너 일 뿐이므로 반응 형 설정을 포함하지 않습니다. 컨테이너 내부의 콘텐츠 (예 : 열 블록)는 반응 형 동작을 제공합니다.

동의합니다. 당분간 필요한 경우 CSS를 사용하여 배경 이미지를 추가 할 수 있습니다. + 1 :

첫 번째 버전을 병합하면 텍스트 블록에서 배경과 텍스트 색상을 잠재적으로 사용하지 않을 수 있습니다. 대신 단락 블록에 인라인 색상 옵션 / 강조 옵션을 사용할 수 있습니다. 이것은 단락에 대해 전반적으로 더 나은 패턴 인 것 같습니다.

섹션 블록을 블록 레벨 색상의 올바른 위치로 간주하는 이유 중 하나는 목록, 제목 및 기타 기본 텍스트 블록에 이러한 색상 옵션이없는 이유에 대해 답해야하기 때문입니다. 그리고 그것들은 블록 수준에서 분할되기 때문에 모든 것을 연속적으로 확장하는 배경 이미지를 가질 수 없지만 섹션 블록은이를 수정합니다.

이러한 색상을 사용하지 않는 방법은 잠재적으로 UI를 제거하고 기존 블록의 스타일을 그대로 유지하는 것입니다.

좋은! 수직 패딩을 위해 소형 / 중형 / 대형 클래스를 갖는 것이 유용 할 것입니다.

좋은! 수직 패딩을 위해 소형 / 중형 / 대형 클래스를 갖는 것이 유용 할 것입니다.

이것은 테마 / 프레임 워크 수준으로 떨어지며 코어에 https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing 과 같은 위치가 있는지 확실하지 않습니다.

시작하려면 배경 이미지없이 시작해야한다고 생각합니다.

더 이상 동의 할 수 없습니다. v1을 꺼내면 v2가 더 복잡한 기능을 추가 할 수 있습니다.

이 블록에는 반응 형 설정이 포함되지 않습니다.

동의 함-이 블록은 가능한 한 간단하고 의견이 없어야합니다.

가능하면 이 PR을 병합해야한다고 생각합니다.

나는 다음과 같은 것을 쳤습니다 ... 플러그인으로 출시되었습니다.

https://wordpress.org/plugins/magic-block/

사람들이 그것에 의존하게 만드는 더 이상 플러그인은 없습니다. 이미 저주받은 블록을 놓아주세요.

@webdados 나는 이것을 두 번째.

다른 사람의 작업을 줄이려는 것은 아니지만, 우리는 이것이 실제로 어떤 수준에서 내장되어야합니다.

특히이 문제 가있는 세상에서.

# 13391에 대한 적절한 솔루션을 찾으면 수많은 컨테이너 블록 구현이 있으면 괜찮을 것입니다.

새로운 블록 빌더가 제 3 자 플러그인이 확장 할 수있는 레이아웃 요소 (컨테이너, 섹션, 행 열)에 대한 표준 기반을 갖출 때까지 아무 것도없고 제 3 자 블록, 테마, 빌더 ( 레이아웃 문제를 해결하려는 사용자) 콘텐츠와 페이지 레이아웃을 잃게됩니다.

이 기능은 언제 기대할 수 있습니까?

이미 최신 버전이어야합니다.
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere : 플러그인 v5.5.0의 변경 로그가 비어 있기 때문에 놓쳤습니다.

지금까지 이것에 대한 구현을 정말로 파헤 치고 있습니다. 5.5에서 방금 출시 된 것으로 알고 있지만, 배경 이미지 (및 위치), 배경 색상 불투명도 등에 대한 추가 기능이 언제 추가 될지 궁금합니다. 2019 년 말 이전에 예상해야 할 사항인가요, 아니면 더 오래 이야기할까요? -그보다 용어?

@nathansnelgrove 의견을 보내 주셔서 감사합니다. 그룹 블록에는 확실히 몇 가지 개선 사항이 있으며 다음은 이미 진행중인 두 가지입니다.

• 스타일링을 더 쉽게하기 위해 내부 컨테이너 추가-https: //github.com/WordPress/gutenberg/pull/15210
• 블록의 선택을 그룹 해제 / 그룹화 편집기 옵션을 추가 - https://github.com/WordPress/gutenberg/pull/14908

배경 이미지 및 불투명도에 대해 언급 한 문제를 어디에서나 추적하지 못했습니다. 이제이 문제가 종결 될 때까지 시간이 있다면 별도의 문제를 만드는 것이 좋습니다.

배경 이미지 / 색상 / 불투명도는 원래 제안에서 가져온 것입니다. 새로운 문제를 만들어 보겠습니다.

방금 WordPress 5.2.4를 설치했는데 "섹션"또는 "그룹"블록을 찾을 수 없습니다. 여기서 무슨 일이 일어나고 있습니까?

@patrikhuber : 11 월 12 일 출시 예정인 워드 프레스 5.3에 포함될 예정입니다.

@noisysocks 정말 감사합니다!