Error CPT with 2.0.3

Hi Michael,

thank you, I really appreciate it.

I am not certain about the problem description. Did the permalinks stop working (the custom URIs were no longer detected) or the problem was with the custom permalinks address (they were not correctly displayed)?

In 2.0.3 version I set “Deep URI detect” to be disabled by default (this function increases the pageload time and is not used by most of the users). It can be reenabled with a single line of code (pasted to functions.php in theme folder):

add_filter('permalink-manager-deep-uri-detect', '__return_true');

When “Deep URI detect” is disabled, the WordPress treats the last numeric part of the URL as a pagination, e.g.:

example.com/video/20100110201710 is detected as 20100110201710th page of example.com/video:

• my plugin checks if video is assigned to any post/page
• 20100110201710 is detected as endpoint

When “Deep URI detect” is enabled, my plugin does one more check:

• my plugin checks if full URI: video/20100110201710 is assigned to any post/page
• 20100110201710 endpoint (pagination) is unset if any post/page is detected

Best regards,
Maciej

• This reply was modified 8 years, 4 months ago by Maciej Bis.
• This reply was modified 8 years, 4 months ago by Maciej Bis.

Hi Mikael,

I will add an extra option to plugin’s settings in next release of the plugin, so it would be possible to enable “Deep detect” from WP-Admin dashboard and you will not have to use the snippet I pasted above.

As regards redirects problem, it is probably caused by canonical redirects. Could you disable them in my plugin’s settings and check if the issue still persists?

Please also describe your problem with 2.0.3 version. What exactly happened with the custom URIs, did they stop working completely or only the URLs that ends with numeric string (e.g. video/10312908201798379/) were not detected? Without that I am not be able to guarantee that the next version of plugin will solve your problem, because I am not be able to troubleshoot the issue and no one else reported the same bug. Thanks in advance!

Best Regards,
Maciej

• This reply was modified 8 years, 4 months ago by Maciej Bis.

Hi again Michael,

as far as I can see, the visitors were redirected because the same URI was already assigned to another CPT item:
http://www.autocustom.com.br/?p=98750

You should change the custom URI for this post:
http://www.autocustom.com.br/agenda/2o-encontro-beneficente-carangas-club/ (#98750)

and after that restore the correct custom URI for orignal post (#98714).

Please note that all the custom URIs should be unique. A list of duplicated URIs should be displayed here (this feature was added in 2.0.0 version):
http://www.autocustom.com.br/wp-admin/tools.php?page=permalink-manager&section=tools

Could you also tell me what feature stopped working after you updated the plugin to 2.0.3 version? Are the duplicated URIs the only problem you encountered?

All the plugin you use are compatible with Permalink Manager.

• This reply was modified 8 years, 4 months ago by Maciej Bis.
• This reply was modified 8 years, 4 months ago by Maciej Bis.
• This reply was modified 8 years, 4 months ago by Maciej Bis.
• This reply was modified 8 years, 4 months ago by Maciej Bis.

Hi Michael,

yes and I was talking about it in the very beginning (read and analyze my first comment) 🙂 As I explained in the first comment, in normal circumstances the Custom URIs that end with numerals are treated as pagination endpoints, but in your situation they are the integral part of the URIs and they are not pagination endpoints.

————

In 2.0.3 version, this permalink (it ends with numerals):
http://www.autocustom.com.br/video/08472205201793597/

is recognized natively as:
* Custom URI: video (this URI is not assigned to any page/post/CPT item)
* Page (pagination endpoint): 08472205201793597th page of …

while it should be detected like this:
* Custom URI: video/08472205201793597
* Page (pagination endpoint): [no pagination endpoint is declared]

And this permalink (it does not end with numerals):
http://www.autocustom.com.br/video/08472205201793597/1-mega-concentration-recordings-equipment-sem-limits/

is recognized natively as:
* Custom URI: video/08472205201793597/1-mega-concentration-recordings-equipment-sem-limits [correctly]
* Page (pagination endpoint): [no pagination endpoint is declared]

while it should be detected like this:
* Custom URI: video/08472205201793597/1-mega-concentration-recordings-equipment-sem-limits [correctly]
* Page (pagination endpoint): [no pagination endpoint is declared]

————

I adjusted the URI detect function in the most recent version of Permalink Manager and it is probably the reason why the custom URIs ending with numerals are no longer detected in 2.0.3 version. As I stated before, extra hook was needed to enable “Deep detect” in 2.0.3 version, so the Custom URIs that end with numerals are checked one more time.

“Force custom slugs” option has no effect in your case, so it does not matter if it is enabled or not.

Please download the dev version (2.0.4) from here:
https://downloads.wordpress.org/plugin/permalink-manager.2.0.4.zip

Then please install it manually and check if the issue still persists.

In 2.0.4 version, I added a new setting that allows to enable or disable “Deep URI Detect” (so no additional hook/code snippet is no longer needed). By the way, I analyzed the code and for sure it will not increase the pageload time, because no extra SQL queries are executed when the feature is enabled.

• This reply was modified 8 years, 4 months ago by Maciej Bis.

Hi Michael,

I double-checked it and reanalyzed the code, it has practically zero impact on page load. As I already mentioned, no additional SQL queries are executed. This feature is based on in_array() PHP function that does not slow down the website.