先森最近在梳理網站的代碼，想辦法為網站加速，主要從代碼、軟件、網絡層面進行優化，這一切都是從網站切換到HTTPS開始的。先森已經連續觀察了多日的CDN了，目前也就到了查缺補漏的階段了。先森還將整個網站目前備份到了另一臺服務器，將網站在本地解析到這臺服務器上，開始了對代碼的檢查。開啟了debug，把大的一些問題都處理了，然后也把主題的代碼理了一遍，并且網站也加上了Redis緩存。但是先森發現，即使加上了Redis，有時候網頁打開生成時間還是得一秒多，先森就很納悶，一直想搞明白到底是什么情況。排查工具很早以前，先森就在主題的footer.php末尾，添加了下面的代碼，以便于登錄之后可以看到當前網頁的查詢次數，生成時間：<?php if (is_user_logged_in()){    echo "<pre>".get_num_queries().'次查詢，用時';    timer_stop(3);    echo '秒</pre>';?>這個代碼網絡上到處都是，相信很多人都添加的有。先森網站加Redis之前，網頁的查詢次數都是150+次，生成時間2-3秒，甚至更多。用上之后減少到50+次，但是有時還是會需要1秒多，讓先森百思不得其解。然后先森把主題代碼該優化的都優化后，查詢次數30+次，生成時間降到1秒左右，但是先森還是不太滿足，所以想看看到底是執行了哪些查詢，然后就在網上找到了這段代碼，和上面的有些類似。首先需要先在WordPress的根目錄配置文件wp-config.php中添加保存查詢的代碼：define('SAVEQUERIES', true);然后也是在footer.php的網頁最后部分添加打印代碼：<?phpif (current_user_can('administrator')){    global $wpdb;    echo "<pre>";    print_r($wpdb->queries);    echo "</pre>";}?>但是先森添加后看了一下，差點當場去世，這樣打印出來的是一個很大的多維數組，看的人眼花繚亂，重點是太長了還顯示不全。先森將打印復制出來，拿到NotePad++里面打開，依舊顯得很亂。查詢的打印不過大概看了一下，大數組的每一個鍵值表示一個查詢，然后一個查詢數組了，第一個值是執行的SQL，第二個值是使用的時間，第三個值是調用的代碼位置。其實可以用循環做一個網格，讓前端顯示看著方便一點，但是先森很懶，網上看了一下，有插件可以做到相關功能，且不用修改wp-config.php，即Debug Queries，所以先森就懶得自己寫了，直接裝了一個來進行排查。需要注意的是，Debug Queries很久沒有更新了，安裝可能會報錯，不過還是可以正常使用的。其實Debug Queries介紹頁也推薦使用Debug Objects插件，但是先森試了一下Debug Queries可以用，也就懶得再試另一個插件了。排查問題工具準備好了，先森就來好好排查到底是哪里查詢比較慢了。插件裝好了，再去看打印出來的查詢信息，就比較清晰了。先森對比了一下，大部分的查詢都是0.00x秒的，就是幾毫秒的，但是只要涉及到wp_al_urls的查詢，就會是即時甚至上百毫秒。wp_al_urls的查詢先森看了一下，這個表是插件anylink的，這個插件主要是將網站上的外鏈全都轉化成內鏈，點擊后可以跳轉到外鏈。對于anylink，先森這里也發過兩篇相關的文章：WordPress為anylink插件外鏈跳轉添加漂亮的跳轉頁面WordPress：WPJAM BASIC插件與anylink沖突這個插件先森也是從建站伊始就在用了，是一個很好用的插件，但沒有想到這個插件會出現慢查詢。通過上面的截圖可以看到，對wp_al_urls的查詢條件是網站鏈接，看了一下數據庫，這個SQL是為了去拿到內鏈的slug記錄：anylink獲取slug這里去查的，實際上是網頁正文里的外鏈、各位評論大佬的網址對應的內鏈地址。先森看了一下這個表，沒想到竟然有10M的大小，接近10萬條數據，而且這里查詢的是al_origURL字段，先森看了一下，這個字段是沒有索引的。解決問題對于MySQL的查詢，先森能想到的優化方法就是加索引，所以先森直接就操作加索引，但是報錯了：給al_origURL字段加索引報錯看報錯是跟字段格式有關的，看了一下這個字段的類型是mediumtext的，這個字段是存URL的，有些URL非常的長，如果該varchar的話，可能會出問題，varchar最長255個字符。網上找了一陣子解決方案，都是說text相關的類型無法加索引。先森本來就對數據庫索引什么的不太了解，所以只能放棄這條路。先森還能想到的辦法，就是看下這個查詢的代碼，想辦法把結果存到Redis上緩存起來。至于怎么找到實際執行的代碼，先森看了一下，直接找調用的最后一段就可以了。找到慢查詢的調用代碼可以看到，兩個SQL實際上是一樣的，查的是同個網址，結果執行的時間竟然都比較長，所以確實得把結果緩存起來。為了優化代碼，先森把整個網站都作為了一個PhpStorm里的一個項目，不得不說一個好的IDE工具寫起代碼來是真的舒服。直接全局搜索，尋找get_slug_by_url這個函數，順利找到了代碼所在。搜索get_slug_by_url函數這里有兩個結果，第一個是原本的函數，已經被先森注釋起來了，第二個是先森改了之后的。可以看到這個函數就是調用$wpdb來執行SQL語句，將得到的結果再返回一下。函數比較簡單，也很利于先森修改。然后先森又找了一下WordPress如何添加緩存，結果找到一下，發現非常簡單。WordPress操作緩存WordPress 為我們提供了使用對象緩存的函數，方便我們使用對象緩存。wp_cache_add() ：添加數據到緩存中，如果數據已存在，返回 flasewp_cache_set() ：添加數據到緩存中，如果數據已存在，會覆蓋數據wp_cache_get() ：獲取緩存中的數據，如果數據不存在，返回 falsewp_cache_delete() ： 從緩存中刪除數據wp_cache_replace() ：替換緩存中的數據，類似 wp_cache_set，但是如果數據不存在，不自動添加wp_cache_flush()：清除所有緩存如果沒有裝redis緩存插件，上面的這些函數是在./wp-includes/cache.php里。如果裝了Redis Object Cache等插件，就會自動增加一個./wp-content/object-cache.php文件，這些函數也會存在于這個文件中，用于存入緩存。WordPress 對象緩存使用使用示例$result = wp_cache_get( 'my_result' );if ( false === $result ) {    $result = $wpdb->get_results( $query );    wp_cache_set( 'my_result', $result );}對anylink的get_slug_by_url函數改造有了上面這個案例，先森為anylink的函數增加緩存就很方便了。示例很簡單，get_slug_by_url函數本身也簡單，所以改造后如下：public function get_slug_by_url( $url ) { $arr_slug = wp_cache_get( $url ); if ( false === $arr_slug ) { global $wpdb; $arr_slug = array(); $arr_slug = $wpdb->get_row($wpdb->prepare( "SELECT * FROM " . ANYLNK_DBTB . "  WHERE al_origURL = %s", $url ), ARRAY_A); wp_cache_set( $url, $arr_slug ); } return $arr_slug;}因為示例和函數太契合了，所以這個函數幾乎就和示例結構一樣。首先去Redis獲取緩存數據，獲取不到就去MySQL查詢，查到后再存到Redis。2022年4月4日更新：此代碼存在億點點bug，修復參考此文章：修復anylink增加Redis緩存后存在的bug檢查效果代碼修改后，同步到測試服務器，訪問了兩次之前訪問的頁面，查詢次數和用時都降下來了。然后看到查詢次數還是有33次，其中有部分是查詢wp_al_urls_index這個表的，雖然速度不慢，但是次數比較多，先森重復上面的方法也修改了一下相關函數，最終效果如下圖：最終效果查看Redis的keys上面改造的代碼中，是拿url地址去做的key名稱，那么先森也來看下緩存數據在Redis里的情況：redis的緩存上面改造的代碼比較簡陋，直接拿的URL做的key名稱，如果URL比較短還好，如果長的話就可能出現問題，key名稱其實可以做一下長度限制。提示：Redis最好不要使用默認端口6379，除非安全做的非常好。使用Redis時注意以下幾點：1、一定要配置強密碼；2、安全組、防火墻一定要最小范圍放通Redis端口，即針對指定IP放通訪問；3、盡量不要使用默認端口。因為Redis而導致服務器中木馬病毒的保障，先森這邊經常遇到。總結先森以前以為給WordPress配上Redis很麻煩，實際使用發現真香，建議有能力的朋友都上一下，畢竟生命不止，折騰不息。本文最主要的還是記錄一下排查網頁查詢慢的過程和解決方法，希望能夠給其他朋友提供思路。

先森之前先發了一篇博文，講述了一些想從http轉為https做的一些準備：網站http轉為https之始，從七牛到騰訊云前進的道路從來都不是一帆風順的，先森在切換的過程中也是遇到了一些問題，這里簡單的記錄一下歷程。七牛轉騰訊云七牛令先森最喜愛的功能就是圖片的處理功能了，現在是騰訊云的對象存儲COS也支持直接圖片處理，所以先森才開始打算從http轉為https。針對七牛的圖片處理，先森以前還是寫過幾篇博文的：WordPress百度UEditor編輯器自動添加七牛云儲存裁剪代碼將WordPress歷史文章中所有圖片加上七牛裁剪水印代碼七牛圖片處理樣式的正確使用方式當然，當時的用法比較簡單粗暴，直接用了一大段的圖片處理參數，而正確的方法應該是將固定的處理方法保存為處理樣式，直接在圖片后面調用圖片處理樣式，這個先森也在上面的最后一篇博客中寫到了。先森使用圖片處理，最主要的用途還是加速網站打開速度。將不同位置的圖片縮小至合適的大小，讓圖片的體積盡可能的減小，以實現加快網站訪問速度。先森最喜歡的一點，還是文章中的圖片，結合燈箱插件，讓圖片在未點擊時呈現縮放并降低圖片質量的狀態，點擊后顯示原始大小及質量。這么好的功能先森當然不想放棄，先森網站的各種縮略圖都是不同的大小，所以有不同的樣式。本以為從七牛的圖片處理換到騰訊云的圖片處理，相關規則還得自己研究半天才能實現同樣的效果，結果圖片處理的規則竟然非常兼容。COS圖片處理規則除了需要添加水印的規則，其他的規則直接將七牛的復制過來就可以直接用了，簡直方便的一批。COS新增樣式時，添加水印圖片竟然只能上傳圖片，而不能從存儲桶里直接選擇，這一點有些體驗不佳。而自己通過自定義規則去添加水印圖片的話，又會比較麻煩：使用自定義參數添加水印圖片需要滿足3個條件不過研究一下還是可以完成操作，總的來說，這個切換過程還是非常滿意的。自適應http和https先森前面的文章也寫到過，為了避免切換到https有問題，先森切換的時候是沒有開啟強制跳轉到https的，所以這里就需要做到http和https的兼容。先森想到的兼容方式就是將網頁中的‘http://’換成‘//’，這樣就會根據訪問的協議自動顯示相應的協議。要實現也很簡單，先森下面這篇博客中講到了“WordPress七牛CDN代碼版”：七牛圖片處理樣式的正確使用方式先森這里把這個代碼改吧改吧就能實現https的兼容了。//WordPress七牛CDN代碼版function QiNiuCDN(){    function Rewrite_URI($html){        /* 前面是需要用到七牛的域名,后面是需要加速的靜態文件類型，使用分隔符 | 隔開即可 */        /* 這里先森小改了一下，兼容https */        $pattern ='/http[s]{0,1}:\/\/(www\.|)capjsj\.cn\/(wp-|ueditor|avatar)([^"\']*?)\.(jpg|js|css|gif|png|jpeg|ico|cur)/i';        /* 七牛CDN空間地址,請自行替換成實際空間地址*/        /* 先森這里又換成騰訊云COS的地址了 */        $replacement = '//cos.capjsj.cn/$2$3.$4';    $html = preg_replace($pattern, $replacement,$html);    /* 增加了一次替換，把http://替換為// */    $html = preg_replace('/http:\/\/www.cnidcc.cn/i', '//www.cnidcc.cn',$html);    return $html;    }    if(!is_admin()){        ob_start("Rewrite_URI");    }}add_action('init', 'QiNiuCDN');這個時候需要注意，WordPress后臺登錄的時候，需要使用http，因為在設置-常規處的WordPress地址與站點地址還未修改，為了http與https的兼容，所以當時也并未修改。但若要修改，這里還有個坑。全站HTTPS先森經過一段時間的測試，發現https沒有什么問題，所以就打算將網站開啟HTTP到HTTPS的強制跳轉，并且把后臺配置中的站點地址也改成HTTPS，但是先森修改后，竟然遇到了后臺地址無限跳轉。HTTPS無限302跳轉經過一番搜索，發現是需要在WordPress網站根目錄中的wp-config.php中添加配置進行解決：/* 解決https無限跳轉*/$_SERVER['HTTPS'] = 'on';define('FORCE_SSL_LOGIN', true);define('FORCE_SSL_ADMIN', true);添加在文件開頭處即可，藥到病除。CDN緩存命中率低先森閑來無事，跑去17ce測試了一下網站的GET速度，結果大出先森預料，竟然全國通紅（忘了截圖）。先森覺得很奇怪，先森這網站這么久了沒更新了，按理說應該訪問到的都是緩存才對啊，然后先森進行了排查。先森就從首頁排查起，先森在非放置本站的服務器上curl首頁，結果發現經常是 X-Cache-Lookup: Cache Miss，但是連著刷兩次就會變成Cache Hit，但是再過幾秒curl又變成Cache Miss了，這就有點奇怪了。仔細看了一下響應頭，結果先森發現 Cache-Control: must-revalidate, max-age=3，這就表示緩存3秒啊，怪不得連著刷能命中緩存，接下來就要看這個響應頭是怎么配置的了。不過講道理，騰訊云的CDN判定是否命中緩存的規則是看X-Cache-Lookup是否為Hit From MemCache或Hit From Disktank，直接顯示Cache Hit和Cache Miss是很奇怪的。X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節點的內存。X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節點的磁盤。不過先森也去查了一下，Cache Hit也是正常命中緩存了，也不需要過多的去糾結。這個僅緩存3秒的響應頭，先森自己記得是沒有配置的，可能比較容易出問題的可能是WordPress中使用的緩存插件。先森使用的緩存插件是WP Super Cache，所以首先就是懷疑這貨。百度大法好，果然是這貨影響的。默認情況下，WP Super Cache 返回的 Cache Control Header 固定為： cache-control: max-age=3, must-revalidate ，不管你在插件設置中設置的緩存超時時間是多久。修改起來也簡單，只要在WordPress根目錄的wp-config.php增加配置即可：define('WPSC_CACHE_CONTROL_HEADER','max-age=3600, must-revalidate');參考：WP SUPER CACHE 緩存插件但是，如果CDN的緩存也是繼承源站的響應頭，那先森在騰訊云CDN的緩存配置豈不是沒有用了？所以還是得研究一下什么情況下，CDN會繼承源站的配置。騰訊云官方文檔對高級緩存配置的說明經過一番查閱騰訊云官方文檔，發現是開啟高級緩存配置時，CDN會對比源站響應頭中的max-age值。先森看了一下自己CDN的配置，果然是開啟了高級緩存配置的，趕緊關閉：關閉高級緩存配置這個配置估計是為了迎合一些對自定義配置要求較高的用戶，先森這種小站就沒必要開啟了。CDN對no-cache或者no-store不緩存需要注意的一點是，默認情況下，CDN也不會對no-cache或者no-store的資源進行緩存，所以如果有遇到始終無法緩存的情況，可以檢查一下cache-control是否配置了禁止緩存。先森最終是即修改了WP Super Cache的配置，將max-age改為了3600，即1個小時；CDN側是關閉了高級緩存配置。至于為什么關閉了高級緩存配置的情況下，還要修改插件的緩存配置，那是因為max-age還會影響到客戶端瀏覽器的緩存配置，3秒太短了，所以還是修改一下比較好。修改之后，過了一段時間，先森再進入17ce進行GET測試，測試的結果就能讓先森接受了：17ce測速總結先森在網站開啟HTTPS中，可能還有一些比較小的坑，先森隨手就解決了，這里就沒有記錄了。網站加了CDN后，訪客具體的訪問速度先森實際上也不得而知，因為先森自己打開網站覺得還是很快的，結果用17ce一測，全紅，這個17ce的數據也不知道與實際情況是否匹配。如果有訪問比較慢的，還希望能夠留言告訴先森，您的地域與具體訪問的URL。

最近先森還是重拾了一點大學期間的激情，對網站又上心了一點。周圍的網站看著都將http換成了https，先森也想著動一動了。目前是已經完全換為https有一段時間了，先森也記錄一下切換過程中折騰的一些情況。首先，七牛七牛，先森最早開始使用的CDN與對象存儲。當然，當時并不清楚這些概念，不過依然非常感謝七牛這些年來的陪伴。先森最早一篇關于七牛的文章是2015年9月初寫的，先森的域名是同年6月份購買的。最早的記錄：WordPress使用七牛CDN導致ajax評論報錯{“error”:”get from image source failed: E405″}當初先森還不愿意使用七牛，因為插件沒什么作用，但后面正確使用后的感覺是真香，這一香，就香了五年。七牛對象存儲的免費額度七牛免費10G的存儲空間，以及10G的下載流量，還有圖片處理的免費額度，讓當時囊中羞澀（現在也是）的先森萬分欣喜。當時先森使用的還是萬網的免費虛擬主機，一個月只有10G的流量，剛開始沒有使用七牛的時候，各種折騰，然后各種跑滿。使用七牛，讓圖片、js文件等靜態文件都走七牛CDN后，問題得到有效解決。不過要使用https了，還是得跟七牛暫時告一段落了。七牛CDN的免費額度七牛的對象存儲必須搭配CDN進行使用，否則無法外網訪問。而七牛的CDN只有http請求有免費額度，https是必須收費的。雖然非常感謝七牛的陪伴，但是有白嫖的機會又何必花錢呢？然后，騰訊云先森一直不愿意換HTTPS的原因就是因為七牛，尤其是七牛的圖片處理，可以在請求圖片時對圖片進行各種壓縮、裁剪、加水印等操作，對網站加速訪問很有益處。但先森畢竟是一名騰訊云公有云售后運維，對自家產品了解還是很深的。在七牛使用了兩個產品，一個是對象存儲，一個是CDN。而要換到騰訊云，就得觀察好對應的產品。以前知道騰訊云也有圖片處理的相關產品，叫做萬象優圖，現在改名叫做數據萬象，不僅僅做圖片處理了。但是一直沒有去深入了解，也覺得既要使用騰訊云對象存儲，還要使用萬象優圖，很麻煩，不像七牛那么方便：對象存儲的圖片，加上參數就能做圖片處理。但是今年3月，騰訊云對象存儲做出了改變，當時發了郵件：對象存儲發布圖片處理功能當時先森對網站是放任不管的，對此也沒有在意。不過最近騰訊云又發了一次短信通知，先森又去研究了一下。對象存儲COS先森目前對網站本來就不是很重視，要切換使用一定是在有免費額度的基礎上。這里就需要注意的是，騰訊云的對象存儲COS在去年9月份是對免費額度進行了調整的，在2019年1月22日之前開通使用對象存儲的老用戶繼續每月享有之前的免費額度，之后開通的，就只有6個月的免費額度了。但是老用戶還得注意，看自己有沒有收到過以下郵件：COS免費額度變更標明了【不受此次變更影響】的用戶才能繼續享受每月免費額度，如果有什么疑問，可以在騰訊云官網聯系在線客服或提交工單。騰訊云COS的免費額度還是比較給力，存儲50G，流量10G，請求次數100萬次。先森在使用時，一般都是配合CDN進行使用，所以這里要關注的是CDN回源流量。先森這邊剛好有個賬號還享有免費額度，所以具備七牛遷移騰訊云的基本條件。然后繼續往下看。騰訊云的對象存儲簡稱COS，后面都直接用COS了。數據萬象CICOS的圖片處理功能，使用的是數據萬象的功能，所以還得看數據萬象有沒有免費額度。在數據萬象的文檔中可以看到，很多操作都是有免費額度的：數據萬象免費額度這里先森重點關注的是基礎圖片處理和CDN回源流量，這兩項是先森用的上的。基礎圖片處理10TB/月，七牛是20TB/月，對于先森來說完全夠了，先森11月5號開始使用，截止目前才用不到2GB，說來也是慚愧。CDN回源流量10GB/月，對先森來說也是完全夠用了。由于是結合COS來使用的，圖片不添加處理參數時，是不會回源到數據萬象的，所以這個流量先森目前用的特別少，才200MB+。需要注意的是外網出流量，只要你不直接使用數據萬象CI默認域名進行訪問，僅使用CDN->COS->CI的方式訪問的話，是不會產生的。數據萬象默認域名格式為存儲桶名-賬號Appid.piccd.myqcloud.com，盡量還是使用自己的域名通過CDN訪問吧。內容分發網絡CDN對象存儲和數據萬象都有免費額度了，那么再來看看CDN。CDN不像對象存儲和數據萬象，這樣費用那樣費用，簡單直接，就一個流量費用。不過CDN的免費額度按照官方文檔來說，個人用戶于官網開通 CDN 當天可獲贈共120GB免費境內流量包。分6個月生效，每月生效20GB。其他就沒有更多說明了，不過目前看來，只要接入了CDN，每個月還是會有10GB的贈送流量包，對先森來說夠用了，使用前可以在控制臺看下自己是否有贈送流量包：CDN免費流量包另外一點，SSL證書要從http切換為https，證書是肯定少不了的。想要安全，肯定不可能使用自頒發的證書，不過免費的證書也還是挺多的。先森使用的SSL證書是在騰訊云上直接免費申請的。騰訊云申請的免費證書是由亞洲誠信提供的，實際上也是DigiCert的免費DV證書。想比于Let's Encrypt證書的3個月一換，先森還是喜歡一年一換的。雖然Let's Encrypt證書可以跑腳本進行替換，但是從寶塔上的一些體驗來看，這個自動替換還是有點坑的。先森不想過多的去修改源站web服務器上的配置，所以SSL證書是直接部署到CDN上的，使用http的方式進行回源。剛開始切換https的時候，先森擔心https會出現問題，所以沒有開啟http到https的強制跳轉，將證書部署在CDN上面，切換起來比較方便。當然，在切換的過程中，還是不免的遇到一些坑，為了避免篇幅過長，先森這邊后面再說。后面的記錄：網站從http轉為https折騰記錄

先森的網站還是放在阿里云免費云虛擬主機，每個月被關停之后，只能啟動三次。先森上一次被關停是7月份的事情，沒想到昨天凌晨，噩夢又來襲。早上先森上班之后，抽空看了一下網站的日志。因為阿里云的提示短信是凌晨三點四十多發的短信，所以先森重點關注這個時間段的，然后就發現了罪魁禍首，這篇文章的主角——百度云觀測。坑爹的百度云觀測在日志中，我發現了大量的請求，全是User-Agent:Baidu-YunGuanCe-ScanBot(ce.baidu.com），而且訪問的還都是/wp-comments-post.php和/wp-admin/admin-ajax.php這些會接收數據，查詢、修改數據庫的php文件，這樣一來對網站的壓力就非常的大了。來自百度云觀測的大量請求這種情況，先森趕緊去百度云觀測把網站監控關閉，百度云觀測的騷操作太恐怖了。關閉百度云觀測后續先森在百度云觀測找到這樣的一段話，先森感覺心中一萬只。。。。網站初始化包含多個分析過程，一般需要5~10分鐘。 網站初始化時，我們會對你的網站進行全方位安全體檢。初始化這段時間內，可能會向你的網站發送一定攻擊探測請求，以發現安全漏洞。 一般情況下，正常網站不會因為安全體檢受到任何影響。后來，昨天下午先森的網站又被關停了一次，這一次，不是百度云觀測的鍋了，先森已經關了。這次，是有人在拿先森網站練手，搞DDOS，先森看日志，發現大量的125.39.239.*網段的請求。因為網站放在百度云CDN，免費版又不能設置黑白名單，所以先森只把防守放在了.htaccess文件里面，但是先森發現，放在里面并無卵用，有了CDN，該訪問還是能訪問。所以先森還是把網站CDN都解析到騰訊云CDN。騰訊云CDN對移動寬帶的支持貌似不太友好，但是好在是能夠配置黑白名單，有這點就夠了。

上篇文章解決了WordPress加入CDN后“非插件瀏覽次數統計”瀏覽次數不刷新問題，同時留下了兩個未解決的問題：1.按F5可無限制刷新文章訪問量，并影響數據庫效率；2.只解決了后臺不更新問題，前臺顯示還是得等CDN刷新后才能更新。那么這篇文章就是為了解決以上兩個問題。問題分析第一個問題，先森想到的解決方法是用JS代碼創建cookies，如果cookies存在就不在更新后臺的統計量。第二個問題，直接讓ajax獲取后臺的訪問量，修改前臺顯示的訪問量就行了。一開始，先森配置的讓ajax多傳一個參數，是判斷cookies是否存在的，存在為1，不存在為0。若cookies不存在，則后臺訪問量統計就+1，并返回數據庫中的瀏覽量并+1。若cookies存在，則后臺不增加訪問數量，直接返回數據庫中的瀏覽量并+1，如此訪客刷新也不會增加訪問量了。但是這樣還是存在會在后臺查詢數據的問題，查詢多了對數據庫也是一種負擔。先森之前沒有意識到這個問題，結果還是晚上睡覺前反思發現了，且也琢磨除了一個更好的解決方法。直接在JavaScript代碼中加判斷，如果cookies已存在，則直接不向后端服務器發數據。這樣一來，前端再怎么刷新，也停留在CDN的層面上。那么要實現這種效果，就需要先實現不向后端服務器發送數據，也能獲取到當前文章的訪問量。解決方法很簡單，第一次獲取訪問量時，將后端服務器返回的訪問量直接寫入cookies，下次刷新時，直接從cookies中讀取訪問量。另外，還有一個地方需要解釋一下，cookies的過期時間。如果cookies時間太長了的話，那么未免還是會損失一些訪問量，所以先森就沒有設置cookies的過期時間，保持默認。cookies的默認過期為關閉瀏覽器，先森覺得，這樣一來還是比較合理的。同時，一個訪客，可能并不會只打開本站一篇文章就關閉，打開多篇文章時，每篇文章的訪問量是不一樣的，需要從cookies中獲取的話，cookies的名稱就必須不一樣。不然訪問打開其他文章，看到了訪問量都是同一個數值。解決方法就是，已“固定值+文章ID”的方式，確定cookies名稱的唯一。效果實現上一篇文章中，先森是模仿通用的評論ajax提交的處理方式，自建了一個類似的php。但這樣可能有點不安全，也有點麻煩，所以先森還是研究著將php代碼部分放進了主題的functions.php。首先還是在footer.php中添加ajax的代碼，注意需要將前臺顯示訪問量的標簽ID或class名稱改成自己的。<script type= "text/javascript" > function GetCookie(sName) {    var arr = document.cookie.match(new RegExp("(^| )"+sName+"=([^;]*)(;|$)"));    if(arr !=null){return unescape(arr[2])};    return null;}var postviews_cook=GetCookie("postviews<?php the_ID();?>");  if ( postviews_cook == null ){$.ajax({ type:'POST', url: "<?php echo admin_url('admin-ajax.php');?>" , data:"postviews_id=<?php the_ID();?>&action=postviews",cache:false,success: function(postviews_count){ $("#views").text('閱讀：' + postviews_count + ' 次');document.cookie="postviews<?php the_ID();?>=" + postviews_count;} });   }  else{$("#views").text('閱讀：' + postviews_cook + ' 次');}; </script><?php endif ; ?>然后直接在自己主題的functions.php中添加下面的代碼：/** 緩存時更新瀏覽量-有緩存* //www.cnidcc.cn/ajax_cookies_views.html*/function postviews_cache(){    if( empty( $_POST['postviews_id'] ) ) return;        $post_ID = $_POST['postviews_id'];        if( $post_ID > 0 ) {                $post_views = (int)get_post_meta($post_ID, 'views', true);/*if( !defined( 'WP_CACHE' ) || !WP_CACHE ){ 以前的錯誤代碼*/if( defined( 'WP_CACHE' ) && WP_CACHE ){ //如果wp-config.php開啟緩存    update_post_meta($post_ID, 'views', ( $post_views + 1 ));}                echo ( $post_views + 1 );                exit();        }}add_action( 'wp_ajax_nopriv_postviews', 'postviews_cache' );add_action( 'wp_ajax_postviews', 'postviews_cache' );2018年06月07日更新：感謝網友@魚魚 在評論區指出的BUG，以前寫上面的代碼的時候參考了wp-postviews插件wp-postviews.php里面的代碼，結果學藝不精，只看了上半截，忽略了下半截。錯誤的代碼竟然用了近1年的時間沒發現，還發布在這里誤人子弟，實在羞愧。上面的代碼中，錯誤的代碼依然留存著，只是注釋了，修改的方法有兩種，第一種是上面那樣，第二種則是將10-12行的if段改為下方模式（這種就是wp-postviews插件的寫法）：if( defined( 'WP_CACHE' ) && WP_CACHE ) //如果wp-config.php沒有開啟緩存    return;                             //退出（中止函數的運行）    update_post_meta($post_ID, 'views', ( $post_views + 1 ));注意，如果網站的WordPress只加入了CDN，沒有使用緩存插件的話，需要將上面代碼改成下面的，也就是刪除開啟緩存判斷：/** 緩存時更新瀏覽量-無緩存* //www.cnidcc.cn/ajax_cookies_views.html*/function postviews_cache(){    if( empty( $_POST['postviews_id'] ) ) return;        $post_ID = $_POST['postviews_id'];        if( $post_ID > 0 ) {                $post_views = (int)get_post_meta($post_ID, 'views', true);                update_post_meta($post_ID, 'views', ( $post_views + 1 ));                echo ( $post_views + 1 );                exit();        }}如果想使用有緩存的版本，想要開啟網站緩存，可以選擇安裝緩存插件，或者直接在網站根目錄的wp-config.php中，加入下面這行代碼：define('WP_CACHE', true);如果網站沒有加入CDN，也沒有使用緩存插件，那么有兩個選項：1、Ctrl + D 保存本頁到書簽，待文章變成靜態頁面后再拿出來看看；2、Ctrl + W 關閉本頁，因為除非你要研究代碼，本頁對你沒有什么價值，看看更多該看的吧。總結對于本文的解決方案有什么意見和建議，希望能夠在下方評論欄中提出來，先森覺得還有能夠改進的地方，但一人之力實在有些相形見絀。ajax是個很實用的東西，可能還有更多可以使用的地方，先森也得好好想想。

不知道多少人和先森一樣，在最初接觸wordpress的時候，被網上的各類教程灌輸了“能用代碼版，就不用插件”的概念。先森就本著這個概念，在文章的訪問量的時候，先森就找的代碼版。網上提供的代碼版瀏覽次數統計功能的文章，名稱都差不多，類似“WordPress非插件添加文章瀏覽次數統計功能”這種比比皆是。先森應該是在wordpress大學看到的教程，關于教程先森就不再贅述了。本文主要解決的是，開啟CDN后，用這種代碼版訪問量統計的方式瀏覽次數不再刷新的問題，如果想結合著來使用的話，統計代碼部分可以去wordpress大學看《WordPress非插件添加文章瀏覽次數統計功能》這篇文章。瀏覽次數問題分析先森其實很早就意識到，開啟CDN后，其實瀏覽量不是不刷新，而是只在首次緩存的時候才會增加一次。因為只有第一次訪問的時候才會執行php，緩存后就直接訪問的html了，所以就不會增加統計了。所以解決問題的方式，是讓html也能統計到瀏覽次數，先森認知中的方法就只有一個：ajax。然而當初先森雖然知道問題原因，知道解決方式，但奈何先森代碼能力不強，當時沒能解決。先森始終認為，一個問題如果死活解決不了，那么就先放放，過段時間再反顧可能就會發現，這個問題根本就不是事。當然，這個時間可能就有點久了，起碼就ajax這個問題，先森等了一兩年。。。。先森想到的用ajax更新瀏覽次數的方法就是，使用ajax提交文章的ID給后方的php，后方的php接收到文章ID后，將該文章的瀏覽次數+1。效果實現先森研究了一晚上，發現要解決還是挺簡單的。又是研究幾小時，分享幾分鐘，心塞。首先，在footer.php中添加ajax的代碼，注意url的地址要改為自己的php路徑：<?php if  (is_singular()) : ?>  <!-- ajax post view -->  <!-- ajax post view -->  <script type= "text/javascript" >$.ajax({ type:'POST', url: "//www.cnidcc.cn/wp-content/themes/*/*.php" ,   /*此處需要修改為自己的php路徑*/data: { "postviews_id" : "<?php the_ID();?>" } });   </script><?php endif ; ?>接收數據的php代碼很簡單，參考了評論的comments-ajax.php的頭部，禁止直接訪問，然后加上了幾行更新瀏覽量的代碼。將下面內容保存到一個php文件中，放入自己的wordpress主題里面，將該php的訪問鏈接加入到上面的url中：<?php//禁止直接訪問本phpif ( 'POST' != $_SERVER['REQUEST_METHOD'] ) {        header('Allow: POST');        header('HTTP/1.1 405 Method Not Allowed');        header('Content-Type: text/plain');        exit;}require( dirname(__FILE__) . '/../../../wp-load.php' );nocache_headers();$post_ID = $_POST['postviews_id'];$post_views = (int)get_post_meta($post_ID, 'views', true);update_post_meta($post_ID, 'views', ($post_views+1));?>如此一來，即使加入了CDN，文章頁面變成了靜態頁面，后臺也會更新訪問次數了。總結這樣僅僅是解決了文章頁面被緩存后，瀏覽次數無法被統計到的問題，但是還并不完善。上面的功能實現之后，你會發現，每一次刷新瀏覽次數都會加一，如果有人一直按著F5，那么增加的瀏覽次數就有點恐怖了。這樣還會增加服務器的負擔，像先森這種把網站放在阿里云虛擬主機的，若負載過量還會直接關停，被人這樣搞的關機先森就哭了。所以，下篇文章先森會分享使用cookies來限制訪問次數無限增加的問題。另外，除了訪問量持續增加的問題，還有一個地方可以優化。既然ajax能夠異步提交數據，那么能不能動態的修改文章中的瀏覽次數呢？答案是肯定的，先森也會在下一篇文章中更新。關于上面的問題，請查看下一篇文章：CDN后用Ajax動態提交、顯示文章閱讀量，cookies避免重復刷新

自從用上CDN，需要關注的前臺頁面的問題就更多了，因為要避免一些不該被CDN緩存的內容被緩存，導致訪客訪問到不該看到的內容，影響使用體驗。最近，先森發現曾解決過的問題故態復萌。用了CDN之后比較突出的問題，就是如果一篇文章如果先森登錄之后再去訪問，其他訪客訪問的時候，會顯示“內容管理”、“登出”、評論框會顯示先森的頭像等問題。這個問題其實之前已經處理過了，但是先森wordpress升級之后，發現原本通過WP Super Cache設置的“不要為已知用戶緩存”和“讓已知用戶匿名使他們瀏覽的內容是緩存文件”竟然失效了。查看了下WP Super Cache的版本，發現四周前才更新，并且提示與當前WordPres版本兼容，先森也確定選項已經勾選，但就是不生效，所以就很心塞。發現問題，處理問題。先森冒著英語超爛的風險，去了WP Super Cache的插件頁面，看了一圈問題討論，就是沒發現有人提這個BUG的，在官方找解決方案的道路失敗了。也不知道新的版本什么時候發布，發布會不會包含解決這個問題，所以先森只能又冒著php一知半解的風險來寫代碼了。解題思路解決方式先森覺得有兩種，一個是去把自己的主題中的前臺中管理員登錄后才會顯示的代碼給刪掉，另一種就是讓管理員在前臺匿名，被認為沒有登錄。第一種方案，先森覺得有點費時費力。當初主題的代碼是自己一行一行的寫的，現在讓自己去刪，內心表示很痛苦啊（心中憧憬著哪天要是不用CDN了...）。所以先森還是想實現第二種方案。經過研究自己的主題，先森發現，會顯示管理員才能看到的東西，大多使用了這樣的一種套路：<?php if (is_user_logged_in()){    '我是管理員'} ?>都用的is_user_logged_in()這個函數來判斷用戶是否登錄，所以先森就想，讓這個函數返回“用戶沒有登錄”豈不是就可以了？is_user_logged_in()函數介紹：is_user_logged_in()函數位于wp-includes/pluggable.php函數參數：該函數不接受任何參數。返回值：已登陸返回True，否則返回False。先森在函數所在位置，找到了這個函數的代碼：if ( !function_exists('is_user_logged_in') ) :/** * Checks if the current visitor is a logged in user. * * @since 2.0.0 * * @return bool True if user is logged in, false if not logged in. */function is_user_logged_in() {        $user = wp_get_current_user();        return $user->exists();}endif;先森把上面的return內容改成了如下內容：if(!is_admin()){    return false;}else{return $user->exists();}這樣之后，只要不是后臺，就會返回false，這樣前臺就會得到管理員沒有登錄。先森發現使用了is_user_logged_in()函數的位置都已經不會在登錄的情況下顯示了，但是還有兩個地方例外。第一個地方是文章頁面上的“編輯”按鈕，另一個就是評論的頭像了。通過查看代碼，先森發現編輯按鈕用的是edit_post_link()函數：edit_post_link('編輯', ' &#124; ', '');函數說明：若用戶已登錄且具有編輯文章的權限，該標簽顯示一個可編輯當前文章的鏈接。該標簽必須用在主循環（loop）中。這個函數就沒有使用is_user_logged_in()函數了，所以通過修改is_user_logged_in()的返回值就對“編輯”按鈕不生效了。再來看評論頭像。修改了is_user_logged_in()的返回值之后，頭像旁邊的文字已經變成了未登錄狀態下的文字，但是頭像依然是先森的管理員評論頭像。再去查看代碼，發現評論頭像部分雖然也使用了is_user_logged_in()函數，但是還另外使用了一個全局變量，代碼大致如下：global $current_user;get_currentuserinfo();...echo get_avatar( $current_user->user_email, $size = '48' ,'');這樣是通過獲取當前用戶信息，然后來獲取用戶的email郵箱地址，這樣就和is_user_logged_in()函數無關了，因此前臺還是會顯示管理員的頭像。但也正是這個問題，讓先森找到了解決的辦法。讓管理員在前臺匿名評論頭像是通過獲取當前登錄用戶的相關信息，進而獲取用戶郵箱來顯示頭像的。用到的獲取用戶信息函數是:get_currentuserinfo()而其實看is_user_logged_in()函數，其實它也有獲取當前用戶的相關信息，但用的是另一個函數：$user = wp_get_current_user();而這兩個函數，其實是同一個函數，只是wp_get_current_user()是get_currentuserinfo()的進階版：Notice: 自4.5.0版本起，已不建議使用get_currentuserinfo，請換用wp_get_current_user()。 in ***\wp-includes\functions.php on line 3707既然如此，只需要讓當前用戶信息為空即可。在自己的主題function.php最后加入以下代碼，那么在前臺就用戶信息就為空了，即獲取不到用戶信息了：/*** 讓管理員在前臺訪問匿名** //www.cnidcc.cn/make_known_users_anonymous.html*/function make_known_users_anonymous() {    global $current_user; if(!is_admin()){    $current_user = array( 'user_login' => '', 'user_email' =>'', 'user_level' => '', 'user_firstname' => '', 'user_lastname' => '', 'display_name' => '', 'ID' => '', 'user_url' => '', ); } return $current_user;}add_action( 'init', 'make_known_users_anonymous' );如果想要調試的話，可以把以下代碼放在前臺頁面中想放的位置：<?php  global $current_user; get_currentuserinfo(); //或者將這兩行換成 $current_user = wp_get_current_user();if( is_user_logged_in()){    echo '已經登錄';}else{    echo '沒有登錄';}echo('Username: ' . $current_user->user_login . "\n"); //輸出用戶名  ?>但目前這種方式有個BUG，那就是在文章編輯頁面點擊預覽的時候會返回404，這個待先森找找解決方法。2017-09-01更新先森看了下，預覽的頁面會在文章鏈接后面加上“?preview=true”或者“?p=xxx&preview=true”,那么，當訪問鏈接是帶了“preview=true”的，就不清除登錄信息就行了。那么，把上面的匿名代碼改成下面的代碼，加入functions.php中/*** 讓管理員在前臺訪問匿名** //www.cnidcc.cn/make_known_users_anonymous.html*/function make_known_users_anonymous() {    global $current_user; if(!is_admin() && $_GET['preview'] != 'true'){    $current_user = array( 'user_login' => '', 'user_email' =>'', 'user_level' => '', 'user_firstname' => '', 'user_lastname' => '', 'display_name' => '', 'ID' => '', 'user_url' => '', ); } return $current_user;}add_action( 'init', 'make_known_users_anonymous' );如果有任何問題，可以在下方評論。關于訪客填寫的昵稱、郵箱、域名等信息不被CDN緩存，可以看看先森的解決方案：用cookie解決網站開啟CDN緩存之后已知用戶頭像昵稱被緩存等系列問題用cookie記住用戶信息后隱藏信息輸入框，優化用戶體驗

最新在新建一個博客，新的博客是建在云服務器的，完全自主，不得不說感覺非常好，比起虛擬主機可操作性強太多了。因為可操作性強，所以想把該做的都做好，比如備份。受張戈博客影響，看到了張戈的同步7天的那篇文章，想照著操作的時候發現，七牛的qrsync工具竟已廢棄：qrsync已廢棄看這簡介，推薦使用qshell命令行工具，先森就干脆研究下使用新的工具來同步。有段時間沒和七牛云儲存打交道了，變化還是挺大的。為七牛的推陳出新點個贊。一、數據庫、網站本地備份腳本在服務器上編輯shell腳本，腳本代碼如下：#!/bin/bash# Name:liuxxbak.sh# This is a ShellScript For Auto Backup and Delete old Backup# Date:2017-8-19source /etc/profilebackupdir=/web/data/liuxx_bak   # 本地備份路徑time=` date +%Y%m%d `date=` date +"%Y-%m-%d %H:%M:%S" `day=15  #本地備份保留天數# 數據庫信息user=rootpassword=******host=127.0.0.1port=3306databases=wordpress# 本地網站根目錄backhome=/web/data/html/if [ ! -d $backupdir ]; then  mkdir $backupdirfi        mysqldump -h $host -P $post -u $user -p$password ${data} | gzip > $backupdir/${data}_$time.sql.gzif [ "$?" == 0 ];then        echo "[${date}] 數據庫 ${data} 備份成功!!" >> ${backupdir}/mysqllog.logelse#備份失敗則進行以下操作        echo "[${date}] 數據庫 ${data} 備份失敗!!" >> ${backupdir}/mysqllog.logfi# 備份網站tar -zcvf $backupdir/liuxx_${time}.tar.gz $backhome > /dev/null 2>&1# 刪除同步find $backupdir -name "*.gz" -type f -mtime +${day} -exec rm {} \; > /dev/null 2>&1先森將以上代碼保存為‘liuxxbak.sh’，名稱可以隨意自定義。保存后需要增加可執行權限：chmod +x liuxxbak.sh使用說明：將以上內容變量按需修改：backupdir=本地備份絕對路徑day=本地備份保留天數user=數據庫用戶名（建議使用root用戶，出錯可能性小）password=數據庫密碼host=數據庫IP或域名port=數據庫端口databases=數據庫名稱backhome=本地網站根目錄腳本執行方式：./liuxxbak.sh或者/web/data/liuxxbak.sh    # 絕對路徑執行如此可以檢查一下是否能夠成功備份。二、遠程備份到七牛云儲存1.命令。首先下載qshell命令行工具，下載頁面：根據服務器類型選擇下載linux 64位的服務器可以直接在服務器上這樣下載并增加可執行權限：wget -O qshell http://devtools.qiniu.com/2.1.3/qshell-linux-x64 && chmod +x qshell可以將qshell命令放入自定義目錄。或直接放至/usr/bin/路徑下，這樣就可以任何地方直接輸入命令了。2.鑒權。有了命令之后，我們需要七牛的鑒權，否則沒法使用接下來的命令。需要鑒權的命令都需要依賴七牛賬號下的 AccessKey 和 SecretKey。所以這類命令運行之前，需要使用 account 命令來設置下 AccessKey ，SecretKey 。鑒權的方式很簡單，首先進入七牛的個人中心->密鑰管理中，找到AccessKey 和 SecretKey。然后在服務器中運行一下命令：/web/data/qshell account ak sk執行之后，用戶的所有信息寫入到磁盤$HOME_DIR/.qshell下面。如：root用戶執行后，信息會保存在/root/.qshell/account.json文件中。如果你修改了密鑰，只需要重新執行以上命令即可，配置信息將被覆蓋。3.同步。終于到了這一步。qshell命令的命令有很多，同步需要用到的命令是qupload。qupload是用來將本地目錄中的文件同步到七牛空間中的命令。命令格式：qshell qupload [<ThreadCount>] <LocalUploadConfig>ThreadCount：并發上傳的協程數量，默認為1，即文件一個個上傳，對于大量小文件來說，可以通過提高該參數值來提升同步速度。LocalUploadConfig：數據同步的配置文件，該配置文件里面包含了一些諸如本地同步目錄，目標空間名稱等信息。ThreadCount是可以忽略的參數，默認一個文件一個文件的上傳，因為是要備份數據庫和本地網站文件，文件較少且大，顧保持默認就好。LocalUploadConfig為配置文件，配置文件中可帶的參數共有21個，先森選用了其中的7個。詳細的配置介紹請看這里。先森選用的參數如下，將以下內容保存到文件‘localupload.cnf’：{   "src_dir"            :   "/web/data/liuxx_bak",   "bucket"             :   "liuxx-backup",   "ignore_dir"         :   true,   "overwrite"          :   true,   "check_exists"       :   true,   "check_hash"         :   true,   "rescan_local"       :   true}解釋，*為必須項："src_dir":"/web/data/liuxx_bak",  # 本地備份路徑*"bucket":"liuxx-backup",    #同步數據的目標空間名稱，可以為公開空間或私有空間*"ignore_dir":true,    #遠程同步到七牛時，忽略本地路徑"overwrite":true,    #覆蓋同名文件"check_exists":true,    #上傳前檢查是否有同名文件"check_hash":true,    #在check_exists設置為true的情況下生效，是否檢查本地文件hash和空間文件hash一致"rescan_local":true,    #檢測本地新增文件并同步最后，遠程同步到七牛云儲存的命令為:/web/data/qshell qupload /web/data/localupload.cnf可以執行一下上面的命令，檢查是否能夠成功同步。先森同步到七牛云的效果：同步效果三、定時備份同步準備工作已經完畢了，現在所需的就是每天的自動備份及遠程備份了。執行crontab -e添加以下內容：00 02 * * * /web/data/liuxxbak.sh30 02 * * * /web/data/qshell qupload /web/data/localupload.cnf >/dev/null 2>&1凌晨兩點執行本地備份，凌晨兩點半執行遠程備份。當然，你也可以將qshell命令加到liuxxbak.sh腳本的最后，那么只用添加第一條計劃任務就可以了。四、七牛十五天循環備份七牛云儲存免費的存儲空間大小是10G，如果你的七牛云存儲空間有點緊急的話，可以繼續本操作。這時候，點擊‘生命周期’，添加規則，我們可以設定刪除15天前的文件。先森設定的規則如下：刪除15天前的文件當然，如果七牛云存儲的剩余空間很足的話，可以保留更多天，這樣可供回退的版本就更多了。總結無論是用虛擬主機，還是使用云服務器，有一套備份的機制是很重要的。如果像先森一樣，主站使用的是虛擬主機，也有另外的云服務器的話，這套備份方案改改，也可以把自己虛擬主機的數據庫一起備份起來嘛。

先森之前就發現，“成航先森”在手機上訪問使用搜索時，無法使用鍵盤上的“前往/搜索”按鈕。點擊沒有反應，必須要點擊網頁中的搜索按鈕才行。之前因為懶得管，就一直沒有解決這個問題，這兩天丑了點時間研究了一下，最后發現這個問題是分階段的。“前往”和“搜索”按鈕的問題手機中的輸入框，有時候右下角是“前往”，而有時候是“搜索”。先森起初以為是因為先森的搜索框顯示的是“前往”，所以無法使用這個按鈕。后來先森發現，寫一個簡單的html頁面，通過手機訪問，無論是“前往”還是“搜索”，都不會影響點擊該按鈕的效果。不過讓鍵盤顯示“搜索”還是要顯得專業一些。實現方法：<input type="search">搜索框的type必須是search。“前往”與“搜索”點擊輸入法中的“搜索”沒有反應的原因上面所說的，按鍵上無論顯示什么文字，都不會影響功能。然而先森的網站中，點輸入法上的按鈕是死活沒有作用，所以原因還是要繼續找。先森本以為是某個JS代碼導致了這個問題，所以先森把首頁保存到本地，一個個的刪除嘗試。花費了大概一個小時的時間，終于，先森確認跟JS代碼沒有任何關系。最后無意間刪了一個<base>標簽，結果發現竟然可以了，手機輸入法點擊“搜索”可以搜索了。罪魁禍首就是它：<base target="_blank">這個base標簽的作用是網頁中的每個鏈接都默認為新標簽頁打開，好不好用就不做累述了。刪除與恢復刪除這個<base>標簽就可以實現使用手機輸入法中的搜索按鈕效果，但是我們想要的新標簽頁打開網頁就沒有了。先森參考網上的JavaScript腳本，新寫了一段js代碼，從而實現相類似的效果。需要注意的是，不能簡單的給每個<a>標簽都增加上新標簽頁打開，因為有些地方不適合新標簽頁打開，比如頁碼，每點一次下一頁就新開一個窗口，訪客要瘋了吧？所以，當<a>標簽已經設置了本頁打開的需要排除，其他<a>標簽才加上_blank屬性。把下面的JavaScript代碼放在head某處：<script type="text/javascript">$(function(){    $('body a').each(function(){        if($(this).attr('target')!=='_self'){        $(this).attr('target','_blank');}    });});</script>那么，你的網站搜索框能用手機的搜索按鈕嗎？

很久沒有管過博客了，最近發現博客里的跳轉鏈接全都失效了，點擊只能跳轉到首頁。通過審查元素查看，是從末尾不加斜杠的鏈接301跳轉到加個斜杠的鏈接。無論如何，結局就是跳轉失敗了。周末一個閑著無事，就想著解決一下這個問題。通過漫長的排除，發現問題是安裝了WPJAM BASIC插件的問題，停用了之后跳轉鏈接就正常了。WPJAM BASIC插件不得不吐槽一下水煮魚，之前用這WPJAM七牛鏡像存儲，有一天發現可以升級了，隨手就點了升級，結果升級后發現，要啟用這個插件，還需要另外裝一個WPJAM BASIC。然后裝了發現啟動不了，后來看報錯是插件里的函數和先森主題的函數沖突了，先森注釋了自己主題里的函數后，插件可以啟動了。因為先森有保留函數來源的習慣，所以先森檢查那個沖突函數發現，這TM就是從水煮魚網站拷貝的函數。這個插件果然是各種功能的集合，但總有一種強制消費的感覺，隱隱讓人不爽。anylink這個插件先森自建立博客以來就一直在用了，用著已經習慣了，雖然有代碼版但也不想去弄了，覺得還是有操作頁面的比較實用。先森更是用anylink與張戈博客的跳轉美化界面做了結合，還專門發布了一篇文章：WordPress為anylink插件外鏈跳轉添加漂亮的跳轉頁面所以，先森對于anylink這個插件是非常難以拋棄的。但是很棘手的是，為什么WPJAM BASIC插件會與anylink插件起沖突，如何解決。而先森已經在七牛圖片處理樣式的正確使用方式一文中提到，主題已經添加了七牛CDN代碼版。經測試取消啟用WPJAM BASIC插件后，對博客使用七牛并不會產生什么問題，所以，只能拋棄WPJAM BASIC了。