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

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

上篇文章解決了WordPress加入CDN后“非插件瀏覽次數(shù)統(tǒng)計”瀏覽次數(shù)不刷新問題，同時留下了兩個未解決的問題：1.按F5可無限制刷新文章訪問量，并影響數(shù)據(jù)庫效率；2.只解決了后臺不更新問題，前臺顯示還是得等CDN刷新后才能更新。那么這篇文章就是為了解決以上兩個問題。問題分析第一個問題，先森想到的解決方法是用JS代碼創(chuàng)建cookies，如果cookies存在就不在更新后臺的統(tǒng)計量。第二個問題，直接讓ajax獲取后臺的訪問量，修改前臺顯示的訪問量就行了。一開始，先森配置的讓ajax多傳一個參數(shù)，是判斷cookies是否存在的，存在為1，不存在為0。若cookies不存在，則后臺訪問量統(tǒng)計就+1，并返回數(shù)據(jù)庫中的瀏覽量并+1。若cookies存在，則后臺不增加訪問數(shù)量，直接返回數(shù)據(jù)庫中的瀏覽量并+1，如此訪客刷新也不會增加訪問量了。但是這樣還是存在會在后臺查詢數(shù)據(jù)的問題，查詢多了對數(shù)據(jù)庫也是一種負擔(dān)。先森之前沒有意識到這個問題，結(jié)果還是晚上睡覺前反思發(fā)現(xiàn)了，且也琢磨除了一個更好的解決方法。直接在JavaScript代碼中加判斷，如果cookies已存在，則直接不向后端服務(wù)器發(fā)數(shù)據(jù)。這樣一來，前端再怎么刷新，也停留在CDN的層面上。那么要實現(xiàn)這種效果，就需要先實現(xiàn)不向后端服務(wù)器發(fā)送數(shù)據(jù)，也能獲取到當(dāng)前文章的訪問量。解決方法很簡單，第一次獲取訪問量時，將后端服務(wù)器返回的訪問量直接寫入cookies，下次刷新時，直接從cookies中讀取訪問量。另外，還有一個地方需要解釋一下，cookies的過期時間。如果cookies時間太長了的話，那么未免還是會損失一些訪問量，所以先森就沒有設(shè)置cookies的過期時間，保持默認。cookies的默認過期為關(guān)閉瀏覽器，先森覺得，這樣一來還是比較合理的。同時，一個訪客，可能并不會只打開本站一篇文章就關(guān)閉，打開多篇文章時，每篇文章的訪問量是不一樣的，需要從cookies中獲取的話，cookies的名稱就必須不一樣。不然訪問打開其他文章，看到了訪問量都是同一個數(shù)值。解決方法就是，已“固定值+文章ID”的方式，確定cookies名稱的唯一。效果實現(xiàn)上一篇文章中，先森是模仿通用的評論ajax提交的處理方式，自建了一個類似的php。但這樣可能有點不安全，也有點麻煩，所以先森還是研究著將php代碼部分放進了主題的functions.php。首先還是在footer.php中添加ajax的代碼，注意需要將前臺顯示訪問量的標(biāo)簽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日更新：感謝網(wǎng)友@魚魚 在評論區(qū)指出的BUG，以前寫上面的代碼的時候參考了wp-postviews插件wp-postviews.php里面的代碼，結(jié)果學(xué)藝不精，只看了上半截，忽略了下半截。錯誤的代碼竟然用了近1年的時間沒發(fā)現(xiàn)，還發(fā)布在這里誤人子弟，實在羞愧。上面的代碼中，錯誤的代碼依然留存著，只是注釋了，修改的方法有兩種，第一種是上面那樣，第二種則是將10-12行的if段改為下方模式（這種就是wp-postviews插件的寫法）：if( defined( 'WP_CACHE' ) && WP_CACHE ) //如果wp-config.php沒有開啟緩存    return;                             //退出（中止函數(shù)的運行）    update_post_meta($post_ID, 'views', ( $post_views + 1 ));注意，如果網(wǎng)站的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();        }}如果想使用有緩存的版本，想要開啟網(wǎng)站緩存，可以選擇安裝緩存插件，或者直接在網(wǎng)站根目錄的wp-config.php中，加入下面這行代碼：define('WP_CACHE', true);如果網(wǎng)站沒有加入CDN，也沒有使用緩存插件，那么有兩個選項：1、Ctrl + D 保存本頁到書簽，待文章變成靜態(tài)頁面后再拿出來看看；2、Ctrl + W 關(guān)閉本頁，因為除非你要研究代碼，本頁對你沒有什么價值，看看更多該看的吧?？偨Y(jié)對于本文的解決方案有什么意見和建議，希望能夠在下方評論欄中提出來，先森覺得還有能夠改進的地方，但一人之力實在有些相形見絀。ajax是個很實用的東西，可能還有更多可以使用的地方，先森也得好好想想。

