参与者列表

感谢 2020 ~ 2023.4 所有关注过 LitePress 的用户

此版已存档,详情参见 《推广名单》

《“ 参与者列表” 》 有 2,005 条评论

  1. doingxx 的头像

    腾讯云北京

  2. 不凡 的头像

    你用的哪家服务器?

  3. doingxx 的头像

    服务器直接 Ping 是没问题的  Php 也能抓到 ip

  4. doingxx 的头像

    安装也不行

  5. 不凡 的头像

    有个错误提示是未能连接 wp 服务器,你安装这个插件试试

    https://a1.wp-china-yes.net/apps/wp-china-yes.zip

  6. doingxx 的头像

    刚安装 没有任何插件

  7. 不凡 的头像

    是不是用了什么插件把 REST API 禁用了?

  8. 文派叶子 🍃 的头像

    添加以下代码尝试在发布文章时重新指定触发时间戳:

    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 小时。

  9. cgq630105023 的头像

    看了数据库   数据库里和后台定时的时间是一致的

  10. 文派叶子 🍃 的头像

    在 wp_options 目录下执行以下 sql,直接在数据库里查看 Cron 任务:

    select * from wp_options where option_name like '%cron%';

    检索了下资料,WordPress 的 Cron 始终以 UTC 时间触发。通过 WP Crontrol 查看的时间有可能被转换过,所以直接在数据库里看,然后再进一步诊断问题。

  11. cgq630105023 的头像

    停用插件没用,比如现在是 22:56  8 个小时后定时的文章 (06:56) 的文章发布了  等于定时发布提前了 8 小时

  12. 文派叶子 🍃 的头像

    你不是说提前 8 小时触发吗?所以不是应该看看暂时停用后还会不会提前触发的嘛。何谓 「没反应」

  13. cgq630105023 的头像

    停止了  还是没反应

  14. 文派叶子 🍃 的头像

    WPJAM_Baidu_ZZ 这个插件暂时停一下呢?

  15. cgq630105023 的头像

    这个时间我看了是对的   但是发布后时间就错了

  16. 文派叶子 🍃 的头像

    所以,这个时间对不对?

  17. cgq630105023 的头像

    上海时间

  18. enterdawn 的头像

    看看系统时区对不对,也许系统时间是格林尼治时间。

  19. 文派叶子 🍃 的头像

    装这个插件:https://litepress.cn/plugins/wp-crontrol

    看看设置的定时任务执行时间是多少。

  20. 文派叶子 🍃 的头像

    至于逆向 wordpress.org 的预处理过程的话,是基本不现实的。

    举个例子,比如 wordpress.org 会把-转换为,而有的插件本身就是用的。于是我无法得知这个到底是 wordpress.org 转换的还是插件原本的,于是我无法对其逆向处理。

  21. 文派叶子 🍃 的头像

    目前 litepress.cn 上该功能的实现遇到了一个很难解决的问题。那就是通过爬虫爬取到的产品详情的文本是经过 wordpress.org 预处理过的,已经和 glotpress 里面的原文对应不上了……

    一个可能是解决方案是根据插件的 readme.txt 文件仿照 wordpress.org 的算法以生成原始 html 。

  22. 文派叶子 🍃 的头像

    有的云存储插件会替换附件在数据库中的链接。

    参考这个帖子介绍的方法运行 SQL 替换之:https://litepress.cn/topic/20635

  23. 不凡 的头像

    然而两个小时过去了。。。

  24. myelse 的头像

    没有没有,就是想研究一下,跟博客没有完全的关系。实际使用上来讲,redis 毕竟有商业化软件支持,更方便。没有问题了。

  25. 文派叶子 🍃 的头像

    这个没测试过。不过一个博客不需要在意这些吧……这俩的 key value 结构都是 O(1) 查询复杂度,已经快到几乎没时间损耗了,对这个难以理解可以去了解一下散列表这个数据结构。

    他们测试的速度快慢可能是在大负载量下由两个软件的架构差异导致的 (这一部分是猜测) 。还有一种可能是做这个测试的人没控制好变量,使用了两种不同的插件来测试 memcached 和 redis,这样插件所缓存的数据范围不同,在浏览体验上就会存在差异。

  26. myelse 的头像

    然而 memcached 的插件太难找了,redis 直接就 redis object cache 。

  27. 文派叶子 🍃 的头像

    支持多少数据类型不是判断是否落后的依据,这个是由业务场景决定的。对于 WordPress 的缓存场景,memcached 足够用了。 redis 除了用于缓存外还可以用于消息队列等复杂应用场景。

  28. myelse 的头像

    我看有的地方说 memcached 的浏览体验比 redis 要快一些。

  29. myelse 的头像

    哈哈,也是。

  30. myelse 的头像

    好的,懂了。那就是 redis 随便用了。

    memcached 是不是相比于 redis 落后了?redis 支持缓存的数据类型比 memcached 多一些?