Be extra careful when setting up paginated block views in Drupal_PHP Tutorial

In a recent drupal project, we encountered a very strange problem: the total number of records and the total number of pages on the search results page are always a wrong fixed number. This extremely confusing illusion led us to search for the answer to the problem in various wrong directions, and there was no progress. However, when we found the real cause of the problem, the results can be said to be shocking.

We first disabled all the custom-developed parts: switched the theme back to drupal's default front-end theme Bartik, and disabled all self-developed modules, and then reinstalled them bit by bit. The test result is that the problem lies in the theme part. .

But then it becomes even more confusing. First, our theme only makes some very small overrides of the default search results, which is not enough to cause problems; second, when switching to other themes, such as Zen , the same problem occurs. Therefore, the previous conclusion that the problem lies in the theme part has been overturned.

Next, we looked for problems from abnormal data, keyword indexing, caching, etc. After all this was in vain, we returned to the code part and followed the execution path of the function one by one. Finally, we found that the total number of records was changed after a certain block was rendered, and this block happened to be Views A paginated view generated by the module.

I suddenly realized that it must be a problem with the Pager ID of Views! I have encountered this problem before, and I reminded myself to pay attention to it in the future, but I didn't expect that I still neglected it this time.

That’s right, it’s the place in the picture below:

This small setting is often ignored by many people, because in most cases, there is no problem keeping the default settings. But remember, this setting becomes critical once you have multiple paginators on the page (this usually happens when a paginated view generated by Views is embedded in the page as a block). Because each pager on the same page must have a different ID, and this ID is set through the options here.

So what exactly is this Pager ID? While solving our project problems, I also took a deep look at some of drupal's core codes and gained a deeper understanding of Pager ID.

It turns out that in Drupal, any pager we see is generated based on four global array variables, which are:

global $pager_page_array; // Store the current page number

global $pager_total; // Store the total number of pages

global $pager_total_items; // Store the total number of records

global $pager_limits; // Store the number of records per page

Since each variable is an array, drupal can use different array subscripts to distinguish multiple paginators. This subscript, or index, is the Pager ID mentioned above.

Generally speaking, the modules that need to display the pager are basically Entity and its derived modules. The Entity module will automatically distinguish multiple pagers by incrementing the Pager ID, so that when multiple pagers appear on the same page, they will live in peace with each other.

But when the Views module generates a pager, the Pager ID is 0 by default, so if there is more than one pager on the page, it will overwrite the pager with a Pager ID of 0. This is what we encountered in our project - the pager of the search results page was overwritten by the block pager generated by Views. In this case, you need to set the Pager ID manually. What is the appropriate setting for Pager ID? In fact, as long as they can be distinguished from each other, generally speaking, it is safer to set it to a larger number.