Attachments and Feeds lost "items to display" control

confirming the bug (or at least my inability to figure it out)

In the meantime I have been getting around this by attaching views using a views_customfield php field to call views_embed_view(...).

Edit: Err nm, to work around this I am using php code in the view header. I was using php field to do something else.

Upgrading to critical; this is a side effect of the way pagers have changed and attachments need to update to match.

There might be another issue for this already, I'm not sure.

In case it helps anyone else I was able to edit the pager settings by going to the url directly, it is only the interface where it does not show up, the setting must still exist. So I went to http://www.example.com/admin/build/views/nojs/display/map/attachment_1/p... and was able to adjust the pager setting for my attachment view.

In case it helps anyone else I was able to edit the pager settings by going to the url directly, it is only the interface where it does not show up, the setting must still exist. So I went to http://www.example.com/admin/build/views/nojs/display/map/attachment_1/p... and was able to adjust the pager setting for my attachment view.

Thank you for posting that. Saved my bacon. :)

Setting 'use pager' => TRUE in plugin.inc makes the item show up, but I suspect that isn't the full solution.

Yeah. I still need to figure out the proper solution to this one.

subscribe ...I'll buy ya a beer when ya fix it :)

Adds a new flag "always avaiblible"

When use pager is not set, only "always avaiblible" pagers are selectable.

Let's try this patch instead; I had problems with inheriting from the default display. We have to change things a little bit from the older ways of doing things.

Sorry for the dupe; I tested this for the feed display handler and it worked as expected for unlimited and limited #s of items. Also subscribing.

Thanks,
David

It applies to latest CVS (which is what the 3.x-dev should be) with no offsets at all. Maybe the -dev you have isn't the one you think it is?

Oh. I only read the pre-edited comment (I read most of my issue responses by mail and they tend not to get the edits).

I can't think of why the Aug 18 -dev is any different. I'm on the tip of the 3.x branch. No changes have been committed since I rolled that patch. I am confused.

subscribe ..

The patch in comment #12 didn't quite apply cleanly to 6.x-3.x-dev from 2010-04-30 (datestamp=1272586770), however the rejections were only for chunks that removed extraneous whitespace. I've attached a version of the patch from #12 that I modified and applied cleanly, as well as the resulting diff from the SVN repo for the respective deployment of views.

2 minor bugs were found in the UI:

1. First settings pane doesn't take UI to second settings pane.
   Steps to reproduce;
   1. Click "Items to display" in an attachment display
   2. Click "Update"
   • Expected behaviour; The second step of the "Items to display" settings is shown
   • Actual behaviour; The edit-area of Views UI is blank and the second step of "Items to display" is not displayed.

   This will probably be solved by the following issue;

2. "Items to display" setting is inconsistent with other displays, and/or is in the wrong settings-summary table.
   Steps to reproduce;
   1. Add a new attachment display
   • Expected behaviour; The display inherits all settings from defaults, except for "Machine name", "Name" and the various settings in the "Attachment settings" summary-table/area.
   • Actual behaviour; "Items to display" is not overridden and can not be set to "Use default".

   Perhaps the "Items to display" setting should be merged in with the "Use pager" setting, or moved to the "Attachment settings" group of settings? Or maybe this is intentional for some reason I am not aware of?

With these fixed I would call this RTBC. More testing would be ideal, but it is ready for wider testing and certainly fixes more than it is likely to break.

For what it's worth, this also impacts the "Feeds" display. I modified the issue title appropriately. I'm on Views 3 -dev as of 8/1/10. I tested both with #12 (which required me to manually fix the whitespace) and with #20 (specifically the -svn patch). Feedback is the same for both patches.

Here's what works:
- I now see the "Items to display" dialog box
- If I choose the option "Display a specified number of items" and input a number, it works properly and I see that number of results in the output.

Here's what does not work:
- If I choose the option "Display all items", offset 0, it only displays 10 items.

Can someone else try with "Display all items" and see what you get? Thanks.

subscribing

subscribe

Confirming the patch in #20 works for me.

Update to old status

I think needs work was a mistake in #20.

I intentionally set it to "needs work". However that patch needs both work and review.

subscribe

I don't think the first problem with inheritance is fixable.

The second one actually works as intended. It advances to the settings if and only if you actually make a change to the pager type. That's the way all of the pluggable settings work.

Committed the patch attached, with some cleanup to inherit and render pager as well.

Hi,

using the last dev version, I have an attachment with "render pager:no" and "inherit pager:yes" but the pager is still being rendered twice, one for the original block and one for the attachment. How to get rid of the attachment pager while still being able to control both displays with the same pager?

Same problem exist in D7 version, patch didn't apply cleanly but appears to work anyways ;p

It seems the display render_pager() functionality actually got lost in the transition to Views 3.

While investigating this, I uncovered that we also lost the ability for exposed input to get to the pager, like it was supposed to. I am SURE I have seen bug reports about that. They should be directed here as this patch will fix that too.

Committed.