先森最近更新了一篇文章，發布后先森自己沒有去看，今天去看了一眼，結果突然發現這篇文章中所有的外鏈沒有自動轉成內鏈。以前優化SEO的時候，看到的優化建議基本都有不要直接跳轉到外鏈，會導致權重降低，所以先森一直都有用anylink這個插件來實現這個功能。對于anylink這個插件，先森的使用體驗還是非常好的，之前一共還發過三篇博文：WordPress為anylink插件外鏈跳轉添加漂亮的跳轉頁面WordPress：WPJAM BASIC插件與anylink沖突WordPress優化：為anylink插件增加緩存既然發現了問題，那么就得解決問題，正好是清明節放假期間，托疫情的福先森哪里也不好去，所以來會會這個bug。排查過程首先，出現沒有轉內鏈的文章只有先森最新發布的那一篇，之前的文章都是正常的。1、懷疑緩存可能是CDN有緩存，先森將本機hosts改成源站，直接訪問源站，測試依舊正常，pass。除了CDN，先森WordPress還有緩存，先森用的是插件wp-super-cache進行緩存。先森清理了插件緩存后，問題依舊；然后想是不是插件有問題，直接將wp-super-cache插件停用了，問題依舊。2、懷疑anylink插件排除了緩存的問題，先森又想是不是anylink插件自己出了什么問題，先森將anylink插件停用后再啟用，發現問題依舊，插件運行問題pass。然后先森考慮是不是插件在本篇文章的執行有問題，開debug看一看。先森在WordPress的wp-config.php中打開了dubug：define( 'WP_DEBUG', true );define( 'SAVEQUERIES', true );先森開debug主要是想看本篇文章中的SQL查詢，所以在后臺開啟了Debug Queries插件，結果開啟后并沒有看到anylink的查詢，然后先森想到了為anylink添加redis緩存這篇文章中，已經將相關的SQL查詢優化了，這樣debug確實已經看不到去MySQL的查詢了。此時先森已經開始懷疑是不是當時優化有什么bug了，但還是需要先確認一下是不是MySQL、Redis數據庫有問題。3、懷疑數據庫有問題先森的MySQL是云數據庫，Redis是部署在源站本機的。MySQL運行肯定沒有問題， 不然就不只是外鏈有問題了；Redis檢查后發現也是正常運行的。先森再去看anylink的MySQL表，發現wp_al_urls表里是有出問題這篇文章的外鏈轉內鏈對應表的，這就奇怪了，到這里MySQL的問題排除了，先森就懷疑是自己之前的優化存在問題了。4、懷疑優化存在BUG先森本來想直接在redis里查有問題文章的緩存，但是redis的key太多了，先森已經忘了key是什么規則了，所以就先去研究了一下anylink的代碼，先搞清楚之前先森的優化。首先確認到，先森優化的是插件的classes/al_filter.php文件，優化了getAllLnks()和get_slug_by_url()這兩個類中的函數，增加了先查redis緩存，沒有再查數據庫并將結果存到redis的代碼。修改的部分這兩個函數先森研究了一下，get_slug_by_url()這個函數是用在把留言者的鏈接轉換成內鏈的，所以出現問題的不可能是這個函數，那只能是getAllLnks()這個函數了。getAllLnks()這個函數保存緩存的key是‘getAllLnks:’開頭的，后面跟的是文章的id，先森就去redis查相關key。應該是redis的key不支持冒號，所以實際存儲的key是‘getAllLnks-’開頭的。先森發現有問題的文章ID是1968，所以它的key是‘getAllLnks-1968’，先森先查的是正常文章的key，查出來是一大堆的內容，而查到1968就發現明顯有問題：getAllLnks有問題這個key的內容簡直就沒有內容，按邏輯來想起碼有兩個內容：外鏈地址、內鏈地址，將這個key刪除，然后重新訪問有問題的文章，發現外鏈就已經自動轉為內鏈了，此時再來查redis的key查詢結果，正常多了：getAllLnks正常結果至此，問題已經臨時得到了解決，但是原因還需要分析一下。出現bug的原因一開始，先森以為這個問題原因是anylink在管理員登錄時不會處理外鏈，先森預覽文章被緩存了，但是找了一圈anylink的代碼，沒有找到判斷管理員是否登錄的代碼，所以應該不是這個原因。好好想了一下，發現bug的原因應該是這個：當文章還在編輯的過程中，預覽文章，由于此時文章還沒有外鏈，所以數據庫查詢結果為空，但是這個空結果被先森的代碼保存到Redis中了，由于Redis的緩存沒有設置過期或到期時間未到，先森也沒有設置redis緩存更新，導致后續anylink插件來查詢這篇文章的外鏈時一直是空的。解決方案問題原因找到了，就好解決了，先森想到了兩個解決方案：方法1：管理員登錄時anylink不處理鏈接方法2：文章發布、變更時更新anylink的緩存第一種方法，管理員登錄時，尤其是正在編輯文章時，預覽文章不會造成錯誤的key被redis緩存。但此方法還是有bug，管理員未來更新文章時新增了其他外鏈，此時由于Redis已經緩存了這篇文章的外鏈查詢情況，如果改緩存未過期，新增的外鏈在文章中會出現未被轉換的情況。且這種方法容易造成管理員視角和訪客視角不同，先森用的其它插件有類似設定，實際使用中會讓人比較頭疼，所以先森不太希望使用這種方式進行修復。相較而言，第二種方法就要合理的多，只要文章有變動，那就把anylink該文章的redis緩存刪了，有人訪問該文章時再緩存。實現也比較簡單，在自己的主體function.php最后加一個publish_post鉤子，實現這個需求：/** * 更新或發布文章清理Redis緩存 * 增加時間：2022-04-04 12:43:00 * By：http://www.cnidcc.cn/ */function Clean_Redis($post_ID){ wp_cache_delete( 'getAllLnks:'.$post_ID );}add_action('publish_post', 'Clean_Redis', 0);來測試一下，在管理后臺隨便更新了一篇已發布的文章，發布前查詢該文章的redis緩存，刷新后再去查詢，該文章的key已經查不到數據了。測試hook刪除redis緩存2020年埋下的bug終于在2022年被修復了，還好期間先森新發布的文章只有2021兩篇（有點慚愧），且不涉及外鏈，所以影響不大。按理說也會影響到舊文章的更新，但是先森最近幾年對博客這邊的關注實在太少，影響著實不大。無論怎樣，寫代碼還是的考慮周到一點，還好先森不是程序員，只是一枚小運維。

