WordPress.org

Ready to get started?Download WordPress

Forums

custom post type 404s even after resetting permalinks (7 posts)

  1. jonathanjfshaw
    Member
    Posted 1 year ago #

    I created a custom post type, of which the (simplified) arguments are:

    register_post_type( 'Event',
    			'public' => true,
    			'rewrite'	=> array( 'slug' => 'eventy'),
    			'has_archive' => false,
    			'hierarchical' => false
    )

    It works fine in general. However if I try to rewrite the URLs in functions.php, for example:

    function my_post_type_link_filter_function( $post_link, $id = 0, $leavename = FALSE ) {
       return str_replace('eventy', 'eventx', $post_link);
    }
    add_filter('post_type_link', 'my_post_type_link_filter_function', 1, 3);

    The result is that the new 'eventx' URLs appear correctly in links, lists, etc, generated by wordpress. But when I go to those 'eventx' URLs I get a 404. But going to an 'eventy' URL still works.

    I've tried changing the permalinks settings to default and back to post name, many times. This is supposed to rest permalinks and fixes this issue for many people I've seen online. Not for me.

    Anyone know what the cause might be? How do I go about troubleshooting this? I'm weak on the theory of URL rewriting.

    If you're interested, my purpose is not the trivial eventy-->eventx substitution mentioned above. I actually want to slip in the year/month an event starts (not was published) into its URL. Debugging got me to realise I had a more basic issue as even this trivial x-->y rewrite still throws 404s.

    Thanks for reading!

  2. bcworkz
    Member
    Posted 1 year ago #

    It's easy to rewrite URLs, but if the request parser doesn't know about it (it can't know about your filter hook), it can't form the correct query to retrieve the content, resulting in a 404 error.

    I think I understand what you're really trying to do. Perhaps you could use the Rewrite API to extract the year/month portions of the URL and return them as URL parameters. Then your post type template can extract the URL parameters from $_GET and do whatever needs doing with the data.

  3. jonathanjfshaw
    Member
    Posted 1 year ago #

    Hmm. I assumed that add_filter('post_type_link ... was clever enough to tweak the request parser as well.

    The people in these discussions:
    //http://xplus3.net/2010/05/20/wp3-custom-post-type-permalinks/
    //http://wordpress.stackexchange.com/questions/36017/custom-slug-for-custom-post-type

    Seems to be doing this fine without getting the 404s I'm hitting.

    I don't think I need them year&month as URL parameters because I don't want to do any data manipulation or lookup with them particularly.

    It's just that at the moment I have say three events (posts in my custom post type) called say "Fishing trip". These get assigned permalinks by default like
    mysite.com/events/fishing-trip
    mysite.com/events/fishing-trip-2
    mysite.com/events/fishing-trip-3
    Which is boring and inelegant.

    I want instead
    mysite.com/events/2013/january/fishing-trip
    mysite.com/events/2013/may/fishing-trip
    mysite.com/events/2014/march/fishing-trip
    Prettier and more informative.

    But I'm just using the year&month to build a more unique URL name for the post, I'm not interested in doing anything more with them. No template or function of mine needs to read the URL to know the year and month of the current post. If they need to know this I just query the start_date custom field of the post.
    I'm not interested in having category-style pages like
    mysite.com/events/2013.
    The year&month is just cosmetic in the URL.

    Anyway, if my use is simple like this, where to go next?
    If I need to hack the request parser as well, can you point me in the direction of the function name / doc / example I need.
    It's weird that the other discussion I link to above, which seem to be trying to do exactly the kind of thing I am, don't talk about this.

    Thanks for taking an interest!
    Jonathan

  4. bcworkz
    Member
    Posted 1 year ago #

    I guess I didn't understand what you're trying to do after all, but I think I've got it now.

    Your post slug needs to have a static element for the parser to recognize. Then you can replace the variable portion with whatever. Your post type slug should be something like /events/%year%/%month% . Then your hook function can insert any year and month it likes, and the parser is happy because it recognizes /events.

  5. jonathanjfshaw
    Member
    Posted 1 year ago #

    Having in my custom post type
    'rewrite' => array( 'slug' => 'event/xxx'),
    and in my post_type_link filter
    $output = str_replace('xxx', 'yyy', $post_link);

    Still leaves the same results, even after resaving permalinks:
    the URLs list fine but return 404s.
    e.g. mydomain.co.uk/betasitewpinstall/event/yyy/introduction-to-vision-quest-3/ returns 404

    I'm getting the idea that maybe I need to add add_rewrite_rule as well

  6. bcworkz
    Member
    Posted 1 year ago #

    You shouldn't need to use the rewrite API as using the rewrite argument when registering your post type should have the same effect. I'm at my limit of understanding this aspect of custom post types, but I would guess that the portion of the slug that you will overwrite needs to be bracketed with '%" to indicate a variable tag.

    The way you have it, the parser is looking for the entire slug including the 'xxx'. Your slug should be 'event/%xxx%'. Then your filter can replace that with 'yyy' and the parser will only try to match 'event'. I wish I was more confident this is correct, but it did work for those other guys in the links you provided. Gotta be worth another go?

  7. jonathanjfshaw
    Member
    Posted 1 year ago #

    I tried with % signs but made no difference.

    Adding add_rewrite_tag as suggested by Milo:
    http://wordpress.stackexchange.com/questions/83531/custom-post-type-404s-with-rewriting-even-after-resetting-permalinks

    fixed it nicely.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.