从流行语的角度来看,这一切听起来都很好,但对我来说这有点令人困惑,因为我已经将 PHP 的模型视为MVC模型。它为您提供API来编程并将您的内容传送到您的网络服务器 Apache 和您的数据库(类似于 MySQL)。它将代码(模型)为您翻译成 HTML(视图)......前提是您想要这样做,并且您提供代码作为用户输入(控件)。当您将不熟悉您的惯例的人带入协作时,过于沉浸在术语中会让人分心,并可能导致混乱。(这可能永远不应该在生产环境中用于付费演出。)
我可以告诉你,在你引用他们的.htaccess
文件的页面上需要做一些工作。该[L]
标志告诉 mod_rewrite 这是规则返回 true 时要处理的最后一个命令。所以你要么需要这样做:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^(.*)$ public/$1 [L]
</IfModule>
或以下...但他使用的是passthru标志,这意味着他暗示在最后一条规则之前可以处理其他事情(例如,可能是rewrite_base
or ),但他的文件alias
实际上并非如此,因为.htaccess
有点光秃秃的。所以这段代码的工作方式与上面的代码类似,但并不完全相同。但是它们不能一起使用,实际上没有必要:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php?url=$1
</IfModule>
不同之处在于它的处理方式。在第一个.htaccess
示例中,您将任何文件传递给 index.php,无论它是否存在。您可以 [意外地] 重写具有真实文件的路径,以便永远不会使用此方法访问真实文件。一个示例可能是您有一个名为site.css
无法访问的文件,因为它被重定向回index.php
.
在第二个规则集上,他至少检查服务器是否没有被请求的名称的文件或目录,然后他们将其index.php
作为$_GET
变量转发(这似乎有点毫无意义)。
我通常写这些的方式(因为我知道 mod_rewrite 已经加载到配置中)是这样的:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^mydomain.com
RewriteRule (.*) http://www.mydomain.com/$1 [R=301,L]
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule .* index.php
在我的 PHP 代码中,我将其$_SERVER['REQUEST_URI']
与数据库中的 URI 列表进行匹配。如果有匹配,那么我知道它是一个真实的页面(或者至少在某个时间点存在记录)。如果没有匹配,那么我会分解 request_uri 并使用 FULLTEXT 搜索强制它通过数据库,以查看站点上可能匹配的内容。
注意:如果您盲目信任 request_uri 并直接查询数据库而不清理它,您将面临 SQL 注入的风险。你不想成为pwnd。
<?php
$intended_path = $_SERVER['REQUEST_URI'];
if(in_array($intended_path,$uris_from_database)){
//show the page.
} else {
$search_phrase = preg_replace('!/!',' ',$intended_path);
$search_phrase = mysqli_real_escape_string($search_phrase);
$sql = "SELECT * FROM pages WHERE MATCH (title,content) AGAINST ('$search_phrase');"
}
抱歉,如果这听起来有点迂腐,但我有管理几百万美元(临时)网站构建的经验,这些构建遇到了人们不遵守标准约定(或至少是商定的团队共识)的障碍。