關于為何要接入CDN，而且是全站接入CDN，先森就不在贅述了，這些在寫接入騰訊云的時候就已經寫過了。關于VeryCloud，先森其實以前也沒聽說過，但是為了緊跟張戈博客張哥的腳步，先森也跟著做了。關于先森接入騰訊云CDN的過程，希望大家也能看看：全站CDN緩存加速之接入騰訊云用了兩天的VeryCloud，先森對它是有愛有恨。愛的是VeryCloud的售后工程師真的很好。VeryCloud雖然也有系統，但先森第一次使用的是他們的企業QQ，所以后面就一直用的企業QQ和售后交流。先森先后遇到了3個售后工程師，可能他們的售后都被先森問了個遍吧。三個售后都非常好，可能先森的問題已經要把他們逼瘋了，卻依舊能很好的應對。先森有時還問了一些不是他們VeryCloud的問題，他們也會對先森做出指導。但是，無論先森怎么設置VeryCloud的CDN，總是沒能達到預想的成果。先森的靜態文件放在七牛的，所以不需要VeryCloud的CDN緩存。開始沒有在意，先森想著VeryCloud和七牛兩個都把靜態文件緩存一邊挺好的。但后來一想，這樣會導致七牛鏡像會從CDN鏡像，而CDN鏡像會對文件進行一些壓縮，尤其是圖片，這樣會導致最終展示的圖片清晰度減小，所以最后把靜態文件緩存關了。也不知道這樣的理解對不對，但是確實也導致了第一天七牛無法回源，顯示：{"error":"get from image source failed: E502"}，而頭部的返回解析狀態碼則顯示478。各種地方尋求幫助，把顯示逼瘋了，結果還是自己好了。然后七牛的工單有反應了。。。而先森想要達到的效果，是網頁代碼，讓VeryCloud進行緩存，而靜態文件，則讓七牛緩存。然而根據先森的理解，并沒有實現。好吧，廢話了這么多，回歸主題，先森再談談VeryCloud。VeryCloudVeryCloud非常給力，每個月都是50G的免費CDN流量。而對于我們這種網站本身服務器流量每個月10G都用不完的來說，簡直多的不能再多了。反正先森用了3天，也沒用幾百兆流量。使用流量很慢怎么接入什么的，在其網站上幫助里面都寫的很清楚了，先森也就不班門弄斧了。重點是緩存設置，先森是按照自己的想法設置的，而感覺實際生效情況卻沒有跟著先森的想法走。先森的想法是，后臺不緩存，前臺的今天資源不緩存，只緩存HTML界面以及WP Super Cache的緩存目錄。所以先森是這樣設置的：VeryCloud緩存設置若有網友知道怎么設置能夠實現先森想法的配置，還請指明。先森問了售后工程師，VeryCloud的緩存策略也是有優先級的，這點在其設置中沒有明確指出。優先級別是從上到下，越上面的越優先。這兩天鼓搗CDN，讓先森新get到的技能，就是看網頁的頭信息，也就是按F12到network里面去看header中的信息。CDN緩存設置中的是否遵循源站，源站的規則，在這里就能夠看到?？搭^部信息，CDN方面最重要的就是看緩存的命中情況。先森也是詢問售后工程師之后，才知道了怎么查看VeryCloud的命中情況。VeryCloud命中情況查看VeryCloud命中情況，是通過查看頭部信息中響應抱頭的'Powered-By-VeryCDN'項，如上圖紅框“Powered-By-VeryCDN:MISS from cuc-xg-1-1-c1761, MISS from utn-ho-1-1-c17a1”。先森還框住了兩個'MISS'。在這里，MISS代表著沒有命中緩存，回源。而如果命中緩存，則顯示HIT?？梢钥吹?，先森這里顯示的是MISS。而這里的兩個MISS，第一個MISS代表著從瀏覽器到CDN命中緩存失敗，第二個MISS顯示從CDN到源站服務器命中緩存失敗。先森無論刷新多少次，HTML的緩存命中都是MISS了的。但奇怪的是，VeryCloud中的統計情況又顯示HIT遠遠超過MISS：VeryCloud緩存命中統計VeryCloud管理功能讓先森用著有點沒頭腦，經過售后工程師的解釋，先森才明白，那個列表不是顯示緩存到的文件目錄，而是刷新紀錄。先森還是沒把對象存儲和CDN加速區分開，這是深受七牛影響。。。VeryCloud內容刷新先森嘗試著刷新了一波，讓先森想起了一件有點郁悶的事情：VeryCloud內容刷新-提交刷新這里的來源顯示的是來自API。張哥提醒過，VeryCloud的API沒有開放，需要的時候要直接向客服索要，先森去要的時候卻遭遇了清明節——放假，著實有點郁悶?？偨Y對于CDN，先森是沒有怎么搞明白的，每次感覺搞明白了，卻又會被現實潑了冷水。先森是打算轉戰百度云加速了，近期會做嘗試。寫本文的期望就是希望能讓和先森一樣的小白能吃點經驗，少走一些彎路，雖然這些對大神們來說是基礎，但先森希望能給未來的大神們奠定奠定基礎。另外，解析搜索引擎線路的時候，真的不能使用萬網解析，萬網解析的非常不準確，先森將域名解析轉至了DNSPod，百度抓取診斷馬上就準確了。而且DNSPod解析線路非常豐富，幾乎囊概了所有的搜索引擎，而且還有一條名為“搜索引擎”的線路。不知道怎么轉出萬網？將萬網/阿里云域名DNS地址修改到DNSPod