先森最近在梳理網站的代碼，想辦法為網站加速，主要從代碼、軟件、網絡層面進行優化，這一切都是從網站切換到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很麻煩，實際使用發現真香，建議有能力的朋友都上一下，畢竟生命不止，折騰不息。本文最主要的還是記錄一下排查網頁查詢慢的過程和解決方法，希望能夠給其他朋友提供思路。

上篇文章解決了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 關閉本頁，因為除非你要研究代碼，本頁對你沒有什么價值，看看更多該看的吧?？偨Y對于本文的解決方案有什么意見和建議，希望能夠在下方評論欄中提出來，先森覺得還有能夠改進的地方，但一人之力實在有些相形見絀。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，文章頁面變成了靜態頁面，后臺也會更新訪問次數了?？偨Y這樣僅僅是解決了文章頁面被緩存后，瀏覽次數無法被統計到的問題，但是還并不完善。上面的功能實現之后，你會發現，每一次刷新瀏覽次數都會加一，如果有人一直按著F5，那么增加的瀏覽次數就有點恐怖了。這樣還會增加服務器的負擔，像先森這種把網站放在阿里云虛擬主機的，若負載過量還會直接關停，被人這樣搞的關機先森就哭了。所以，下篇文章先森會分享使用cookies來限制訪問次數無限增加的問題。另外，除了訪問量持續增加的問題，還有一個地方可以優化。既然ajax能夠異步提交數據，那么能不能動態的修改文章中的瀏覽次數呢？答案是肯定的，先森也會在下一篇文章中更新。關于上面的問題，請查看下一篇文章：CDN后用Ajax動態提交、顯示文章閱讀量，cookies避免重復刷新

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

有朋友讓教下怎么使用ueditor官方的進行手動集成為WordPress插件，先森就花了點時間研究了一下，現在把方法發布出來。ueditor編輯器文件準備1、首先需要下載一些文件，首先是下載官網最新的UEditor編輯器，現在最新的是1.4.3.3版。進入如下鏈接，下載PHP版：UEditor官方下載地址選擇PHP版本下載2、下載百度UEditor編輯器插件1.4.3.1 For WordPress，我們需要用到一些里面的文件：百度網盤：鏈接: http://pan.baidu.com/s/1c1bKhNy 密碼: sd46下載之后，分別解壓，這時候就有了如下文件：當前擁有的文件手動集成其實手動集成的方法非常簡單，只需復制下文件，修改個文件名即可。1、第一步，把“\Ueditor編輯器1.4.3.1 for wordpress 4.0插件\ueditor”文件夾內“main.php”和“ueditor.class.php”復制到“ueditor1_4_3_3-utf8-php”文件夾中：復制文件2、第二步，將“ueditor1_4_3_3-utf8-php”文件夾中的“utf8-php”文件夾重命名為“ueditor”：文件夾重命名3、第三步，將“ueditor1_4_3_3-utf8-php”文件夾中的文件打包為zip壓縮包，手動集成最新版百度UEditor編輯器插件到WordPress就完成了，從WordPress后臺上傳插件啟用就可以使用了：文件打包BUG修復先森發現，這樣直接上傳之后，后臺編輯框的高度只有80px，非常不利于編輯。編輯器高度修改編輯框的高度很簡單，直接在WordPress后臺->插件->編輯，選擇UEditor，編輯并更新ueditor.config.js中的第93行，將前面的雙斜杠注釋刪掉，后面的高度數值改為想要的高度（建議值：500px）：后臺編輯編輯更新之后，再看編輯器的效果如下（高度為320px）：修改效果總結雖然步驟簡單，但若還是不想親自操作的話，也可以下載先森編譯好的最新版：百度網盤下載 鏈接: http://pan.baidu.com/s/1c2Biu9E 密碼: chxs（成航先森）另外，先森只是實現了手動集成的效果，其他可能出現的BUG還沒有發現或測試，如有疑問，歡迎發表評論。

