【WordPress】WordPress有哪些缺点
据我所知,在街上,最近流行在WordPress中创建Affiliate Blog。然而,从PHP开发者和服务器管理员的角度来看,我认为WordPress有一些问题,我想尽量写下来。
我不打算批评WordPress,只是提醒大家注意:解决方法是以大约4:1:5的比例阅读相关的文章和评论,希望大家能够理解。
⇒ 【WordPress】WordPress的这里很好
1. 设计太过古老
在我之前写的一篇文章中,我对 admin-ajax.php 的代码进行了一番浏览,但是哦…这真糟糕…。
只需要一种选项:要求一次再次被连呼,在全局空间内定义()和配置数组混杂在一起,$_GET、$_POST和$_REQUEST翩翩起舞,文件不仅没有成为类,连函数都没有…不足200行的代码就成了一个笑料的宝库,仿佛时光倒流到了大约15年前的PHP4时代。
WordPress非常注重向后兼容性,这一点从他们最近才停止支持PHP5.2.4(发布于2007年8月30日!)这个非常古老的PHP版本就可以看出来。
我认为WordPress之所以能够成为全球最大的份额,这在很大程度上归功于该策略。
然而,在旧版本的 PHP 中,无法使用命名空间、闭包,也不能强制进行类型检查。
尽管PHP积极吸收其他语言的优点并不断发展,这实在是令人非常遗憾的事。
1-1. 频繁使用类型转换
在WordPress中,广泛使用类型转换。
举个例子,如果用(int)全文搜索源代码,能找到1500多处。
var_dump((int) 'a');
但是,上述的结果将会变为int(0),然而这种行为对于人类来说并不直观,如果随便使用的话,可能会成为错误和漏洞的温床。
我认为WordPress广泛使用类型转换是因为其设计类似于PHP4时代的旧版本,以及考虑到无法强制类型的旧环境等各种因素。
然而,我认为,如果采用更现代化的设计,以下三种致命的漏洞是不会出现的。
- WordPress 4.7.1 の権限昇格脆弱性について検証した | 徳丸浩の日記
1-2. 没有自动装填机制
在WordPress中,没有内置的自动加载机制来处理依赖关系。
例如,当设计师安装新的插件或主题之后,有时会在服务器日志中记录到“未定义的XXX…(XXX未定义)”这样的错误信息。
这是由于插件或主题作者未预料到的条件下,认为文件被加载,但实际上没有被加载的原因。
然而,PHP 自从大约15年前开始,就拥有了一个非常棒的功能,即只要按照特定的规则来定义,它可以在需要时自动加载所需的类(即定义的文件)。
//-- PHP5初期の頃の書き方
function __autoload($class)
{
$path = dirname(__FILE__) . '/' . strtolower($class) . '.class.php';
if (is_file($path)) { require $path; }
}
//-- ↑の書き方では、定義の追加や優先順位付けができないため、
//-- しばらく後、↓のように書けるようになりました。
spl_autoload_register(
function ($class) {
$path = __DIR__ . '/' . strtolower($class) . '.class.php';
if (is_file($path)) { require $path; }
}
);
Composer的出现让我们在使用环境的时候不再需要每次都写require等命令,这个机制正是这个工具的优点。不过,这个机制本身其实早在Composer出现之前就已经存在了。
然而,由于WordPress采用了更早的PHP4时代的遗留设计,除非重新设计,否则似乎很难让WordPress完全支持这个机制。
复杂的依赖关系会成为错误的滋生源,并且理解起来需要付出学习成本。
1-3. 不使用模板引擎
WordPress主题是用这样的代码编写的。
<html <?php language_attributes(); ?>>
<meta charset="<?php bloginfo( 'charset' ); ?>" >
<?php if ( is_front_page() ) { ?>
<h1 class="descr">
<?php bloginfo( 'description' ); ?>
</h1>
<?php } else { ?>
作为PHP的模板语言,它直接利用了PHP的性质,但这导致了可读性的降低和漏洞的出现。5
使用模板引擎除了可以与设计师轻松合作之外,还可以在安全方面轻松处理。
如果使用模板引擎,只需将其设为{{ $hoge }},不必考虑即使头脑空白也会自动完成的好处,这简直太麻烦了。6
使用模板引擎的话,那些低级的XSS攻击是很容易被防范的,这样的报告经常都会被提到,让人不禁会说:“现在才说这种明显谎言吗!?”
如果通过聪明人创造的出色机制,我们能够轻松地高效建立一个安全的系统,那将是理想的情况。可惜,WordPress并不如此,我认为插件和主题成为了产生漏洞的因素。
1-4. 在后方互换位置是一个困难的问题。
我以前是火狐浏览器的用户,但在无法使用“Tab Mix Plus”之后,我转而使用了Chromium浏览器。
我认为有不少像我一样的人。实际上,随着插件规范的改变,Firefox的份额以惊人的速度下降。
WordPress之所以受到欢迎的一个原因是其丰富的插件和主题资源。如果轻易抛弃向后兼容性,它很可能会陷入与Firefox类似的局面。
同样地,像旧版的 Windows 操作系统一样,旧版的 PHP 环境依然存在着很多。许多初学者在这样的环境下使用 WordPress。
这个问题非常困难,就连微软这样的公司,即使将操作系统的升级免费提供,也无法如愿以偿。对一个由志愿者组成的 CMS 来说,要求太多实在是太过分了。
2. 插件和主题的自由
最近WordPress的主体仍支持PHP5.2.4,但是有许多插件和主题不支持旧版本的PHP。
相反地,即使是像WooCommerce这样著名的插件,在PHP7.2或更高版本上的运行保证也会延迟。(WordPress本身推荐使用PHP7.3。)
然而,在使用不支持的版本进行操作时,对于处理方式没有明确的标准,因此 WordPress 本身可能会正常运行,但插件和主题可能无法正常运行…最糟糕的情况是甚至连 WordPress 本身也无法正常工作…这种情况经常发生。
如果您具有知識,只要查看日志就能很快找出原因。
然而,对于初学者而言,他们可能会认为“屏幕变成了一片空白,毫无意义”或者“无法运行,无可奈何”,从而继续使用古老版本的主体、插件和主题,这可能会导致安全漏洞的存在。
必须谨慎对待没有考虑到Nginx的Apache前提的内容。
许多WordPress插件是基于Apache环境进行开发的。
特别是那些使用.htaccess来进行控制和对重要设置文件进行访问限制的插件,需要注意。
在Nginx中,无法使用.htaccess,因此可能会出现插件作者未预料到的问题。
2-2. 兼顾是一个不容易的问题。
如果能够编写PHP,那么一个重要的优点就是可以自由地扩展功能而不受限制。
在第三方功能扩展方面,同时实现自由和稳定是非常困难的问题,在网络浏览器的插件开发领域中也经常被讨论到。
3. 所有的文件都被放置在公共目录下。
举个例子,wp-config.php是一个重要的“配置文件”,其中包含了连接数据库所需的信息。
由于它不是一个可以输出或处理来自外部请求的文件,因此无需从网络浏览器进行访问。
如果是服务器管理员,我认为会对将这样的文件放在公共目录中感到很不舒服。
在WordPress中,有一些PHP文件不希望直接从Web浏览器访问…
if (!defined('ABSPATH')) {
exit;
}
似乎写成这样是一种常规做法,但最好不要把这种文件放在公开目录中。
由于WordPress旨在提供传统的(即使对于初学者也很容易使用的)使用方式,如下载zip文件并解压后通过FTP上传,所以现在的文件结构不可避免地呈现出这样的形式,我认为这是无可奈何的。
然而,这样的设计并不能让任何人都轻松地更改文件结构,许多人仍然将所有文件放在公共目录下,这对于恶意者来说是个可口的环境。
3-1. 弊害的例子-1
例如,有些插件可能需要自行创建某些设置文件。
- http://○○○/wp-content/plugins/△△△/config.ini
这个文件也位于公开目录中,所以有可能通过网络浏览器等方式访问 config.ini,并盗取其中的重要信息。
例如,就像 Akismet 那样,有些插件会使用 .htaccess 在其自身的目录内(△△△)进行处理,但是这样的处理方法因插件而异。
在常用插件中,我觉得像这个例子这样的情况应该不会发生8,但将任何东西放在公共目录中是一个很大的风险。
3-2. 弊害的例子-2
【WordPress】我已经整理了一篇关于用谷歌 Dorks 搜索 WordPress 可能被黑客攻击的文章,请作为一种警示参考。
3-3.基本的文件结构
将不需要通过Web浏览器访问的文件放置在私密目录中是基本操作。
例如,不要把所有文件放在公开目录中,而是…
ServerName example.com
DocumentRoot /path/to/example.com
# example.com(公開) ┬ index.php
# ├ img ┬ 111.jpg
# │ └ 222.png
# └ data ┬ aaa.ini
# └ bbb.log
只需要将必须从浏览器访问的内容放在公开目录中,就不需要额外使用.htaccess等文件来限制访问。
ServerName example.com
DocumentRoot /path/to/example.com/www
# example.com ┬ www(公開) ┬ index.php
# │ └ img ┬ 111.jpg
# │ └ 222.png
# └ _data(非公開) ┬ aaa.ini
# └ bbb.log
4. 用户众多
WordPress是全世界最常用的内容管理系统(CMS)。
由于被吹嘘为适用于任何人的简易性,因此在其中也有很多人几乎没有安全意识。
因此,升级被忽略 ≒ 漏洞被忽略 ⇒ 网站篡改 ⇒ 攻击跳板 ⇒ 篡改另一个具有漏洞的WordPress… 导致了负面连锁反应。
实际上,根据服务器日志追踪攻击来源时,经常发现WordPress受到篡改,并被用作跳板。
在严重的情况下,同一服务器上运行的所有 WordPress 网域可能会遭到篡改。
4-1. 示例
以下是一个例子,涉及我所管理的服务器上受到大量恶意请求的篡改受害WordPress的HTML源代码。
为了避免代码被防病毒软件检测到,我进行了大部分的省略和隐藏,并对部分进行了整理。
<!-- eval()がある時点で悪い予感しかしません -->
<head>
<script>eval(String.fromCharCode(○, ○, ○, ...略</script>
<script async src='https://○agle○.x○z/ds.js&'></script>
<script async src='https://○ome○page.com/○○?frm=script&_cid=○'></script>
此网站拥有WordPress 4.5.2版本且未进行升级,此外还使用了有严重漏洞的插件。
即使收到了很多不正请求,只要采取了适当的防范措施,服务器的日志只会稍微被污染。
然而,如果对WordPress版本升级或插件的漏洞等问题置之不理,那么受到非法请求的WordPress也可能会遭到篡改损害。
4-2.虽然有一些优点,但是…
用户众多=意味着信息丰富。
在困扰时,稍微搜索一下就会有很多信息出现,这也被称为一个优点。
然而,PHP 领域的信息(尤其是旧的信息)是一片混乱。
动了(好像)就可以了!这样写的代码有问题,或者只是应急措施掩盖了臭味等等,可能会被介绍成最佳的解决方法,而且还被复制粘贴广传。
了解如下: 了解如下:有很多信息并不仅仅有益,也包括不易辨别正确与错误之处,尤其对于初学者而言,他们可能无法判断信息的真假,这是需要了解的缺点。尤其要注意旧信息。
作为一名PHP程序员,这种情况非常令人悲伤。
由于我通常会提供一些适用于初学者并可直接复制粘贴使用的简单代码,所以我将格外注意这些方面。
5. 源代码已公开
WordPress是一种开源软件。
由于该代码已经对全球优秀的技术人员开放,大部分情况下,Bug会立即被报告并迅速得到解决。
這是一個極具優勢的特點,現今網絡服務所依賴的許多技術都是基於開源開發的。
然而,这也意味着恶意的人可以自由阅读代码,即使代码已经修正好了,如果运营人员不及时升级版本,劣势将会变得更大。
6. 这是全球最易受到攻击的内容管理系统。
出于以上理由,对于有恶意的人来说,WordPress 成为了一个理想的目标。
实际上,当你查看病毒防护软件“危险”警告的URL的HTML源代码时,大多数情况下是像前面4-1中介绍的那样,是WordPress遭受了篡改损害。
重新审视使用的方法
即使是被認為具有優點的事物,根據操作者的不同可能會成為一個巨大的缺點。
- 我没有服务器知识,只能使用托管服务器。我并没有专注于WordPress,而是使用通用的托管服务器。我通过下载zip文件然后通过FTP上传的方式进行设置。版本更新基本上是手动通过WordPress管理界面进行的。
如果以上都适用于您,我并不表示您应该不使用WordPress。
如果你在Google上搜索一下,应该能找到一些提供针对WordPress运营进行调整和安全防护的专门租赁服务的地方。
在这种服务中,只需要通过网络浏览器进行简单操作,就可以解决WordPress的问题,因此我们建议首先从运营环境进行审视。
此外,我认为我们还需要小心那些不经过风险和缺点说明就轻易推荐WordPress的公司。
7. 重的
WordPress是一个非常占用资源的内容管理系统。
生成动态内容自然需要付出一定的成本,但WordPress可以使用各种挂钩来实现。随着插件的增加,它也会变得明显较重。
重量大的意思是指显示速度慢,而且容易受到过载的影响。
7-1. 简单的基准测试 de
在安装了Apache的环境中,可以使用ab命令(Apache Bench)来进行简便的基准测试。
-
- Apache 2.4.39
-
- MariaDB 10.3.15
-
- PHP 7.3.6
WordPress 5.2.1
我尝试在某VPS的最便宜套餐上搭建了上述环境,并尽量将其保持在原汁原味的状态下进行实验。
WordPress 是一个只进行了最基本设置的状态,只显示 “Hello world!” (插件和主题保持默认状态)。
$ /path/to/apache/bin/ab -c 10 -n 100 http://...
#-- yumなどでインストールしたパスの通った環境なら ab だけで使えます
# $ ab -c 10 -n 100 http://...
#-- Window 環境でもコマンドプロンプトから簡単に使えます
# C:\path\to\apache\bin\ab -c 10 -n 100 http://...
7-2. 结果
由于每秒请求数(即每秒处理了多少个请求)很容易理解,因此我选择了从一些服务器上多次尝试的结果中提取了仅仅3个实例。
7-2-1. WordPress
7-2-1. WordPress
Requests per second: 2.90 [#/sec] (mean)
Requests per second: 2.18 [#/sec] (mean)
Requests per second: 1.28 [#/sec] (mean)
7-2-2.原始的 HTML
这是一个输出与WordPress相同内容的HTML文件。
Requests per second: 489.61 [#/sec] (mean)
Requests per second: 474.17 [#/sec] (mean)
Requests per second: 339.36 [#/sec] (mean)
7-2-3. PHP的基本语法。
//-- ↓のようなコードでは、素のHTMLとほぼ同じ結果でした
echo <<<'__HTML__'
WordPressが出力するものと同じHTML
__HTML__;
完全没有进行任何调整的情况下,速度比预期的还要慢(汗)。
7-3. 让我们充分利用现金。
尤其是在博客中,从数据库中读取数据并生成HTML页面的过程(博客的展示)比数据库更新(博客的更新)的过程要多得多。
如果博客的内容没有更新,生成的HTML每次都是相同的。
如果将生成结果缓存并显示,会更快,对吧?相反,若经过程序或数据库,则会变慢相应的时间。特别是数据库方面容易成为瓶颈。12
如果我们积极引入缓存机制,包括加强使用CDN,可以在速度方面获得显著的效果。
很遗憾,WordPress默认没有这样的机制。
7-4. 草薙
作为一种经过多种调整的 WordPress 运行环境,还有一种名为 KUSANAGI 的选择。
如果您对此感兴趣,请考虑引入。
※以下的内容与主题无关。
8. 對於甜蜜的財利說辭,請注意。
有许多声称「只要用WordPress就能轻松赚钱的博客!」的人,但据说能够通过联盟营销每月赚取1万日元的人只占总体的不到百分之几。
你不需要费劲地向完全陌生的人透露赚钱的信息。所以,我认为你应该好好考虑一下为什么要公开信息。
请务必注意,不要被营销产品等所骗。
9. 关于SEO
有人认为WordPress在SEO方面很强大,但我认为这只对一半正确,一半错误。
毫无疑问,WordPress可以强有力地支持“向搜索引擎爬虫传递信息是更好的方法”这一想法,而无需过多思考复杂的事情。
尤其对于初学者而言,这无疑是一个巨大的优势。
9-1. 不是什麼特別的事情
但是,这只是一个被称为”技术性SEO”的部分,意思是要遵守这些规则,绝对不是”只有WordPress才能做的特殊事情”。
作为SEO方面的证据,经常会提到Google的Matt Cutts先生赞美WordPress的旧文章。
氏所称赞的是,WordPress 忠实地遵守了“向Google爬虫传达规则”的要求。
我认为将SEO描述为”强大”是一种误解的表达方式。
如果有专业知识的人,这是他们自古以来一直遵守的事情,所以不要误解这一点。
9-2. 搜索引擎的目标是什么?
搜索引擎的使命是“让人们更容易找到有用的信息”,如果不能做到这一点,就没有人会再使用搜索引擎了。
因此,从很久以前开始,“信息的质量”和“能够舒适安全地浏览页面”变得非常重要,这是非常自然的事情。
即使搜索引擎的算法发生些许变化,这个根本部分仍然不会改变。
你会想要查看一个没有什么实质内容的建立在WordPress上的赚流量博客吗?搜索引擎也在不断演进,以与人类一样进行判断。
我觉得SEO(特别是技术方面)有一种类似宗教的特点。
请把以”SEO”之名投入的时间和金钱,是否考虑花费在提供更高质量的内容上会更有意义呢,请好好想一想。
也许除了WordPress之外,还可以做其他的事情。