先森一直在用的CDN是七牛云儲存，而且緩存的只是靜態資源，也就是沒有開啟全站緩存。先森之前覺得全站緩存麻煩，所以就沒有使用各種CDN提供的全站緩存。但是近日在張戈博客上逛的時候看到張哥提出網站不要暴露真實IP的種種重要性，先森被震驚了。先森常常聽到的名詞DDOS，其中有一種攻擊方式叫做CC攻擊的，就是我們小站經常受到的攻擊。雖然不是很懂，先森的小站目前也沒有收到共類似攻擊，但是先森也怕遇到這種情況。關于暴露真實IP的危險性，強烈建議類似先森這種懵懂的小站長們看看張戈是怎么說的：淺談個人博客網站or屌絲vps服務器暴露真實IP的危險性真實IP和本文要說的騰訊云CDN有什么關系呢？不暴露真實IP，我們要做到兩點：1.我們自己不在網站上泄露公開真實IP；2.訪客訪問時隱藏真實IP。第一點的意思，就是我們在運營網站時，發布文章、圖片什么的，不主動將自己的真實IP泄露出來，該打碼的要打碼。第二點，就是讓人無法掃描到你的真實IP。而隱藏真實IP的常用方法就是使用CDN。張戈提出，他主要使用了三種CDN：騰訊云、VeryCloud以及七牛CDN。其中騰訊云負責電信線路流量，VeryCloud負責默認線路流量，而七牛主要是用于縮略圖展示。先森不怎么在行，所以緊跟大神腳步，先把CDN摸熟。張戈使用騰訊云的原因是可以申請安全認證，這個認證也就是在QQ聊天中，你的網站會加上綠色的安全勾勾。然而先森在接入后卻發現，選擇“主營業務”的時候，并不能選擇，也就不能申請了。當然，這是后話了。注冊騰訊云首先就來到了騰訊云中介紹其CDN業務的頁面，騰訊云還專門對CDN的概念做了一個簡單的解釋：內容分發網絡 CDN當然，站長們肯定都已經對CDN有了或多或少的認識，我們所關注的，是其是否免費，免費的話，免費配置是怎樣的。網頁拉到最下，先森找到了優惠的地方。騰訊云-內容分發網絡CDN優惠情況騰訊云的體驗方式和七牛、百度云加速的不一樣，不是能夠直接按照每個月的份額長期免費下去，而是直接獲得6個月共300G的流量包。對于小站來說，完全夠用了。至于6個月的問題，先用著吧。還有一點，國內的CDN也都是這樣，接入的網站需要備案。注冊賬號什么的就不多說了，重點是還需要進行一些資質認證，才能夠領取那6個月的300G流量包。果然免費的東西不好拿。但是認證起來還是很方便的，先森也就順手把能認證的都認證了。各種認證除了能領取那6個50G的流量包，還附贈了8張價值260元的代金券，這一點倒是能夠留住一些真心愿意用騰訊云的人。先森應該就用不上了。騰訊云代金券接入騰訊云1.廢話了這么多，現在開始將網站接入騰訊云了。首先填寫基本信息，真實IP先森也就不寫出來了（點擊圖片放大）：接入-填寫基本信息2.接下來就是重點，填寫配置信息了。這里的是否過濾參數還要看自己網站的實際使用情況了，先森選擇的是不開啟，也就是不勾選。緩存過期設置對我們來說非常重要，雖然這是可選項。這里可以選擇設置非常多的規則，而不像百度云加速免費版只能設置3條規則。首先我們設置CDN要明確一點，那就是我們WordPress后臺不能緩存，或者說不能全部緩存。所以，先森首先選擇的就是禁止緩存后臺的文件夾。騰訊云的不緩存的方式為將刷新時間設置為0秒。對于其他，先森就不怎么會設置了，也就隨便設置了一下。下面的截圖中有一個設置沒有截在里面，也就是防盜鏈。對于這個設置，先森暫時還用不著，所以就不做設置了。填寫配置信息先森還是將自己的配置貼出來，如果有什么錯誤，希望有人能夠提出幫助先森改正：緩存過期配置對于上圖，先森做些解釋?！案呒壘彺孢^期設置”指的是繼承源站http cache_control，默認是不繼承，先森這里選擇了繼承。下面的配置項有優先級，列表越下面優先級越高。這些在圖中的那個“如何設置緩存時間？”里都有介紹。3.確認信息。這點沒有什么說的，就是將你的所有設置總覽一邊，確認無誤后提交，騰訊云這邊的設置就完成了。騰訊云域名管理4.提交之后，騰訊云首先會在狀態一欄顯示“部署中”，但無須在意，騰訊云部署的時間大概要幾分鐘。同時我們得到了上面的CNAME，這里先森的是www.cnidcc.cn.cdn.dnsv1.com 這里我們就需要去自己的DNS服務商那里配置解析了。先森用的是阿里云免費版云虛擬主機，解析用的是萬網。域名解析上圖可以看到，先森將騰訊云的CNAME解析到了電信線路，這點和張戈保持高度一致。雖然不知道先森這樣有什么用，但是感覺不弄的話，騰訊云就沒什么用了。因為先森僅僅解析了電信線路，所以還沒有將解析到服務器真實IP的a記錄關停。眼尖的可以看到，上圖除了有騰訊云的解析，先森還做了三個搜索引擎的解析。解析的地址是服務器的真實IP。這樣的好處是，搜索引擎不會解析到你CDN的IP，保證IP地址是自己的真實IP。因為CDN的IP是經常換的，如果讓搜索引擎訪問這樣的IP會引起不好的影響。這點，張戈提醒了很多次?？上f網只提供了百度、谷歌和必應3條搜索引擎的線路，沒有多提供一條包括所有引擎的“搜索引擎”線路。但先森也沒法了，好搜、搜狗什么的，就看造化吧?？偨Y1.不忘初心，我們小站沒什么流量，不怕流量不夠用。使用CDN的原因是為了隱藏真實IP。2.CDN配置的時候最重要的一點就是后臺地址不緩存或者不全緩存。其他要注意是否會使需要動態請求的地方失效。3.解析地址的時候，記得要單獨解析搜索引擎線路。所有線路都接到CDN后可以把a類解析關了。4.先森還會寫接入verycloud CDN的經過。

