Slugs needed for permalink static pages?

Assuming you permalink structure is simply /%postname%/, then this-word, that-word etc. would be your page slugs. It’s what determines what page is returned. It is fixed, thus why the entire URL is called a permalink — it’s a “permanent” way to reach that page. There’s no need for any more than a page slug and your domain name to fetch a particular page. Any added data like category or date is for SEO purposes and not strictly necessary.

WP Documentation article:
https://www.ads-software.com/documentation/article/wordpress-glossary/#permalink
https://www.ads-software.com/documentation/article/wordpress-glossary/#slug

Thanks bcworkz
I think I had it the wrong way round if slug comes first (as I understand you), and then permalink. I thought one starts off with the preferred custom permalink that overrides the automatically created slug.
But if the custom permalink differs from the automatic slug, which is used in links? Does the custom permalink override the slug?
Example:
* Custom permalink: this-word
* WP created slug: this-word-2
Which is used for the link, and which will show in the public display of the page/post?

If WP is appending “-2” to “this-word” slug, there’s presumably an existing resource for “this-word” and thus it’s unavailable for any other permalink use. It’s possible it did exist, then the this-word-2 page was created, then later the initial this-word resource was removed. If that’s the case, you could alter this-word-2’s slug to be simply this-word. There’s no need for a custom permalink. If you cannot change the slug to this-word, the resource still exists somewhere and is unavailable for a custom permalink.

Usually there’s a way to have the default permalink schema work for any need and there’s little need for custom, resource specific permalinks. But if you do need such a thing anyway, the first thing to do is to get WP to generate the right link to start with. There are a number of filters we can use to do this, which one to use depends on what post type the resource is. For pages it’s “page_link”.

Altering a permalink via filter does not mean WP will recognize such a request. For WP to recognize a custom link, you need to add_rewrite_rule(). Depending on the resource type requested, WP may or may not redirect to the resource’s canonical URL. Canonical redirect behavior can be managed through the “canonical_redirect” filter.

As you can see, custom permalinks can be a bit involved. Thus if at all possible it’s better to work within the default schema.

Thanks bcworkz

I did suspect “initial this-word resource was removed” as the problem. During import from the development-site we had server problems as well as network problems – and at that time I was wondering whether we would encounter problems.

What I did expect from WP (first time we use this platform) is that the data of the slug would exist somewhere in a format that could be editable – such as a DB field. Pity one cannot do this – especially as we’re still in early stage of development, which means we will sit with this dirty little thing forever ?? — I like consistency and neatness.

If I understand you well, slugs are primary, and need to be overridden with permalinks to enforce a different URL structure.
Ciao
jq

If “this-word” slug is no longer used by any resource, you can change “this-word-2” slug to “this-word” right in the page editor. If you use the default block editor, view the page’s settings sidebar (right side). Click on the URL field value. You’ll get a pop-up dialog box where you can edit the page’s permalink slug.

Slugs can also be changed in the Quick Edit dialog on the page list table screen. Page slugs are not truly permanent. Permalinks are intended to be permanent, but they do not have to be. The one thing that should be truly permanent is a page’s GUID which is saved in the DB but is not otherwise used anywhere within the WP UI.

Thanks bcworkz

I have indeed tried those places but after saving a “this-word”, the refreshing window reverts back to “this-word-2”. It refuses to remove the -2.

Copied from a different thread, which I believe belongs here. You posted:

Given the various problems (still unsolved) we experience, it is probably best to start again. Something must have gone wrong during the export/import process from the Dev site (where the basic skeleton was developed) to the final site. Fortunately we are not far down the development path on the final site, building on top of the skeleton.

Question (hopefully last on this topic):

If we purge the slug table (to get rid of duplicate slugs), can we then add slugs to the pages – without breaking the system completely? This is after all not yet a working site.
Fortunately we keep a separate record of the slugs and permalinks off site, so updating a clean table will be much quicker than to redo everything form the start.

Post slugs are part of the posts table and are part of every post record. It’s impractical to purge slugs without also purging the related posts. If /this-word/ slug does not exist anywhere in the posts table, you should be able to change /this-word-2/ to /this-word/. The fact you cannot causes me to believe a /this-word/ post still exists somewhere in the DB. It may not necessarily show up in the WP posts list table, but it’s in the DB somewhere.

You could search the DB using the phpMyAdmin app. Examine the record found and determine if it’s still relevant or not. If not, it could be removed to free up the slug it’s using. However, do not simply delete the record via phpMyAdmin. There’s likely a bunch of other data tied to this record that also needs to be removed. Doing it correctly via phpMyAdmin can be difficult. It’s better to use wp_delete_post() and PHP. Be sure to use the $force_delete parameter to bypass trash and to delete permanently. Posts in trash still maintain their slugs and the slugs are thus unavailable for other posts.

Investigating with phpMyAdmin and deleting with custom code is feasible if there are not too many posts whose slugs need correcting. If there are a lot of slugs to correct you’re probably better off importing everything all over again. When importing a complete site, you should import into an empty DB. I think what may have happened is the DB was not empty and imported slugs already existed so the -2 had to be appended to the imported slugs.