不知道多少人和先森一樣，在最初接觸wordpress的時候，被網(wǎng)上的各類教程灌輸了“能用代碼版，就不用插件”的概念。先森就本著這個概念，在文章的訪問量的時候，先森就找的代碼版。網(wǎng)上提供的代碼版瀏覽次數(shù)統(tǒng)計功能的文章，名稱都差不多，類似“WordPress非插件添加文章瀏覽次數(shù)統(tǒng)計功能”這種比比皆是。先森應(yīng)該是在wordpress大學(xué)看到的教程，關(guān)于教程先森就不再贅述了。本文主要解決的是，開啟CDN后，用這種代碼版訪問量統(tǒng)計的方式瀏覽次數(shù)不再刷新的問題，如果想結(jié)合著來使用的話，統(tǒng)計代碼部分可以去wordpress大學(xué)看《WordPress非插件添加文章瀏覽次數(shù)統(tǒng)計功能》這篇文章。瀏覽次數(shù)問題分析先森其實很早就意識到，開啟CDN后，其實瀏覽量不是不刷新，而是只在首次緩存的時候才會增加一次。因為只有第一次訪問的時候才會執(zhí)行php，緩存后就直接訪問的html了，所以就不會增加統(tǒng)計了。所以解決問題的方式，是讓html也能統(tǒng)計到瀏覽次數(shù)，先森認知中的方法就只有一個：ajax。然而當(dāng)初先森雖然知道問題原因，知道解決方式，但奈何先森代碼能力不強，當(dāng)時沒能解決。先森始終認為，一個問題如果死活解決不了，那么就先放放，過段時間再反顧可能就會發(fā)現(xiàn)，這個問題根本就不是事。當(dāng)然，這個時間可能就有點久了，起碼就ajax這個問題，先森等了一兩年。。。。先森想到的用ajax更新瀏覽次數(shù)的方法就是，使用ajax提交文章的ID給后方的php，后方的php接收到文章ID后，將該文章的瀏覽次數(shù)+1。效果實現(xiàn)先森研究了一晚上，發(fā)現(xiàn)要解決還是挺簡單的。又是研究幾小時，分享幾分鐘，心塞。首先，在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 ; ?>接收數(shù)據(jù)的php代碼很簡單，參考了評論的comments-ajax.php的頭部，禁止直接訪問，然后加上了幾行更新瀏覽量的代碼。將下面內(nèi)容保存到一個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，文章頁面變成了靜態(tài)頁面，后臺也會更新訪問次數(shù)了?？偨Y(jié)這樣僅僅是解決了文章頁面被緩存后，瀏覽次數(shù)無法被統(tǒng)計到的問題，但是還并不完善。上面的功能實現(xiàn)之后，你會發(fā)現(xiàn)，每一次刷新瀏覽次數(shù)都會加一，如果有人一直按著F5，那么增加的瀏覽次數(shù)就有點恐怖了。這樣還會增加服務(wù)器的負擔(dān)，像先森這種把網(wǎng)站放在阿里云虛擬主機的，若負載過量還會直接關(guān)停，被人這樣搞的關(guān)機先森就哭了。所以，下篇文章先森會分享使用cookies來限制訪問次數(shù)無限增加的問題。另外，除了訪問量持續(xù)增加的問題，還有一個地方可以優(yōu)化。既然ajax能夠異步提交數(shù)據(jù)，那么能不能動態(tài)的修改文章中的瀏覽次數(shù)呢？答案是肯定的，先森也會在下一篇文章中更新。關(guān)于上面的問題，請查看下一篇文章：CDN后用Ajax動態(tài)提交、顯示文章閱讀量，cookies避免重復(fù)刷新

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

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

