参与者列表 Search 感谢 2020 ~ 2023.4 所有关注过 LitePress 的用户 此版已存档，详情参见 《推广名单》 《“ 参与者列表” 》 有 2,005 条评论 doingxx 2021.07.15 腾讯云北京 不凡 2021.07.15 你用的哪家服务器？ doingxx 2021.07.15 服务器直接 Ping 是没问题的 Php 也能抓到 ip doingxx 2021.07.15 安装也不行 不凡 2021.07.15 有个错误提示是未能连接 wp 服务器，你安装这个插件试试 https://a1.wp-china-yes.net/apps/wp-china-yes.zip doingxx 2021.07.15 刚安装 没有任何插件 不凡 2021.07.15 是不是用了什么插件把 REST API 禁用了？ 文派叶子 🍃 2021.07.15 添加以下代码尝试在发布文章时重新指定触发时间戳： 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 小时。 cgq630105023 2021.07.14 看了数据库 数据库里和后台定时的时间是一致的 文派叶子 🍃 2021.07.14 在 wp_options 目录下执行以下 sql，直接在数据库里查看 Cron 任务： select * from wp_options where option_name like '%cron%'; 检索了下资料，WordPress 的 Cron 始终以 UTC 时间触发。通过 WP Crontrol 查看的时间有可能被转换过，所以直接在数据库里看，然后再进一步诊断问题。 cgq630105023 2021.07.14 停用插件没用，比如现在是 22:56 8 个小时后定时的文章 （06:56） 的文章发布了 等于定时发布提前了 8 小时 文派叶子 🍃 2021.07.14 你不是说提前 8 小时触发吗？所以不是应该看看暂时停用后还会不会提前触发的嘛。何谓 「没反应」 cgq630105023 2021.07.14 停止了 还是没反应 文派叶子 🍃 2021.07.14 WPJAM_Baidu_ZZ 这个插件暂时停一下呢？ cgq630105023 2021.07.14 这个时间我看了是对的 但是发布后时间就错了 文派叶子 🍃 2021.07.14 所以，这个时间对不对？ cgq630105023 2021.07.14 上海时间 enterdawn 2021.07.14 看看系统时区对不对，也许系统时间是格林尼治时间。 文派叶子 🍃 2021.07.14 装这个插件：https://litepress.cn/plugins/wp-crontrol 看看设置的定时任务执行时间是多少。 文派叶子 🍃 2021.07.14 至于逆向 wordpress.org 的预处理过程的话，是基本不现实的。 举个例子，比如 wordpress.org 会把-转换为–，而有的插件本身就是用的–。于是我无法得知这个–到底是 wordpress.org 转换的还是插件原本的，于是我无法对其逆向处理。 文派叶子 🍃 2021.07.14 目前 litepress.cn 上该功能的实现遇到了一个很难解决的问题。那就是通过爬虫爬取到的产品详情的文本是经过 wordpress.org 预处理过的，已经和 glotpress 里面的原文对应不上了…… 一个可能是解决方案是根据插件的 readme.txt 文件仿照 wordpress.org 的算法以生成原始 html 。 文派叶子 🍃 2021.07.14 有的云存储插件会替换附件在数据库中的链接。 参考这个帖子介绍的方法运行 SQL 替换之：https://litepress.cn/topic/20635 。 不凡 2021.07.14 然而两个小时过去了。。。 myelse 2021.07.13 没有没有，就是想研究一下，跟博客没有完全的关系。实际使用上来讲，redis 毕竟有商业化软件支持，更方便。没有问题了。 文派叶子 🍃 2021.07.13 这个没测试过。不过一个博客不需要在意这些吧……这俩的 key value 结构都是 O(1) 查询复杂度，已经快到几乎没时间损耗了，对这个难以理解可以去了解一下散列表这个数据结构。 他们测试的速度快慢可能是在大负载量下由两个软件的架构差异导致的 （这一部分是猜测） 。还有一种可能是做这个测试的人没控制好变量，使用了两种不同的插件来测试 memcached 和 redis，这样插件所缓存的数据范围不同，在浏览体验上就会存在差异。 myelse 2021.07.13 然而 memcached 的插件太难找了，redis 直接就 redis object cache 。 文派叶子 🍃 2021.07.13 支持多少数据类型不是判断是否落后的依据，这个是由业务场景决定的。对于 WordPress 的缓存场景，memcached 足够用了。 redis 除了用于缓存外还可以用于消息队列等复杂应用场景。 myelse 2021.07.13 我看有的地方说 memcached 的浏览体验比 redis 要快一些。 myelse 2021.07.13 哈哈，也是。 myelse 2021.07.13 好的，懂了。那就是 redis 随便用了。 memcached 是不是相比于 redis 落后了？redis 支持缓存的数据类型比 memcached 多一些？ ←较旧评论 1 … 18 19 20 21 22 … 63 较新评论→
《“ 参与者列表” 》 有 2,005 条评论
腾讯云北京
你用的哪家服务器？
服务器直接 Ping 是没问题的 Php 也能抓到 ip
安装也不行
有个错误提示是未能连接 wp 服务器，你安装这个插件试试
https://a1.wp-china-yes.net/apps/wp-china-yes.zip
刚安装 没有任何插件
是不是用了什么插件把 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 任务：
检索了下资料，WordPress 的 Cron 始终以 UTC 时间触发。通过 WP Crontrol 查看的时间有可能被转换过，所以直接在数据库里看，然后再进一步诊断问题。
停用插件没用，比如现在是 22:56 8 个小时后定时的文章 （06:56） 的文章发布了 等于定时发布提前了 8 小时
你不是说提前 8 小时触发吗？所以不是应该看看暂时停用后还会不会提前触发的嘛。何谓 「没反应」
停止了 还是没反应
WPJAM_Baidu_ZZ 这个插件暂时停一下呢？
这个时间我看了是对的 但是发布后时间就错了
所以，这个时间对不对？
上海时间
看看系统时区对不对，也许系统时间是格林尼治时间。
装这个插件：https://litepress.cn/plugins/wp-crontrol
看看设置的定时任务执行时间是多少。
至于逆向 wordpress.org 的预处理过程的话，是基本不现实的。
举个例子，比如 wordpress.org 会把
-转换为–，而有的插件本身就是用的–。于是我无法得知这个–到底是 wordpress.org 转换的还是插件原本的，于是我无法对其逆向处理。目前 litepress.cn 上该功能的实现遇到了一个很难解决的问题。那就是通过爬虫爬取到的产品详情的文本是经过 wordpress.org 预处理过的，已经和 glotpress 里面的原文对应不上了……
一个可能是解决方案是根据插件的 readme.txt 文件仿照 wordpress.org 的算法以生成原始 html 。
有的云存储插件会替换附件在数据库中的链接。
参考这个帖子介绍的方法运行 SQL 替换之：https://litepress.cn/topic/20635 。
然而两个小时过去了。。。
没有没有，就是想研究一下，跟博客没有完全的关系。实际使用上来讲，redis 毕竟有商业化软件支持，更方便。没有问题了。
这个没测试过。不过一个博客不需要在意这些吧……这俩的 key value 结构都是 O(1) 查询复杂度，已经快到几乎没时间损耗了，对这个难以理解可以去了解一下散列表这个数据结构。
他们测试的速度快慢可能是在大负载量下由两个软件的架构差异导致的 （这一部分是猜测） 。还有一种可能是做这个测试的人没控制好变量，使用了两种不同的插件来测试 memcached 和 redis，这样插件所缓存的数据范围不同，在浏览体验上就会存在差异。
然而 memcached 的插件太难找了，redis 直接就 redis object cache 。
支持多少数据类型不是判断是否落后的依据，这个是由业务场景决定的。对于 WordPress 的缓存场景，memcached 足够用了。 redis 除了用于缓存外还可以用于消息队列等复杂应用场景。
我看有的地方说 memcached 的浏览体验比 redis 要快一些。
哈哈，也是。
好的，懂了。那就是 redis 随便用了。
memcached 是不是相比于 redis 落后了？redis 支持缓存的数据类型比 memcached 多一些？