先森曾發文說本站設置了全站鏈接為新頁面打開，然后發現這樣對用戶體驗不好，個別鏈接需要本頁面打開。上次為大家分享了歸檔頁分頁頁面實現本頁面打開，而這次先森要修改的是文章頂部評論統計部分的鏈接。優化：讓你的wordpress在新窗口打開鏈接WordPress整站鏈接新窗口打開模式下指定鏈接本窗口打開訪客通過點擊該鏈接，可以直接跳過文章內容，到達評論區。而現在的情況是，訪客點擊之后，會新頁面打開本文，再跳置評論區。想一想就知道這對用戶體驗有多不好了。評論統計-搶個沙發本以為這很簡單，直接在鏈接中添加一個target="_self"就行了，結果查看single.php的時候發現，a標簽是調用的comments_popup_link函數直接輸出的。當時先森就懵逼了，怎么搞？其實先森心里知道，這次先森終于要開始接觸WordPress的鉤子HOOK了。以往都是直接百度找能實現功能的代碼，然后直接復制到functions.php，現在終于要自己做功能實現的代碼了，想想還有點小激動。以往都是直接百度找能實現功能的代碼，然后直接復制到functions.php，現在終于要自己做功能實現的代碼了，想想還有點小激動。通過一兩個個小時的摸索，總算了解了一點add_action和add_filter兩個常用鉤子函數。關于鉤子函數等詳細內容，想要學習的可以將WordPress大學中WordPress開發部分好好研讀，先森也準備先馬后看。WordPress大學： WordPress開發去官網查找和comments_popup_link有關的過濾器，共有兩個結果，一個就是介紹該函數的功能，另一個就是我們需要用到的comments_popup_link_attributes。comments_popup_link_attributes過濾器comments_popup_link_attributes過濾器的作用是過濾評論輸出的鏈接顯示的屬性，也就是通過該鏈接我們可以給評論統計鏈接添加屬性。這里我們要加的屬性是“target="_self"”。將以下代碼加入functions.php中即可：/***給comments_popup_link函數（顯示評論數量）的a標簽添加本頁跳轉**//www.cnidcc.cn/w_wp_pltjljtj_target_sx.html*/function comment_a_self() { return ' target="_self"';}add_filter('comments_popup_link_attributes', 'comment_a_self');非常簡單的代碼，卻也是先森跨出的WordPress開發第一步了。

