Birgit Pauli-Haack

Hi there @sharkeyx – Sorry, you have had problems accessing the plugin. Does that still occur with the newest version of the plugin?
If yes, could you please provide which WordPress version and which theme you are using? There could be plugin conflict as well… I’d be happy to assist with troubleshooting this issue with you.

Hi @cheonmu Is it possible that the classic editor is the default editor? Do you have the classic editor plugin installed? If yes, you might need to test your calls with different settings.
See Screenshot of the Classic Editor plugin

You can also check out the storybook and generate the code via the interface there. https://wordpress.github.io/gutenberg/?path=/docs/components-colorpicker–docs

Hi there. I only skimmed your block code, and couldn’t find anything obvious that would cause the Footnotes block not to provided you with a text block to enter the information.

I see in your video that you also have additional plugins installed on your site. Did you try deactivating all of them except for the plugin you are testing, and see if you can eliminate possible plugin conflicts? The plugin Health Check & Troubleshooting allows you do troubleshoot your site by deactivating plugins (and themes) only for the Admin user, and leaving the front end intact for your visitors. It’s the fastest way to start eliminating conflicts. Let use know if that makes a difference.

Every so often it helps, especially with links, to go to ‘Settings > Permalinks and click on the save button twice. (I am aware that it sounds a bit counterintuitive) Try it.

@andrewcodes404 JSON is definitely something to get used to. I myself are still a novice at handling styling and layout via theme.json. Nevertheless, I noticed a couple of things.

If this works
.b-h2 {max-width: 1160px;margin: 0 auto;}

Then you might need to rewrite the json piece:
"core/heading": {
"css": "max-width: 1160px; margin: 0 auto;"
}

The CSS field in the theme.json takes pure CSS.

In the styles section (first code examples), the elements value needs to be actual HTML tag representation, so they are not “heading” but h1, h2 etc.

You could try something like this…

"styles": {
      "blocks": {
           "core/heading": {
                 "typography": {
                      "fontWeight": "700",
                      "lineHeight": "1.1"
                  },
                "spacing":{
                      "margin":"0",
                  },
             "css": "max-width: 1160px;"
             },
      }
}

Reading resources, you probably already studied:

• Custom CSS for global styles and per block (Dev Note 6.2)
• On theme.json and style variations

But WordPress is saying it is going away by dropping support for the Classic Editor and Classic Widgets.

There might be misunderstanding of what the Classic Editor plugin does. It gives a user interface to have a site owner and content creator make choices toward the usage of the block editor.

It is basically a GUI using available block filters to disable the block editor. Here is the corresponding DevNote from the WordPress 5.0 release. AFAIK, there are no plans to discontinue these filters as they are also used by core to support, for instance, post types that set the “show_in_rest” to false. It then automatically loads the TinyMCE editor for the Edit screen of the post_type in WP-admin, even if the classic editor plugin is not installed.

Similarly, the Classic Widget plugin is also more meant to support #nocode site owners and site builders providing UI to core filters, agency developer could use directly in their theme’s functions php. The documentation is available her.
Furthermore, AFAIK, no efforts are contemplated to discontinue these filters. They are part of the backwards compatibility promise WordPress makes.

I hope this alleviates some uncertainty about the future viability of conventional themes and plugins.

As for disable features in the block-editor the theme.json can also be used in conventional themes to easy the control of the block editor. Here is a post on how this works by a Gutenberg contributor.

• This reply was modified 3 years ago by Birgit Pauli-Haack.
• This reply was modified 3 years ago by Birgit Pauli-Haack.

It really seems, this ship has sailed. After four years and hundreds of millions downloads, the Block editor is here to stay. It also had received a ton of updates and improvements over those years, and you might want to take another look at it.

You can certainly use the classic editor plugin and the classic widgets plugin, all also built by WordPress contributors to hide all block editor stuff and use your existing processes and tools.

I’d be happy to connect with you and discuss adoption pathways, of you change your mind.

Hi there. There is definitely a steep learning curve to development for and around the block editor, especially if JavaScript is not your primary development language. It’s hard to be a newbie again and learn something new. Many people have a love/hate relationship with JavaScript.

Are there any specific problems, you are setting out to solve? A few developers who have gone before you, are available at the Gutenberg Developer Hours, on March 8th (tomorrow) and on March 22. Bring your problems, your questions, and your code, and discuss them with the expert panelists. There are more developer-centric events planned on the meetup group.

Also, you might appreciate Ryan Welcher’s TwitchStream recording on YouTube with live coding session building blocks and other block editor related topics. I learned quite a bit from them.

Thanks for your feedback and your review. Sorry, you had some frustrating experience as a new user of the block editor. What specifically do you find not working?
You don’t have to drag & drop blocks around, you can just start typing and hit enter as you do in the classic editor. If the toolbar on the block is in your way you can make it a top toolbar via the 3 dot menu on the right. You don’t have to design anything until you are done writing.

If you are open to additional more specific conversation about how to transition from the classic editor to the block editor as a site owner, or writer, I’d be happy to connect some more.

Hi there,
Thank you for your feedback. Sorry, you still feel that way. What if not improving the editor, would be ‘reasonable problems’ in your view?

Obviously, the contributors to WordPress feel opposite to you; otherwise they wouldn’t have worked on it for the last five years and wouldn’t have published 120 releases.

Imagine the block editor will stay around for all the years to come. What would be the most important quirks to solve, so it could start working for you, too?

Hi Alex,
Thanks for your feedback. I am sorry, you still feel that way after it has been merged into core a few years ago. It would be helpful to other users as well, if you could spend a bit of a time and be a bit more as you “What particular ‘intuitive’ features are missing now in comparison to before?

Your notes would be appreciated.

Hi there,

Thanks for your feedback. I am sorry, you had this bad experience. I would be interested in learning more of what you attempted to do with the editor and what you find missing. What particular habits, where you can not replace adequately with the block editor? Maybe I can give you a few hints, after having used it for quite a bit. I do remember there were a few key shortcuts I had to relearn and it took a while to optimize for speed and ‘muscle memory’.

• This reply was modified 3 years ago by Birgit Pauli-Haack.

@tflight thank you so much for your comments. Why can’t it be both, doesn’t have to be CMS or Page builder. Some developer actually use WordPress for their headless implementation.

We hear about the problems for theme developer especially with the changes in 5.9.

I am wondering if you go the time to check out the new Theme.json Globel Styles and Block Settings that allows you to control the site editor including disabling some block settings like Drop Cap or custom colors.

Now that the framework for full-site editing is released there is also an overall Proposal on GitHub that could use your constructive input: Proposal: Standardized block markup, theme.json design tokens, and CSS classes to improve interoperability

As for CMS, nothing that you are accustomed to is going away: You can still create custom post types, themes, and plugins. As long as you don’t create a block theme, there isn’t much that will get in your way.

Wow, thank you for letting us know about your positive experience. It means a lot.