PHP

　　最近在嘗試為網址添加百度的MIP(Mobile Instant Page - 移動網頁加速器)版本，網站改動後先用MIP Validator進行驗證和Preview預覽，沒有大的問題就可以等着百度蜘蛛來爬取了，不過還可以在百度站長平台中主動提交MIP版本，讓百度蜘蛛更快、更全面知曉。

　　進入百度站長平台後，可以在已有的網站（沒有的網站需要先驗證和添加網站）菜單中選擇“移動專區、MIP引入”，先要确認“《百度MIP資源接入内容責任書》的相關協議”，然後看到“手動提交”和“主動推送（

　　剛才記錄了一篇《自己編寫的網站監控程序》，可以實現比較複雜的多系列網站巡檢，設置第二個參數為sitemap.xml就可以檢查網站地圖。

　　不過看到以前還寫過一個更簡單的sitemap.xml檢查程序monitor_xmlsitemap.php，也把PHP源代碼貼出來：

<?php
function check($host) {
    //$keyword = 'xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"';
    $keyw
  

　　偶爾會發現各Drupal系列網站的sitemap.xml丢失的情況，應該是在運行cron階段把老的sitemap.xml删除了，但在生成新的sitemap.xml的時候因為網站數據量大導緻mysql進程被殺死或者其它超時等原因重新生成失敗，我們管理員一般不會去特意檢查這個sitemap是否存在，而搜索引擎會一遍一遍經常檢查，遇到不存在報錯的情況可能會存在相當長的時間。(解決辦法：可以在Sitemap配置中的ADVANCED SETTINGS裡面把Disable cron generation of sitemap files.勾選，或者運行drush vset xmlsitemap_

　　在用Drupal搭建網站的時候，有時需要用到一些複雜的查找及替換，隻用str_replace是無法做到的，這時需要用到正則表達式，有這樣幾個PHP函數可能會用到：​

• preg_replace  正則替換函數
• preg_replace_callback 正則替換回調函數（這個超強功能是最近遇到複雜情況才用到幾次，可以對查找匹配出來的内容進行函數轉換再替換）

　　更多PCRE 函數：

• preg_filter — 執行一

　　一直以來我們放在國外服務器上的網站在國内訪問都很慢，當網站中包含有Google地圖等内容的時候，更是在國内訪問會被卡住，等待幾十秒後才打開頁面剩餘部分，而地圖部分也是空白。

　　去年在做ipshu.com網站的時候也是遇到這個問題，因為這個站本身就是判斷IP地址的，所以也方便解決，當時記錄了一篇博客《讓國内國外都可以調用Google地圖API》，采用的其中第二種辦法。

　　但其它放在國外的網站依然沒有解決，昨天幹脆去編寫了一個簡單的Drupal模塊in_china（放在本文的附件中），主要作用就是定義一個PHP函數in_china()，用于判斷

　　前些天嘗試成功了“Drupal中文網站簡體版本自動生成一個對應的繁體版本”，那篇博文中詳細記錄了Drupal中需要修改的地方，而簡體到繁體轉換的核心PHP程序并沒有給出，現在就放在下面供需要的朋友參考。

　　需要說明的是，我在網上搜了好些中文簡體繁體轉換PHP程序的文章，基本上都殘缺不全，需要下載的對照數據成了死鍊接，無法真正使用，我隻好又找了别的語言(有一篇介紹Java做簡繁轉換的文章)程序中找到純文本的對照數據，自己再花了一些時間來轉換，最好放到自己的程序中，很是折騰，希望下面這段代碼讓需要的朋友不用這樣折騰了。

　　最近需要編寫一段程序來讀取Drupal網站中頁面Node的某個文本字段，進行處理、判斷、匹配後，将這個頁面歸類Taxonomy到某個術語表Vocabulary的術語Term中。在剛開始用Drupal 6的時候就曾經編寫過類似程序來分類，見博文《Drupal中讓Node歸類的PHP程序》，在後來使用Drupal 7的過程中，絕大多數分類都是在創建網站、導入數據的時候就自動進行了，使用了術語來源Term reference字段和自動完成術語挂件（标簽）Autocomplete term widget (tagging)控件，但也有把數據作為文本導入字段，然後再運行php程序進行分類的情況

　　以前托管服務器或者租用的服務器一般都是100M共享的帶寬，很少出現機器帶寬被占滿的情況，去年開始采用阿裡雲平台後，帶寬就是一個不得不考慮的成本因素，我們一般都是每台ECS購買的10M左右帶寬，每年費用已經不少了，而投入使用後很輕易就會被占滿，關鍵是網站的流量并沒有特别提升，廣告收入沒有增加，成本卻在大幅提高，還導緻正常用戶訪問變慢、困難。

　　同事在Linux服務器上安裝了一個iftop來查看帶寬占用情況，很容易就發現了是搜索引擎的爬蟲抓取sitemap.xml這樣的網址占用了很大帶寬，我們網站系列多、頁面多、還有多語言或者手機版，網站地圖就特别的多，如果爬蟲來得

　　整個2015年從開始到結尾都在進行網站向雲服務器的搬遷以及網站的升級，其中大數據量的數據遷移是個令人很頭痛的問題，幾百萬的數據量加上幾十個字段，系列網站還有幾十個這樣的網站，需要等待數據遷移程序運行的時間真是太長太長了。上半年就遇到大數據量的問題，後來通過修改服務器配置，讓PHP使用更多的内存、最大執行時間、數據庫連接緩存等辦法，還是用drush content-migrate-fields這樣的命令來進行，算是解決了部分難以遷移的站點。但現在到年尾，而且随着Drupal 8的退出，Drupal 6很快就面臨失去支持的境況，我們需要把所有Drupal 6網站都升級，現在把所有服務器資

　　Drupal 8在上月推出，Drupal 6在3個月後不再提供支持，今年我們本來就花了很多時間在做服務器遷移到阿裡雲以及Drupal系統升級的事情，現在還剩下的幾個Drupal 6系列網站的升級工作也要抓緊進行。

　　升級工作的流程我們已經很熟悉了，可以批量進行（見博客文章《用Drush批量升級Drupal 6到Drupal 7》），但遇到數據量很大的站點時，content migrating 的時間特别長，還容易因為服務器内存、php運行時間限制、SQL時間過長等原因報錯失敗，數量在幾十萬以内的升級起來都很快，但單個站點數據量達到數百萬、每個站點的字段數量有幾十