不知道這種古怪的需求有多少市場，反正先森是正好需要了。近期網站樣式改版，發現友鏈的內頁展示頁和申請頁竟然是分開的，這樣很不方便，就想把兩個內容進行合并。友情鏈接內頁展示頁是用的頁面，而友鏈的申請頁用的是文章頁。就功能上來說，肯定是將文章頁刪除，申請友鏈的內容并入友鏈內頁中了。那么問題來了，申請友鏈頁的評論，也就是站長朋友們的申請，不想讓其受損，怎么轉移呢？這就產生了對轉移評論的需求。開始先森想的是，新版的內頁展示+申請做好之后，自己在下面按照站長們的昵稱、郵箱、網站評論一次，后面再改數據庫中的評論時間。但是細想，既然還是要動數據庫，那為什么不在數據庫里完成這一系列的操作呢？先森數據庫沒學好，所以是很不愿意動數據庫的，因為一不小心就很全毀，又不好撤銷操作。所以奉勸各位，數據庫操作之前一定要備份。轉移評論1.查看ID先找到要相互轉移評論的兩篇文章/頁面，先查看兩篇文章/頁面的ID號，記住。如果不知道怎么查看，還請自行百度。2.操作wp_comments數據表打開熟悉的數據庫界面，在數據表中打開wp_posts、wp_comments兩個表。首先看wp_comments數據表。每個表都有很多個字段，這個表我們主要看comment_post_ID字段。這個字段記錄的是評論的文章ID，也就是第一步中我們找到的ID號。wp_comments數據表直接使用旁邊的篩選，查找需要將評論轉移走的文章/頁面ID。找出來之后，將comment_post_ID的值改為需要轉移到的文章/頁面ID。修改完之后，點擊提交保存修改。3.操作wp_posts數據表雖然上面修改了，但是先森發現刷新頁面還是沒有產生變化，經檢查，還需要這第三步。打開wp_posts數據表，依舊是用旁邊的篩選，查找需要將評論轉移走的文章/頁面ID。直接查看結果中的最后一個字段comment_count。數據庫wp_posts表轉移評論的文章comment_count字段記錄的是文章的評論數量，我們要將這里的記錄值手動的改為“0”。其實這里不改也可以，反正先森后面會將這篇文章刪除。重點是要記住這個值，然后篩選出另外需要將評論轉移過去的文章/頁面。數據庫wp_posts表評論轉移到的頁面這里comment_count字段記錄的值為零，所以我們要將其改為之前的文章的評論數量“10”。修改之后，點擊下面的提交修改，即完成了對評論的轉移。也歡迎大家查看、申請我的友鏈：友鏈展示|申請：申請友鏈

