這裡是 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轉換的還是外掛原本的，於是我無法對其逆向處理。
發表回覆