[wp-trac] [WordPress Trac] #13490: Permalinks Issues for Custom Post Types with Parents

WordPress Trac wp-trac at lists.automattic.com
Sun May 23 02:16:01 UTC 2010


#13490: Permalinks Issues for Custom Post Types with Parents
-------------------------------+--------------------------------------------
 Reporter:  mikeschinkel       |        Owner:            
     Type:  defect (bug)       |       Status:  closed    
 Priority:  normal             |    Milestone:            
Component:  Post Types         |      Version:  3.0       
 Severity:  normal             |   Resolution:  worksforme
 Keywords:  reporter-feedback  |  
-------------------------------+--------------------------------------------

Comment(by mikeschinkel):

 Replying to [comment:9 dd32]:
 > The problem with this ticket, Is that you're not separating out the
 issues you're having.

 Fair enough.  I'll break them out as I have time.

 > No. Custom post types default rewrite rules are not supposed to have
 post_type1/post_type2/post_type3, As you've done however, theres nothing
 stopping you manually adding a rewrite rule to achiece this.

 Can we avoid talk of "supposed to have" and "not supposed to have?"  It
 just clouds the issue.

 There is a use-case and I'm trying to solve it.

 > The reason the tokens are not being replaced in the url, is most likely
 because only one post is being requested, The post hierarchical code is
 for a SINGLE post type, as in post1/post2/post3, all of the same
 post_type, The same as pages in core, You cant mix them.

 There are many valid use-cases that will emerge with custom post types
 where this will be needed. I have two clients of two who need this, and
 every personal project I have needs it too.  I understand that the code
 might currently not contemplate such usage but the purpose of my ticket it
 to present these use-cases as useful requirements.

 > Finally, Yes, The core rewrite code is limited in the URL's it can
 create and handle without a plugin/theme extending the rewrite rules, This
 is expected, it covers 99% of use-cases, and allows for authors to define
 their own.

 My expectation is that 99% of use-cases for blogging are covered but that
 probably 10% of use-case as a CMS are currently covered. I believe we'll
 see a lot of demand for this type of URL and post-to-post relationship.
 But no need to take my word for it, we can just wait to see how many
 others demand it.

 > The system is limited in how it can parse urls, and as you know, theres
 another ticket for that.

 Yes I'm all too aware. At least one other ticket for this I submitted.
 That was a bigger picture ticket; this was a tactical ticket.

 > I cant follow the essay of this ticket to determine if there is actually
 any bugs i've not covered, Trac is for reporting issues, specific issues,
 You might be better off on wp-hackers for working out how to do some
 things.

 I appreciate that this is long so I will break it up as I have time.

 As for wp-hackers list, I don't really think that list is productive
 anymore. Too many competing visions for how it should be used and too many
 people annoyed by people who don't use it the way they want it used.
 Better to discuss issues elsewhere I think.

 > Set the rewrite arguement to false to prevent the default rules being
 created - Reading the register_post_type() function or its documentation
 will reveal this.

 Your response is a bit dismissive here, don't you think?  Consider you are
 chastising me for not "''finding a needle in the haystack''." I have read
 the function, I've traced through it many times with a debugger, and I
 have read the documentation, many times but I've never recognized that
 behavior.  I guess I'm just asking for a bit more respect on this point.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13490#comment:10>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list