The reason it adds an incremental is to distinguish between identically labeled endpoints (categories in your case).
By removing the ability to distinguish them WordPress will essentially be unable to map your content correctly and you will end up with it trying to match the first category it can find with that slug.
Could you tell us a little about your use case which you feel this behavior breaks and we might be able to help you come up with a better solution?
Thread Starter
malger
(@malger)
The assumption that the content wouldn’t map “correctly” is bootless, as the desired behavior is the “incorrect” behavior. The intent is to allow the same content to map to the same slug seamlessly.
The site is ottoprint.com. The code is that which generates the internal link buttons in the header of each post (the red buttons)
<!--code to display article category and item drill-downs in block at top of article division-->
<div class="article_cat_terms">
<ul class="article_terms">
<li class="article_category">
<?php $red_button = get_post_meta($post->ID, 'red_button', true);
//Checking if anything exists for the key red_button
if ($red_button) { ?>
<?php echo $red_button; ?>
<?php } //if there is nothing for red_button then display
else { ?>
<?php the_category(', '); ?></li>
<?php } ?>
<?php $trails = array("size","feat","tmplt","gall"); ?>
<?php $category = get_the_category(); ?>
<?php $cat_slug = $category[0]->category_nicename; ?>
<?php $parts = explode( '-', $cat_slug ); ?>
<?php if(($parts[1] == $trails[0])):
echo '';
else:
echo '<li class="article_terms"><a title="See the Shapes and Sizes Available in this Otto Product"
href="';
echo home_url( '/' );
echo $parts[0] . ( '-' ) . $trails[0] . ( '/' ) . '">SIZES & SHAPES</a></li>';
endif; ?>
<?php if(($parts[1] == $trails[1])):
echo '';
else:
echo '<li class="article_terms"><a title="Learn About the Features of this Otto Product"
href="';
echo home_url ( '/' );
echo $parts[0] . ( '-' ) . $trails[1] . ( '/' ) . '">FEATURES</a></li>';
endif; ?>
<?php if(($parts[1] == $trails[2])):
echo '';
else:
echo '<li class="article_terms"><a title="Get Art Template(s) for this Otto Product"
href="';
echo home_url ( '/' );
echo $parts[0] . ( '-' ) . $trails[2] . ( '/' ) . '">TEMPLATES</a></li>';
endif; ?>
<?php if(($parts[1] == $trails[3])):
echo '';
else:
echo '<li class="article_terms"><a title="See a Gallery of Images of this Otto Product"
href="';
echo home_url ( '/' );
echo $parts[0] . ( '-' ) . $trails[3] . ( '/' ) . '">GALLERY</a></li>';
endif; ?>
</ul>
</div>
We experienced an exploit which apparently struck against our server and wiped out our chart of categories, which had to be rebuilt. The only one which has this added-increment is the category with the slug wbnd. The ancillary posts which fall under that product thus cannot be found without the visitor to the site knowing the actual URL of the post desired — which might be problematic. Otherwise, I’ll have to hard-code those links, which becomes MOST awkward. It seems to me the sensible thing would be to eliminate the incrementing suffix to the slug. Which is what I’m asking for assistance in doing.
What is happening is that, if I assign a new post to the category Wristbands, it is assigned the slug wbnd-2 and cannot be found by our navigational armature. This is a problem I would prefer to avoid.
I see, ideally when you’ve experienced a hack you should be restoring backups instead of manually rebuilding things, it saves time and avoids problems like this. (I know that line can sound like I’m a bit of an ass, but that’s not my intention at all).
As for that single category receiving a numeric that indicated that the slug does indeed already exist in your database, or else it wouldn’t have appended a numeric at all. You could manually check for its existence if you feel like it, it should be in the table wp_terms
A quick lookup query to help you look into it;
SELECT
t.name,
t.slug,
p.ID,
p.post_title
FROM
wp_terms t
LEFT JOIN
wp_term_taxonomy tt
ON ( tt.term_id = t.term_id )
LEFT JOIN
wp_term_relationships tr
ON ( tr.term_taxonomy_id = tt.term_taxonomy_id )
LEFT JOIN
wp_posts p
ON ( p.ID = tr.object_id )
WHERE
t.slug LIKE 'wbnd%'
That will list any slugs it finds, as well as any posts assigned to each of them (it will show null in the ID field if there are no posts, just the category)
Thread Starter
malger
(@malger)
Yeah. ::wry grin:: I get that about the backups. But the panic-inducing stimuli of a boss screaming “We’ve been hacked! The Website is down! Fix It! Fix it with tape! Now!” kinda harsh your Zen mellow. And restoring from backups not being something one is all that comfortable with… Well, yes. Not really. In any case, I didn’t.
So what happens if I do surgery on the database and remove the incrementer? (I don’t see any behavior resulting in duplicate slugs being worse than orphaning any future posts and pages.)
I’d remove it the proper way if possible to ensure the proper cleanup functions run relating to it, did the initial one show up along the lines of this:
Wristbands, category, null, null
IF so it should be visible in the Posts > Categories list and you can just click the delete button which would be ideal.
There isn’t any major implications to just removing any entry from the wp_term_relationships, wp_terms and wp_term_relationships tables though, just that you need to make sure you remove any ocurrence from all 3
