標籤為 “wordpress” 的文章

如何客製WordPress後台的「說明」(Contextual Help)頁面與「顯示選項」(Screen Options)頁面?

登入WP後台時,可以發現畫面的右上角有兩個標籤連結,分別是「顯示選項」及「說明」。按下這兩個連結,都會拉出一個小畫面,分別顯示與此頁面相關的控制選項及說明頁面。本篇文章先介紹其中的「說明」頁面該如何客製,而顯示選項(Screen Options)頁面的客製方式其實也差不多。

為什麼要客製「說明」和「顯示選項」頁面?

為什麼您可能需要去客製「說明」頁面呢?也許是因為您製作了新的外掛(Plugin),而您的外掛在後台提供了操作頁面,這時如果您希望使用者在進行設定時能獲得更詳細的說明時,您就需要去客製說明頁面。也有可能您不希望客戶看到預設的說明頁內容,您當然也可以把預設的內容「隱藏」起來。同樣的,如果有一些進階選項,您也可以放在顯示選項頁面裡。

客製「說明」頁面

要客製說明頁面,只要增加一個contextual_help的filter就可以了:

繼續閱讀

如何設定WordPress自訂選單功能的自訂鏈結,讓頁面在新視窗開啟?

WordPress自3.0版開始支援自訂選單的功能,只要佈景支援,使用者就可以進入後台的「外觀>選單」,自訂選單內的選項。因為可以直接把現有的文章、分頁、類別拉進選單項目中,因此非常的便利,除此之外也能建立自訂鏈結,讓選單項目可以連至其他網址。

前陣子遇到的一個小問題是,這個自訂鏈結只能建立URL、名稱以及標題屬性(即是a的title屬性),但沒有發現可以設定開啟目標(即是target屬性)及設定CSS屬性,真的有這麼弱嗎? 繼續閱讀

如何讓WordPress可以設定多個管理員信箱?


WordPress有著非常方便易用的信件通知功能,但預設上卻無法設置多個管理員信箱,如果我們希望系統在寄出通知信 (如新用戶註冊、回覆留言等) 時,能同時寄給多個管理員時,是否有辦法做到?

在我們撰寫外掛插件(Plugin)或佈景functions.php時,如果有寄送信件的需求時,我們會使用wp_mail這個函式來處理: 繼續閱讀

WordPress 角色(Role)與權限(capability)簡介

最近幾個月非常忙,所以很久都沒發文了… 不過總覺得這樣不太好,所以決定有空還是整理一下工作上遇到的問題。首先要分享的是WordPress 3.0有關會員權限的問題,我想首先從WordPress的使用者權限機制稍作說明來開始好了。

WP 會員權限機制的發展

WordPress早期在1.5版時開始使用的權限設計是採用User Level機制,也就是將內建的全部權限切分為十個等級,而每個等級能做的事都定義出來,所以使用者可以透過存取user的等級來決定權限。

這樣充滿限制的權限設計,可想而知不會太長命,果然到了WP2.0開始就建議大家換用角色(Roles)與能力(Capabilities)機制了,並且到了WP3.0,User Level就成為了不建議使用(deprecated)的功能了。

WP 自訂角色(Roles)與能力(Capabilities)

簡單來說,Roles與Capabilities的機制就是每個角色能擁有許多不同的能力,除了內建的六個角色(超級管理者-Super Admin, 管理者-Administrator, 編輯-Editor, 作者-Author, 投稿者-Contributor, 訂閱者-Subscriber),開發人員也能自訂新的角色,而能力也是如此,除了內建的能力(讀文章、發表文章、管理使用者…等等),也能自訂新的能力。自訂新角色時也能順便指定新的自訂能力,方式是:

add_role('test_role','測試者',array('test_cap'));

你可以把這個語法寫在自訂的plugin裡,當然也能用在佈景(theme)的function.php中。其中test_role是我自訂的新角色,「測試者」是新角色顯示的名稱,而test_cap則是此角色擁有的能力,執行了這行,就代表你的WP出現了一個新的角色-test_role,而這個角色擁有test_cap這項能力。

為什麼你會覺得WP的會員權限很鳥?

