在近期的一個drupal項目中，我們遇到一個十分奇怪的問題：搜索結果頁面的總記錄數和總頁數永遠是一個錯誤的固定數字。這個極具迷惑性的假象讓我們朝著各種錯誤的方向去尋找問題的答案，並且遲遲沒有進展，然而等我們找到真正的問題原因時，結果可以說是讓人大跌眼鏡。
我們先是禁用了所有自定義開發的部分：把主題切換回drupal默認的前端主題Bartik，同時禁用所有自主開發的模塊，然後再一點點重裝回去，測試的結果是問題出在主題部分。
但接下來更讓人迷惑了，一是我們的主題中只是對默認的搜索結果做了一些非常細小的覆寫，不足以引發問題;二是當換成其他主題，比如Zen的時候，也出現同樣問題。所以前面的問題出在主題部分的論斷又被推翻了。
接下來我們又從異常的數據、關鍵字索引、緩存等方面去找問題。這一切都無功而返以後，我們還是回到代碼部分，循著函數的執行路徑逐個往回找，最後發現總記錄數在某個區塊渲染以後被更改了，而這個區塊正好是Views模塊生成的一個帶分頁的視圖。
我恍然大悟，一定是Views的Pager ID問題!這個問題我以前曾經遇到過，而且還提醒過自己日後注意，沒想到這次還是疏忽了。
沒錯，就是下圖中的這個地方：
這個細小的設置，常常被很多人忽略，因為在絕大多數情況下，保持默認設置是沒有問題的。但是記住，一旦頁面上有多個分頁器(這種情況通常是在把Views生成的一個帶分頁的視圖作為區塊嵌入頁面的時候出現的)，這個設置就變得至關重要。因為同一個頁面上的各個分頁器必須有各不相同的ID，而這個ID就是通過此處的選項來進行設置。
那麼這個Pager ID到底是個什麼東西呢?在解決我們項目問題的同時，我也順便深入看了一下drupal的部分核心代碼，對Pager ID也有了一些更深的認識。
原來在Drupal中，我們看到的任何分頁器都是基於四個全局數組變量生成的，它們是：
global $pager_page_array; // 存儲當前頁碼
global $pager_total; // 存儲總頁數
global $pager_total_items; // 存儲總記錄數
global $pager_limits; // 存儲每頁的記錄數
由於每個變量都是數組，drupal就可以用不同的數組下標來區分多個分頁器。這個下標，或者叫索引，就是上面所說的Pager ID。
一般來說，需要顯示分頁器的模塊基本上都是Entity及其派生模塊。Entity模塊會通過遞增Pager ID來自動區分多個分頁器，這樣多個分頁器出現在同一個頁面上時就會各自相安無事。
但是Views模塊在生成分頁器時Pager ID默認是0，這樣如果頁面上有超過一個分頁器，它就會覆蓋那個Pager ID為0的分頁器。這就是我們項目中遇到的情況——搜索結果頁面的分頁器被Views生成的區塊分頁器覆蓋掉了。這種情況下，就需要手動設置Pager ID。Pager ID設置為多少是合適的呢?其實只要能互相區分就可以了，一般來說，設置成較大的數字總是比較保險的。
