关于 ASP.NET MVC 内容系统中的 slugs 的一些问题
在我的应用程序中，我当前使用的表单允许输入“标题”和“Slug”字段。现在我已经在蛞蝓的事情上挣扎了一段时间，因为我永远无法一劳永逸地决定如何处理它们。
1) 使标题和副标题独立
我是否应该允许用户分别输入标题和副标题？这是我首先拥有的。我还有一个选项，如果用户没有输入 Slug，则它是从标题派生的。如果两者都输入，则 Slug 字段优先。
2）从标题派生Slug，插入内容后即为Slug，不再进行更改
然后，我切换到仅标题字段并从标题派生Slug。在这样做的过程中，我发现现在我必须更改所有允许用户输入数据的表单。这种方法还可以防止用户更改 Slug - 他们可以更改标题，但对 Slug 没有影响。你可以把它想象成Slug是唯一的ID。
3）现在我再次考虑允许用户更改slug
尽管我认为这没有那么有用。有多少次有人已经添加、花费时间编写的内容甚至需要更改标题或别名？我不认为有那么多次。
第三个选项的最大问题是，如果我使用 Slug 作为 ID，则当 Slug 更改时，我需要更新整个地方的引用。或者维护一个包含某种 Slug 历史记录的表。
我希望您对这些有效的问题有何看法？
如果有人有这方面的示例数据库设计，如果您在此处分享，我们将不胜感激。
In my application I'm currently using forms which allow to enter Title and Slug fields. Now I've been struggling with the slugs thing for a while because I can never decide once and for all how to handle them.
1) Make Title and Slug indenpendent
Should I allow users to enter both Title and Slug separetely? This is what I had first. I also had an option that if user did not enter the Slug it was derived from the Title. If both were enter, the Slug field took precedence.
2) Derive Slug from Title, when content is inserted that's it for the Slug, no more changes
Then, I switched to only Title field and derive Slug from title. While doing it I found out that now I have to change all the forms that allowed user to enter a slug. This way of doing it also prevents users to change Slugs - they can change the Title but it has no effect on the Slug. You can think of it like Slug is uniqued ID.
3) Now I'm thinking again of allowing users to change slug
Though I don't think it is all that useful. How many times does the content that someone already added, spent time on writing it, even require a change of either Title or slug? I don't think it is that many times.
The biggest problem with the 3rd option is that If I use Slugs as IDs, I need to update the reference all over the place when Slug changes. Or maintain a table that would contain somekind of Slug history.
What are you thoughts on these, I hope, valid questions?
If someone has a sample DB design for this, it would be appreciated if you share it here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您决定允许用户编辑 slug，则可以在 URL 中包含内容 ID，并在 slug 与当前 slug 不匹配时执行
301 永久移动。例如，如果/product/42/black-bucket/现在是/product/42/shiny-black-bucket/，您可以重定向到新的 slug。我看到了一些建议，不允许您的 URL 出现任意的 slugs，因为这打破了搜索引擎爬虫的规范链接的概念，并允许恶意人员操纵您的结果。If you decide to allow users to edit slugs, you could include the ID of the content in the URL and perform a
301 Moved Permanentlywhen the slug doesn't match the current slug. E.g., if/product/42/black-bucket/is now/product/42/shiny-black-bucket/, you could redirect to the new slug. I saw recommendations not to allow arbitrary slugs for your URLs, as this breaks the concept of canonical links for search engine crawlers and allows malicious folks to game your results.我刚刚与客户一起经历了所有这些，整理了有关 URL 的规则等。
您的 slug 应该至少稍微独立于标题，如果只是为了确保您可以取出标准的“停止”单词” - 大多数 SEO 会建议页面路径尽可能丰富关键字，因此页面标题为：
可能会成为：
但如果可能的话，您应该在作者创建帖子时尽可能将其自动化，以便当他们使用 Tab 键/移出标题字段时，您可以使用以下内容填充 Slug/Name/Path 字段一个删除了所有符号的字符串，（理想情况下）删除了商定的停用词列表并用连字符替换了空格，因此该标题的自动 slug 可能是：
但你需要给予作者超越这一点的调整能力。
我们还指定，这种自动化仅在作者创建帖子时才会发生，因此后续编辑不会自动更改 slug，以确保我们不会遭受外部链接腐烂（我们使用的 CMS 管理所有内部链接）。
作者唯一真正应该更改标题的情况是他们发表了拼写错误或诽谤性内容。
I've just been going through all of this with a client, sorting out the rules around the URLs, etc.
Your slug should be at the very least slightly independent of the title, if only to ensure that you can take out standard "stop words" - most SEO's would recommend that the page path be as keyword rich as possible so a page title of:
Could become a slug of:
But if possible, you should automate it as much as possible when the author is creating the post, so as they tab/move out of the Title field you populate the Slug/Name/Path field with a string that has removed all symbols, (ideally) removed an agreed list of stop words and replaced spaces with hyphens, so the automated slug from that title could be:
But you need to give the author the ability to tweak beyond that.
We've also specified that this automation will only happen when the author creates the post, so subsequent edits would not automatically change the slug, to ensure that we don't suffer from external link rot (the CMS we're using manages all the internal links).
The only time the author should really be changing the slug would be if they'd published a typo, or something libellous.
我个人建议让用户编辑页面记录的标题和其他内容。一旦他们完成了此操作，您就可以从标题（或您喜欢的任何其他内容）中得出 slug。如果他们更改标题，则 slug 可能会更改，但您可以保留与同一页面关联的旧 slugs 的记录。如果有人带着旧的 slug 访问该网站，那么您可以向他们发送 301 响应并将他们重定向到新页面。这将通过您的路由处理的拦截页面进行。
另一个问题是，如果他们更改标题，这肯定是一个包含新内容和新标题的新页面吗？
想法？
Personally I would suggest letting the user edit the title and the other contents of the record for the page. Once they have done this you can derive the slug from the title (or anything else you feel like). If they change the title then the slug can change but you could keep a record of the old slugs associated with the same page. If someone comes to the site with an old slug then you can send them 301 response and redirect them to the new page. This would be via an interception page handled by your routing.
Another question would be if they are changing the title, surely it's a new page with new content and with a new slug?
Thoughts?
只允许用户在页面处于草稿状态时编辑标题或 slug 怎么样？页面发布后，标题和 slug 将永久保留。
或者正如@WestDiscGolf 所说，记录所有旧的子弹并发送重定向。
How about only allowing the user to edit the title or slug while the page is in draft. When the page is published the title and slug become permanent.
Or as @WestDiscGolf said, keep a record of all old slugs and send a redirect.