其實本文著重介紹的不是彩色美化框，而是如何給百度UEditor編輯器增加自定義按鈕。關(guān)于什么是彩色美化框，看過先森前文《WordPress默認TinyMCE編輯器增加彩色美化框自定義按鈕》應(yīng)該都知道的。其實也沒什么，也就是給引用來的文字段加一個更明顯的樣式，就像下面這樣。這是一個綠色提示框這種美化框，各位站長應(yīng)該經(jīng)常能見到，或許你也希望能給自己的WordPress上添加這種美化框。前文已經(jīng)介紹過如何在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');這個短代碼的作用是，在編輯器中輸入如下短代碼后，在前臺打開文章時，會把這些短代碼變?yōu)樯厦嫖覀兌x的blockquote標(biāo)簽：編輯器中的短代碼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個圖標(biāo)鏈接，請將鏈接改為你保存的位置圖標(biāo)素材下載：鏈接: http://pan.baidu.com/s/1bo3ziCB 密碼: chxs(成航先森)只有前期準備是對WordPress主題的代碼添加，后面的步驟都是在UEditor編輯器插件的代碼修改了。UEditor添加按鈕本文參考：百度UEditor官方-UEditor二次開發(fā)-增加一個普通按鈕（上）（下）百度UEditor官方-API文檔第一步:添加按鈕位置在/wp-content/plugins/ueditor/ueditor目錄中，找到ueditor.config.js文件打開，找到ueditor.config.js文件中的toolbars參數(shù)，增加'v_notice', 'v_error', 'v_warn', 'v_tips'字符串，為了方便區(qū)分，我們可以在這四個字符串前加上一個'|'豎線。添加效果如圖：第一步:添加按鈕位置第二步：注冊按鈕實例還是在/wp-content/plugins/ueditor/ueditor目錄中，找到ueditor.all.js文件打開，直接定位到大概第649行，有個數(shù)組如下：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"在數(shù)組中的最后按格式添加第一步中的v_notice v_error v_warn v_tips四個字符串，添加效果如下：第二步：注冊按鈕實例這時候清空緩存刷新下頁面，看看工具欄的對應(yīng)位置是否出現(xiàn)了四個個自己定義的按鈕呢？如下圖所示：新增的4個按鈕由于此時未設(shè)置對應(yīng)按鈕的圖片樣式，所以會顯示默認的“B”字符。要想讓其顯示成自己需要的圖標(biāo)樣式，接著按照下面的步驟動手吧。第三步：更改圖標(biāo)首先是更改圖標(biāo)為默認圖標(biāo)的方法。找到UEditor編輯器插件目錄中的themes/default/ueditor.css文件，末尾增加一條樣式定義:.edui-for-v_notice .edui-icon {    background-position: -700px -40px;}完成后刷新瀏覽器，可以看到此時第一個圖標(biāo)已經(jīng)顯示為如下圖所示：第三步-修改圖標(biāo)此處的樣式定義了showmsg圖標(biāo)在UEditor默認的精靈Icon圖片（themes/default/images/icons.png）中的位置偏移。如需更改成另外圖標(biāo)，只需添加圖標(biāo)到該圖片文件中，然后設(shè)置偏移值即可。先森已經(jīng)將圖標(biāo)添加到icons.png圖片中了（下圖右側(cè)），大家只需要將下圖用新窗口打開，去掉圖片鏈接后面的問號及參數(shù)另存，重命名后替換themes/default/images/icons.png圖片即可：icon圖標(biāo)文件對應(yīng)的，在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;}這時候，重新刷新瀏覽器，應(yīng)該就可以看到如下效果了：更改圖標(biāo)的最終效果第四步：定義按鈕事件處理方法到此為止，在UI層面已經(jīng)完成了一個工具欄圖標(biāo)的顯示，但是我們發(fā)現(xiàn)點擊按鈕之后毫無反應(yīng)。那是必然的，我們還必須為該按鈕綁定屬于它自己的事件處理方法。實質(zhì)上，此時一個默認的事件處理方法已經(jīng)被UEditor綁定到按鈕上了，只不過由于我們還沒有定義該方法的具體內(nèi)容，所以點擊之后無任何變化。下面我們就來定義該方法的具體內(nèi)容：再回到到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+'');}    }};添加后代碼中如下圖：定義按鈕事件處理方法這時候刷新瀏覽器，點擊按鈕，應(yīng)該可以看到以下效果（圖中先森是手動換行）：按鈕功能效果代碼解釋：UE.commands['v_notice']這個表示注冊一個命令。execCommand : function(){}execCommand是UEditor執(zhí)行命令的通用接口。var range = this.selection.getRange();        range.select();        var txt = this.selection.getText();這一串是百度UEditor的ue.selection.getText();或者說是editor.selection.getText();命令的使用方法，其作用是獲得當(dāng)前選中的文本。因為添加了這個命令，所以使用按鈕的時候，可以先將文字寫好，然后選中后點擊按鈕。但遺憾的是選中的文字只能是純文本，如果有鏈接或其他樣式，選中后點擊按鈕也會變成純文字。本來先森研究了半天也沒搞懂editor.selection.getText();命令的使用方法，還是要多謝平平深度文件搜索軟件，先森通過其深度搜索功能，在ueditor文件夾內(nèi)搜索“selection.getText()”，這才找到了使用實例。然后if和else是為了判斷是否選中了文本，最核心的其實就是下面這行代碼：this.execCommand('insertHtml','灰色提示框：輸入文字');這行代碼就是插入HTML代碼，代碼內(nèi)容為“[ v_tips]灰色提示框：輸入文字[ /v_tips]”。更多功能命令，請查看UEditor官方文檔和API文檔。第五步：添加鼠標(biāo)移上按鈕時的提示其實到此為止，給UEditor添加按鈕的功能已經(jīng)完全實現(xiàn)了，但是我們還缺少一個不是那么重要的功能，也就是當(dāng)鼠標(biāo)移到按鈕上的時候給出的提示。在標(biāo)準版本里面，其實第一步里面就已經(jīng)可以添加提示了，但是WordPress for UEditor插件用的是zh-cn這種自動多語言配置，所以我們還需要在翻譯文件中添加提示語言。打開/wp-content/plugins/ueditor/ueditor/lang/zh-cn目錄，打開zh-cn.js文件。在labelMap數(shù)組中添加4個對應(yīng)提示：'v_notice':'綠色提示框', 'v_error':'紅色提示框', 'v_warn':'黃色提示框', 'v_tips':'灰色提示框'添加后zh-cn.js內(nèi)代碼應(yīng)該如下圖：添加鼠標(biāo)移上按鈕時的提示到這里，給WordPress版UEditor編輯器增加四個彩色美化框自定義按鈕就完全實現(xiàn)了。修改版下載可能有些小伙伴看了上文已經(jīng)頭大了，喜歡折騰的可以跟著折騰一番，如果實在不會折騰的，先森也把為寫本教程制作出來的WordPress版UEditor編輯器插件分享給大家：百度云網(wǎng)盤下載：鏈接: http://pan.baidu.com/s/1i5i4M4P 密碼: chxs（成航先森）寫在最后本文一是提供一個給UEditor編輯器添加按鈕的方法，而是添加彩色美化框的方法。先森覺得，有了添加按鈕的方法最為重要，有了方法之后我們可以自定義更多方便的按鈕。先森接下來想做的就是添加下載鏈接的按鈕，讓前臺的下載鏈接顯得更美觀，不像上面那樣光禿禿的一個鏈接。至于彩色美化框，先森覺得選中后會是鏈接什么的被過濾掉實在是個不小的BUG，所以希望未來能將其攻克，也希望有朋友能提供更好的代碼，先森的JavaScript實在太差。

