Answers to questions and solving problems with Omni Gallery.
What is the point of providing multiple sliders and multiple galleries in one package, surely any site will only need one of each?
With all these display widgets available, we don't think any site should try and use them all. The only reason we use them all in the examples here is so you can see them, compare them, and copy example configurations to use on tour own sites.
Some of our display widgets are similar, or at least are capable of being configured to look similar. But they can also be configured to behave very differently. Different arrangements. Different navigation. Different transitions. Different interactions and different degrees of theme integration.
Consider the hassle and expense of working through a number of different addons looking for the one you like. Each needs to be installed, configured to show the images you want with the information overlay you need. Then you can finally evaluate what it actually looks like. Then you repeat the entire process for the next addon. Then once you have found what looks best for your site you need to clear up the debris from all the unwanted sliders and galleries that didn't quite make the grade.
With Omni Gallery you only install one addon. You only configure one addon to show the images you want and the information you need. Then you can quickly swap between display widgets to find the slider and gallery that looks right on your site.
Having found what looks right for you, as well as images listed from the file manager you can re use the same display widgets with different image sources to show galleries or sliders of page lists, user lists, calendar events, express objects, store products and more. Omni Gallery solves many more functional problems than simply picking images to show.
Omni Gallery provides many options for generating gallery styles. These are normally generated for each specific gallery block and injected into the page header as <style> elements.
If you would rather build such styling into a custom theme, output of Omni Gallery generated styles can be suppressed by selecting Suppress style output in the Advanced tab of the edit dialog.
A useful trick may be to initially use Omni Gallery to generate the styles, capture them from the page, then copy and edit the stles into your theme, removing block instance specific selectors.
Suppress style output is an all or nothing setting. Once selected, you will need to provide all styling through your theme css.
With v1.2.0, Omni Gallery supports two description groups in Image Selectors.
Each of these descriptions can be configured independently in the Image Selector and then selected independently in the Display Widget and Lightbox. For example, use Description in the Display Widget and Extended Description in the Lightbox. Or use Description in the Display Widget and both Description and Extended Description in the Lightbox.
Showing a lightbox overlay requires 2 complimentary settings
The usual loading problems for any gallery block are caused by inappropriate selection of image sizes and the elements used to display images. In general, make sure images uploaded are big enough for your purposes and no bigger.
Within Omni Gallery, there are some further settings you can take advantage of to optimise the galleries and sliders generated.
In Image Display and Lighbox, select an appropriate image element. For example, a picture element with source set and optimal selection of thumbnail types will usually be better for a site that has mixed mobile and desktop view.
If you anticipate the Lightbox being used a lot, it can sometimes be better to select image elements and sizes appropriate to Lightbox within Image Display, so reducing diversification of files loaded.
In the Advanced settings, experiment with Lazy Loading settings.
In Image Selection, slow loading could be the consequence of prefetching large lists of images. Using an Infinite Dynamic variant of an Image Source will limit the images prefetched to those needed for the current Pagination in Image Display.
If a gallery or slider does not show or is showing but empty, the most likely reason is that there are no images in it!
That situation is easy to detect when listing a fileset or folder, but a little more complex when creating a gallery from page or user lists. With a page or user list, Omni Gallery lists images for the pages or users from their attributes. Attributes for Associated Images are selected in the edit dialog based on their association with the page or user object - not on their actually pointing to image files. Hence it is entirely possible to have a page or user with no associated images, and that page or user is then omitted from the gallery.
If that situation applies to all pages or users listed, the gallery will be empty.
If you want items without associated images to show in the Omni Gallery display, the image source may have an option for a default image.
This is related to the above consideration for galleries built from images associated with pages or users.
The point to always remember is that Omni Gallery works with images. Anything else as a source is merely an indirect means of listing images. Hence a gallery built from a page list where a page provides 3 images will list 3 images, and while the image attributes will be different, the page attributes associated with each of those 3 images will be identical.
Related to this, Omni Gallery can be configured to only show an image once. Continuing with our page list scenario, if 3 pages have the same thumbnail image and that is the only image for those pages, with this option set only one copy of the image will be shown in the gallery with only one of the pages. The other 2 pages would then be superfluous.
When a page or user does not have associated images, you can force the Omni Gallery image source to list it by specifying a default image.
An Omni Gallery listing a File Manager Folder image source could show images for logged in users, but not for visitors/guests. This arises as a quirk of file folder listing. The concrete core permissions when listing are combined from both the permission to view the individual file - which is what you would expect; and permission to search the folder - which is not what you would expect.
A consequence is that even though a visitor has permission to view a file, when a folder is searched they won't see the file because they don't have permission to search the folder the file is in!
There are two possible solutions
Both of these could have unanticipated consequences, either allowing further searching that is not intended, or a gallery showing files that are not supposed to be visible to guests. Take care over which permissions you configure when using a folder image source.
One of the options on sorting a list of images sourced from a file folder is A-Z.
Behind the scenes, the A-Z list also picks up sort options from the dashboard file manager advanced search/sort. That is built into the way file folder listing works within some concrete CMS versions.
The consequence is that sometimes a folder image source sorter A-Z or Z-A will whoops and show an error screen about incompatible options in a MySQL database query. This arises from the dashboard advanced search and saved search settings. Those settings don't actually change what is listed by Omni Gallery, but they do result in the file folder list using a more complex than needed query and hence run into the conditions that cause the whoops.
The immediate solution to try is to go to the dashboard file manager and remove any saved advanced searches. That alone may be enough to enable A-Z sorting of folders to work again!
If that doesn't work out, if you can get the page with the Omni gallery into edit mode, you can cancel the A-Z sort, delete and re-create a block or revert the page version. From v.9.0.0, Omni Gallery also has a Panic Mode option. This is a configuration option you need to set manually at application/config/generated_overrides/jl_omni_gallery.php. When the key 'panic_mode' is set to true all Omni Gallery blocks on a site will show the edit mode marker. This will allow you to get pages into edit mode and make changes. Remember to reset 'panic_mode' to false afterwards!
Since version 9.0.0 Omni Gallery also provides options for Additional Sort on any attribute or property, including the image title and image name. These options are only available for some image sources, including Folder List Dynamic/Static (but not infinite). When selected, additional sorting is applied to intermediary lists of images before display and after images have been listed and paginated. If used with pagination you will get sorting within a page of images, but not across pages.
When building galleries from list of pages, users, calendar events, express entries or products, Omni Gallery retrieves images from their attributes. Omni Gallery is already configured to work with a selection of core and 3rd party attributes and will automatically detect them where installed to a site.
Currently supported attribute types for images are:
If you have another image selecting or listing attribute type installed, you can configure Omni Gallery to use it by editing the config file at /application/config/jl_omni_gallery.php. Details are provided at Attribute Sources.
What we are looking at here is often called a Hero Slider. There are essentially three aspects to achieving a full width slider or gallery:
Other considerations such as managing the height of the slider and position of information overlay are discussed in the notes for creating a Hero Slider.
Filling the height of the page is often associated with filling the width of the page, so we have a full page hero slider.
If what you really require is for the slider to be the background for the entire page, first consider Full Page Background with Vegas.
However, when you actually need a slider with information overlays for each slide, you can simply add a slider, full width or otherwise, and set the image height to 100vh. The vh units are a percentage of the viewport height. So 100vh is translated to 100% of the height of the viewport.
Suppose you have a Magnific overlay that needs to show a large amount of text. That works OK on a large screen, but on a smaller screen it gets truncated by the bottom of the modal. You need a vertical scroll bar.
The trick is to set the position bottom of the overlay to none/ignore and the height to either Auto or a big number. The position of the overlay is now governed by its position top and, where necessary, extends down from the window. The entire overlay will now show a vertical scroll bar.
You can use this with any variation of left, right, and top position for the overlay. As long as you don't set a bottom position, it can extend down below the window and the entire overlay will scroll vertically where necessary.
If a gallery does not work, it could be that something is interfering with the gallery display widget's JavaScript. Galleries attach themselves to DOM elements. A typical problem scenario is that after a gallery has attached itself, something else manipulates the DOM and breaks that attachment.
The solution is to manipulate the order in which the scripts initialise, so that the gallery display widget initialises after the interfering JavaScript has finished messing with the DOM, or to forcibly re-initialise the gallery display widget after the DOM messing has completed. This is a bit too complicated to provide a generic solution. If you need help, please contact me for support and we can discuss your problem and possible solutions.
Another scenario is an over-enthusiastic smooth scroll script hijacking controls in the gallery display widget. Here the solution is easier, just make the smooth scroll less greedy about what it selects.
The opposite is also possible. In particular, the Vegas display widget manipulates the DOM about the element it is attaching a background to. This can break the attachment of other JavaScripts to elements within that DOM element. Unfortunately the vegas.js is not as well behaved as we would have liked, so it can be neccessary to delay the initialisation of the other JavaScript until after Vegas has finished messing about!
What we mean here are things like visual ripples or tearing as one slide transitions to another. Transitions in any slider or gallery are managed by creating a rendered object for the next slide, then transitioning out the existing slide while transitioning in the next slide. This can involve CSS transitions or discrete movements in JavaScript, but underneath it all the underlaying mechanism is the processor or graphics card shuffling bytes about until the new slide is in place and the old slide is out of view.
With that underlaying constraint in mind, such transition artifacts are usually a sign of the browser rendering engine or device graphics hardware not being able to keep up with what is going on. The more bytes that need to be shuffled, the harder the browser and hardware will be working. Hence small sliders rarely show artifacts, whilst big sliders are more likely to show artifacts.
If you are seeing unwanted artifacts in your image transitions, what can you do about it?
While experimenting, you can record current settings using the Export button on the Support tab, so you can always get back to or replicate a previous slider independently of page versions.
In the Advanced tab of the edit dialog, Replace with marker in edit mode will normally decide whether the Omni Gallery block shows as an edit mode placeholder or a static view of the gallery or slider.
However, some display widgets are unable to partially render in edit mode. Those widgets will always replace with a marker and ignore this setting.
For example, trying to display a Vegas background in edit mode would interfere with the concrete5 editing process. Similarly, the Swiper JavaScript is just too complex to run in edit mode.
There is some overlap between the capabilities of Omni Gallery and Universal Content Puller. Both can create lists of things and display them.
Omni Gallery Elements searches for elements in all packages and in /application/elements. It then filters out some packages and elements and highlights elements declared as compatible because they are in an /omni_gallery_elements/ subdirectory.
You can set some configuration lists in /application/config to customize what gets filtered on your site, see Fine Tuning the Element Selector.
From v.9.0.0, Omni Gallery has a Panic Mode configuration option. This is a configuration option you need to set manually by editing the file application/config/generated_overrides/jl_omni_gallery.php.
When the key 'panic_mode' is set to true all Omni Gallery blocks on a site will show the edit mode marker. This will allow you to get pages into edit mode and make changes such as reverting a page version or adjusting anything that is causing an Omni Gallery block to whoops the page.
Remember to reset 'panic_mode' to false afterwards!
What we mean here is an internal code exception in an addon or the core when you click the install button from the Add Functionality dashboard page or when you visit a page after installing an addon package.
If you experience such an issue, here are a few things you can check that may resolve the problem.
If you experience a code error on or immediately after install and need assistance, please use the Get Help link from the addon marketplace page to report the problem. On the Whoops report, click the [copy] button immediately below the error message. That will provide a stack trace you can paste into the help request and save time having to request that report later.
A windows system can throw an exception about cache path length. The full message will be something like "Cache path exceeds Windows PHP MAX_LENGTH of 260 characters" and the name of the exception is WindowsPathMaxLengthException.
This arises as a combination of ConcreteCMS and php internal issues. From JtFResources v2.19.32 we have a work-round for this by introducing the configuration value max_key_length in the file application/config/generated_overrides/jtf_resources.php. On windows, this will be automatically set to a value suitable for most windows installations.
If you experience the above exception:
In general, keep the value of max_key_length as high as practical for your installation. The ConcreteCMS core applies a hashing algorithm to all cache keys and a longer value for max_key_length reduces the (already extremely small) probability of cache key collisions.
Perhaps you are unable to connect your site directly to the ConcreteCMS marketplace to install an addon or theme. This manual process works for all addons and themes - not just mine.
The process is exactly the same for addons and themes, except themes have an extra step of activating the theme after installing.
Sometimes step 3 above can run out of PHP execution time. This is most likely when installing an addon or theme that installs a large amount of sample content. You should not run into such an issue with any of my addons or themes.
If you do run into such issues, you can run the install manually from the shell command line.
$ concrete/bin/concrete5 c5:package-install my_package_handle
or
$ concrete/bin/concrete5 c5:package-update my_package_handle
When updating, be sure to replace the previously installed package directory rather than adding to it. If not, you could end up accumulating obsolete debris from a previous version of the package.
If you find yourself needing to install or update many addons or themes manually, consider my Package Magic addon.
Once Package Magic Starter is installed, through the marketplace or manually, all further installs can be handled from the site dashboard using Package Magic.
Most sites have just one, or maybe a few, gallery and slider formats. So once you have your gallery and slider formats configured, you can do similar for all galleries and sliders within your site. See Simplifying Omni Gallery.