Edit page for custom post type not showing slug & pretty permalink

[vlasky]

I am using 3.0-beta1. I have registered a custom post type called 'mycustom'.

In permalink settings, I have a custom structure of:
/archives/%postname%/

When I edit a post of my custom post type, instead of seeing the text box that displays the slug underneath the title, I see the following:

Permalink: ​http://wp.remoteexperiments.com:808/wordpress/?post_type=mycustom&p=44 and then a button marked 'Change Permalinks'

Enclosed is a screenshot, and here is the code I have used to register the custom type. Note that I have tried both with and without the 'rewrite' option.

$supports = array( 'title', 'editor', 'custom-fields', 'revisions');

$args = array ('label' => ('MyCustom'),

'singular_label' => ('MyCustom'),
'_builtin' => false,
'public' => true,
'show_ui' => true,
'capability_type' => 'post',
'supports' => $supports,
'exclude_from_search' => true,
'hierarchical' => false

'rewrite' => array('slug' => 'mycustom')
);

register_post_type('mycustom', $args);

[vlasky]

Screen shot of editor showing missing slug when editing a custom post type under WP 3.0-beta1

[uglyrobot]

You have to enable rewrites for that post type, as well as configure them how you want. Custom post types will not be added to the default rewrite rules unless you add them manually.

[vlasky]

Please read my report carefully - I included the option 'rewrite' when registering the custom post_type. I had tried both enabling and disabling that option.

After doing more research, I discovered that this issue was previously reported in ticket 12742 and patched in ticket 13865. Was this patch properly tested and rolled out in the last nightly build?

[vlasky]

I changed this back to normal priority and severity so I don't seem overly self-important, but I just wanna say that it was wrong for uglyrobot to rush to declare this issue as 'invalid' without looking into it properly.

I also wish to note that another patch to address this problem was just released in 12895 by duck_

[duck_]

Managed to not read this properly when submitting #12895.

Anyway, problem is because you're editing a draft custom post type, only published custom post types show the pretty permalink. Patch attached.

[uglyrobot]

Replying to vlasky:

I changed this back to normal priority and severity so I don't seem overly self-important, but I just wanna say that it was wrong for uglyrobot to rush to declare this issue as 'invalid' without looking into it properly.

In your sample code you had rewrites commented out. That was expected behavior without defining a rewrite and query_var.

[dd32]

See Also: #12742

Looks like i didn't catch it all..

I just noticed that the slug displayed may not be correct, for example, It showed /note/test/ in hte slug preview, and /note/test-6/ after a draft save when it realised test was already taken.

[dd32]

r14068 /trunk/wp-includes/link-template.php: Correct sample URL's for custom post_type's. uses pretty permalinks if possible. Props duck_. See #12870

[duck_]

Replying to dd32:

I just noticed that the slug displayed may not be correct, for example, It showed /note/test/ in hte slug preview, and /note/test-6/ after a draft save when it realised test was already taken.

Problem was that autosave.js was not sending a new_slug to admin-ajax.php, if this isn't set then it defaults to empty string. get_sample_permalink(_html) use null as a default for this value, so even though a unique slug was retrieved in the get_sample_permalink function it was overwritten because $name (aka the new_slug) was not null. Fix sets default for unset new_slug to be null. Also move the check for a new name in get_sample_permalink to before the unique slug call so that the same problem doesn't happen when editing the permalink of an existing post (try this now and you'll see that the number suffix isn't added until save).

PS, the patch also includes minor optimisation of _get_page_link function from link-template.php

[dd32]

(In [14124]) Display the correct Slug in the permalink preview. Props duck_. Fixes #12870

url_to_postid() decides whether a URL belongs to this site by comparing its host to the site's host, after removing www. from both:

$url_host      = str_replace( 'www.', '', $url_host );
$home_url_host = str_replace( 'www.', '', $home_url_host );

The removal is unanchored, so it strips www. from anywhere in the host, not just the conventional prefix. Any host that reduces to the site's host is then treated as local:

host	reduces to
www.example.com	example.com — intended
exwww.ample.com	example.com — different domain
example.cwww.om	example.com — different domain

Both of those are ordinary registrations (ample.com; cwww.om under Oman's TLD). On a site at example.com:

url_to_postid( 'https://exwww.ample.com/?p=16' )   // 16
url_to_postid( 'https://example.cwww.om/?p=16' )   // 16
url_to_postid( 'https://evil.com/?p=16' )          // 0

Trac ticket: TODO — needs filing

## Changes

Anchor the removal so only a leading www. is optional:

$url_host = preg_replace( '|^www\.|', '', $url_host );

This is the same idiom already used for host normalisation in ms-functions.php and ms-blogs.php.

## Why it matters

url_to_postid() returning a post ID is widely treated as proof that a URL is internal, both in core and by plugins. Anywhere that answer feeds a trust decision, a registrable lookalike domain currently passes.

This surfaced while reviewing #12870, which uses the function for exactly that kind of decision. It is worth fixing on its own regardless of what happens to that PR.

## Testing

tests/phpunit/tests/rewrite.php gains a data-provided case covering the site host, the www. prefix, both mid-host collisions, an unrelated host, and the site host used as a subdomain of an attacker domain.

Reverting only the source change fails exactly the two collision cases and leaves the rest green:

1) …with data set "www inside the domain" ('exwww.ample.com', false)
   Failed asserting that 6 is identical to 0.
2) …with data set "www inside the TLD" ('example.cwww.om', false)
   Failed asserting that 7 is identical to 0.

npm run test:php -- --filter Tests_Rewrite    # 92 tests, 279 assertions

phpcs reports no issues on either file.

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Research, implementation, and tests; reviewed and edited by me.

Is this intended to be targeted for 7.1? The code in url_to_postid() is a problem from long before #65016, so it seems like this should have a separate ticket. However, if fixing this is critical to having 65016 be viable, then please clarify that.

But this seems like something that regressed in ​https://github.com/WordPress/wordpress-develop/commit/c02645bf1355d6b6465be97ee11b44020e2b8092; the previous logic used a slightly different construction.

Is this intended to be targeted for 7.1? The code in url_to_postid() is a problem from long before #65016, so it seems like this should have a separate ticket. However, if fixing this is critical to having 65016 be viable, then please clarify that.

I have looked into this matter.

This PR indeed fixes a long-standing bug in the url_to_postid() function. However, it is believed that the issue has been exacerbated by r63036, which introduced this function into the logic for automatically approving pingbacks. Therefore, if possible, it might be good to include this PR in the 7.1 release.