关于数据库访问的一个更重要的注意事项是，您不应该使用数据库常量。相反，您应该使用WPDB类，例如。
global $wpdb;
$results = $wpdb->get_results( \'SELECT * FROM wp_options WHERE option_id = 1\', OBJECT );
这仍然会给您带来一个问题，即您需要在WP上下文中，但它简化了数据库访问，并允许更多的缓存机会和安全检查
我应该包括wp-config.php?
否，您不应该执行您建议的任何一项操作，而应该按照预期使用WP CLI命令。不要从独立文件手动引导WordPress，这是一个安全问题，更不用说其他事情了
https://make.wordpress.org/cli/handbook/commands-cookbook/
updatedb\\u命令。php
class UpdateDB_Command {
public function __invoke( $args ) {
// ... update db cron code goes here
WP_CLI::success( \'All done!\' );
}
}
$instance = new UpdateDB_Command();
WP_CLI::add_command( \'updatedbcron\', \'UpdateDB_Command\' );
索引。php
// only include the command if WP CLI is running
if ( defined( \'WP_CLI\' ) && WP_CLI ) {
require_once dirname( __FILE__ ) . \'/updatedb_command.php\';
}
用法在cron作业中，运行以下命令：
wp updatedbcron --path="path to WordPress install on your server"
但我在共享主机上？我无法访问真正的cron作业或Shell访问权限。在这种情况下，您的cron作业似乎根本不是cron作业，而是用作cron作业的其他内容。在这种情况下，WordPress已经为这个名为WP Cron的机制提供了一种近似的机制。
您可以安排一个cron作业来触发一个操作/挂钩/事件，然后在该挂钩上运行代码，例如：
if ( ! wp_next_scheduled( \'my_task_hook\' ) ) {
wp_schedule_event( time(), \'hourly\', \'my_task_hook\' );
}
add_action( \'my_task_hook\', \'my_task_function\' );
function my_task_function() {
// your code
}
将在中运行代码
my_task_function 大约每小时一次。如果您能够访问真正的cron作业，则可以使用
wp cron event run --due-now --path="path to install" 定期
关于试图引导WordPress或在WP上下文之外执行其自身操作的独立文件的安全性说明可能很危险。WordPress是一个CMS，用于处理所有请求。
对于推送数据或检索数据的前端请求，请使用：
对于表单处理程序和其他页面提交，请使用：
钩住同一页面，检查页面是否已提交定期定时事件，或批量处理执行繁重操作的命令，如批量上载、图像处理、批量编辑，使用：
WP Cron WP CLI命令记住要有干运行模式，以便在提交之前检查结果。如果您使用的是标准的WP Cron，不要一次做太多，否则会耗尽时间或内存，尽量不要把事情看作是一个单一的任务，而更像是一个队列来清空您反复咬下的小块
独立文件会使我遭受什么样的攻击
我可以通过向您的
updatedb_cron.php 脚本，比如说每秒10次。现在，服务器正在运行其中10个脚本，试图更新数据库。恭喜您，您现在遇到了资源匮乏攻击，只需ping该URL足够多次，您的数据库服务器就会崩溃或锁定。
更不用说让它们同时运行可能会对您的站点造成的损害。重复的帖子、多个试图无序更新内容的脚本中损坏的内容等
你还需要在WordPress尝试做的开箱即用的事情中加入很多安全性。
更不用说脚本将始终运行，即使插件已停用。这意味着它也将在多站点安装中的每个站点上运行，即使它仅用于根站点
