notice in wp-includes/canonical.php:392

[jakubbis]

Hello,

We're getting notice in wp-includes/canonical.php:392, but it requires some specific steps to obtain it.

Steps:

1. Setup a clean install of WPML
2. Set permalinks to postname without ending slash: /%postname%
3. Create a page in secondary language
4. Set this page as Home Page (under Settings/Reading) but only in the secondary language

When you enter "home page", you get 404 because a page for original language does not exist.
In line 121, you get $redirect_url = get_permalink($redirect_post); and value of $redirect_url is for instance "​http://testsite.dev?lang=fr". As you see, there is no "/" before "?", that's why path is empty.

You have already fixed the similar issue in line:77-79

// Notice fixing
if ( !isset($redirect['path']) )
   $redirect['path'] = '';

I suspect, we need the same fix before line: 392

$redirect['path'] = preg_replace('|/' . preg_quote( $wp_rewrite->index, '|' ) . '/*?$|', '/', $redirect['path']);

[SergeyBiryukov]

Related: #34353

[jipmoors]

Hi @jakubbis,

Thank you for submitting this report and the detailed information with it.

I have taken a look at the file and the locations you mentioned and I have determined where this problem is coming from.
There are two error suppressed calls to parse_url which both can cause this issue.

[jipmoors]

Avoid notice on non-existing key.

[SergeyBiryukov]

#52864 was marked as a duplicate.

[SergeyBiryukov]

Related: #51725

[hellofromTonya]

Today is 5.8 Beta 1. As there's been no activity, punting to 5.9.

[sayedulsayem]

There is no need to assign an empty string after empty checking. Going to close this ticket. from bug scrub discussion.

[SergeyBiryukov]

It looks like there was some confusion during the bug scrub, as someone thought the problem is already solved in lines 83-85 of canonical.php​.

However, that part was introduced in [9506] and adjusted in [13866]. It already existed when this ticket was created. The patch here touches a different area of the code, after the parse_url() call in line 568​ further down.

The ticket still seems valid. Reopening for additional review.

[audrasjb]

As per today's bug scrub, it appears this ticket needs investigating to confirm the problem is there. If yes, then manual and automated testing. Moving for Future release consideration for now.