Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save navigation not working when site is not in domain root #25181

Closed
tellthemachines opened this issue Sep 9, 2020 · 6 comments · Fixed by #31028
Closed

Save navigation not working when site is not in domain root #25181

tellthemachines opened this issue Sep 9, 2020 · 6 comments · Fixed by #31028
Assignees
Labels
[Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@tellthemachines
Copy link
Contributor

Describe the bug
A clear and concise description of what the bug is.

When trying to "Save navigation" in the navigation screen on my live website, a message pops up saying "There was an error" and the navigation isn't saved.
In the Network tab I can see that the POST request for saving the nav is using an incorrect URL. My website is not in the domain root but in a folder, like mydomain.com/wp-website, but the POST URL assumes it's in the root, so it's structured like: mydomain.com/wp-admin/admin-ajax.php?_locale=user

The issue seems to be with this line

To reproduce
Steps to reproduce the behavior:

  1. In a website that is not located in the domain root, try creating a menu in the navigation screen and saving it.
  2. Check that error occurs.
  3. Check POST URL in the dev tools network tab.

Expected behavior
A clear and concise description of what you expected to happen.

Expected to be able to save the nav no matter what my URL structure is like.

Screenshots
If applicable, add screenshots to help explain your problem.

Editor version (please complete the following information):

  • WordPress version: 5.5.1
  • If the Gutenberg plugin is installed, which version is it? Yes, 8.9.3
@talldan
Copy link
Contributor

talldan commented Sep 16, 2020

Just noting there were some comments on this in a triage session in slack (https://wordpress.slack.com/archives/C02RQBWTW/p1599638472256400).

@draganescu mentioned the URL needs to take into account the SITE_URL.

I also mentioned that there's some apiFetch middleware that might be responsible for handling this for other requests (like REST API requests):
https://github.com/WordPress/gutenberg/blob/master/packages/api-fetch/src/middlewares/root-url.js

Potentially that middleware also needs to also take into account this URL's path

@noisysocks
Copy link
Member

Probably we just need to include this bit of code in lib/navigation-page.php.

https://github.com/WordPress/wordpress-develop/blob/7d23a212c491cc85fa1c467362df1a16ea4e3e80/src/wp-includes/script-loader.php#L283-L290

The difficulty is in setting up a test environment for this case 🙂

@noisysocks noisysocks added the [Type] Bug An existing feature does not function as intended label Sep 29, 2020
@gwwar
Copy link
Contributor

gwwar commented Feb 8, 2021

I verified that this is still an issue, if folks have a PR I can help test.

One thing that stands out is that we're likely missing other fetch-api middleware / default scripts in the navigation page context. It'd be worth auditing what the edit-post context gets in comparison with this page.

@gwwar
Copy link
Contributor

gwwar commented Feb 18, 2021

I checked in on this one and couldn't reproduce. It looks like the root middleware is now enqueued on the navigation page.

Screen Shot 2021-02-18 at 2 43 15 PM

Going to close this one out. @tellthemachines please reopen if you're still seeing this.

@gwwar gwwar closed this as completed Feb 18, 2021
@talldan talldan reopened this Apr 12, 2021
@talldan
Copy link
Contributor

talldan commented Apr 12, 2021

It seems like this is still a bug as discussed in slack, so reopening:
https://wordpress.slack.com/archives/C01KDAZJMQ9/p1618209525004800

I think the middleware works for REST API requests, but doesn't work for the Customize ajax request that's being used temporarily by the screen to save menu items.

@raaaahman
Copy link

It seems like this is still a bug as discussed in slack, so reopening:
https://wordpress.slack.com/archives/C01KDAZJMQ9/p1618209525004800

To add details to the issue:

  • Tested with a clone of WordPress/gutenberg, commit 27f935 (10.4.0-rc.1) as well version 10.3.2 installed through WordPress plugin repository.
  • URL of the website (LAMP virtualhost) is: http://localhost/wordpress-5
  • With the Gutenberg > Experiments > Enable Navigation Screen option checked.

When clicking on the Save button in Gutenberg > Navigation (beta), the following request is issued:

XHR POST http://localhost/wp-admin/admin-ajax.php?_locale=user
[HTTP/1.1 404 Not Found 1ms]

	
POST
	
scheme
	http
host
	localhost
filename
	/wp-admin/admin-ajax.php
_locale
	user
Address
	127.0.0.1:80
Status404
Not Found
VersionHTTP/1.1
Transferred1.71 kB (1.36 kB size)
Referrer Policystrict-origin-when-cross-origin

    	
    Accept-Ranges
    	bytes
    Connection
    	Keep-Alive
    Content-Language
    	fr
    Content-Type
    	text/html; charset=utf-8
    Date
    	Mon, 12 Apr 2021 11:32:44 GMT
    Keep-Alive
    	timeout=5, max=97
    Server
    	Apache/2.4.35 (Unix) OpenSSL/1.0.2p PHP/7.2.11 mod_perl/2.0.8-dev Perl/v5.16.3
    Transfer-Encoding
    	chunked
    Vary
    	accept-language,accept-charset
    	
    Accept
    	application/json, */*;q=0.1
    Accept-Encoding
    	gzip, deflate
    Accept-Language
    	fr-FR,fr;q=0.8,en-US;q=0.5,en;q=0.3
    Cache-Control
    	no-cache
    Connection
    	keep-alive
    Content-Length
    	1573
    Content-Type
    	multipart/form-data; boundary=---------------------------232783779724450187591110507708
    Cookie
    	wordpress_test_cookie=WP+Cookie+check
    DNT
    	1
    Host
    	localhost
    Origin
    	http://localhost
    Pragma
    	no-cache
    Referer
    	http://localhost/wordpress-5/wp-admin/admin.php?page=gutenberg-navigation
    User-Agent
    	Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
    X-WP-Nonce
    	0c3499af26

With body:

-----------------------------232783779724450187591110507708
Content-Disposition: form-data; name="wp_customize"

on
-----------------------------232783779724450187591110507708
Content-Disposition: form-data; name="customize_theme"

twentytwenty
-----------------------------232783779724450187591110507708
Content-Disposition: form-data; name="nonce"

838a887f01
-----------------------------232783779724450187591110507708
Content-Disposition: form-data; name="customize_changeset_uuid"

647fbfb1-c1ce-4494-9487-3cc4e7cea959
-----------------------------232783779724450187591110507708
Content-Disposition: form-data; name="customize_autosaved"

on
-----------------------------232783779724450187591110507708
Content-Disposition: form-data; name="customize_changeset_status"

publish
-----------------------------232783779724450187591110507708
Content-Disposition: form-data; name="action"

customize_save
-----------------------------232783779724450187591110507708
Content-Disposition: form-data; name="customized"

{"nav_menu_item[45]":{"id":45,"title":"Hello world!","status":"publish","url":"http://localhost/wordpress-5/index.php/2021/04/09/hello-world/","attr_title":"","description":"","type":"custom","type_label":"Custom Link","object":"custom","object_id":45,"content":{"raw":"","rendered":"","block_version":0},"parent":0,"menu_order":1,"target":"","classes":[""],"xfn":[""],"original_title":"","position":1,"nav_menu_term_id":2,"menu_item_parent":0,"_invalid":false}}
-----------------------------232783779724450187591110507708--

The response is a 404 error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants