Dennis Snell

@garrigan I believe that the 404 is known and pointed out twice in the linked Trac ticket. You can watch Core-54435 if you want to be notified of updates on that one.

I’m afraid I’m going to be limited in how much I can help you diagnose your particular issues, but maybe someone else with more helpful skills can help you figure this out. That being said, I’ll see updates here so if I notice something that makes sense I can jump in.

@garrigan if you add the lines mentioned in the Trac ticket to the top of the wp_check_invalid_utf8() function inside wp-includes/formatting.php, then repeat the issue that caused the 404, then it should print the data on the webpage somewhere (and this will likely be messed up. if you want, do this instead var_dump( "<plaintext>" ); var_dump( $text )) and it should still break the displayed page but be easier to see the output.

the Error should produce a log message in the same place you saw the error above.

Here’s a big warning though: don’t do this on a production site. Only do this is you are able to test the changes without interruption your own site or someone else’s.

@byam21 I looked at the link you shared and it’s currently showing PHP 7.4 with mysql support. Also I checked your site and it appears to be working. Did you figure this out? Or maybe your host was slow to update their configuration?

Hi @kittenchief117. These are good questions and there’s a big answer to them; here’s a not-so-brief summary.

The most important part to understanding this is probably that WordPress is trying to build an open and extensible system. Most of the decisions related to the way content is stored is directly working to one of those two goals.

more brief and concise code means: faster to write, less network bytes consumed, efficient browser parsing/rendering/reflow performance, easier to read/maintain, more productivity, and better Developer Experience (DX).

WordPress posts tend to perform quite well in rendered pages and there’s been a fair amount of care built into the editor in order to produce semantic and efficient HTML. One part to note is that the content stored in a post is not the same content delivered to the browser. In any case, the extra metadata stored with each block is rather minor, and a single image upload to a site might outweigh the total of all the additional data surrounding blocks.

Those HTML comments provide a very fast way to parse the blocks out of a post and to isolate them for processing on page render without requiring the use of more opaque data structures like a proprietary JSON format. They provide for sufficient functionality when rendered as an HTML file without any server while communicating the higher-level attributes which define what any given block is and means.

For a deeper dive into this question, you can read more in an article I wrote many years ago now.

Many styles are duplicated first in the WP block comment, and then in the actual tag itself. Why? Can’t we just write Tailwind-like styles…Why not use that instead of "orientation":"vertical"?

Duplication should be kept at a minimum, but if you look carefully at the example you posted you will see that there are minor differences. A Block represents a kind of rich media and its attributes define the parameters which define that particular bit. An image block’s url attribute indicates where to find an image file, but the HTML that’s rendered for that block could be one of many different HTML constructions depending on things like whether there are different sizes available for display, whether there’s a caption, whether there are artistic choices being made based on the screen size. Styling is similar in that there are concepts being defined at a higher lever than raw CSS. There’s a close correspondence, but CSS becomes a way to express the higher-level style kind. Therefore most block’s have attributes indicating the intentional styles while the HTML inside a block contains the realization of that style with CSS.

It’s common when developing blocks to add CSS late during render and to do that based on the block attribute or based on some other information available to the server when rendering a page. If you examine the rendered page you will note, for instance, that most blocks contain a number of additional classes which aren’t stored with the block in the editor or in the database. WordPress provides the render_block filter to modify the HTML when sending a page to a browser.

Also, more complicated styles not supported by the WP editor…have to be added to Blocks with CSS class names I think, which are then harder for normal users to identify and remove one if they want to.

If you find that you are adding things routinely to many blocks then you might look into that render_block filter and see if it’s something that you can provide dynamically.

Many of the style systems are designed to work together with Global Styles and block supports that give people the ability to adjust the layout or visual styling of a block or page without resorting to code or CSS. This is also one of the reasons it’s hard to rely entirely on CSS, because the WordPress concepts often transcend an individual block in a post or an individual setting.

Everything being built is done in the open and in a spirit of cooperation and invitation. If you experience specific problems or want to share an idea for how to do things differently, you can interact on the Issues page for Gutenberg (the name of the editor).

Thanks for asking!

@bubokko after some experimentation I’m also seeing that error message, but it also appears to be working. That is, even though it prints that warning, it’s still mounting my theme the way I expect it to. I installed 6.4.1 and then copied the twentytwentyfour theme into a new directory, then I renamed the theme to twentytwentyfourohfour just to make sure it wasn’t loading a theme from the wp-env contents.

So you might double-check and see if it’s working for you. That warning shows up whenever it doesn’t find a .wp-env.json file, even if it finds themes and plugins, which I confirmed by digging into wp-env directly. I think it would make sense to show something clearer like Found the "twentytwentyfour" theme.

I’ve proposed an update to wp-env to clarify the warning message.

• This reply was modified 2 years, 6 months ago by Dennis Snell.

@bubokko is the directory with your code posted somewhere? what does the list of files in the project root look like?

If you only have theme files then yes, it should find the style.css file and look for the header there.

Hi @cutenmore. It looks like your site is currently showing a menu built in Elementor. You may want to check in the Elementor docs for the Menu widget or in the ElementorKit addon’s docs for its nav menu component. They are probably replacing the menu from WordPress and it looks like they have their own interface to edit it.

@bubokko you can create a .wp-env.json file in the root directory of your project and explicitly declare that it’s a theme. See the config file documentation for help setting that up.

As a side note, if you have a theme file make sure it has the required header at the top of the theme so that WordPress will know what it is.