关于如何使用PHP和Mysql构建wiki的好教程?

Dan*_*rov 1 php mysql wiki

我正在寻找一个关于如何使用PHP和MySQL构建wiki的好教程.我需要的东西会告诉我如何构建mysql数据库以及为文本diff等实现哪些算法.到目前为止,我发现的唯一一个是:http: //www.ibm.com/developerworks/opensource/tutorials/os-php-wiki1 / 但它基于cakePHP,我将不得不花一个月时间学习cakePHP来了解他们做了什么.

提前感谢您的任何提示!

ste*_*esu 8

假设你出于教程的缘故这样做(因为那里已经有很多精彩的wiki软件),让我们看看我是否无法解决这个主题的一般概述.当然,我没有时间或空间在这个答案中对整个wiki进行编码,如果我这样做,你也不会学到任何东西.但我将尝试列出一般的框图并给出一个数据库模式的示例.

首先,考虑您的wiki需要的不同页面.不是信息页面,而是实际上您将拥有的不同功能页面.

  • 一页用于解析请求(找到他们请求的文章并向他们发送信息)
  • 一页用于编辑文章
  • 登录的一页

根据您想要获得的简单或复杂程度,这些是您需要的唯一三个页面.您的"主页"和任何其他重要页面("联系我们","关于我们","如何使用此维基"等)都可以是文章,因此它们的处理方式与解析请求的方式相同.拥有功能性wiki后,您可以考虑添加以下部分内容:

  • 修订跟踪(每篇文章的更改日志)
  • 文章下载程序(使用PHP模块将文章输出为PDF,txt或其他格式,并将其作为下载使用header())
  • 媒体查看器(在维基百科上,当您单击图像时,它会将您带到一个页面,其中包含有关该图像的信息,上传者,有多大,等等)
  • 别的,有创意!=)

由于我们还没有正常运行的wiki,因此需要花费额外的时间和精力来实现,所以让我们从基本的三页开始.这些页面中的每一个都应该有自己的程序框图,或者它们必须执行的简单功能列表(具体的实现方式,我将由您决定)

对于文章解析脚本:

  • 首先,它必须找到他们正在寻找的文章.这可能涉及在执行搜索之前解析他们的搜索字符串(将"the_nile_river"转换为"尼罗河"),或者可能需要进行一些比较才能找到最相关的帖子(看到"尼罗河"并重定向到"尼罗河") .这部分维基可以无限改进,因为还没有人开发出"完美"的搜索算法.
  • 如果找不到文章,那么您需要有一些错误状态.要么提供建议文章的列表,继续搜索在每篇文章的正文中寻找他们的条款而不是标题,或者只是道歉并要求他们再次搜索.一个好的wiki将始终为他们提供创建文章的能力(如果它不存在)(文章编辑页面的链接)
  • 如果可以找到该文章,则需要能够将文章的内容翻译为HTML.对于极其简单的文章,这可能仅仅是使用的问题htmlentities()的事物转化喜欢&&.但是,随着您的文章变得更加复杂,您可能需要一种方式来显示标题,链接到其他文章等.为此,您可能希望使用特殊的模板解析,以便让您的用户无法直接控制HTML.我从来没有亲自编写其中的一个,但我可以想象它有很多preg_replace()陈述.
  • 最后,您需要考虑要显示的页眉/侧边栏/页脚信息.如果这些信息已经登录,则可能会有所不同,它可能包含相关文章的链接,并且可能包含编辑本文的链接.

至于编辑文章,这个页面可能是最简单的.我会做如下的事情:

  • 检查他们是否已登录
  • 如果是,请给它们<textarea>预先填充原始文章sans解析
  • 如果不是,请道歉并告诉他们登录.提供登录页面的链接

至于登录页面,如果您曾编写过多个用户的内容,那么您将了解这应该如何工作.

  • 检查是否$_POST["username"]已设置.如果是这样,他们已经发送了他们的登录信息.如果没有,请将登录表单发送给他们.(用户名,密码,提交)
  • 如果已设置,则哈希密码(使用salt!),与数据库中的哈希进行比较,如果匹配则启动会话.如果他们不匹配,请道歉并再次向他们发送登录表单.

至于数据库应该如何看,你有一个几乎需要的表(每个人都会把它放在一个数据库中,出于安全原因,没有人会相信它对平面文件).

users
-----
id (int)
username (string)
hashed_password (string)
extra info (email, website, last seen, preferences, etc.)
Run Code Online (Sandbox Code Playgroud)

包含任何登录用户信息的表.对于文章本身,您可以选择将它们存储在数据库中或文件中.MediaWiki将所有内容存储在MySQL中,但DokuWiki使用TXT文件.这部分是偏好问题,但还有一些其他问题需要考虑.

  • MySQL行具有设置大小.这个大小可以设置为令人难以置信的大,如16777216个字符,但仍有一个限制,意味着最大的文章大小.TXT文件可以任意增长(http://dev.mysql.com/doc/refman/4.1/en/storage-requirements.html)
  • 如果系统上有许多文件,打开和读取文件会变慢.防止这种减速的技巧在一些系统而不是其他系统上运行(取决于使用的文件系统)是制作多个文件夹.例如,每篇以"ab"开头的文章("Abdominals","Absorbency","Abel(圣经人物)"等)都在一个文件夹中,每篇以"ac"开头的文章都在另一篇文章中. .
  • 从理论上讲,TXT文件会带来更多的安全风险,因为您必须使用SQL服务器进行身份验证.通过将TXT文件放在webroot之外并正确设置权限(700或类似),可以抵消此安全风险
  • 通过将其保存在数据库中,可以更容易地存储关于文章的元数据(在文章的内容旁边,有一个单独的列用于"最后编辑","编辑","最后搜索"等.这种数据可以存储在TXT文件中,但是由于您需要考虑元数据的分隔符并且您必须编辑它而不损害文件的其他内容,因此要困难得多.

如果您要将文章存储在数据库中,我建议使用类似于以下内容的设置:

articles
--------
id (int)
title (tinyblob)
content (mediumblob)
meta info
Run Code Online (Sandbox Code Playgroud)

在添加功能时,您可能也开始想要这些功能的数据库表.例如,如果您要为每个图像设置一个媒体查看器页面(而不仅仅是让文章显示图像),那么您需要考虑以下事项:

  • 数据库链接到图像和有关图像的信息
  • 从模板内引用图像的方法
  • 基于数据库值解析该引用的方法

为了让您考虑可能包含的某些功能以及这些功能将如何影响您的数据库,以下是MediaWiki的数据库:

http://upload.wikimedia.org/wikipedia/commons/4/41/Mediawiki-database-schema.png