其實本文著重介紹的不是彩色美化框，而是如何給百度UEditor編輯器增加自定義按鈕。關于什么是彩色美化框，看過先森前文《WordPress默認TinyMCE編輯器增加彩色美化框自定義按鈕》應該都知道的。其實也沒什么，也就是給引用來的文字段加一個更明顯的樣式，就像下面這樣。這是一個綠色提示框這種美化框，各位站長應該經常能見到，或許你也希望能給自己的WordPress上添加這種美化框。前文已經介紹過如何在WordPress默認的TinyMCE編輯器上添加，那么今天再來介紹下如何在百度UEditor編輯器上添加按鈕了。注：本文中會增加4個按鈕，代表著4中顏色的美化框。如果還沒有安裝百度UEditor編輯器，可以點擊下載百度UEditor編輯器插件1.4.3.1 For WordPress前期準備1.添加短代碼編輯WordPress主題目錄下的functions.php文件，添加如下代碼并保存:/**美化框的短代碼*/function toz($atts, $content=null){return '<blockquote id="sc_notice">'.$content.'</blockquote>'; }  add_shortcode('v_notice','toz');  function toa($atts, $content=null){return '<blockquote id="sc_error">'.$content.'</blockquote>'; }  add_shortcode('v_error','toa');  function toc($atts, $content=null){return '<blockquote id="sc_warn">'.$content.'</blockquote>'; }  add_shortcode('v_warn','toc');  function tob($atts, $content=null){return '<blockquote id="sc_tips">'.$content.'</blockquote>'; }  add_shortcode('v_tips','tob');這個短代碼的作用是，在編輯器中輸入如下短代碼后，在前臺打開文章時，會把這些短代碼變為上面我們定義的blockquote標簽：編輯器中的短代碼2.CSS美化將css代碼放入主題的style.css文件中或其他地方：/*彩色美化框*/#sc_notice { color: #7da33c; background: #ecf2d6 url('images/sc/sc_notice.png') -1px -1px no-repeat; border: 1px solid #aac66d; overflow: hidden; margin: 10px 0; padding: 15px 15px 15px 35px;width: 98%; }#sc_warn, .post-password-form { color: #ad9948; background: #fff4b9 url('images/sc/sc_warn.png') -1px -1px no-repeat; border: 1px solid #eac946; overflow: hidden; margin: 10px 0; padding: 15px 15px 15px 35px;width: 98%; }#sc_error { color: #c66; background: #ffecea url('images/sc/sc_error.png') -1px -1px no-repeat; border: 1px solid #ebb1b1; overflow: hidden; margin: 10px 0; padding: 15px 15px 15px 35px;width: 98%; }#sc_tips {color: #7da33c;background: #ecf2d6 url('images/sc/sc_tips.png') -1px -1px no-repeat;border: 1px solid #aac66d;padding: 15px 15px 5px 35px;margin: 10px 0;width: 98%;overflow: hidden;}CSS代碼中有4個圖標鏈接，請將鏈接改為你保存的位置圖標素材下載：鏈接: http://pan.baidu.com/s/1bo3ziCB 密碼: chxs(成航先森)只有前期準備是對WordPress主題的代碼添加，后面的步驟都是在UEditor編輯器插件的代碼修改了。UEditor添加按鈕本文參考：百度UEditor官方-UEditor二次開發-增加一個普通按鈕（上）（下）百度UEditor官方-API文檔第一步:添加按鈕位置在/wp-content/plugins/ueditor/ueditor目錄中，找到ueditor.config.js文件打開，找到ueditor.config.js文件中的toolbars參數，增加'v_notice', 'v_error', 'v_warn', 'v_tips'字符串，為了方便區分，我們可以在這四個字符串前加上一個'|'豎線。添加效果如圖：第一步:添加按鈕位置第二步：注冊按鈕實例還是在/wp-content/plugins/ueditor/ueditor目錄中，找到ueditor.all.js文件打開，直接定位到大概第649行，有個數組如下：e="undo redo formatmatch bold italic underline fontborder touppercase tolowercase strikethrough subscript superscript source indent outdent blockquote pasteplain pagebreak selectall print horizontal removeformat time date unlink insertparagraphbeforetable insertrow insertcol mergeright mergedown deleterow deletecol splittorows splittocols splittocells mergecells deletetable drafts"在數組中的最后按格式添加第一步中的v_notice v_error v_warn v_tips四個字符串，添加效果如下：第二步：注冊按鈕實例這時候清空緩存刷新下頁面，看看工具欄的對應位置是否出現了四個個自己定義的按鈕呢？如下圖所示：新增的4個按鈕由于此時未設置對應按鈕的圖片樣式，所以會顯示默認的“B”字符。要想讓其顯示成自己需要的圖標樣式，接著按照下面的步驟動手吧。第三步：更改圖標首先是更改圖標為默認圖標的方法。找到UEditor編輯器插件目錄中的themes/default/ueditor.css文件，末尾增加一條樣式定義:.edui-for-v_notice .edui-icon {    background-position: -700px -40px;}完成后刷新瀏覽器，可以看到此時第一個圖標已經顯示為如下圖所示：第三步-修改圖標此處的樣式定義了showmsg圖標在UEditor默認的精靈Icon圖片（themes/default/images/icons.png）中的位置偏移。如需更改成另外圖標，只需添加圖標到該圖片文件中，然后設置偏移值即可。先森已經將圖標添加到icons.png圖片中了（下圖右側），大家只需要將下圖用新窗口打開，去掉圖片鏈接后面的問號及參數另存，重命名后替換themes/default/images/icons.png圖片即可：icon圖標文件對應的，在themes/default/ueditor.css文件中添加的代碼如下：.edui-for-v_notice .edui-icon {    background-position: -830px 0px;}.edui-for-v_error .edui-icon {    background-position: -830px -20px;}.edui-for-v_warn .edui-icon {    background-position: -830px -40px;}.edui-for-v_tips .edui-icon {    background-position: -850px 0px;}這時候，重新刷新瀏覽器，應該就可以看到如下效果了：更改圖標的最終效果第四步：定義按鈕事件處理方法到此為止，在UI層面已經完成了一個工具欄圖標的顯示，但是我們發現點擊按鈕之后毫無反應。那是必然的，我們還必須為該按鈕綁定屬于它自己的事件處理方法。實質上，此時一個默認的事件處理方法已經被UEditor綁定到按鈕上了，只不過由于我們還沒有定義該方法的具體內容，所以點擊之后無任何變化。下面我們就來定義該方法的具體內容：再回到到ueditor.all.js文件，在521行（并不固定于521行，只要在其附近的一個分號后面另起一行即可）后另起一行，然后在該文件中輸入如下代碼：UE.commands['v_notice'] = { execCommand : function(){ var range = this.selection.getRange();        range.select();        var txt = this.selection.getText(); if (txt == ''){this.execCommand('insertHtml','綠色提示框：輸入文字');} else{this.execCommand('insertHtml',''+txt+'');}    }};UE.commands['v_error'] = { execCommand : function(){ var range = this.selection.getRange();        range.select();        var txt = this.selection.getText(); if (txt == ''){this.execCommand('insertHtml','紅色提示框：輸入文字');} else{this.execCommand('insertHtml',''+txt+'');}    }};UE.commands['v_warn'] = { execCommand : function(){ var range = this.selection.getRange();        range.select();        var txt = this.selection.getText(); if (txt == ''){this.execCommand('insertHtml','黃色提示框：輸入文字');} else{this.execCommand('insertHtml',''+txt+'');}    }};UE.commands['v_tips'] = { execCommand : function(){ var range = this.selection.getRange();        range.select();        var txt = this.selection.getText(); if (txt == ''){this.execCommand('insertHtml','灰色提示框：輸入文字');} else{this.execCommand('insertHtml',''+txt+'');}    }};添加后代碼中如下圖：定義按鈕事件處理方法這時候刷新瀏覽器，點擊按鈕，應該可以看到以下效果（圖中先森是手動換行）：按鈕功能效果代碼解釋：UE.commands['v_notice']這個表示注冊一個命令。execCommand : function(){}execCommand是UEditor執行命令的通用接口。var range = this.selection.getRange();        range.select();        var txt = this.selection.getText();這一串是百度UEditor的ue.selection.getText();或者說是editor.selection.getText();命令的使用方法，其作用是獲得當前選中的文本。因為添加了這個命令，所以使用按鈕的時候，可以先將文字寫好，然后選中后點擊按鈕。但遺憾的是選中的文字只能是純文本，如果有鏈接或其他樣式，選中后點擊按鈕也會變成純文字。本來先森研究了半天也沒搞懂editor.selection.getText();命令的使用方法，還是要多謝平平深度文件搜索軟件，先森通過其深度搜索功能，在ueditor文件夾內搜索“selection.getText()”，這才找到了使用實例。然后if和else是為了判斷是否選中了文本，最核心的其實就是下面這行代碼：this.execCommand('insertHtml','灰色提示框：輸入文字');這行代碼就是插入HTML代碼，代碼內容為“[ v_tips]灰色提示框：輸入文字[ /v_tips]”。更多功能命令，請查看UEditor官方文檔和API文檔。第五步：添加鼠標移上按鈕時的提示其實到此為止，給UEditor添加按鈕的功能已經完全實現了，但是我們還缺少一個不是那么重要的功能，也就是當鼠標移到按鈕上的時候給出的提示。在標準版本里面，其實第一步里面就已經可以添加提示了，但是WordPress for UEditor插件用的是zh-cn這種自動多語言配置，所以我們還需要在翻譯文件中添加提示語言。打開/wp-content/plugins/ueditor/ueditor/lang/zh-cn目錄，打開zh-cn.js文件。在labelMap數組中添加4個對應提示：'v_notice':'綠色提示框', 'v_error':'紅色提示框', 'v_warn':'黃色提示框', 'v_tips':'灰色提示框'添加后zh-cn.js內代碼應該如下圖：添加鼠標移上按鈕時的提示到這里，給WordPress版UEditor編輯器增加四個彩色美化框自定義按鈕就完全實現了。修改版下載可能有些小伙伴看了上文已經頭大了，喜歡折騰的可以跟著折騰一番，如果實在不會折騰的，先森也把為寫本教程制作出來的WordPress版UEditor編輯器插件分享給大家：百度云網盤下載：鏈接: http://pan.baidu.com/s/1i5i4M4P 密碼: chxs（成航先森）寫在最后本文一是提供一個給UEditor編輯器添加按鈕的方法，而是添加彩色美化框的方法。先森覺得，有了添加按鈕的方法最為重要，有了方法之后我們可以自定義更多方便的按鈕。先森接下來想做的就是添加下載鏈接的按鈕，讓前臺的下載鏈接顯得更美觀，不像上面那樣光禿禿的一個鏈接。至于彩色美化框，先森覺得選中后會是鏈接什么的被過濾掉實在是個不小的BUG，所以希望未來能將其攻克，也希望有朋友能提供更好的代碼，先森的JavaScript實在太差。

