我的公司想在他们的 Internet 站点上使用 WordPress，我主要关心的是准备好的语句的使用。根据this ，我难以置信地自己阅读了源代码，WordPress 清理了字符串，但没有在数据库中准备好。
我能做些什么来得到真实的东西吗？还是我的担忧没有根据？
最佳答案
历史
了解 wpdb类，最初 a fork的 Justin Vincent's ezSQL library , 介绍 way back in 2003 , 只有 a couple of months MySQL 准备语句协议(protocol)发布后超过a year before PHP 有任何 API 支持来访问它:因此 WordPress 做了它当时唯一能做的事情，并要求将任何变量直接连接到动态 SQL 中。
那时，ezSQL(以及 WordPress)used PHP 的 mysql_escape_string()函数来转义这些文字——因此不知道数据库连接的实际编码(一种仅在 PHP 本身中解决的威胁 just a few months earlier)。
这仍然是 WordPress 对 SQL 注入(inject)的(唯一)防御 for nearly two years ，于是它switched使用(更不安全)addslashes()为了逃避——当时的情况一直存在for over four years直到 mysql_real_escape_string() 终于 utilised (尽管 wpdb::prepare() 在 introduced 中是 the interim)!
然后它不是 another five years直到 WordPress 开始 using本地语句准备的驱动程序能够(即MySQLi):这是不到两年前的事了，@naththedeveloper already pointed out ，讨论在ticket #21663这表明使用 native 准备好的语句甚至可能不在待办事项列表中。
现状
不幸的是，因为 MySQLi 对象是 a protected member wpdb 类没有 getter(并且在内部分配 during instantiation )，您无法将 native 准备好的语句与 WordPress 的数据库连接一起使用(至少，如果不修改/替换 wpdb 与你自己的类)。
Is there anything I can do to get the real thing?
当然，您可以打开自己的/单独的数据库连接，您可以完全灵活地按照自己的意愿进行操作。
Or are my concerns unfounded?
与原生语句准备一样出色(我同意它确实应该是任何新项目中针对 SQL 注入(inject)的默认防御策略)，它也有 its downsides .小心地转义一个变量以用作 SQL 文字(例如，通过 PDO 的准备语句模拟完成；这就是 wpdb::prepare() 这些天试图提供的)应该 抵抗所有已知的攻击...
关于php - 我该怎么做才能在 Wordpress 中获得实际准备好的语句，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38206366/