這裏是 LitePress 社區舊貼存檔，您可以在此留言或提交新的回應和信息。
LitePress 社區舊貼存檔 2020~2023 年度
文章投稿 131 篇
參與 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
-
安裝也不行
-
有個錯誤提示是未能連接wp服務器，你安裝這個插件試試
-
剛安裝 沒有任何插件
-
是不是用了什麼插件把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這個插件暫時停一下呢？
-
這個時間我看了是對的 但是發佈後時間就錯了
-
所以，這個時間對不對？
-
上海時間
-
看看系統時區對不對，也許系統時間是格林尼治時間。
-
裝這個插件：https://litepress.cn/plugins/wp-crontrol
看看設置的定時任務執行時間是多少。
-
剛蹲坑的時候突然茅塞頓開，還拿
-舉例子：我可以在翻譯匹配時將網頁文本和glotpress原文中的所有–都先轉換為-，這樣無論是經過wordpress.org轉移為了–還是它原本就是–都已經無所謂了，最後再執行正則匹配翻譯就可以了。
-
至於逆向wordpress.org的預處理過程的話，是基本不現實的。
舉個例子，比如wordpress.org會把
-轉換為–，而有的插件本身就是用的–。於是我無法得知這個–到底是wordpress.org轉換的還是插件原本的，於是我無法對其逆向處理。
發表回覆