杭州跑完回來以後就空閑下來了,一段時間都沒有比賽,正好把我之前準備做的一件事情辦了:獻血。很早以前就有過這個想法,隻是從30歲左右到40歲出頭一直體重超标,血脂檢查沒有合格過,而且都是超過合格标準的上限不少,經過節食稍微好點,中度脂肪肝也降為輕度,但血脂不符合正常标準也不适合獻血。2011年開始在中體倍力健身俱樂部鍛煉後效果超好,隻有幾個月時間就減輕了上十公斤,多年沒有正常過的
博客文章
我們做的Drupal網站數據量都比較大,幾年前一開始就遇到cron運行報錯的情況,主要就是因為cron運行期間要生成xmlsitemap,遇到php的内存限制或者運行時間限制導緻出錯無法正常執行,我們當時采取的辦法是修改“Minimum sitemap lifetime(sitemap最小存在時間)”為10年(drush vset xmlsitemap_minimum_lifetime "315360000",并且還要修改modules/xmlsitemap/xmlsitemap.admin.inc中的内容,增加10年這個表單選項
一個系列網站從drupal 6升級到drupal 7後日志中發現大量報錯,都是以前可以正常訪問的網址現在找不到了,發現以前drupal 6中是這樣的:
http://ut.mingluji.com/business_directory/Western_Heating_%2526_Air_Conditioning
在google搜索中也是上面這樣的網址,但升級後以上訪問成了404 not found,而用下面這樣的網址可以訪問:
http://ut.mingluji.com/business_direc
Drupal的Views設置中本來就有一個選項是用于去掉重複的,Drupal 6中叫做Distinct:
Defaults: Display only distinct items, without duplicates. Distinct This will make the view display only distinct items. If there are multiple identical items, each will be displayed only once. You can use this to try and remo
整個2015年從開始到結尾都在進行網站向雲服務器的搬遷以及網站的升級,其中大數據量的數據遷移是個令人很頭痛的問題,幾百萬的數據量加上幾十個字段,系列網站還有幾十個這樣的網站,需要等待數據遷移程序運行的時間真是太長太長了。上半年就遇到大數據量的問題,後來通過修改服務器配置,讓PHP使用更多的内存、最大執行時間、數據庫連接緩存等辦法,還是用drush content-migrate-fields這樣的命令來進行,算是解決了部分難以遷移的站點。但現在到年尾,而且随着Drupal 8的退出,Drupal 6很快就面臨失去支持的境況,我們需要把所有Drupal 6網站都升級,現在把所有服務器資
2010年底、2011年初開始嘗試Drupal,當時Drupal 7還沒有正式版,就用的Drupal 6,到2012年初嘗試把網站升級到Drupal 7,升級過程見《本網站從Drupal_6.20升級到6.24,再升級到7.12》,但後來在升級大數據量網站的時候遇到問題,當時也記錄了博文《大數據量Drupal_6網站升級到Drupal_7很麻煩》。今年以來我們陸續都在做Drupal 6網站的升級,現在Drupal 8都推出了,更是要加快升級工作,目前都是剩下一些數據量特别大的站點還在進行中,現在也沒有采用曾經的mysql指令的方式來遷移數據,而是設法添加硬件、修改配置設置來讓drus
以前安裝過一個Drupal 8的測試版,看過界面和很短加起來不到1個小時的測試,上個月Drupal 8的正式版出來了,這幾天才抽空來嘗試安裝、升級等,把一些需要注意的地方記錄如下:
- PHP版本問題:在我們的Linux服務器上安裝時提示PHP版本太低,要求是PHP 5.5.9以上,同事嘗試安裝了PHP 7正式版,但對MemCache等的支持似乎還不夠兼容、資料也不多,于是就安裝了PHP 5.6.16,自帶了Zend OPCache,不再需要APC;
- MySQL
Drupal 8在上月推出,Drupal 6在3個月後不再提供支持,今年我們本來就花了很多時間在做服務器遷移到阿裡雲以及Drupal系統升級的事情,現在還剩下的幾個Drupal 6系列網站的升級工作也要抓緊進行。
升級工作的流程我們已經很熟悉了,可以批量進行(見博客文章《用Drush批量升級Drupal 6到Drupal 7》),但遇到數據量很大的站點時,content migrating 的時間特别長,還容易因為服務器内存、php運行時間限制、SQL時間過長等原因報錯失敗,數量在幾十萬以内的升級起來都很快,但單個站點數據量達到數百萬、每個站點的字段數量有幾十
以前導入數據的Drupal網站中字段基本上都是唯一值的,設置、處理、導入都很簡單,隻要有需要導入的csv文件,在Feeds模塊中設置對應關系,然後導入就可以。
也曾經在少數某些網站考慮過多值數據的導入,不僅僅是某一個字段的多值,而是一組多值,例如下面的field_x_y:
title body field_1 這裡面隻有一個值,類似一個數字 field_n 這裡面有多個值,類似一個一維數組 field_x_y 這裡面有x個子字段,每個子字段有y個值,類似一個二維數組
這種二維數組的總字段是沒有
在Drupal網站有時候有多個内容類型之間需要互相連接,例如内容類型company中的字段field_address,需要查找内容類型location中field_street相同的node,然後在company的顯示模闆中field_address做一個指向location中這個node的鍊接。
在Drupal 7中可以通過Entity查詢來實現,不過因為location中的field_street可能有很多是重複的,我們隻能取其一,就可以在查詢中限制隻找到第一個range(0,1),具體代碼如下:
$address = $f