Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Can't Open Gutenberg Theme Editor #762

gilmorem560 started this conversation in General
Discussion options

Hello, I've run into an issue with the new Gutenberg block theme editor in the current Docker image.

I'm generating my containers via the following compose file:

docker-compose.yml
version: "3.3"
services:
 db:
 image: mariadb:latest
 container_name: db
 restart: unless-stopped
 volumes:
 - db_data:/var/lib/mysql
 - ./docker-files/00-wordpress.sql:/docker-entrypoint-initdb.d/00-wordpress.sql:ro
 - ./docker-files/01-wordpress-mods.sql:/docker-entrypoint-initdb.d/01-wordpress-mods.sql:ro
 environment:
 MYSQL_ROOT_PASSWORD: password
 MYSQL_DATABASE: wordpress
 MYSQL_USER: admin
 MYSQL_PASSWORD: password
 wordpress:
 depends_on:
 - db
 image: wordpress:latest
 container_name: wordpress
 restart: unless-stopped
 volumes:
 - ./docker-files/wp-content/plugins:/var/www/html/wp-content/plugins
 - ./docker-files/wp-content/themes:/var/www/html/wp-content/themes
 - ./docker-files/wp-content/uploads:/var/www/html/wp-content/uploads
 ports:
 - 80:80
 environment:
 WORDPRESS_DB_HOST: db:3306
 WORDPRESS_DB_USER: admin
 WORDPRESS_DB_PASSWORD: password
 WORDPRESS_DB_NAME: wordpress
 WORDPRESS_DEBUG: 1
volumes:
 db_data: {}

Most things seem to work just fine, I've been using Wordpress Docker images for a couple of years now, but where it seems to get hung up is on the new theme editor (which is in beta, maybe this is to be expected...).

This is accessed here via the customize button or the Editor link on the left panel:

image

In both cases, navigating produces a link of the format:

/wp-admin/site-editor.php?postType=wp_template&postId=twentytwentytwo%2F%2Fhome

Which I can confirm is the same route/URL produced on our real site that we're working up.

In the Docker case, I receive the following in the browser console:

console.error
Uncaught (in promise) 
Object { code: "invalid_json", message: "The response is not a valid JSON response." }
edit-site.min.js:12:27963
 Be http://localhost:8080/wp-includes/js/dist/edit-site.min.js?ver=3497072223e20a22d15e7212dd6da2db:12
 InterpretGeneratorResume self-hosted:1819
 AsyncFunctionThrow self-hosted:811
 (Async: async)
 k http://localhost:8080/wp-includes/js/dist/data.min.js?ver=6c1ab5799c4b061254d313d2d8d9fb87:2
 i Redux
 P http://localhost:8080/wp-includes/js/dist/data.min.js?ver=6c1ab5799c4b061254d313d2d8d9fb87:2
 U http://localhost:8080/wp-includes/js/dist/data.min.js?ver=6c1ab5799c4b061254d313d2d8d9fb87:2
 f http://localhost:8080/wp-includes/js/dist/data.min.js?ver=6c1ab5799c4b061254d313d2d8d9fb87:2
 gl http://localhost:8080/wp-includes/js/dist/edit-site.min.js?ver=3497072223e20a22d15e7212dd6da2db:12
 $r http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 unstable_runWithPriority http://localhost:8080/wp-includes/js/dist/vendor/react.min.js?ver=17.0.1:9
 xn http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 Qr http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 Pr http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 Pr self-hosted:1406
 Nn http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 unstable_runWithPriority http://localhost:8080/wp-includes/js/dist/vendor/react.min.js?ver=17.0.1:9
 xn http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 Nn http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 _n http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 Lr http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 ml http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 render http://localhost:8080/wp-includes/js/dist/vendor/react-dom.min.js?ver=17.0.1:9
 go http://localhost:8080/wp-includes/js/dist/edit-site.min.js?ver=3497072223e20a22d15e7212dd6da2db:12
 fo http://localhost:8080/wp-includes/js/dist/edit-site.min.js?ver=3497072223e20a22d15e7212dd6da2db:12
 <anonymous> http://localhost:8080/wp-admin/site-editor.php?postType=wp_template&postId=twentytwentytwo//home:1644
 (Async: EventListener.handleEvent)
 n http://localhost:8080/wp-includes/js/dist/dom-ready.min.js?ver=d996b53411d1533a84951212ab6ac4ff:2
 <anonymous> http://localhost:8080/wp-admin/site-editor.php?postType=wp_template&postId=twentytwentytwo//home:1643

