Categories
Asides

WCEU Open Thread

I just wrapped up a fun session with Matías and Brian, and though we covered a lot of ground we weren’t able to get to all the questions from the audience. Starting at 2:58:

So this is an open thread, if you have any question from the talk please drop it in the comments here, and myself or someone in the community will respond! We’ll keep this open for a day or so.

25 replies on “WCEU Open Thread”

First of all, really loved your talk! When it comes to open contribution and communities, what do you believe are the WordPress sub-communities that should become stronger to support the growth of the ecosystem over the coming years (such as: security community, hosting community, design community, etc.)?

There aren’t really any teams in the WordPress project that we can do without. If I were to look at this question as “which teams desperately need more contributors” I think they are: Plugins, Docs, Training, Polyglots, Security, Design/Accessibility, and Test/Triage.

Hey! I had a question about the control developers can have on what users can build with FSE.

As a web agency, our main concern is that clients could end up adding things we wouldn’t intend them to be able to do (say, a video in a header) and break what we design.

We want to give them as much control as possible, but the ability to restrain what blocks can go inside a container we define would be great, especially for things like homepages which we need to lock down a little more than the rest of the content pages.

How do you see the balance between unique designs an agency would create, and the freedom of Gutenberg?

Good question. There are a few mechanisms to restrict template editing either entirely or partially. You can use the templateLock attribute on group and column blocks to restrict insertion of new blocks, or the ability to move blocks within an area, or both. If you are creating your own blocks there’s further tweaks you can apply, like specifying a list of what blocks should be available. There are more planned improvements to the locking system that would make this more flexible and intuitive.

I really liked the feature video teaser! This kind of marketing is (in my opinion) essential in “selling” the new features as something desirable. Showing patterns also helped and deploying a lot of visual design based on them across the board is important. Specially if WordPress uses them across its products and pages as design cases. The topic of two backend types was interesting: In my opinion even if administration (like the mentioned plugin maintenance) doesn’t need to be immediately revamped a fresh coat of paint wouldn’t hurt to ease the transition. Clients are still dealing with both worlds and the current full-screen takeover often feels disorienting with the constant reminder of the two separate spaces and design languages. Also, if the ecosystem is going to support third-party builder (Gutenberg alternatives or variations like IceBerg), there should be some way to set the “default” editor. Now exiting a “builder” reveals Gutenberg underneath and most buttons are redundant (like in list view: multiple edit links). I was on team TextPattern when WordPress came out (coding on an island in the Mediterranean Sea, working from a satellite internet connection) and loved the elegance of it. But a regular expression-based template system might have been the wrong approach (apart from the license problems in the beginning). Long time ago! Congratulations on this remarkable growth and journey and making the right calls back then! Regards from Berlin.

I am interested in the plans for the Classic Editor plug-in, which I am using on a site that I just transferred from Joomla (that is enough of a project for this amateur, let alone figuring out how to use Gutenberg). I also work on a old wordpress.com site from about 2009 (getfisaright.wordpress.com); though there are only a few posts per year, those few are important and we our use of digital media to get the new president’s attention was novel at the time; only a footnote to history, but one I would like to ensure remains at least minimally active.
I have also more recently started on maintenance teams for a couple of newer wordpress.org sites, so updating a lot of my knowledge.

Classic editor is an option, but if you wanted some of the best of the old and new you can always use a single classic block instead. Also remember that you can hide a lot of Gutenberg if you want! We’ve actually found it pretty intuitive for new users just writing, as they don’t have to use any blocks they don’t need, they can just type and press enter and make a post. As much as possible the sooner you can teach someone the Gutenberg interface the better, as it’s the basis for the next decade or two of WordPress.

@Matías: Thank you for the kind advice on the REST API and how to get the Gutenberg styles integrated in the design on the client side. You mentioned that there were some tools, that could help – but did not mention the names of these tools. If you could elaborate a bit on such tools it could be helpful for many frontenders trying to integrate the Gutenberg experience with HTML / JavaScript solutions.

Definitely! The main tool I had in mind was the upcoming `theme.json` support, which will allow you to consume style declarations in different ways on the frontend. This theme file codifies many of the style attributes of blocks and presets and is in a format well suited for a REST or decoupled consumption. Also depending on what type of use you are looking for there are different options. For example, for more fine grained control you might want to check the enqueue_block_styles_assets() function and the styles registry. Frontity is also doing some cool things with blocks and site editing from a JS frontend if you want to check it out for ideas.

There’s a ton of things to still explore here, so if you have some more concrete use cases in mind, please share them.

Hi Matías Thank you for these ideas. My use case is this:

I teach WordPress to students at the Business Academy in Aarhus, Denmark. When they work with content in Gutenbert, they would like to get a result like what they see.

They are also intoduced to the REST API.

Ideally I am looking for a simple solution that is easy to use for a student beginning to explore JavaScript and API – soon they will continue with internships. And of course the business would asume that they could get a result with the cool design developed in Gutenberg.

It is surprisingly hard to find such information, so I really appreciate your suggestions in the reply.

(PS: I tried to reply a moment ago, but there was an error of some kind, so I try again)

Hi again Matás:

I tried the enqueue_block_styles_assets() in a child theme – and with a good result. In the head section of the rendered HTML in Twentytwentyone this stylesheet was found:

../wp-includes/css/dist/block-library/style.min.css/wp-includes/css/dist/block-library/style.min.css

Now image effects etc. work like a charm – that was just the tip we needed 🙂

This was a great session! I really liked Matt’s thoughts on the importance of contributing, and the genuine commitment to community input making a better web. The WordPress community is amazingly friendly as a whole, but gotta be honest…contributing to such a huge, global group of intelligent people on such a large, widely used system can be a little overwhelming! Can you highlight some of the ways you’re encouraging psychological safety amongst contributors of all levels?

We can’t guarantee anyone will feel a certain way, but we can take strong responsibility for our personal actions. In my communications I try to keep in mind a VIEW mindset, which stands for being vulnerable, impartial, acting with empathy, and keeping a sense of wonder or curiosity in interactions.

Matt’s right about having an expectation for people to take responsibility for the way they treat others. There are a few specific “best practices” that you can see within teams, too.

– Many teams will open meetings with information about who is there, what work gets done, how we treat each other, and an invitation to any new contributors who aren’t comfortable speaking up yet.
– There are also teams that host regular office hours so anyone who has questions but doesn’t want to “interrupt” team meetings has a time to do that.
– Core in particular has a meeting specifically for new contributors (hosted by some of our most knowledgable contributors) where they look at good first bugs, discuss what is needed, and answer tons of questions.
– Some of our teams have a contributor role that’s just for welcoming new folks they say checking in at meetings.

As more of a personal anecdote, I observed Core team chats for about two years before finally speaking up in any of them for a lot of the same reasons you’re sharing! I know that the first few tries are a little scary and also can overwhelm you pretty fast. 🙂

Hey Marissa. This is a very valid question. The WordPress project is a community effort. That means no one company nor one individual has the weight of it all upon them. We work as a team. Many of us step in to support each other if we need to take some time away or have schedule conflicts.

If I feel that my situation is not as safe as I’d like, I know I can turn to others within my team and also project leadership to intervene. This is true in our online presence, as well as in person events as well. We have regular contributors to the project who assume an alias and never reveal their likeness in photos or on camera in any means. Their contribution is not diminished by their pursuit of anonymity.

We apply the Code of Conduct to in-person, and I believe online interactions as well. https://make.wordpress.org/community/handbook/wordcamp-organizer/planning-details/code-of-conduct/. The incident report info is at https://make.wordpress.org/community/handbook/wordcamp-organizer/planning-details/code-of-conduct/incident-reporting/. The team doing this work does review all incoming concerns.

Greeting from Bhutan @matt
Is Classic Editor going to be permanently removed as we’re notified with the given date until December 31, 2021 by introduction to the new Full Site Editing to WordPress?

It’s pretty easy to keep the Classic Editor plugin working for now, but people who stay on it are definitely having a much worse WordPress experience, and it’ll get worse every year. In 2018 we only wanted to promise to keep it going until 2022, but we’ll evaluate how it’s going toward the end of 2021 and it probably won’t be hard to extend its support another year.

Following Matt’s suggestion I briefly toyed with the idea of creating a periodical table for blocks but decided against it for a number of reasons. 1. I felt the periodic table more suited to HTML elements. 2. Blocks are compounds or genes. 3. Is it treading on Elementor’s toes? 4. There are more pressing issues.

The more pressing issues are related to replacing meta boxes with blocks. There needs to be a lot more work done to provide examples and documentation indicating how to achieve this. Are you aware of any block plugins that have successfully reimplemented meta boxes as blocks? When is WooCommerce going to join the game?

Howdy! I’m assuming you’re referencing the WooCommerce product editor in relation to meta-boxes? If so, you’re aware we haven’t enabled the block editor for this yet but it is something we’ve been deliberating on.

As you can imagine there are some unique nuances to work through with a data heavy interface such as the current Woo Product Editor (not only for managing product data but also around extensibility as well). We do have ideas though and I personally hope to see some work on this soonish.

In the meantime, there’s lots of learning my team at Woo is gaining around WooCommerce Blocks (in particular what we’re building with Cart and Checkout blocks as a part of a new checkout flow).

Hi Matt!

I was really interested to find out more about full site editing over the course of WCEU, and I’m excited to give it a try. A couple of potential challenges do spring to mind though.

The switch to FSE themes is a huge change to the way we build and structure them, and I think it’s a far greater jump than the new editor was (blocks in the_content vs building a whole theme around the Gutenberg paradigm). Do you think it’s difficult to balance such a leap with the “Ship of Theseus” idea of backwards compatibility and continuity we’ve always had as part of WP? It feels to me like there’ll be a sharp divide in themes between pre-FSE and post-FSE (converting a theme is pretty much a full rewrite).

Secondly, looking at FSE and Gutenberg in general, it’s clear that more and more of a site’s identity, layout and presentation is going to be blocks (and therefore the database rather than files). What are your thoughts on the impact on things like version control, collaborative working and merging with git etc? Do you think something like VersionPress is where we’re headed?

SHARE YOUR THOUGHTS