Opened 4 years ago
Closed 4 years ago
#52942 closed defect (bug) (invalid)
Multisite setup problem with Requests_IDNAEncoder
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 5.7 |
Component: | General | Keywords: | |
Focuses: | administration, multisite | Cc: |
Description
Hello everyone,
I'm facing a issue regarding WordPress admin URL generation. I don't know if it's a bug but this problem is affecting one of the plugins (Elementor) we use in our multisite network setup with nested urls.
By nested urls I mean our structure is like this:
example.com/my-site
example.com/my-site/my-sub-site
example.com/my-site/my-sub-site/another-sub-site
I found that Elementor is using the below WordPress method to generate the admin url when loading the Editor:
Requests_IDNAEncoder::encode( get_admin_url() );
The problem happens when the "get_admin_url()" address is larger than 64 chars, we are presented with an error 500 loading Elementor editor, the error presented is "Provided string is too long".
This issue is causing a lot of headaches in the university I work for, because we have a lot of sub sites using Elementor and people are not able to edit those pages.
I already opened a ticket on Elementor as you can check herehttps://github.com/elementor/elementor/issues/13789, but assuming this is a core WordPress method I think it would be good to ask for some help here too.
Glad for any help.
Hi @edemir206,
Sorry for the issue you're running in here - however the issue lies with Elementor, as they're using the functionality incorrectly.
Requests_IDNAEncoder::encode()
is intended to encode a hostname only, ie. theexample.org
part ofhttps://example.org/my/site/path/here
, not the entire URI - infact using it on the entire URI will result in invalid URLs.Elementor should a) Not be calling the function in the way they are and b) handling error conditions of the function if they must call it incorrectly like that.
Requests is a separate project from WordPress, although bundled with WordPress and now maintained by us. While this could be reported to that Github repo, as the function is being called incorrectly there's not a lot good that reporting it here will do.
I'm marking this issue as
invalid
, not because this isn't an issue, but that it's an issue that can't be dealt with by WordPress core here.