Where on our server, I get

console.log
Updated Block: core/spacer blocks.min.js:3:138810
Block successfully updated for `core/spacer` ( 
Object { name: "core/spacer", icon: {...}, keywords: [], attributes: {...}, providesContext: {}, usesContext: (1) [...], supports: {...}, styles: [], variations: [], save: save(e), ... }
 ).
New content generated by `save` function:
<div style="height:112px" aria-hidden="true" class="wp-block-spacer"></div>
Content retrieved from post body:
<div style="height:112px" aria-hidden="true" class="wp-block-spacer"></div> blocks.min.js:3:138861

As for my environment:
macOS 12.5.1 (x86_64)
Docker 20.10.17
Compose 2.7.0
WordPress 6.0.2
Firefox Developer Edition 105.0b8

This machine is a bit anomalous in that I usually work on this on a Raspberry Pi 400, somewhere around Linux 5.19.x (rpi fork, not upstream), typical GNU stack, aarch64 obviously, but I don't see those being significant variables, especially given this current experience is on a much more mainstream computer than I usually use for my hobby projects.

Please let me know if I can provide any further info. I will be trying this later on my usual machine to see if my experience is any different and will post the specs and details if I do find any further discrepancies.

Thank you!

You must be logged in to vote

Replies: 5 comments

Comment options

I'm not able to reproduce on a standard deployment (on linux).
You might try some of these workarounds https://passionwp.com/response-is-not-a-valid-json-response-error/

But I imagine it's just some nuance with your initialized environment that just isn't meshing with that new editor

You must be logged in to vote
0 replies
Comment options

Good point, I should've shared the contents of that SQL mod my compose file makes, that is here

UPDATE wp_options
SET
 option_value = 'http://localhost/'
WHERE
 option_name IN ('siteurl', 'home')

So just a URL refresh in the event I use an 00-wordpress.sql script to initialize the site from an existing database dump. In this case, I've only been working with this project with content I generate therein, so haven't had an 00-wordpress.sql initializing anything yet.

The project I'm working with is open source if it would provide more helpful diagnostic information: https://gitlab.com/whatcomclubhouse/wchtheme

Just a barebones theme I'm working on for a local non-profit, shouldn't be anything too out of the ordinary, but even when I cut out the pieces of the compose file that actually prop up my code and have it just run flat with fresh volumes, I still have the same experience.

Unfortunately haven't gotten around to that test on another device yet, but wanted to provide some more detail that might be relevant.

The one singular thing that I can think of is that my containers currently expose the site to my main machine at port 8080, not 80 (which is weird, my compose file says 80, but maybe I'm missing something somewhere). What I wonder is if this means the :8080 must be on the end of siteurl and home. I'll try that at my next convenience and report back whether that seems to change anything.

You must be logged in to vote
0 replies
Comment options

Sorry, I'm realizing I've linked you to a repository where I've already thrown out working on a Gutenberg theme and switched to a classic theme. In any case, even excluding my bits from it and just composing the containers as an empty site leads to the same effect with twentytwentytwo. Just thought I'd mention the caveat, but I'm not looking to turn this thread into an indictment of the Gutenberg system, that can go in some angry blog somewhere.

You must be logged in to vote
0 replies
Comment options

Aaand I haven't swung back around to this yet, ever since moving to the classic theme I've had no reason to use those forms, so it hasn't happened incidentally. I have some work to do on one of my sites this weekend so will hopefully remember to run this through the ringer again. Sorry for dropping off!

You must be logged in to vote
0 replies
Comment options

Feel free to close this, it's been quite a while and have ditched any attempts at Gutenberg anyway. Hopefully it was just an isolated incident, if nobody else has had this issue it's probably long gone.

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Converted from issue

This discussion was converted from issue #746 on October 06, 2022 23:03.

AltStyle によって変換されたページ (->オリジナル) /