最近在向一個Drupal網站report.bizdirlib.com中導入更多内容時，初期選擇了一種新的内容類型company_chinese來導入，但導入完成後發現不妥，需要修改為另外一種已經存在的類型product，以便使用購物車的各種功能。

　　如果在MySQL中操作來修改估計是可以實現的，但需要了解各種結構、反複測試，後來找到了一個現成的插件node convert，可以比較方便地實現。

　　步驟如下：

1. 安裝這個插件；
2. 修改老内容類型的字段設置，以便轉換有對應的字段；

　　最近一段時間國内、國外的多台服務器都不太平，硬件、軟件故障此起彼伏，搞得人疲于應付，不斷在各台服務器之間臨時轉移網站并應對服務器負載方面的問題。

　　到昨天終于算是把一些臨時放在其它服務器（22、181）上的網站基本都遷移回返修重新上架的服務器（17），重裝系統後有好些細節（例如MySQL版本、文件權限、PHP版本、phpmyadmin的運行）會出現問題，還有不少後續工作要進行。

　　17服務器這次更換電源、硬盤後重新安裝系統，就沒有再使用Squid做反向代理緩存加速，直接讓Apache應對Web訪問，這樣也不需要再在MediaWiki的LocalSe

　　對于我們這種數據量很大的網站，面臨的一個麻煩是總有人來采集，以前多使用過人工檢查、屏蔽的辦法，這種辦法有效果但太費精力，前段時間也找了插件來自動限制最大連接數，但存在誤屏蔽搜索引擎的問題，最近老夫下決定親自操刀寫程序，把這些采集者都斬草除根，雖然

　　6月份放置jamesqi.com這個站點的服務器出了一些問題，一直沒有搞好，站點臨時轉移到其它服務器上，所以也沒有寫什麼日志，現在依然沒有搞好，但還是先寫日志吧。

　　我們有些系列網站數量多，再加上多語言後，xmlsitemap網站地圖的數量就更多了，例如50子網站*50種語言後就是2500個網站地圖，生成就需要很長時間，中途還可能遇到各種報錯，而生成後人工檢查也難以進行，7月1日編寫了一個簡單的腳本來進行自動檢查、記錄：

checksitemap.sh

#!/bin/bash

DB=(zip ak al ar az ca
  

　　Drupal網站中用Views可以顯示需要的各種列表，有時希望把列表的結果保存為另外的文件，當結果數量很大（超過幾十、幾百）時，用人工複制粘貼的辦法就不合适了，需要有自動批量處理的辦法。嘗試了2種辦法可用：

1、從PHPMyAdmin導出

　　昨天嘗試了一個辦法：在Views的設置中打開SQL語句顯示，将語句複制出來，根據需要進行修改，然後再放到PHPMyAdmin中對應的數據庫中運行，将得到的結果（也類似Views的結果）導出成CSV文件。這個過程有點麻煩，特别是需要對複制的SQL語句進行一些修改，最好能懂得一些SQL才好操作。優點是運行速

　　Drupal網站搭建好、數據導入或者編輯完成後，如果需要大批量修改内容，可以有多種辦法：

1、最原始：MySQL語句

　　找到MySQL數據庫中需要修改的内容放置的字段，用MySQL UPDATE語句來直接替換，其運行效率最高，但實現不方便、出錯後無法挽回、頁面時間沒有變化；

2、最傻瓜：Scanner模塊

　　今天找到一個用于search和replace的模塊Scanner，安裝試了一下，很容易使用，替換後是生成一個新的版本，如果有問題可以批量還原，選項也很豐富：大小寫敏感查找、全詞查詢、加前後綴設

　　今年初在搭建Profile Report網站時寫了一篇《系列網站之間相同主題内頁的互相鍊接》，當時主要是用VB編寫程序來對導出的兩個csv文件進行比較，然後計算出可以鍊接的node id，再用PHP程序或者人工的辦法來添加鍊接，整個過程比較繁瑣、自動化程序不高。

　　此後又嘗試了添加更多的數據到這個站，并進行按照省份分類等工作，就采取了PHP程序+MySQL數據庫的方式，搜索匹配的效率大大提高，運行時間縮短很多。

　　近期我們新增了一下幾個網站：

• China Exporters of Canton Fair 11

　　以前的Drupal 6版本中使用函數drupal_set_title來修改頁面Title是頁面的HTML标題和頁面顯示<h1></h1>中的标題都一起變化，但Drupal 7版本中再調用這個函數的時候發現隻是頁面HTML标題變更了，但頁面顯示在<h1></h1>中間的标題卻沒有變，這在有些情況下其實更好，但在确實需要頁面顯示标題也變化的時候就不行了，還得想另外的辦法。

　　下面一段代碼放在my_module.module中就可以實現對原來的title進行翻譯然後顯示在頁面中：

/*
* 
  

　　Drupal網站在Site information的設置中有一個404錯誤頁面可以定制到自己希望的網址，如果你在日志中發現大量404錯誤，而其中很多都是同一個類型可以引導到對用戶更有幫助的内容頁面，那麼就可以在這個定制的404錯誤網址中進行判斷、導向。

　　我做的例子是http://ak.postcodebase.com/not_found ，因為來自外部網站的鍊接中，有一部分是這個站内找不到或者錯誤的郵編，就可以根據URI進行判斷：

• 如果訪問9位郵編頁面不存在但前面5位郵編分類頁面存在，則轉到5位郵編分類頁面；

　　我們很多年前開始做網站就一直遇到被采集的問題，很多次都是讓我們服務器不堪負重，需要排除、采取針對性措施來屏蔽，所以我一直對采集這種方式很排斥。另外，國内太多用采集做成的複制網站、山寨網站、垃圾網站了，在搜索引擎中也不會有長期良好表現，違反了SEO的原則，所以我們一直都沒有用采集的方式來獲取數據。

　　但這兩年也一直有嘗試采集軟件的想法，我們不會去複制網站，但可以用來獲取需要的一些數據，然後再做處理利用，去年也提過但一直沒有實施，今年初再次提到這個想法，我也去看過、比較過一些采集軟件，火車頭采集軟件在這方面比較領先，最近同事去詳細了解、試用，感覺還不錯，我們就幹脆去購買