我知道WordPress的會員權限設定常常飽受批評,就拿Drupal的權限設定來說,預設的後台設置就非常完整的提供了各項存取的權限設定,WP一比較之下,感覺就弱掉了。不過我個人認為,WP也能辦到一樣的事,只是通常在開發Plugin時,開發者沒有把權限設定的code完整的實作出來。

因為在我們定義好新的角色或新的能力之後,我們必須在自訂的佈景或plugin中加上判斷,透過取得目前User的所屬角色及擁有的能力,再來決定對不同權限作不同的呈現或動作。我想WP預設的會員權限這麼弱,大概因為畢竟WP的大戶是部落客,會員通常只有格主一人,所以權限部份時常沒被定義到也很正常XD。

實作有問題!?

好的,就在實作自訂角色及自訂能力時,問題發生了。有個內建的function叫current_user_can(),wp的官方文件說,我們可以透過它來判斷目前的使用者是否為某特定的角色,或者是否擁有特定的能力,因此它的參數可以是「角色」也可以是「能力」,但是我測試的結果是,給它自訂的「角色」去做判斷,運作是正常的;但給它自訂的「能力」進行判斷,運作就不正常了。

在Google了幾個小時,以及罵了好幾聲髒話之後,我決定去看原始碼。這些跟權限相關的functions定義在wp-includes / capabilities.php 裡,從current_user_can()出發,可以發現它又呼叫了has_cap這個function,去取得目前使用者的所有能力,事情就錯在這裡。

在它把目前使用者所有的能力都放進$capabilities這個陣列後,我自訂的能力它找不到,自訂的角色卻找得到,於是print_r這個陣列後發現它長這樣:

Array ( [0] => test_cap [test_role] => 1 )

白話一點說,它裡面有兩個值。我們可以用$capabilities[0] 去取得 test_cap 這個值,也可以用 $capabilities['test_role']去取得1這個值,偏偏在has_cap裡面,它統一用 $capabilities['角色或能力名'] 這種方式來判斷是否擁有某能力,當然 current_user_can 也一併被影響了,所以當我們用 current_user_can(‘test_cap’)時,它只會回傳false,而current_user_can(‘test_role’)才會正確的取得1,並且被判定為True,真是XX你個OO。

解決方案

簡單的解決方式就是用它正常的部份,也就是用角色來判斷就好:

if (current_user_can("test_role"))
{
    echo 'yes, he is the right role!';
}

缺點是很鳥、不正常、不合理,照理說能力是可以跨角色的,只拿角色判斷,完全不彈性,不過在plugin設計不複雜的情況下是可行的。那如果我們現階段真的很想用能力來做判斷怎麼辦? 那你可以這樣做:

// 先取得目前的使用者所屬的角色
$current_user = wp_get_current_user();
$user_roles = $current_user->roles;

// 取得使用者所屬角色後,再檢查這個角色擁有的能力
$role = get_role($user_roles[0]);
foreach ($role->capabilities as $hiscap)
{
    // 如果這個角色擁有 test_cap 這個自訂能力
    if ($hiscap == 'test_cap')
    {
        echo '是的,現在的使用者有test_cap這項能力';
        break;
    }
}

WordPress CMS外掛-Pods CMS:簡單客製化企業網站(下)

上回我們談到Pods後台能設定pods,templates,pages,就好比MVC架構的三個特性。在pods頁面,我們先選state這個pod來看一下設定畫面:

左上角的name是預設的第一個欄位,每個pods都會有一個name。而下一個欄位abbrev就是自訂出來的,所以這個pod有兩個欄位。如果需要自訂pod,就新增一個,再看自己需要什麼樣的欄位,一一設定進去就行了。設定好pod的欄位,就能到後台選單裡的Pods發現多了一個 Add xxx的選項,以state來說就是Add state,這邊就能新增pod的內容,而wp後台pods選單還有browse content選項,可以看到所有設定好的pod及其內容。 繼續閱讀

WordPress CMS外掛-Pods CMS:簡單客製化企業網站(上)


Wordpress是一款開放原始碼(open source)的部落格架站軟體,自從2003年問世後,就逐漸成為自架部落格的指標性軟體。也因為它開放性的外掛(Plug-in)機制,讓許多國內外的好手都加入撰寫外掛行列,成千上萬的外掛給了Wordpress無限的想像空間。 繼續閱讀