msavage
Expert
Joined 15 years ago
User Profile
User Widgets
Contributions
Re: Searchable video gallery - any ideas?
A follow up question for anyone who's interested. Search integration seems like an overly complex request at this time. I'm open to any suggestions on good video gallery ideas- both gallery plugins and what page type(s) in Lithium might be the most accommodating to this layout/content.177ViewsSign in to react to this post0CommentsSearchable video gallery - any ideas?
I've got a collection of videos that I'd like to tile on across a layout, while making each one individually searchable. I could load them into a custom component to display, but I can't think of a way to pass them into the native search results. My best idea is to maybe place them as individual articles on a custom category layout so they can be found in search, then limit the article content to just some descriptive text and the video and have that display as a lightbox, but that seems a little janky to me. The other alternative I've imagined is to use the native video uploading/gallery functionality to create a gallery with an official or bot account, then link directly to that gallery in the site navigation. I haven't tested anything w/ video galleries yet, so I have no idea if those will appear in search if they're publicly listed. If so, that might be the best option, even if the module needs to be hacked into something custom for our community. Has anyone tried out anything along those lines?ViewsSign in to react to this postComment- ViewsSign in to react to this postComment
- ViewsSign in to react to this postComments
restrictions on nestable pages?
I've been working on some new pages and I was attempting to create a consistent header across all of them. However, I noticed a few things: 1) the default Header page has an override that prevents it from being nestable (it will revert false -> true changes in XML view on save, toggle is hidden in Canvas view), which makes it impossible to make a single Header and nest it in each page. The result is constantly having to add all of the header modules to each new page you create, which is highly inefficient. 2) As a workaround, I created a new Page (e.g. Header2) and a new Layout (Header2), assuming that I could make an exact copy of the current header objects with custom content, which would hopefully not be subject to the constraints of #1 above. I can see the 'nestable' toggle now, but the same thing is happening on save- it reverts to 'false'. It's a bit tedious and likely to cause errors if this replication must occur manually on every page we maintain. I've also noticed that the footer page can be nested, which thoroughly perplexes me, as it's common for a site to have consistently fixed header/footer working in tandem. Is there something I'm missing? I've seen new system pages without the frontend header content, but the page layout has the header sections (without the actual custom modules in the layout, though), so maybe they're added by default somehow?ViewsSign in to react to this postCommentsI did some research on this and I believe I've discovered the bug, I'm filing a ticket to have this fixed. The bug is this:
Certain core pages (such as Footer and Header), are set as "nestable=true" by default, so that they can be embedded in other pages. However, modifying any of these pages in the Page Editor, then saving them, auto-sets "nestable=false", thereby rendering them un-embeddable in other pages.
This is what happened in your case, since Header was edited and saved. For now, if you would like me to fix this for you (directly in the Header asset), send me a PM. Hope this helps!
Sincerely,
Venk
- ViewsSign in to react to this postComments
- ViewsSign in to react to this postComments
Hi msavage,
Here are a couple of options I've thought up....
Option 1: A little bit of JS
Our poll component uses jQuery to toggle hiding and showing the results. You could add your own custom component containing some jQuery to "undo" the default togging. Perhaps something like:
<@liaAddScript> (function ($) { $(document).ready(function() { $('.lia-show-trigger').hide(); $('.lia-hide-trigger').show(); $('.lia-toggler-component').show(); }); }(LITHIUM.jQuery)); </@liaAddScript>To me this approach seems fairly clean, and fairly easy. I'd definitely suggest some testing to ensure it's working exactly as you expect.
Option 2: Build your own polls component
It's a little less than ideal, but if you don't want to tinker with JS... There's a an additional poll component in our platform, separate from the one you'll find in Studio, called forums.widget.poll-component. This component requires a pollId parameter corresponding to the internal id of the poll, but also accepts a parameter called initiallyHidden which can be set to true or false.
If you're using this component inside your own custom component, it would look something like:
<@component id="forums.widget.poll-component" pollId="82" initiallyHidden="false"/>
Where 82 is the id of the poll you'd like to display.
A few caveats (why this is a little less than ideal)...
First, this component doesn't have a wrapper like the standard component (ie. no title, no borders, minimal styling). That's why I suggested placing it inside your own custom component instead of directly in a Page via Studio. What this means is that if you would like a wrapper, you'll need to construct that HTML and place this component inside of it.
Second, using this just as I've mentioned above will require obtaining the poll id and manually updating it. With a combination of freemarker and the REST API, you should be able to automate this. For example, you could use the REST API method polls/active to obtain a list of all the currently active polls for that particular node. You could then iterate through the list of polls and add a component for each.
Putting it all together, your custom component might look something like this (psuedocode)
<HTML for wrapper> <REST API call to polls/active for the desired node> <#list polls.poll as poll> <@component id="forums.widget.poll-component" pollId="${poll.id}" initiallyHidden="false"/> </#list> <HTML for wrapper>If you decide to go with Option 2 and need more help thinking through the code, just let me know.
I hope this helps!
177Views
0Comments
You’ve seen all recent content