如何实现类似Wordpress的永久链接

发布于 2024-10-01 18:55:22 字数 88 浏览 3 评论 0原文

我正在考虑构建一个 CMS,并且我想为我的帖子实现类似 wordpress 的永久链接。我该怎么做?
我的意思是,如何为我的页面定义自定义 url 结构?

I was thinking about a building a CMS, and I want to implement the wordpress-like permalink for my posts. How do I do that?
I mean, How do I define the custom url structure for my pages?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

请恋爱 2024-10-08 18:55:22

您使用什么语言?我假设您正在考虑 PHP(考虑到您对 word press 的引用)。您有几个选择:

  1. Mod-Rewrite
  2. 路由器

在我看来,最好的选择是找到一个提供良好路由功能的现代 Web 框架。此外,考虑修改现有的 CMS(存在很多;您似乎听说过 word press)。

What language are you using? I'm assuming that you are thinking about PHP (given your reference to word press). You have a few options:

  1. Mod-Rewrite
  2. Router

In my opinion, the best option is to find a modern web framework that provides good routing functionality. Furthermore, look at modifying an existing CMS (many exist; you seem to have heard of word press).

我不在是我 2024-10-08 18:55:22

我建议创建传递 URL 参数的链接,例如 ..."http://...PostID?123&CatID=232&...",以便当用户单击该特定链接时,您可以解析URL中的参数,根据id获取准确的帖子,甚至根据需要传入其他字段进行进一步过滤。

I'd recommend creating links that pass in a URL parameter such as ..."http://...PostID?123&CatID=232&..." so that when the person clicks on that particular link, you can parse the parameters in the URL, and get the exact post based on id, or even do further filtering by passing in other fields as needed.

温柔戏命师 2024-10-08 18:55:22

如果您想自己构建整个系统,请首先了解前端控制器是什么,因为它实际上是解决了如何针对不同 URL 执行相同代码的根本问题。有了这种理解,就有两种方法可以解决此设计模式的问题:URL 重写或物理文件生成。

URL 重写

通过 URL 重写,您需要拦截请求的 URL 并将其发送到前端控制器。通常,这是在 Web 服务器级别完成的,尽管某些应用程序服务器也充当 Web 服务器。对于 Apache,正如其他人所发布的,您可以使用 mod_rewrite 和如下所示的规则:

RewriteRule ^/(.*) /path/to/front/controller.ext [E=REQUEST_URI:%{REQUEST_URI},QSA,PT,NS]

使用此规则,最初请求的路径将作为名为“REQUEST_URI”的变量发送到前端控制器。请注意,我不确定 PHP 中访问它的正确语法。在前端控制器中散列(例如 MD5)该值并使用它从数据库中查找记录 - 考虑到您使用的任何散列算法都会产生重复项。如果您允许 URL 超过数据库中 varchar 数据的最大列大小(假设您无法搜索 CLOB),则哈希是必需的。

物理文件生成

物理文件生成将创建一个映射到您想象的永久 URL 的文件。因此,您需要编写一些在发布文件时创建/重命名文件的内容。这消除了存储散列的需要,而是将您想要在该文件中提供的帖子的信息(即帖子的 ID)放入其中,并将其传递给前端控制器。

推荐

我更喜欢 URL 重写方法,这样您就不必担心在运行时编写动态代码文件。也就是说,如果您想要一些不那么神奇的东西,或者您期望很多请求,则物理文件生成是可行的方法,因为它更明显并且需要服务器做更少的工作。

If you want to build the whole thing yourself, first understand what a front controller is, as it really addresses the underlying issue of how do you execute the same code for different URLs. With this understanding, there are two ways to attack the problem with this design pattern: URL rewriting or physical file generation.

URL Rewriting

With URL rewriting, you would need intercept the requested URL and send it onto your front controller. Typically this is accomplished at the web server level, although some application servers also act as web servers. With Apache, as others have posted, you would use mod_rewrite with a rule that looks something like this:

RewriteRule ^/(.*) /path/to/front/controller.ext [E=REQUEST_URI:%{REQUEST_URI},QSA,PT,NS]

With this rule, the path originally requested with be sent to the front controller as a variable called "REQUEST_URI". Note, I'm not sure the right syntax in PHP to access it. In the front controller hash (e.g. MD5) this value and use it to lookup the record from a database - take into account whatever hashing algorithm you use will produce duplicates. The hash is necessary if you allow URLs over whatever the max column size is in your database for varchar data, assuming you can't search on CLOBs.

Physical File Generation

Physical file generation would create a file that maps to the permanent URL you're imagining. So you'd write something that creates/renames the file at time it's posted. This removes the need for storing a hash and instead you place information about the post you want to serve inside that file (i.e. ID of the post) and pass that along to the front controller.

Recommendation

My preference is the URL rewriting approach, so you don't have to worry about writing dynamic code files out at runtime. That said, if you want something with less magic, or you're expecting a lot of requests, the physical file generation is the way to go because it's more obvious and requires the server to do less work.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文