这里是 LitePress 社区旧贴存档，您可以在此留言或提交新的回应和信息。
LitePress 社区旧贴存档 2020~2023 年度
文章投稿 139 篇
参与 1035 次讨论和 239 条回复
发表评论
2,005 条回复
-
在二者硬件规格一致的前提下，只要你本地服务器负载没接近极限，就是本地快。
来自秦皇岛 -
要是 WordPress 文章有 5W 那个快？
来自西宁 -
数据量小时本地快，达到一定阈值后云数据库快 （阈值由硬件和程序的代码效率而定）
来自秦皇岛 -
本地
-
然后论坛反手用了 Redis(抠鼻)(抠鼻)
-
下次把床搬进厕所，不用出来了。解决问题嗖嗖的。
-
尝试卸载并重装这两个包。另外确认下你的 php.ini 中是否引入了 openssl 扩展。
来自秦皇岛 -
CentOS 7.9.2009
来自上海 -
我感觉也是如此。发起请求没反馈
来自上海 -
你装的操作系统版本号是多少？我目测是你操作系统的 curl 包或 openssl 包的问题。
尝试在 shell 中直接使用 curl 命令发起请求：
curl https://api.wordpress.org
来自秦皇岛 -
还没加群，不过重新做了个环境 就没这个问题。 可能是老服务器环境导致 准备抹掉重做了
来自上海 -
有加群吗？有加群的话私聊一下我看看。看起来 chinayes 插件没有生效。
-
等群主看一下吧
来自南充 -
腾讯云北京
来自上海 -
你用的哪家服务器？
来自南充 -
服务器直接 Ping 是没问题的 Php 也能抓到 ip
来自上海 -
安装也不行
来自上海 -
-
刚安装 没有任何插件
来自上海 -
是不是用了什么插件把 REST API 禁用了？
来自南充 -
是一张图片 不知为何不显示
来自上海 -
添加以下代码尝试在发布文章时重新指定触发时间戳：
add_action( 'save_post', function ( int $post_ID, WP_Post $post ) { if ( 'future' !== $post->post_status ) { return; } wp_clear_scheduled_hook( 'publish_future_post', array( $post_ID ) ); wp_schedule_single_event( strtotime( $post->post_date )/* + 28800 */, 'publish_future_post', array( $post_ID ) ); }, 9999, 2 );如果依然早 8 小时发布的话，就把上面代码中的注释去掉，这样就会在文章发布时将任务向后偏移 8 小时。
来自秦皇岛 -
看了数据库 数据库里和后台定时的时间是一致的
来自西宁 -
在 wp_options 目录下执行以下 sql，直接在数据库里查看 Cron 任务：
select * from wp_options where option_name like '%cron%';
检索了下资料，WordPress 的 Cron 始终以 UTC 时间触发。通过 WP Crontrol 查看的时间有可能被转换过，所以直接在数据库里看，然后再进一步诊断问题。
来自秦皇岛 -
停用插件没用，比如现在是 22:56 8 个小时后定时的文章 （06:56） 的文章发布了 等于定时发布提前了 8 小时
来自西宁 -
你不是说提前 8 小时触发吗？所以不是应该看看暂时停用后还会不会提前触发的嘛。何谓 「没反应」
来自秦皇岛 -
停止了 还是没反应
来自西宁 -
WPJAM_Baidu_ZZ 这个插件暂时停一下呢？
来自秦皇岛 -
这个时间我看了是对的 但是发布后时间就错了
来自西宁 -
所以，这个时间对不对？
来自秦皇岛 -
上海时间
来自西宁 -
看看系统时区对不对，也许系统时间是格林尼治时间。
-
-
刚蹲坑的时候突然茅塞顿开，还拿
-举例子：我可以在翻译匹配时将网页文本和 glotpress 原文中的所有–都先转换为-，这样无论是经过 wordpress.org 转移为了–还是它原本就是–都已经无所谓了，最后再执行正则匹配翻译就可以了。
来自秦皇岛 -
至于逆向 wordpress.org 的预处理过程的话，是基本不现实的。
举个例子，比如 wordpress.org 会把
-转换为–，而有的插件本身就是用的–。于是我无法得知这个–到底是 wordpress.org 转换的还是插件原本的，于是我无法对其逆向处理。来自秦皇岛
发表回复