When setting block views by page in Drupal, you need to take extra care _ PHP Tutorial

You need to be careful when setting block views for paging in Drupal. 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 is always a wrong fixed number. 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 is always a wrong fixed number. This confusing illusion allows us to look for answers to questions in the wrong direction, and we are not making any progress. However, when we find the real cause of the problem, the result can be said to be disappointing.

First, we disabled all custom development parts: switch the topic back to drupal's default front-end topic Bartik, disable all self-developed modules, and then reinstall them a little bit, the test result is that the problem lies in the topic.

However, the next step is even more confusing. First, our topic only performs some minor overwrites on the default search results, which is insufficient to cause problems. second, when we change to another topic, for example, the same problem occurs in Zen. So the previous problem lies in the topic's argument being overturned.

Next, we will look for problems in terms of abnormal data, keyword indexing, and caching. After all this work is done, we still return to the code section and follow the function execution path to go back one by one. Finally, we found that the total number of records was changed after being rendered in a block, this block is exactly a pagination view generated by the Views module.

I suddenly realized that it must be the Pager ID of Views! I have encountered this problem before, and I have also reminded myself to pay attention to it in the future. I did not expect it to be neglected this time.

That's right. this is where:

This small setting is often ignored by many people, because in most cases, it is no problem to keep the default setting. But remember, once there are multiple page splitters on the page (this usually occurs when a paginated view generated by Views is embedded into the page as a block ), this setting becomes crucial. Because each page splitter on the same page must have different IDs, and this ID is set through the options here.

So what is this Pager ID? While solving our project problems, I also took a closer look at some of the core code of drupal and got a deeper understanding of Pager ID.

In Drupal, any page splitter we see is generated based on four global array variables. they are:

Global $ pager_page_array; // store the current page number

Global $ pager_total; // total number of pages stored

Global $ pager_total_items; // total number of stored records

Global $ pager_limits; // stores the number of records per page

Because every variable is an array, drupal can use different array subscripts to differentiate multiple page splitters. This subscript, or index, is the Pager ID mentioned above.

In general, the modules that need to display the page splitter are basically Entity and its derived modules. The Entity module automatically distinguishes multiple page splitters by increasing the Pager ID, so that when multiple page splitters appear on the same page, they will have nothing to do with each other.

However, when the Views module generates a page Splitter, the Pager ID defaults to 0, so that if there is more than one page splitter on the page, it will overwrite the page splitter with the Pager ID 0. This is what we encountered in our project-the page splitter of the search result page is overwritten by the block page splitter generated by Views. In this case, you need to manually set the Pager ID. How many Pager IDs are suitable? In fact, as long as they can be differentiated, generally, it is safer to set a large number.

Bytes. This is extremely confusing...