No front end access with Pretty Permalink

  • Resolved zorba256

    (@zorba256)


    5 years, 3 months ago

    I’m trying to use MetaBox plugin with the MB Custom Post type plugin (or the online Post Type Generator) to implement a custom post type. This is a simple “page like” CPT – without any custom fields.

    The setup at the back end is fine and the resulting CPT and individual pages appear in the Admin menu and can be edited without any issues. But I cannot access the resulting pages at the front end when using “Pretty Permalinks” set to “Post Name”. Only when this is set to “Plain” can I access the pages.

    The URLs for the pages, as seen in the editor, appear sensible and the rewrite rules in the wp_options table also appear sensible but I’m guessing that there is a problem here. I’ve made innumerable changes to the various parameter settings for the CPT – removing and re-creating the pages each time and reloading the resulting PHP code to functions.php and then regenerating the rewrite_rules. I’ve also tried using the WP Troubleshooting mode to disable all plugins other than MetaBox without any effect.

    Any suggestions as to what exactly is wrong and how to fix this?

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Anh Tran

    (@rilwis)

    5 years, 3 months ago

    Hi,

    I think the permalink is not refreshed yet. Can you try going to Settings > Permalink and re-save the settings?

    Thread Starter zorba256

    (@zorba256)

    5 years, 3 months ago

    Anh,

    Thanks for the suggestion but I know that the rewrite rules were being refreshed because my procedure has been to reset permalinks to “Plain” – check in the database WP_options table that all entries have gone and then set back to “Post Name” and confirm that rules have been inserted into the “rewrite_rules” “option_value” column.

    But of course when I generate the rules again this morning – having changed nothing since I changed some parameters yesterday and retested without success – everything now works OK.

    The key difference is though that I now have 34 lines with 17 rules – whereas previously I’ve always had just 22 lines with 11 rules

    Here’s a typical example of the 22 lines that have been generated before – note I’ve inserted CRLF here for ease of reading – (that’s not in the database):

    s:36:”mbmagazine/.+?/attachment/([^/]+)/?$”;
    s:32:”index.php?attachment=$matches[1]”;
    s:46:”mbmagazine/.+?/attachment/([^/]+)/trackback/?$”;
    s:37:”index.php?attachment=$matches[1]&tb=1″;
    s:66:”mbmagazine/.+?/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$”;
    s:49:”index.php?attachment=$matches[1]&feed=$matches[2]”;
    s:61:”mbmagazine/.+?/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$”;
    s:49:”index.php?attachment=$matches[1]&feed=$matches[2]”;
    s:61:”mbmagazine/.+?/attachment/([^/]+)/comment-page-([0-9]{1,})/?$”;
    s:50:”index.php?attachment=$matches[1]&cpage=$matches[2]”;
    s:42:”mbmagazine/.+?/attachment/([^/]+)/embed/?$”;
    s:43:”index.php?attachment=$matches[1]&embed=true”;
    s:25:”mbmagazine/(.+?)/embed/?$”;
    s:62:”index.php?post_type=mbmagazine&pagename=$matches[1]&embed=true”;
    s:29:”mbmagazine/(.+?)/trackback/?$”;
    s:56:”index.php?post_type=mbmagazine&pagename=$matches[1]&tb=1″;
    s:37:”mbmagazine/(.+?)/page/?([0-9]{1,})/?$”;
    s:69:”index.php?post_type=mbmagazine&pagename=$matches[1]&paged=$matches[2]”;
    s:44:”mbmagazine/(.+?)/comment-page-([0-9]{1,})/?$”;
    s:69:”index.php?post_type=mbmagazine&pagename=$matches[1]&cpage=$matches[2]”;
    s:33:”mbmagazine/(.+?)(?:/([0-9]+))?/?$”;
    s:68:”index.php?post_type=mbmagazine&pagename=$matches[1]&page=$matches[2]”;

    Here’s the 34 lines that are now generated that now work – note I’ve inserted CRLF here for ease of reading – (that’s not in the database)::

    s:38:”mbmagazine/[^/]+/attachment/([^/]+)/?$”;
    s:32:”index.php?attachment=$matches[1]”;
    s:48:”mbmagazine/[^/]+/attachment/([^/]+)/trackback/?$”;
    s:37:”index.php?attachment=$matches[1]&tb=1″;
    s:68:”mbmagazine/[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$”;
    s:49:”index.php?attachment=$matches[1]&feed=$matches[2]”;
    s:63:”mbmagazine/[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$”;
    s:49:”index.php?attachment=$matches[1]&feed=$matches[2]”;
    s:63:”mbmagazine/[^/]+/attachment/([^/]+)/comment-page-([0-9]{1,})/?$”;
    s:50:”index.php?attachment=$matches[1]&cpage=$matches[2]”;
    s:44:”mbmagazine/[^/]+/attachment/([^/]+)/embed/?$”;
    s:43:”index.php?attachment=$matches[1]&embed=true”;
    s:27:”mbmagazine/([^/]+)/embed/?$”;
    s:58:”index.php?post_type=mbmagazine&name=$matches[1]&embed=true”;
    s:31:”mbmagazine/([^/]+)/trackback/?$”;
    s:52:”index.php?post_type=mbmagazine&name=$matches[1]&tb=1″;
    s:39:”mbmagazine/([^/]+)/page/?([0-9]{1,})/?$”;
    s:65:”index.php?post_type=mbmagazine&name=$matches[1]&paged=$matches[2]”;
    s:46:”mbmagazine/([^/]+)/comment-page-([0-9]{1,})/?$”;
    s:65:”index.php?post_type=mbmagazine&name=$matches[1]&cpage=$matches[2]”;
    s:35:”mbmagazine/([^/]+)(?:/([0-9]+))?/?$”;
    s:64:”index.php?post_type=mbmagazine&name=$matches[1]&page=$matches[2]”;
    s:27:”mbmagazine/[^/]+/([^/]+)/?$”;
    s:32:”index.php?attachment=$matches[1]”;
    s:37:”mbmagazine/[^/]+/([^/]+)/trackback/?$”;
    s:37:”index.php?attachment=$matches[1]&tb=1″;
    s:57:”mbmagazine/[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$”;
    s:49:”index.php?attachment=$matches[1]&feed=$matches[2]”;
    s:52:”mbmagazine/[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$”;
    s:49:”index.php?attachment=$matches[1]&feed=$matches[2]”;
    s:52:”mbmagazine/[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$”;
    s:50:”index.php?attachment=$matches[1]&cpage=$matches[2]”;
    s:33:”mbmagazine/[^/]+/([^/]+)/embed/?$”;
    s:43:”index.php?attachment=$matches[1]&embed=true”;

    So presumably something I’ve changed yesterday has enabled this to work 24 hours later – perhaps disallowing hierarchical pages? I’m now worried that until I pin down the root cause I may lose front-end access again if I try changing those “Advanced” parameters again.

    Or could it by some kind of caching effect in WordPress that just took 24 hours to clear?

    Plugin Author Anh Tran

    (@rilwis)

    5 years, 3 months ago

    Hi,

    Looking at the difference between 2 set of rewrite rules, I notice these new rules are added in the larger set:

    s:27:”mbmagazine/[^/]+/([^/]+)/?$”;
s:32:”index.php?attachment=$matches[1]”;
s:37:”mbmagazine/[^/]+/([^/]+)/trackback/?$”;
s:37:”index.php?attachment=$matches[1]&tb=1″;
s:57:”mbmagazine/[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$”;
s:49:”index.php?attachment=$matches[1]&feed=$matches[2]”;
s:52:”mbmagazine/[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$”;
s:49:”index.php?attachment=$matches[1]&feed=$matches[2]”;
s:52:”mbmagazine/[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$”;
s:50:”index.php?attachment=$matches[1]&cpage=$matches[2]”;
s:33:”mbmagazine/[^/]+/([^/]+)/embed/?$”;
s:43:”index.php?attachment=$matches[1]&embed=true”;

    They’re the pretty links for the post type “mbmagazine”. It also was generated for hierarchical post type. I think they were generated (again) when you change the settings for hierarchy. This settings affects the permalink. I don’t think it’s cache problem (I’ve never seen cache issue).

    At least, it works now, which is a good news!

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘No front end access with Pretty Permalink’ is closed to new replies.