Support » Fixing WordPress » Permalink issue when using sub-categories. Why does it entirely rely on ID #?

  • I’m not sure where else to put this, but I’m having some issues with the way permalink structure work with categories (specifically sub categories). Hear me out. Hopefully you’re able to follow:

    Assuming you have a permalink structure of /%category%/%postname%/, then posts can indeed have a slug of /category-parent/category-child/post-name/. This is/was my goal.

    HOWEVER, the issue here is that if a post is assigned the full “tree” of categories (parent > child > sub-child), then it will only have the parent category slug in the permalink (assuming the Parent category was created first, and therefore has a lower ID # … which is often the case). Somewhat strangely though, if you assign ONLY the Sub Child category — which likely has a higher ID than Parent and Child, then the permalink will have the entire tree in the permalink. This is because, even though only Sub-Child was chosen, it cannot have only a sub-category within the permalink… since the sub-categories rely on the parent. But anyway… Here are some examples, and why it’s an issue to rely heavily on the Category ID for permalink. I think this needs to be resolved somehow…

    Example, where Children categories were created before parents (and therefore children had lower ID):

    Test Parent (ID: 163) > Test Child (ID: 162) > Test Sub Child (ID: 161)

    No matter what category I assign (whether only one of them, or the entire tree), the permalink returned is ideal (it includes the full path, up to the chosen category)

    • E.g., if I chose ONLY “Test Child”, the permalink is /test-parent/test-child/post-name/
    • E.g., if I chose ONLY “Test Sub Child”, the permalink is /test-parent/test-child/test-sub-child/post-name/
    • E.g., if I chose “Test Parent” and “Test Sub Child” (and didn’t choose “Test Child”), the permalink is still the full path of /test-parent/test-child/test-sub-child/post-name/
    • E.g, if I chose ALL 3 (entire tree), the permalink is still /test-parent/test-child/test-sub-child/post-name/
    • All of these are ideal, as I have /%category%/%postname%/ as the permalink structure. Therefore if/when there are sub-categories, it should add them to the permalink structure as a new directory. Yes please.

    However, this isn’t always the case.

    I also have another category structure of:

    Example Parent (ID: 120) > Example Child (ID: 142) > Example Sub Child (ID: 160)

    • In THIS case, the only difference is that the IDs become higher for the children.
    • In the other example, the sub-child was made first, then the child, then the parent. Therefore, because the sub-child has the lower ID #, the Post would always try to use that slug if it is assigned to it. Then, because it does use that slug… it also relies on using the child and parent too. That is ideal, where a post with a parent/child category has the full structure in the permalink.
    • But, based on the Example directly above, why on earth should the slug ID # determine how the permalink structure is? If I have a parent/child category selection in my Post, then it should ALWAYS use the full structure in the permalink. Yet, if the Parent’s ID is LOWER than the Child’s ID, it will only ever use the parent slug in the permalink.

    While I realize this probably isn’t considered a bug; at the very least, it should be considered unexpected behavior. Perhaps, there should be an option somewhere to choose whether the admin wants to have the full permalink structure when using sub-categories… or if they only want the parent category (or maybe only the child category). But the fact that it’s entirely dependent on the ID is a bit silly, as it now requires the IDs to be in a certain [backwards] sequential order (in order for the full path to show up).

    This makes it near impossible to have a full permalink structure of /parent/child/sub-child/ without going through all existing cats and ensuring the Parent/Child category relationship has lower IDs the further into the tree you go.

    • This topic was modified 1 year, 2 months ago by Jon Fuller.
Viewing 3 replies - 1 through 3 (of 3 total)
  • You got your answer from Otto, didn’t you? (and did you create a Trac ticket?)

    Yes, Otto replied to the Slack message after I posted here. But it doesn’t really answer/solve the issue, other than “don’t expect %category% in permalink to act in any rational behavior“.

    Ideally this problem (not technically a “bug”, but sure acts like one) would be looked into further and adjustments made at some point. I don’t know if my understanding of the ID # is the true cause of this issue, but it seems like it. If so, it prevents the “desired outcome” in most cases. Unless the admin user is aware of this strange “limitation”, then it surely leaves folks scratching their heads with why it works sometimes, but not others.

    In the end, due to the supposed way it works, it’s causing inconsistent and undesirable permalinks — as a result of an ID # that is somewhat “hidden” and unchangeable. Therefore the permalink is somewhat contingent on “the luck of the draw” of which order you added your Categories and Sub Categories (both, in the past and in the future). Unless every admin user of the install is always cognisant of the limitations; and remembers (from day one) to always add the parent/child categories in specific (reverse) order.

    Hence the addition of a Trac ticket. 😉

    As it stands now, our install is not able to have consistent /parent-cat/child-cat/post-name/ permalinks, since some parent/child categories were not added in the required order (IDs are not descending).

    • This reply was modified 1 year, 2 months ago by Jon Fuller. Reason: added code wrapper

    For anyone following along, here is the Trac ticket:

    I thought there was a recent similar question, but I searched and didn’t find it.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Permalink issue when using sub-categories. Why does it entirely rely on ID #?’ is closed to new replies.