先森曾轉載過一篇鳥叔轉載的文章，這篇文章的內容是分別將WordPress后臺、訪客評論鏈接、友情鏈接設置為在新窗口打開，和一個大招，非常簡單的代碼讓網站上所有鏈接都在新窗口打開。有興趣的可以去看看：優化：讓你的wordpress在新窗口打開鏈接為WordPress評論統計鏈接添加target屬性本文主要講的是，如何在上文中所說的大招情況下，讓部分鏈接能夠在本窗口打開。這個大招非常霸道，但是設置起來卻非常簡單，上文中的描述都很少：設置全站鏈接在新窗口打開其中的重點，也就是加入紅框內的代碼。其實就是將所有鏈接的打開方式target設置成了_blank，這個屬性，我們在單獨設置鏈接的時候也時常用到。這樣設置的好處是，你不用再一個一個的給鏈接添加該屬性，訪客也不容易直接跳出你的網站。但是缺點也是顯而易見，訪客在訪問你的網站時，每點擊一個鏈接都會新開一個窗口，要是窗口打開多了，會讓人感到厭煩。所以先森這次想要實現的目標是，自己設置一些鏈接，能夠讓其不受<base target="_blank">的影響。不是所有的鏈接都需要設置新窗口打開，本次先森就拿文章列表歸檔頁的頁碼下手。解決問題首先，先森從百度了解到，在設置了<base target="_blank">之后，單獨給鏈接設置target="_self"之后，鏈接就會變成本窗口打開。這樣當然簡單，但是本次先森還要將其用到歸檔頁的頁碼中，沒想到還遇到一點問題。關于歸檔頁的頁碼，先森用的是倡萌提供的代碼。需要的可以參考下：WordPress 非插件實現文章列表分頁導航其中核心的代碼就是在functions.php中添加以下代碼，然后調用即可：function par_pagenavi($range = 9){ global $paged, $wp_query; if ( !$max_page ) {$max_page = $wp_query->max_num_pages;} if($max_page > 1){if(!$paged){$paged = 1;} if($paged != 1){echo " 返回首頁 ";} previous_posts_link(' 上一頁 ');    if($max_page > $range){ if($paged < $range){for($i = 1; $i <= ($range + 1); $i++){echo "$i";}}    elseif($paged >= ($max_page - ceil(($range/2)))){ for($i = $max_page - $range; $i <= $max_page; $i++){echo "$i";}} elseif($paged >= $range && $paged < ($max_page - ceil(($range/2)))){ for($i = ($paged - ceil($range/2)); $i <= ($paged + ceil(($range/2))); $i++){echo "$i";}}}    else{for($i = 1; $i <= $max_page; $i++){echo "$i";}} next_posts_link(' 下一頁 ');    if($paged != $max_page){echo " 最后一頁 ";}}根據鏈接打開方式的規則，可以很簡單的完成代碼的改造。上面輸出了很多種的a標簽，我們只需要在里面加入target=_self即可。但是，這些都很好解決，上面的代碼中還有兩個不同的代碼，它們是自動輸出a標簽，不需要再次添加：previous_posts_link(' 上一頁 ');next_posts_link(' 下一頁 ');就是“上一頁”和“下一頁”這兩個代碼。這是WordPress自帶的函數，括號里的是要顯示的文本，而整個輸出，則直接是一個a標簽。關于用法，大家自行百度。那么問題就來了，這樣先森就不能直接在a標簽中加本窗口打開的代碼了呀。百度后了解到，還有另外兩個函數：get_previous_posts_link();get_next_posts_link();這兩個函數的用法和去掉“get_”的用法一樣，但是不會直接輸出，在前面加輸出“echo”后就和不加“get_”的完全一樣了。先森沒有找到能夠直接獲取a標簽中上一頁與下一頁鏈接的方法，只知道上面兩個函數。沒辦法，曲線救國，先森想到了替換。PHP替換函數，先森曾經介紹過：替換函數：PHP str_replace() 函數 點擊可以學習函數的用法，這里先森就不累述了。直接貼出最終的代碼;//文章分頁代碼function par_pagenavi($range = 9){ global $paged, $wp_query; if ( !$max_page ) {$max_page = $wp_query->max_num_pages;} if($max_page > 1){if(!$paged){$paged = 1;} if($paged != 1){echo "<a href='" . get_pagenum_link(1) . "' class='extend' title='跳轉到第一頁' target=_self> 首頁 </a>";} $previous_posts= get_previous_posts_link(' 上一頁 '); $tihuan_i=1; echo str_replace(">"," title='跳轉到上一頁' target=_self>",$previous_posts,$tihuan_i);    if($max_page > $range){ if($paged < $range){for($i = 1; $i <= ($range + 1); $i++){echo "<a href='" . get_pagenum_link($i) ."'"; if($i==$paged)echo " class='current'";echo " target=_self>$i</a>";}}    elseif($paged >= ($max_page - ceil(($range/2)))){ for($i = $max_page - $range; $i <= $max_page; $i++){echo "<a href='" . get_pagenum_link($i) ."'"; if($i==$paged)echo " class='current'";echo " target=_self>$i</a>";}} elseif($paged >= $range && $paged < ($max_page - ceil(($range/2)))){ for($i = ($paged - ceil($range/2)); $i <= ($paged + ceil(($range/2))); $i++){echo "<a href='" . get_pagenum_link($i) ."'";if($i==$paged) echo " class='current'";echo " target=_self>$i</a>";}}}    else{for($i = 1; $i <= $max_page; $i++){echo "<a href='" . get_pagenum_link($i) ."'";    if($i==$paged)echo " class='current'";echo " target=_self>$i</a>";}} $next_posts= get_next_posts_link(' 下一頁 '); echo str_replace(">"," title='跳轉到下一頁' target=_self>",$next_posts,$tihuan_i);    if($paged != $max_page){echo "<a href='" . get_pagenum_link($max_page) . "' class='extend' title='跳轉到最后一頁' target=_self> 最后一頁 </a>";}} else {echo '<a href="javascript:;">共1頁</a>';}}修改代碼->保存->檢查->OK:代碼生效先森目前發現需要本窗口打開的鏈接還僅僅是頁碼，以后也許會陸陸續續的修改很多，這里也就不再多說了。

先森很早就發現，手機端查看本站文章，文章里的圖片會產生拉伸問題，即圖片不是等比例縮放，而是高度或寬帶其中一個自適應了，另一個保持不變。這就讓圖片看起來很長或很寬，很影響用戶體驗。而產生問題的原因，經過先森查明，發現是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給刪除了。先森無奈的發現，該方法如果文章中有設置不同寬高的兩張及以上圖片，則只會其中其中一張。如果圖片的寬高數據完全相同，才會全部替換成功。研究各種語言還真是辛苦，還好先森各種語言以前都還多多少少有所學習，以及還好不會用到匯編語言。

先森建站初始，WordPress寫文章非常隨意，幾乎是一篇文章新增一個標簽，任性的不要不要的?，F在很少增加標簽了，一般都是規劃好文章分類。最新做了很多和七牛相關的變更，所以想著干脆新增一個“七牛”標簽。先森前幾天把文章、分類、標簽名稱自動添加拼音別名的插件Pinyin Permalinks刪了，覺得沒什么用。結果增加標簽的時候發現，打開七牛標簽是“tag/七?！钡膸е形牡刂?，結果打開不了，趕緊去增加了別名。結果再次刷新，錯誤500，瀏覽器提示：“網站在檢索此網址時出現錯誤。托管此網站的服務器可能關閉進行維護或配置不正確。”當時我就懵逼了：發現問題，就要解決問題。趕緊百度找原因，結果百度半天，沒能找到問題原因和解決辦法。看到別人寫的錯誤500的分析，說可能是插件沖突、緩存插件、.htaccess文件等等原因。先森首先想到的就是Pinyin Permalinks插件，因為以前刪除這個插件的時候，導致最早的一些文章無法訪問，后來解決了，也就把插件刪了。Pinyin Permalinks插件看張戈博客中提到的刪除插件導致頁面404的文章，說將后臺設置-固定鏈接隨便換為默認的幾種固定鏈接的一種，再換成自定義鏈接，就可以解決了。但是先森嘗試了一番，并沒有什么卵用。張戈博客說，將刪除的插件重新裝回，能訪問成功。然而先森重裝上之后，發現還是并沒有什么卵用。后來先森又懷疑是.htaccess文件被修改了的原因，結果反復嘗試之后，發現也沒能解決問題，有次還把除首頁外的網頁全變成404，無語。。。先森繼張戈博客留言、開發者論壇提問無果后，準備把WordPress重裝了。重裝前覺得網站應該還能搶救一波，所以把WordPress的開發者調試模式打開了，沒想到真的解決問題了。從WordPress的根目錄下載wp-config.php到本地，修改第72行，define('WP_DEBUG', false)改成true。并添加ini_set('display_errors','Off')：開啟DeBug調試模式不知道怎么回事，先森從FTP軟件FileZilla中下載服務器文件，內容都會每行被增加一個換行。開啟之后，再去刷新tag標簽頁面，密密麻麻的，還真有點暈。DeBug調試tag標簽頁研究了一下，發現重點是最后一句：“Parse error: syntax error, unexpected ';' in /data/home/************/htdocs/wp-content/themes/jiage-V2.9/tag.php on line 21”也就是先森的主題中標簽模板的第21行有語法錯誤。先森直接在后天編輯主題，看了半天沒發現問題。本地新建了一個php空頁，把代碼復制過去果然有問題。第21行語法錯誤最后發現的問題讓先森哭笑不得，結果就是最近整改標簽頁的時候不小心加了一個括號，還不是在本地測試的時候添加的，是直接在WordPress后臺將調試好的代碼復制過去的時候添加的。WordPress后臺編輯主題沒有代碼高亮，沒有錯誤提示，大家編輯的時候一定要小心一點啊。最好還是在本地調整代碼，最后直接復制整篇代碼。對了，找出原因之后，修改->測試->問題解決，一定還要記得把wp-config.php中的修改改回來。

近期先森對WordPress和七牛研究的比較勤，折騰了很多，其中很多都是和七牛有關的。七牛的裁剪功能確實好用，但是先森為縮略圖（文章下面相關文章的圖片）和文章中的圖片都加上七牛裁剪代碼后，就發生了沖突。關于為縮略圖和文章圖片添加七牛裁剪代碼，大家可以先看看這些文章：1.七牛代碼如何使用：WordPress調整Tag標簽頁文章列表縮略圖優化小記2.已發布的文章添加代碼：將WordPress歷史文章中所有圖片加上七牛裁剪水印代碼其實，發生沖突是必然的事情。首先，縮略圖調用的圖片，是從文章中調用圖片鏈接。圖片鏈接獲取的優先順序是：自定義字段為 thumb 的圖片>特色縮略圖>文章第一張圖片>隨機圖片/默認圖片。也就是只有文章中沒有圖片時，才會調用你設置的隨機圖片。而文章中的圖片，先森已經全部加上了七牛裁剪代碼。調用這些圖片鏈接的時候，鏈接里面實際上已經有一段七牛裁剪代碼了。這將導致，縮略圖調用的時候在后面增加的裁剪代碼會重復加在后面，而七牛的規則是只生效前面的一段，也就是縮略圖的裁剪失效了，你調用縮略的時候還是更大的圖片，沒有達到裁剪縮小圖片體積的目的。加上了兩段七牛裁剪代碼前期準備這種情況，整理了一下思路，總結了下解決方案。增加判斷，如果圖片鏈接中含有裁剪代碼，則替換成新的裁剪代碼；如果不包含，則直接在鏈接后面添加裁剪代碼。要用兩種函數，查找和替換。先森在w3school里找到了這兩種適合的函數，要了解的可以看看：查找函數：PHP strpos() 函數替換函數：PHP str_replace() 函數除了準備這兩個函數，如果是使用WordPress大學中的縮略圖調用代碼的同學，還要修改下代碼?？s略圖調用：WORDPRESS添加相關文章功能（標題/縮略圖樣式）WordPress大學提供的代碼，是加在functions.php中的，調用的時候可以直接輸出圖片鏈接：//添加特色縮略圖支持if ( function_exists('add_theme_support') )add_theme_support('post-thumbnails'); //輸出縮略圖地址 From wpdaxue.comfunction post_thumbnail_src(){    global $post; if( $values = get_post_custom_values("thumb") ) { //輸出自定義域圖片地址 $values = get_post_custom_values("thumb"); $post_thumbnail_src = $values [0]; } elseif( has_post_thumbnail() ){    //如果有特色縮略圖，則輸出縮略圖地址        $thumbnail_src = wp_get_attachment_image_src(get_post_thumbnail_id($post->ID),'full'); $post_thumbnail_src = $thumbnail_src [0];    } else { $post_thumbnail_src = ''; ob_start(); ob_end_clean(); $output = preg_match_all('/<img.+src=['"]([^'"]+)['"].*>/i', $post->post_content, $matches); $post_thumbnail_src = $matches [1] [0];   //獲取該圖片 src if(empty($post_thumbnail_src)){ //如果日志中沒有圖片，則顯示隨機圖片 $random = mt_rand(1, 10); echo get_bloginfo('template_url'); echo '/images/pic/'.$random.'.jpg'; //如果日志中沒有圖片，則顯示默認圖片 //echo '/images/default_thumb.jpg'; } }; echo $post_thumbnail_src;}因為要對圖片鏈接增加查找，所以上面代碼中，最后幾行的輸出可不能要，這樣是判斷不了的。需要將上面的最后五行的"echo"換成"return"，即： return get_bloginfo('template_url').'/images/pic/'.$random.'.jpg'; //如果日志中沒有圖片，則顯示默認圖片 //echo '/images/default_thumb.jpg'; } }; return $post_thumbnail_src;}解決方法準備齊全之后，就可以解決問題了。之前，先森是這樣調用相關文章的圖片的： <img src="<?php echo post_thumbnail_src(); ?>?imageView2/1/w/130/h/100/q/100" alt="<?php the_title(); ?>" class="thumbnail" />那么，現在為了解決重復代碼的問題，需要將上面的代碼換成下面的內容：<?php     $imgsrc = post_thumbnail_src();    $qiniu_dengxiang='imageView2/2/w/500/q/100|watermark/1/image/aHR0cDovL2ltZy5jYXBqc2ouY24vY2FweHNfMi5wbmc=/dissolve/80/gravity/SouthEast/dx/5/dy/4';    $qiniu_xiangguan='imageView2/1/w/130/h/100/q/100'; if(strpos($imgsrc,$qiniu_dengxiang)){?>            <img src="<?php echo str_replace($qiniu_dengxiang,$qiniu_xiangguan,$imgsrc);?>" alt="<?php the_title(); ?>" class="thumbnail" />           <?php }        else{?>            <img src="<?php echo post_thumbnail_src(); ?>?imageView2/1/w/130/h/100/q/100" alt="<?php the_title(); ?>" class="thumbnail" />        <?php }?>修改保存之后，檢查一番，發現問題確實得到了解決：只增加了一次七牛裁剪代碼同理，側邊欄的最新文章縮略圖也可以這么修改，先森也就不累述了。

關于WordPress發布文章怎么同步推送到微博，先森很早以前就已經分享過了。但是文中也提到，先森申請微博高級寫入接口時，卻遇到了閉門羹。開始先森以為是剛申請的原因，可能是通過微博點擊進入網站的人不多，所以申請失敗。所以先森在開啟同步后幾個月又重新申請了一次，結果還是失敗了。這樣先森就沒轍了，所以干脆就沒管了。先森在有一次申請的失敗的時候，也曾找過原因，但沒有找到。所以就去了分享同步推送微博方法的提供者，張戈博客那里留言。這段時間先森在張戈博客那里比較活躍，所以張大哥也破天荒的回答了我1月份提出的問題：張戈博客的回復郵件張戈提出，可能是和微博粉絲數量有關。這一句話，讓先森恍然大悟。在這里再次感謝張戈張大哥。有了方向，先森就知道往哪里努力了。打開微博，先森發現，先森的微博@成航先森 才80+的粉絲，果然有點拿不出手。所以開始了一系列的刷粉。開始漲的很慢，但是當先森找到了方法后，兩天的時間，讓粉絲增加到了350左右。關于短期內如何快速漲粉，以及如何同步發布文章到微博，先森都做了分享：WordPress發布文章自動同步到新浪微博詳細方法微博短期內快速漲粉先森的做法本來這次先森的目標是1000+的，想粉絲上千后再申請一下試試。但到了350左右先森又嘗試申請了一下，沒想到就申請成功了。微博高級寫入接口申請成功額。。關于上圖的微博高級讀取接口，是先森申請的時候申請錯了，請忽略。下面，重要的事情說三遍：微博關注@成航先森！微博關注@成航先森！微博關注@成航先森！

最近先森在對網站進行改版。說起來，改版的原因就是想給文章頁側邊欄的最新文章列表添加縮略圖。但是一看發現，側邊欄的寬度不夠。然后去研究大神們的網站是怎么做的的時候，發現大神們的網站會根據瀏覽器的寬度進行自適應。先森對側邊欄拓寬之后就開始研究自適應，這一研究就一發不可收拾。關于怎么自適應就不多說了?，F在為什么想給側邊欄的最新文章添加縮略圖，就是因為以前的樣式實在是太丑了。雖然先森的網站現在沒有多少人看，但是人要臉樹要皮，要把自己最好的一面展示給觀眾嘛。我來將以前的“最新文章”樣式貼出來，大家與現在旁邊的樣式對比，隨便感受一波：以前的“最新文章”代碼實現-方案1有了樣式的想法之后，先森就開始搜索實現方法了。但是百度一查， 寫這方面的文章的文章好像并沒有很多，熟悉的幾位大神也都沒有寫這方面的文章。其他寫實現方法的文章還有很多是重復轉載的。后來先森找到一種可以帶縮略圖的“最新文章”列表方法：<ul><?php $result = $wpdb->get_results(“SELECT ID,post_title FROM $wpdb->posts where post_status=’publish’ and post_type=’post’ ORDER BY ID DESC LIMIT 0 , 5″);foreach ($result as $post) {setup_postdata($post);$postid = $post->ID;$title = $post->post_title;?><li><img src="<?php echo post_thumbnail_src($postid); ?>" alt="<?php echo $title; ?>" class="new-post-img" /><a href=”<?php echo get_permalink($postid); ?>” title=”<?php echo $title ?>”><?php echo $title ?></a> </li><?php } ?></ul>上面的5是調用5篇最新文章。關于上面的那種調用縮略圖的方式，先森曾經在文章中提到過，調用的縮略圖優先順序是：自定義字段為 thumb 的圖片>特色縮略圖>文章第一張圖片>隨機圖片/默認圖片；。主題還沒有集成調用縮略圖的同學可以去看看。WordPress調整Tag標簽頁文章列表縮略圖優化小記代碼實現-方案2好了，言歸正傳。上面找到的那種調用代碼，雖然已經可以實現縮略圖和文章列表，但是文章標題下面卻顯得空空的。先森想了一下那里可以放什么，看了一下其他博主一般放的是瀏覽量和點贊量。先森的網站人少，瀏覽量少，點贊的更少，所以想想還是算了。最后決定放發布時間。發布時間的代碼簡單嘛，就是the_time('Y-m-d')嘛，但是放上去竟然出錯了。調用出來的時間全是1970年1月1日。無語ing...先森想了各種辦法解決時間調用的問題，結果發現：從古至今眾人皆談的時間果然不是那么好解決的。上面的代碼，貌似是直接用的數據庫搜索語句，里面沒有搜索時間，所以調用出來的時間就有問題。但是不像先森一樣畫蛇添足的還想加時間，上面的代碼就完全夠用了?，F在在凌亂中繼續搜索代碼實現方法。最終終于找到了合適的代碼，重點還很簡單：添加至主題的sidebar.php中：    <ul id="new-posts">                   <?php $postslist = get_posts('numberposts=5'); foreach( $postslist as $post ) : ?>         <li class="new-post-li">           <a class="new-post-a" title="<?php the_title(); ?>" href="<?php the_permalink();?>">             <div class="new-post-imgdiv">             <img src="<?php echo post_thumbnail_src(); ?>" alt="<?php the_title(); ?>" class="new-post-img" />             </div>           </a>          <div class="new-postadiv">          <a class="new-post-title"  href="<?php echo  the_permalink(); ?>" title="<?php the_title();?>"><?php the_title(); ?></a>          </div>          <div id="new-post-time"> <i class="fa fa-clock-o"></i><a><?php echo the_time('Y-m-d'); ?></a></div>        </li><?php endforeach;wp_reset_query(); ?>      </ul>就這樣，先森的想法就變成事實了。新“最新文章”帶縮略圖、發布時間