Plugin content in hook public_items_show might not be appropriate to sidebar

[patrickmj]

Some content that plugins add to items/show might not work well in the <aside> element.. Comments from Commenting will get very smooshed, especially with threaded comments. If/when we upgrade ItemAnnotation, that too will likely want more room than there is in the sidebar.

The broader picture is that we don't have a solid way to think about sidebars in Omeka themes. Maybe themes that are designed for sidebars should implement a hook called public_items_show_sidebar to parallel what we have on the admin side, and we'd want to document that practice for theme and plugin developers.

More generally (and imagining the existence of three-column themes someday), maybe two hooks, something like public_items_show_sidebar_primary and public_items_show_sidebar_secondary.

Another possibility: have public_items_show also pass in similar data among the arguments. So seasons could fire the hook twice, once inside the sidebar and once outside, including the argument 'sidebar'=>true . Or maybe either 'sidebar'=>'primary' or 'sidebar'=>'secondary' for cover both 2- and 3- column cases? That might provide the plugin writers the most graceful degradation when working with themes of different numbers of columns? We'd just have to establish and publish conventions for theme and plugin developers for what arguments to expect, and how to switch around the three possibilities.

[patrickmj]

uhh...sorry for the double. don't know what happened when I edited the original. :-1:

[zerocrates]

If you just add more hooks, how would you actually use them as a plugin writer?

If you want to use public_items_show_sidebar_secondary, what do you do for a theme that doesn't have a sidebar, or just one sidebar? You can't also use public_items_show, because you'd get double output. Or would you want a 1-column theme to call all those hooks, one after another? Similarly, if you call the same hook twice with different args, you'll get double output from legacy plugins that don't know to check whatever arg you're adding.

We can do the sidebar hooks in the admin because we know there's a sidebar there. We could have gone with more hooks generally, but 2.0 was kind of the time for that, because you need simultaneous changes from plugins and themes to make the hook stuff work right.

[patrickmj]

Yep on all counts as I've been thinking through this. 2.0 would have been the ideal time, which leaves us either waiting for 3.0, or minimizing the pain for something earlier, like a 2.1.

As it stands, at least one of our existing plugins won't work with one theme (of three).

So I see wait for this (fairly common?) theme feature until 3.0, or cut losses quickly, and provide fallback guidance. Seems like we could offer some band-aid code in forums and documentation to insert at the top of hooks to public_items_show to check if new args are present and branch accordingly. Not ideal, but seems doable. If plugins don't implement it, well, they'll just get the behavior we have now.

So, yeah, on the double output. Here again, we'd have to point people to boilerplate things to add to their plugins as above to prevent that. Question of priority of pain of that now, or pain of waiting for 3.0, I think.

We don't have anything that actually uses a secondary sidebar, so I'm all good to punt that detail so long as we can come up with something that anticipates that possibility.

[zerocrates]

Isn't the simplest answer just to make our themes with their hooks, particularly items/show hooks, in the "primary" area where there's the most flexibility?

Of course themes are generally free to dump stuff wherever, but I think our themes, particularly the bundled ones, should be as generally applicable as possible.

Of course, as with all things, it could be a theme-config thing of where the plugin output should go. I still think that we'll always have trouble picking the "right" hook place across plugins and themes, and a widget/block setup is the only feasible way to allow the flexibility people seem to want. Anything else is restrictive on the theme design or the plugin design to an undesirable degree, and makes users resort to theme hacking.

On 3/5/2013 7:21 PM, Patrick Murray-John wrote:

Yep on all counts as I've been thinking through this. 2.0 would have been the ideal time, which leaves us either waiting for 3.0, or minimizing the pain for something earlier, like a 2.1.

As it stands, at least one of our existing plugins won't work with one theme (of three).

So I see wait for this (fairly common?) theme feature until 3.0, or cut losses quickly, and provide fallback guidance. Seems like we could offer some band-aid code in forums and documentation to insert at the top of hooks to |public_items_show| to check if new args are present and branch accordingly. Not ideal, but seems doable. If plugins don't implement it, well, they'll just get the behavior we have now.

So, yeah, on the double output. Here again, we'd have to point people to boilerplate things to add to their plugins as above to prevent that. Question of priority of pain of that now, or pain of waiting for 3.0, I think.

We don't have anything that actually uses a secondary sidebar, so I'm all good to punt that detail so long as we can come up with something that anticipates that possibility.

— Reply to this email directly or view it on GitHub https://github.com/omeka/theme-seasons/issues/8#issuecomment-14474690.

[patrickmj]

Not sure yet. I see a virtue in the seasons design of putting (some) things in a sidebar, which raises the possibility of plugin developers having the option to decide if it is sidebar-appropriate or primary-content-appropriate.

A theme-config thing saying 1, 2, or 3 columns would be awesome. But that depth seems like a 3.0 thing. An intermediary step of basic ways to work with either 1 or 2 column themes -- as we currently have bundled -- seems good.

[zerocrates]

I didn't mean that the theme should have a config option deciding how many columns it has (though a theme could already do that now).

I meant more that the theme could have a config option for where the hooks go: in the sidebar or in the primary content area. This still sticks all the plugin stuff in the same place, but the user can change where that is without editing the theme, and make their own judgment about what works best for the plugins they're using.

I get, and agree, that it would be nice for plugins to be able to add more minor or merely informational content and have it appear in the sidebar/aside, but we're not set up with the hooks to really allow that. One extra hook for "minor" or "secondary" information would get you that flexibility for 2-column themes, but not for three. No number of hooks gives you any reasonable control over vertical placement of plugin content, either on the page as a whole, or among the various plugins. I don't really see any way to reasonably do that, short of "widget-y" functionality. (I agree that's a 2.1/3.0 conversation, not something that could happen in this theme or in the immediate future.)

Back to the actual topic, I don't really see how the current seasons "works" with a great number of plugins when it sticks things in the sidebar. Off the top of my head, Commenting, DocsViewer, ZoomIt, ImageAnnotation, Geolocation, and any number of other plugins won't work well in the sidebar (Geolocation might be fine). Some things work great in the sidebar, and really should go there, but "some" isn't an option here at the moment.

[patrickmj]

Sounds like we'll just keep this on our collective radars for future awesomeness. Thanks!

[kimisgold]

For now, I've moved the hook so that plugin content appears in the primary content space. (See: a5bb8d1986f19b805e162df787d27f759c209b76) Should this issue stay open for further discussion regarding plans for handling plugin sidebar content?

[zerocrates]

That probably should be an omeka/Omeka issue instead.