Undefined index: in views_plugin_pager_full

update status

Looks fine. Thanks for the patch

Im having the same issue even though I have blog entries.. I am wondering how to install the patch> read the page on applying patches http://drupal.org/node/60818 but when I run the command I get

can't find file to patch at input line 10
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|### Eclipse Workspace Patch 1.0
|#P views
|Index: plugins/views_plugin_pager_full.inc
|===================================================================
|RCS file: /cvs/drupal/contributions/modules/views/plugins/Attic/views_plugin_pager_full.inc,v
|retrieving revision 1.1.4.7
|diff -u -r1.1.4.7 views_plugin_pager_full.inc
|--- plugins/views_plugin_pager_full.inc 22 Mar 2010 20:25:10 -0000 1.1.4.7
|+++ plugins/views_plugin_pager_full.inc 6 Sep 2010 13:14:03 -0000
--------------------------
File to patch:

I have no Idea what is going on as I thought the patch file views_plugin_pager_full.inc-prevent-undefined-offset.patch was the patch.

Any help would be appreciated

thanks

Marcel

Just ran into this - looks like there is a small typo in views_plugin_pager_full.inc that is causing this bug to crop up again. First noticed it because page containing the view was timing out. This was the error in my logs:

Notice: Undefined index: in views_plugin_pager_full->set_current_page() (line 233 of /www/eff.org/docs/sites/all/modules/views/plugins/views_plugin_pager_full.inc).

Here's a patch against 7.x-3.x-dev.

Oops, setting back to active. MAybe should have made a new issue...

The code below fills in the values already, maybe your patch should be adapted a bit.

    $page = isset($_GET['page']) ? explode(',', $_GET['page']) : array();

    for ($i = 0; $i <= $this->options['id'] || $i < count($pager_page_array); $i++) {
      $pager_page_array[$i] = empty($page[$i]) ? 0 : $page[$i];
    }

Please also reroll your patch, so the testbot can test it.

I have the same issue after using search twice with 0 results. The errors are thrown only on pages which contain pagers (like paged blocks). Patches posted above don't work :(

Hitting this same error in #5 above, with a pager used on a views panel pane, with an exposed setting for pager offset. If the panel pane doesn't specifically set the offset, the options['id'] is just an empty string (which breaks line 233).

This patch creates a $pager_id with this specific case in mind. the variable is then used in the for loop and on line 233.

Note, the patch in #10 was applied against an earlier version of views, and should still apply to 7.x-3.x-dev with offset (i just reapplied it to 7.x-3.3, with offset).

-- deleted, double post.

Well actually $this->options['id'] should be always set from the views side, maybe panels is doing something wrong.

You know fixing just a notice might hide other bugs, at least in my experience.

views_plugin_pager_full.inc-prevent-undefined-offset.patch queued for re-testing.

I just run across this bug.

To reproduce it :

• create a view using a pager (full or mini)
• in "Pager options" set "Pager ID" to nothing
• save your view

Now trying to access page 2, you'll probably face this error:

Notice: Undefined index: in views_plugin_pager_full->set_current_page() (line 315 of /projects/contrib/views/plugins/views_plugin_pager_full.inc).

After digging into views_plugin_pager, I found the get_pager_id() method which is great but almost never used.

So here is a patch that make use of this method to ensure we never use an empty pager id.

This is a great fix!

I am still seeing this error

I reviewed the patch in #16 and I find those changes to be already part my current Views implementation (v7.x-3.8), so I have nothing to patch.

My scenario that causes the error may be a bit different from what started this thread. I create a view containing a block, and add that block to Left Sidebar, showing on all pages. I use a Full pager in the view/block definition, and I set the pager id for the pager in the block to 1. (I need to set the pager id since the main portion of whatever page the block shows on can have its own pager, and each pager on a page needs to have a unique pager id or else the pagers talk to one another when you changes pages).

If I type a nonsense string into the main Search box and do a search that returns no results, I get the "Undefined offset: 0 in theme_pager()" error. If I remove the new block from Left Sidebar, the error does not happen.

I'm assuming the Search Results page is failing to set some variable when there are no search results for the pager that would normally be associated with the list of search results, and that unset variable is being processed by the extra block (with pager) that I have added to the page and which then causes the error.

So, this is probably a Search error in its use of a pager. But should the pager code in Views detect this state and fail gracefully?

Thanks for your thoughts

Moving this back to the 7.x-3.x queue

Checked D8 core and getPagerId() is present but never used, while $this->options['id'] is used all over the pagers.

No Notice is given when using an empty Pager ID, but the pager doesn't work either. Will open a new issue for that in the Drupal core 8.0.x queue (and maybe use getPagerId in that .