I was confused at first to what it did exactly, assuming that everything would be automatic. This adds some help text, but perhaps the default views should include block as well as page displays?

--Andrew

Comments

dww’s picture

Project: Signup » Signal
Version: 5.x-2.x-dev »

In my testing, this isn't actually true:
"NOTE: if the display is not enabled for the view, nothing will be displayed, so be sure that the display is enabled and configured properly."
I found that I could embed the default view just fine, even if it was still disabled.

dww’s picture

Project: Signal » Signup
Version: » 5.x-2.x-dev
Component: Documentation » User interface

Sorry, no idea how I managed that. ;)

dww’s picture

Status: Active » Needs work

There's a patch here. I just think the proposed help text needs a little more work, based on #1.

deviantintegral’s picture

What I was going for was the "enable page" or "enable block" checkboxes. I guess my use of Views 2 terminology crept in. If you disable the block display for the view, and select Block in the signup options, do you get anything rendered?

--Andrew

dww’s picture

Right, in D5 those checkboxes are called "Provide Page view" and "Provide block". In D5, the "enable/disable" terminology shows up in the views UI relative to entire blocks.

In my testing, if you have a disabled view (the default view that now ships with signup), and that view only provides a page view but not a block view if it is enabled, then you see the output if you use the 'Page' setting here, but not the 'Block' one. If you change the default view to also provide a block, even if the view itself is disabled, the block output appears if you use the 'Block' setting here.

So yeah, it seems that what matters isn't whether the view itself is enabled/disabled, but which display types the view provides. So, maybe the solution here is a string like this:

"Choose whether to use the Page or the Block display from the view. NOTE: if the selected display type is not provided by the view, nothing will be displayed, so be sure that the display type is enabled and configured properly."

Another thing we could probably do pretty easily is in the selector itself, when we list the view name and description, we could also indicate which display types it provides, e.g.:

signup_user_list: List all users signed up for a node (Page)
signup_current_signups: A list of all signups for the current user (Page, Block)
...

Side note: I agree it'd be nice to just have the default view provide a Block display, too, but I couldn't get that working the other night, and don't have time to do so now. Once the view was providing a block, and I enabled the block and configured it to display on all pages, I couldn't get the block to appear on signup enabled nodes, even after trying to manually set the arguments via PHP code that checked arg(). Did you get this working already? ;)

dww’s picture

Status: Needs work » Needs review
StatusFileSize
new3.58 KB

Try this on for size... ;)

dww’s picture

Whoops, I was using page and block in that $view object when it's not always a real fully loaded $view. I was just querying {view_view} for name and description, so the display types weren't right for site-customized views. Try this, instead.

stborchert’s picture

+1 from me.
Probably deviantintegral should take a look and set it to "reviewed & tested"...

shanefjordan’s picture

Looks good to me

deviantintegral’s picture

Status: Needs review » Reviewed & tested by the community

It looks good, and works for me!

--Andrew

dww’s picture

Status: Reviewed & tested by the community » Fixed

Committed to HEAD. Thanks for the testing/reviews, folks.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.