Drupal, Views date format
Drupal 內需要顯示日期的時間有很多,
node 的內頁, index page 的文章按日期排列等等
但 Drupal 只內建long, medium, short 三種預定了的日期格式
需要其他的格式當然可以自己在 theme 的層面使用 php 的 date()
但其實 Drupal 的 date module 可以使用 Drupal 設定的方式改變輸出的格式
Administer ›› Site configuration ›› Date and time ›› format ›› add (admin/settings/date-time/formats/add)
就可以將 "short" 改成 Aug 21, 2010 之類的格式了
自定Views 欄位輸出 Views fields display
開發多了以後, 慢慢發展了一個自己比較喜歡的 views templating 方式, 分享一下
1. Row style
絕大部份 "Row style" 都會使用 "fields",
是為了靈活性, 可以在 "Fields" 取需要的欄位
相反 "Row style" "node" 只可以選擇 "full node" 或者 "teaser"
而且它的輸出就會使用 node.tpl.php
不方便, 我習慣自己建立 "frontpage" 資料夾專門用作放置該 views 的 template 的
2. *.tpl.php 儲存結構
續上, 一個 views 在該 theme 之內都有一個資料夾
甚至是一個 display 一個, 例如 views "frontpage":
--theme_joe (資料夾)
----frontpage (資料夾)
------views-view-fields--frontpage.tpl.php
----taxonomy (資料夾)
------views-view-fields--taxonomy.tpl.php
3. 專注在 "Row style" 自定輸出
在 theme information 中的 views-view-field*.tpl.php 是最好用的
可以自定以一個 result 為單位的 templates,
通常我都將views 自定的 HTML tags 全部移除
換上我需要的, 以一個 row 為單位重覆的 HTML,
<div class="row">
<div class="pic"><?php echo $field_picture[0]['view'] ?></div>
<div class="right">
<div class="title"><?php echo $title; ?></div>
<div class="description"><?php echo $field_description[0]['view'] ?></div>
</div>
</div>要留意的是, 使用
<?php echo $field_description[0]['view'] ?>便要自己設定 "display as"
上例的的 picture 便要使用 "image" 或者 "image link to node"
而不可以使用 "generic file" 或者 "URL to file"
又或者, 你打算 image 的 alt 使用 title,
pic 用 "URL to file", views-view-fields*.tpl.php:
<img src="<?php echo $field_picture[0]['view'] ?>" alt="<?php echo $title; ?>" />Render Imagecached image through PHP
<?php
echo theme('imagecache', $preset, $imagepath, $alt, $image_title)
?>Can be use in node.tpl.php
在 node.tpl.php 內可用
$preset is the machine name in imagecache UI
其中 $preset 是imagecache profile 的 machine name
2010-08-16 Dedicated server or Amazon Cloud on Drupal? Drupal 適合使用雲端嗎?
雲端服務早在上一年已經是非常火熱的題目
由 Amazon 帶起的新一輪伺服器競賽
為租用伺服器帶來很多新的概念,
如 "瞬間加大處理能力", "多樣化的備份, 儲存方案", "CDN 的普及化", 甚至專為Rails 使用的托管等等
伺服器巿場變得更多樣化, 更多競爭
但就 amazon系列 ec2, EBS 等是否適用於全部專案?
更特定講, Drupal上適合 aws嗎?
結論來講, aws沒有優勢
價錢上並沒有優勢.
在2010年中, aws 的價格實際上不是非常地便宜
aws 的真正優點在於平行計算時可以一瞬提供大量計算力
而不需要自己建立一組, 事後又放在一邊沒有用
但網站不會一週只開五日吧, 日常都 24x7 的
在網站伺服器的領域上, 日常都需要維持一定的處理能力
一般一週高峰流量和低之間大約相差只有50% 左右
低流量一樣需要付
"可以降為使用低一級的s1" 只是美麗的誤會
其實是 "一百部 s1 可以降為五十部"
但, 網站的負載不是加五十台 web tier 就可以的
始終不是真正的平行計算
EBS 不算是真正的 harddisk
需要自己mount, ec2 down了要自己重新 mount
都是新的技能, 網管可不是像 dedicated server 般輕鬆
其實最重要的是
瞬間增加計算力的功能已經出現在 dedicated server 巿場
Media temple 便提供短時間提升 MYSQL 的效能
MT, slicehost, linode 都可以一小時內升到更高級的伺服器plan, 而且月付
應付所謂 "digg effect", 其實真正需要的只是一個 monitor service 吧
當然, 像我的blog 的低流量 (<10k PV/m)
只需要 shared hosting 就可以了
待 inmediahk.net 轉到 rackspace 再講講到底為什麼最後都是使用 cloudservers
2bits 也有一文:
http://2bits.com/drupal-performance/drupal-on-a-dedicated-servers-vs-ama...
webform module
webform - http://drupal.org/project/webform
是另一個非常有用的 Module, 主要用於提供一張表單,
可以收集用戶的資料
可以做統計資料收集, 投票等等
而且可以方便的做種分析, 輸出資理到 Excel 方便處理
但問題是, "表單儲存資料" 的工作,
已經有 cck 在做, 那什麼時候使用 webform, 什麼時候用 cck?
最大的分別是, cck 儲存的資料會變成 node
而 webform 的不會
另一個角度看,
就是 webform 的資料不會被其他用戶看得到
因為一般情況, 訪客是可以看到全部已經發表的 node 的
所以更適合用於收集訪客的個人資料等等比較看重資安的應用
而 webform 提供的自建表單也提供很足夠的客製化
email, textfield, textarea, radio, checkbox, select 等等都有
又提供自定的 validation 機制 (PHP based)
更可以發確認電郵到提交者和網管 (可 cc/bcc)
可真是一應俱全的功能
所以我都開始用 webform 代替 Drupal 內建的 contact module
就是看中它的確認電郵功能