很早以前就在張戈博客那里看到了這么一個工具，當時覺得沒有什么用，但后來才知道是自己不知道怎么用。工具的用途是工具的價值體現。在正確的地方，使用正確的工具，就顯得工具非常有實用價值。張哥發出這個工具是為了解決網站開啟CDN后，評論者的用戶信息不能被保存，每次都要重現填寫的困境。因為是站在了巨人的肩膀上，所以先森很方便的用cookie的方法解決了用戶信息不能被保存的問題，所以當時對這個工具不是很在意。但是先森在參加培訓的時候的電腦都有還原卡，到各個博客去評論的時候都需要重新填寫自己的信息，就算是復制粘貼也太麻煩了，所以就想起了這個工具。工具介紹這個工具很簡單，只需要將自己的昵稱、郵箱地址、站點信息在下面填寫好后，點擊生成代碼，即可得到一串屬于自己的代碼。一鍵填寫WordPress評論中用戶信息代碼生成工具使用然后將下面生成的鏈接拖到書簽欄即可保存書簽，使用的時候直接在需要填寫的頁面單擊該書簽即可。老版的瀏覽器可以右鍵鏈接保存為書簽，或者直接Ctrl+D打開一個新建書簽的頁面，自定義書簽名稱，將生成的代碼粘貼進網址欄即可。昵稱(必須)：郵箱地址(必須)：站點：拖拽下面的鏈接到您的書簽工具欄或者右鍵單擊鏈接把它添加到您的收藏夾中可創建一個快速填寫WP評論者信息的快捷方式?？焖偬顚慦P評論信息工具源碼如果你也想要在你的博客中添加這樣一個工具，如果你也想弄一個這樣的工具，只需要將以下代碼粘貼到博客相應頁面即可（TinyMCE編輯器需文本模式，UEditor編輯器需HTML模式）：<script type="text/javascript">(function($){ $(document).ready(function() { $('.code_result').hide(); $('#generate_code').click(function(){ var re = /^[0-9a-zA-Z]+([\.\-\_][0-9a-zA-Z]+)*@[0-9a-zA-Z]+([\.\-][0-9a-zA-Z]+)*.[a-zA-Z]+$/; if($('#commenter_author').val() == '') { $('#commenter_author').css('border', 'solid 1px #ff0000'); $('#commenter_author').focus(); } else if(!re.test($('#commenter_email').val())) { $('#commenter_email').css('border', 'solid 1px #ff0000'); $('#commenter_email').focus(); } else { var commenter_code = 'javascript:document.getElementById(\'author\').value = \''+$('#commenter_author').val()+'\'; document.getElementById(\'email\').value = \''+$('#commenter_email').val()+'\'; document.getElementById(\'url\').value = \''+$('#commenter_url').val()+'\'; void(0)'; $('#wp_commenter_code').html(commenter_code); $('.code_result>a').attr('href', commenter_code); $('.code_result').show(); } }); $('#cheon_code_generator input').keyup(function() { $(this).css('border', 'solid 1px #000000'); }); });})(jQuery);</script><div id="cheon_code_generator" style="padding:10px;"><p>昵稱(必須)：<br /><input type="text" value="" name="commenter_author" id="commenter_author" style="border:solid 1px #000;"></p><p>郵箱地址(必須)：<br /><input type="text" value="" name="commenter_email" id="commenter_email" style="border:solid 1px #000;"></p><p>站點：<br /><input type="text" value="" name="commenter_url" id="commenter_url" style="border:solid 1px #000;"></p><p><textarea cols="40" rows="10" name="wp_commenter_code" id="wp_commenter_code" style="border:solid 1px #000;"></textarea></p><p><input type="button" value="生成代碼" id="generate_code" style="cursor: pointer;border:solid 1px #000;"></p><p class="code_result" style="display:none;">拖拽下面的鏈接到您的書簽工具欄或者右鍵單擊鏈接把它添加到您的收藏夾中可創建一個快速填寫WP評論者信息的快捷方式。<br /><a href="#">快速填寫WP評論信息</a></p></div>注：該工具只適合于WordPress博客程序創建的網站。如果要適用其他博客，需對JS代碼中對應的ID進行修改。

