WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 6 months ago

#52942 closed defect (bug) (invalid)

Multisite setup problem with Requests_IDNAEncoder

Reported by: edemir206 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.

Change History (1)

#1 @dd32
6 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

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. the example.org part of https://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.

Note: See TracTickets for help on using tickets.