很早以前就在張戈博客那里看到了這么一個工具，當(dāng)時覺得沒有什么用，但后來才知道是自己不知道怎么用。工具的用途是工具的價值體現(xiàn)。在正確的地方，使用正確的工具，就顯得工具非常有實用價值。張哥發(fā)出這個工具是為了解決網(wǎng)站開啟CDN后，評論者的用戶信息不能被保存，每次都要重現(xiàn)填寫的困境。因為是站在了巨人的肩膀上，所以先森很方便的用cookie的方法解決了用戶信息不能被保存的問題，所以當(dāng)時對這個工具不是很在意。但是先森在參加培訓(xùn)的時候的電腦都有還原卡，到各個博客去評論的時候都需要重新填寫自己的信息，就算是復(fù)制粘貼也太麻煩了，所以就想起了這個工具。工具介紹這個工具很簡單，只需要將自己的昵稱、郵箱地址、站點信息在下面填寫好后，點擊生成代碼，即可得到一串屬于自己的代碼。一鍵填寫WordPress評論中用戶信息代碼生成工具使用然后將下面生成的鏈接拖到書簽欄即可保存書簽，使用的時候直接在需要填寫的頁面單擊該書簽即可。老版的瀏覽器可以右鍵鏈接保存為書簽，或者直接Ctrl+D打開一個新建書簽的頁面，自定義書簽名稱，將生成的代碼粘貼進網(wǎng)址欄即可。昵稱(必須)：郵箱地址(必須)：站點：拖拽下面的鏈接到您的書簽工具欄或者右鍵單擊鏈接把它添加到您的收藏夾中可創(chuàng)建一個快速填寫WP評論者信息的快捷方式?？焖偬顚慦P評論信息工具源碼如果你也想要在你的博客中添加這樣一個工具，如果你也想弄一個這樣的工具，只需要將以下代碼粘貼到博客相應(yīng)頁面即可（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;">拖拽下面的鏈接到您的書簽工具欄或者右鍵單擊鏈接把它添加到您的收藏夾中可創(chuàng)建一個快速填寫WP評論者信息的快捷方式。<br /><a href="#">快速填寫WP評論信息</a></p></div>注：該工具只適合于WordPress博客程序創(chuàng)建的網(wǎng)站。如果要適用其他博客，需對JS代碼中對應(yīng)的ID進行修改。

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

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