2

Admin user wants to be able to upload image banners and select on which pages/nodes/views/panels to show it when visited (as a wide screen image banner above title).

It means when creating the banner node and uploading the image, there should be some field or list of pages to select from. But e.g. Views pages has no NIDs.

I kind of came up with a solution with Panels, where you just add field for your Article content type and upload the banner and then display it via Panels, so it would show above Title, etc. But it works only on node pages, but not Views pages. And that's still very limited, it means you need to add the banner field to every content type and still no solution for Views pages.

Is it possible somehow to have some type of a field that would autocomplete the path/node nid/view path when entering keywords and would be also separated by comma for multiple paths/pages and then render it via Views using contextual filters and output the view display via Panels?

enter image description here

  • If you leave aside the fact that blocks are not fieldable is the best solution you can think of! However I like this question and a short answer could be: use the entity reference field to go with the nodes part, no need for panels, as for the rest (views/panels) are more complicated in terms of implementation. – mchar Sep 13 '16 at 19:26
0

There are a few ways of going about this... and I have literally done dozens of formulas for it since Drupal 6.

The way I usually go about this is with Bean (Drupal 7). Create a new Bean that will represent your banner, add some fields - then let the admin create the bean. Since it is based on blocks, you can set content type visibility or path visibility, and if you add Context (if you need that muscle) you get a lot more options.

Another way to do it, which is hard to describe in a comment, is to setup an entity type for banners (since they are not content), add the fields you need, and then on the node level, add an entity reference field. Create a view that displays the entity type in a view mode of your choosing, and base it on the ER relationship value. As you said, this won't solve Views pages, which is why you might want to stick with the block route. This formula is a little similar, as it entails relating whatever banner entity the user wants to the given node, and, you can set a default value to one banner if you need that option.

Yet another way to do it is to put a Field Collection representing banner components (title, link, image), and hide the Field Collection from the node rendering. Create a View, feed it the node id contextual filter, and have it render the node in a 'Banner' view mode, which will only hold the field collection. Then just theme that level of templates, and you're good to go.

The first way (with Bean) seems like your best option, whereas the second two put the creation aspect in the node form, but you lose a way to set them on non node pages (since the Views arg will fail). Blocks won't care what the page is made up of, as long as the path or visibility rule matches.

  • Doesn't it mean you will need to create a separate block for each and every banner you want to show in different pages? – user13176 Sep 14 '16 at 9:16
  • Yes. No different than on a node level really. – Kevin Sep 14 '16 at 11:00
  • AFAIK The functionality you are looking for -apart from nodes- does not exist out of the box. The closest module to your scenario I can think of is context – mchar Sep 14 '16 at 11:26
  • But you can do same with just default block feature where you enter views paths manually instead of checking Views boxes inc Context. – user13176 Sep 14 '16 at 12:31
  • From your screenshot I know what you are trying to do, it is how I built my first "banner" module for D6 many years ago. In the end, you're basically recreating what blocks can already do on their own, hence the suggestion to use Bean. That would remove many layers of complexity and get the same result. – Kevin Sep 14 '16 at 14:05
0

For now, solved by adding a image field for banner for the content type and then attaching the view block to node (to by pass view-nodes) via panels (with visibility rules).

So now, user can edit banners in all pages, because they are all nodes + views attached below them.

No one-page-settings-with-all-banners (like in screenshot) though.

But it works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.