You need to be careful when setting up a paging block view in Drupal

In a recent Drupal project, we have a very strange problem: the total number of records and total pages in the search results page is always a wrong fixed number. This intriguing illusion has made us look for answers to the wrong questions in all directions, and we have been slow to make progress, but when we find the real problem, the result can be said to be surprising.

We first disable all custom development parts: Switch the theme back to Drupal's default front-end theme Bartik, disable all self-developed modules, and then reload back a little, and the test results are the problem in the topic section.

But then more confusing, one of our topics is just a little bit of the default search results, not enough to cause problems, and the second is to change to other topics, such as Zen, when the same problem arises. So the argument in front of the question is overturned in the subject section.

Next we look at the exception data, keyword index, caching and other aspects to find the problem. All of this went back to the code section, followed the function path one by one, and finally found that the total number of records was changed after a chunk was rendered, which was exactly the view that was generated by the views module with pagination.

I realized that it must be the views of the pager ID problem! This question I have encountered before, but also reminded myself to pay attention in the future, did not think this time or negligence.

Yes, this is the place in the picture below:

This small setting is often overlooked by many people, because in most cases, keeping the default setting is fine. But keep in mind that this setting becomes critical once you have multiple paging on the page, which usually occurs when you embed a page with a paginated view generated by the views as a block. Because each pager on the same page must have different IDs, this ID is set by the options here.

So what exactly is this pager ID? While solving our project problems, I also took a closer look at some of Drupal's core code and had a deeper understanding of the pager ID.

In Drupal, any pager we see is based on four global array variables, which are:

Global $pager _page_array; Store current page number

Global $pager _total; Storage Total Pages

Global $pager _total_items; Total number of records stored

Global $pager _limits; Store the number of records per page

Because each variable is an array, Drupal can differentiate multiple paging with different array subscripts. This subscript, or index, is the pager ID mentioned above.

Generally speaking, the modules that need to display the paging are basically entity and their derived modules. The entity module distinguishes multiple paging by incrementing the pager ID, so that multiple pages appear on the same page.

However, when the views module is in the raw page, the pager ID defaults to 0, so that if there is more than one pager on the page, it overwrites the pager ID 0 pager. This is what happens in our project-the page of the search results page is overwritten by the views-generated chunk pager. In this case, you need to manually set the pager ID. Pager ID set to how much is appropriate? In fact, as long as can distinguish each other, in general, set the larger number is always relatively safe.