先森之前也發文提到過，網站已經接入百度云加速，開啟了全站緩存。先森使用了兩天之后，感覺很不錯，就把體驗的結果寫了一篇文章發布了。但是突然又發現，先森終于用到了讓很多站長頭疼的動態數據的問題。先森發現，CDN開啟網頁HTML緩存之后，一篇文章在沒有緩存的情況下，如果第一次訪問是先森自己訪問的，那CDN緩存的時候，就會把先森登錄后顯示的界面緩存下來。也就是訪客訪問的時候，會顯示“內容管理”、“登出”、評論框會顯示先森的頭像，前面兩個因為沒有登錄，所以點擊之后也沒有用，但是評論框顯示先森的頭像的時候，沒有更改昵稱和郵箱的選項，當訪客寫好評論提交的時候會提示“請輸入昵稱和郵箱”。先森的網站本來評論就少，這樣一來豈不是更收不到評論了。動態判斷內容被緩存為了解決這個問題，暫時又沒找到合適的解決方法，只得把CDN的緩存HTML給關了。在找解決方法的時候，先森又回頭研究WP Super Cache，這次對WP Super Cache又有了新的領悟，所以趕緊寫篇文章記錄一下。對WP Super Cache新的領悟1.WP Super Cache有兩種緩存機制WP Super Cache 設置->內容里面，點擊列出所有已緩存的文件網頁會刷新出一個顯示框，里面有“最新的 WP-Cached 文件”和“最新的 Super Cached 文件”。之前先森以為都是沒有什么區別，或者說沒弄明白有什么區別。WP Super Cache的兩種緩存經過一番研究終于搞明白，WP Super Cache緩存的內容有兩種，一種是對已知用戶的，一種是對未知用戶的。這兩種緩存文件放置的位置和格式都不相同。其實這一點，先森也發現WordPress大學中，倡萌早有提及。倡萌的介紹比先森自己寫的更規范易懂，但先森也發現有些描述也與現在的插件不吻合了，所以先森自己重新引用整理一下，讓先森自己和更多的人看明白：WP Super Cache 緩存機制有兩種，WP Cache 和 Super Cache。WP Cache 緩存時，會在你的“wordpress 安裝文件夾/wp-content/cache/”文件夾下生成一系列wp-cache-xxxxxx.php格式的文件。而且先森發現，每個不同的已知用戶即使他們訪問同一個頁面，都為單獨的為他們緩存一個新的文件，因為他們的昵稱、郵箱、網址是不同的；為已知用戶緩存Super Cache 緩存時，則在你的“wordpress 安裝文件夾/wp-content/cache/supercache/”文件夾下生成對應每一篇文章或者標簽等的目錄。名稱為xxx.html，取決于你的文章ID是怎么設置。目錄下面就是靜態的 index.html 文件。為未知用戶緩存當你一個訪問者來的你的站點，他沒有登錄或者也沒有留言，這樣他得到是一個在 WordPress cache 文件夾下的 supercache 子文件夾下的純靜態文件，其實你都可以自己到上面的 supercache 目錄下去查看同樣的永久鏈接的 HTML 文件的備份。如果要判斷一個頁面是否已經被緩存了，在頁面中右鍵查看該頁面的源代碼，最后一行會有“Cached page generated by WP-Super-Cache+緩存時間”這行字，就像下面這行代碼一樣：<!-- Dynamic page generated in 0.840 seconds. -->    <!-- Cached page generated by WP-Super-Cache on 2016-04-13 17:48:08 -->而如果你開啟了壓縮頁面，緩存會多一行如下代碼：<!-- Compression = gzip -->判斷網頁是否被WP Super Cache緩存2.WP Super Cache高級設置雜項中的兩個設置的作用搞明白了WP Super Cache的兩種緩存機制之后，加上CDN緩存HTML出現的問題，先森又對WP Super Cache高級設置里，雜項的兩個設置的作業有了領悟。兩個雜項設置的作用上圖紅框中的兩個設置，以前先森不知道這兩個設置所對應的情景是怎樣的，現在終于有所感悟了?！安灰獮橐阎脩艟彺妗钡淖饔谩：苊黠@，開啟之后，在“wordpress 安裝文件夾/wp-content/cache/”文件夾下就不會生成一系列wp-cache-xxxxxx.php格式的文件了。在開啟CDN緩存HTML文件后，緩存期內，誰第一個訪問一個頁面，后來者顯示的都是他打開后顯示的頁面。所以即使繼續為已知用戶緩存，他們也訪問不到為他們單獨緩存的界面。因此，勾選這個選項就很有必要了?！白屢阎脩裟涿顾麄優g覽的內容是緩存文件”的作用。上面也說了，開啟CDN緩存HTML文件后，緩存期內，誰第一個訪問一個頁面，后來者顯示的都是他打開后顯示的頁面。而產生這個問題的原因，就是WordPress會記住評論者的信息，這些人就成為了WP Super Cache中的已知用戶，他們在打開文章的時候，會自動填上昵稱、郵箱等內容。而勾選了這個選項之后，這些已知用戶訪問頁面的時候，會強制匿名，讓他們也成為未知用戶。其實勾選這兩個設置之后，基本能解決CDN緩存昵稱、頭像的問題，但是這樣也導致了已知用戶們每次訪問都會重新輸入一系列信息，對用戶體驗非常之不好。對于這一點，先森也大致找到了解決方法，等研究好了再分享出來。2016年4月22日更新針對CDN緩存問題，先森將近期的解決方法更新上來，有興趣的朋友可以去看看：用cookie解決網站開啟CDN緩存之后已知用戶頭像昵稱被緩存等系列問題用cookie記住用戶信息后隱藏信息輸入框，優化用戶體驗用cookie記住用戶信息后ajax實現實時顯示Gravatar頭像并實時緩存到本地3.緩存的機制這一點的名字可能很多人會沒看懂，其實先森是自己進入了一個牛角尖，沒有對緩存的機制徹底領悟。先森一直在想，WP Super Cache是怎么做到讓訪客訪問的"www.域名.com/*.html"加載的內容變成“www.域名.com/wp-content/cache/supercache/*.html”的呢？也就是怎么讓頁面的內容直接訪問到緩存的內容。開始先森在想，是不是301跳轉什么的，先森記得有個什么隱形跳轉，就是鏈接不變，內容變了。后來先森想明白了，WP Super Cache會將規則寫入.htaccess中，用這個規則進行訪問緩存文件。可能有人會對這第三點感到很不屑，但是先森覺得自己弄明白了一件事，還是非常高興的。

先森很早就發現，手機端查看本站文章，文章里的圖片會產生拉伸問題，即圖片不是等比例縮放，而是高度或寬帶其中一個自適應了，另一個保持不變。這就讓圖片看起來很長或很寬，很影響用戶體驗。而產生問題的原因，經過先森查明，發現是WordPress上安裝的編輯器插件百度UEditor。先森曾經找到了解決新增的文章不再產生拉伸問題的方法，而對曾經發布的文章中的圖片，則束手無策了。畢竟，如果歷史文章少，還好一個一個的改回來。但先森已經發布了近兩百篇文章，一篇一篇的改，太麻煩了。關于怎么使新增文章的圖片不再受到該問題影響的方法，有同樣問題的可以去看看：解決方法：解決使用百度UEditor編輯器后移動端圖片被拉伸問題先森發現，不僅僅是移動端，PC端的圖片其實也有影響，但影響基本不大，不像移動端那么容易被發現。先森文章中的圖片都是被七牛裁剪過的，固定寬度為500px，高度隨寬度自適應，并且還加上了水印。就是這個水印，讓先森在查看歷史文章的時候，發現了UEditor對PC端的影響。圖片有明顯的拉伸感（點擊圖片后按F查看原圖）通過上面的水印，可以看出，整張圖片有明顯的拉伸感。而罪魁禍首，就是圖片<img>標簽中的樣式代碼：style="width: 766px; height: 291px;"而現實在右邊，將這段樣式設置注釋后，圖片就好看多了：圖片恢復正常（點擊圖片后按F查看原圖）近日，先森研究七牛的時候，發現了MySql的結構化查詢語言對處理文章中出現的問題特別有幫助，所以先森就想試試用SQL語言來解決圖片拉伸的問題。接著先森就開始著手研究消除圖片<img>中的style樣式代碼了。因為每張圖片的高度設置都不一樣，所以代碼中肯定要用通配符。百度一下，說MySql中百分號“%”是統配一個或多個字符，果斷把以前常用的替換代碼修改了一下，拿去執行：update `qdm********_db`.`wp_posts` set post_content=replace(post_content,'style="width: %px; height: %px;"','')執行過后，清除緩存，文章刷新，發現并沒有什么卵用。結果百度replace函數，結果網上說這個函數并不能使用通配符。再找解決辦法，百度谷歌了半天，也只找到一個類似的，但是卻還是有些差別。沒辦法，先森只有開始了研究代碼之路。認識MySql代碼首先是replace函數。REPLACE(str,from_str,to_str)返回字符串str中所有出現的字符串from_str替換為字符串to_str。from_str雖然不支持使用通配符，卻可以使用別的函數的返回值。也就是，我們可以用別的函數，通配出變化中的的“style”的高和寬。先森在解決類似問題的文章中認識了兩個函數，CONCAT和SUBSTRING_INDEX。大寫的函數單詞可能會看著比較蛋疼，雖然大小寫并不會影響小型數據處理。但是代碼在執行的時候，都會先把小寫轉換為大寫，再進行執行。所以在寫代碼的時候，直接用大寫會減少執行的時間。當然，這是閑話了。關于這兩個函數的作用，首先是CONCAT。CONCAT(str1,str2,...)--例：CONCAT(成航,先森,...)最后生成“成航先森”返回的字符串參數連接的結果。也就是將str1、str2等各段都合并起來。然后是SUBSTRING_INDEX。SUBSTRING_INDEX(str,delim,count)--例：SUBSTRING_INDEX('www.cnidcc.cn', '.', 1)  會輸出“www”返回的子字符串str計數前出現的分隔符DELIM。如果計數是正的，左側的最后一個分隔符（從左邊算起）的一切被返回。如果計數為負，一切向右側的最后一個分隔符（計數從右側）將被返回。 SUBSTRING_INDEX()執行區分大小寫的匹配時搜索DELIM。這個比較難理解，但是自己把上面的例子拿到數據庫命令窗口去多試幾遍就明白了。整理思路認識了上面的三個函數，該怎么使用呢？我們可以逆推。最終要實現的，是將下面的代碼在表中注刪掉：style="width: 766px; height: 291px;"這個可以使用REPLACE函數，但是這個函數不能使用通配符。所以需要將“width: 766px; height: 291px”用別的函數通配出來。這里可以用SUBSTRING_INDEX函數，以style后面的兩個雙引號為分隔符，將中間的“width: 766px; height: 291px”提取出來。接著在用CONCAT函數將“width: 766px; height: 291px”前面的style="和后面的雙引號連接合并到一起，這樣就將整個“style="width: 766px; "text-indent: 2em;">則解決方法為：提取-->合并-->替換。測試代碼先說明，先森很囧的用SUBSTRING_INDEX把數據庫給毀了，因為錯誤的執行了一行代碼，所有的圖片都沒有了。又沒辦法撤銷。所以把數據庫從備份還原了，還好先森在3月16號才備份了一次數據庫，17號只發布了4篇文章，影響不大。但就算這樣，先森把網站還原也用了近一個小時。所以備份很重要啊，尤其是要對數據庫進行數據處理之前。先森吃了虧，再進行操作的時候就小心翼翼的了。不敢直接拿數據庫動刀，只敢一點點的用測試代碼。復制了一整串受影響的<img>標簽，先森開始了測試。<img title="成都航院正校門" alt="成都航院正校門" src="http://img.capjsj.cn/ueditor/php/upload/image/20150622/1434945153483522.jpg" width="766" height="291" border="0" vspace="0" style="width: 766px; height: 291px;">由于先森的圖片增加了七牛裁剪代碼，所以代碼看著特別長，所以下文先森就在代碼中不寫圖片鏈接了，反正不影響測試。首先，我們需要從上面的標簽中提取圖片的內置寬高設置。而真正執行的時候，需要搜索的對象是整個表，所以先森用分隔符是“style="width: ”，以避免別的style。需要用SUBSTRING_INDEX函數，先森用的代碼是：SELECT SUBSTRING_INDEX('<img title="成都航院正校門" alt="成都航院正校門" width="766" height="291" border="0" vspace="0" style="width: 766px; height: 291px;">','style="width: ',-1);上面的代碼拿到數據庫命令窗口去執行：第一次執行的結果（點擊圖片后按F查看原圖）我們可以看到輸出的結果是：766px; height: 291px;">而這個結果正是所有被搜索對象的分隔符后面所有內容，也就是如果搜索對象是全文的話，這段代碼會輸出分割符后面所有的內容，包括圖像標簽以外文章正文。所以這肯定是還不行的。所以我們需要上面的輸出結果再用SUBSTRING_INDEX函數再提取一次。這次還需要加上上面的代碼，也就是：SELECT SUBSTRING_INDEX(SUBSTRING_INDEX('<img title="成都航院正校門" alt="成都航院正校門" width="766" height="291" border="0" vspace="0" style="width: 766px; height: 291px;">','style="width: ',-1),'"',1);第二次執行的結果（點擊圖片后按F查看原圖）經過兩次的提取后，我們就得到了需要通配符匹配的結果：766px; height: 291px;既然能夠匹配出最麻煩的地方了，接下來也就簡單了。下面我們把需要用來搜索的地方用CONCAT函數鏈接起來。代碼：SELECT CONCAT('style="width: ',SUBSTRING_INDEX(SUBSTRING_INDEX('<img title="成都航院正校門" alt="成都航院正校門" width="766" height="291" border="0" vspace="0" style="width: 766px; height: 291px;">','style="width: ',-1),'"',1),'"');第三次執行的結果（點擊圖片后按F查看原圖）經過復雜的提取和拼湊后，我們得到了需要用來搜索的部分：style="width: 766px; height: 291px;"既然得到了需要用來搜索的部分，在上面的函數外面再套上REPLACE函數就可以了：SELECT REPLACE('<img title="成都航院正校門" alt="成都航院正校門" width="766" height="291" border="0" vspace="0" style="width: 766px; height: 291px;">',CONCAT('style="width: ',SUBSTRING_INDEX(SUBSTRING_INDEX('<img title="成都航院正校門" alt="成都航院正校門" width="766" height="291" border="0" vspace="0" style="width: 766px; height: 291px;">','style="width: ',-1),'"',1),'"'),'');第四次執行的結果（點擊圖片后按F查看原圖）我們看上圖，可以看到，圖片<img>標簽中，內置的樣式代碼已經成功的替換成無了，也就刪除了。當然，到這里，先森都還是測試，能不能成功還要看最后真正的替換。執行代碼通過上面一系列的測試，我們終于可以配置出最終的代碼了：update wp_posts set post_content=REPLACE(post_content,CONCAT('style="width: ',SUBSTRING_INDEX(SUBSTRING_INDEX(post_content,'style="width: ',-1),'"',1),'"'),'')最終代碼執行結果（點擊圖片后按F查看原圖）可以看到，共影響了396行，當然并不是代表著修改了396篇文章。檢驗結果的時候來了，到后臺刪除所有緩存，到前臺打開一些最早發布的文章，一查看，OK，成功的將內置style給刪除了。先森無奈的發現，該方法如果文章中有設置不同寬高的兩張及以上圖片，則只會其中其中一張。如果圖片的寬高數據完全相同，才會全部替換成功。研究各種語言還真是辛苦，還好先森各種語言以前都還多多少少有所學習，以及還好不會用到匯編語言。