Forum Replies Created

Viewing 15 replies - 1 through 15 (of 201 total)
  • Plugin Author steveush

    (@steveush)

    Hi Colin,

    Ok, the behavior you’re seeing is from the lightbox captions Auto-hide on Mobile option, this essentially ensures captions are in a closed state on mobile devices in order to preserve maximum viewing space for the media. You can adjust this behavior by opening the gallery edit page, then navigate to the Gallery Settings > Lightbox > Captions tab. Once there simply switch the Auto-hide on Mobile option from Auto-hide (default), to Always visible.

    Thanks
    Steve

    Plugin Author steveush

    (@steveush)

    Hi Colin,

    Unfortunately I haven’t been able to replicate this stuck in loading behavior. The page I used for testing was https://2027.sebeetles.com/1963-vto/ and items with captions could correctly show them on mobile using Chrome DevTools. Is there a specific page you’re seeing this behavior on? If there is one please provide the exact URL so I can see if I can replicate using it, maybe there is something on a specific set of pages conflicting with our plugin.

    Apart from the testing, I also traced the caption loading code paths and theoretically there’s no path that should result in the fg-loading state becoming stuck, so this is a bit of an odd one to me.

    Thanks
    Steve

    Plugin Author steveush

    (@steveush)

    Hi @angelamarie-1,

    Thanks for letting me know! I’ll include this fix into the actual plugin code so it should be part of the next release, you could then remove that custom snippet.

    Thanks
    Steve

    Plugin Author steveush

    (@steveush)

    Hi @angelamarie-1,

    I think I have found the root cause of the issue, please could you try the following JS snippet by inserting it into the FooGallery > Settings >Custom JS & CSS > Custom Javascript option. Once inserted and saved, make sure any caches are cleared (browser & site) and then try the search again and let me know the result.

    (function( _ ) {

    if ( ! _ || ! _.Item || ! _.Item.override || ! _.utils || ! _.utils.is ) {
    return;
    }

    var _is = _.utils.is;

    _.Item.override( "construct", function( template, options ) {
    this._super( template, options );

    var attr = this.attr || {},
    anchor = attr.anchor || {},
    image = attr.image || {},
    caption = anchor["data-title"] || anchor["data-caption-title"],
    description = anchor["data-description"] || anchor["data-caption-desc"];

    if ( _is.empty( this.title ) && _is.string( image.title ) ) this.title = _.safeParse( image.title );
    if ( _is.empty( this.alt ) && _is.string( image.alt ) ) this.alt = _.safeParse( image.alt );
    if ( _is.empty( this.caption ) && _is.string( caption ) ) this.caption = _.safeParse( caption );
    if ( _is.empty( this.description ) && _is.string( description ) ) this.description = _.safeParse( description );
    } );

    })( FooGallery );

    I think this is an issue caused when the items are split up and some are passed to the frontend only as JSON objects for paging. The properties the search checks are not properly normalized until those JSON items are actually made into DOM elements and inserted into the page. I believe the above fix should resolve that.

    Thanks
    Steve

    Plugin Author steveush

    (@steveush)

    Hi @lennox2017,

    There are a number of CSS issues regarding our plugin happening on your site and they are being caused by WP Rocket. You can confirm this by using the ?nowprocket added to the end of your URL’s, for example: https://www.groeneluxe.nl/lappenmos/?nowprocket

    WP Rocket can cause a number of problems based on configuration, they have dedicated articles to work through and resolve issues like yours, please take a look at https://docs.wp-rocket.me/article/106-my-site-is-broken which is the main introductory article. The specific issue in this case is I believe the “Remove Unused CSS” feature, here is the associated troubleshooting article https://docs.wp-rocket.me/article/1718-troubleshoot-remove-unused-css-issues. WP Rocket has removed a lot of our plugins CSS which it thinks is not needed but actually is. I recommend “safelisting” FooGallery’s CSS file to prevent WP Rocket from touching it entirely.

    Thanks
    Steve

    Plugin Author steveush

    (@steveush)

    Hi @hannahha,

    Thanks for giving us access to your site, for future reference and to close this ticket, the issue was a mix of stale caches between FooGallery and LiteSpeed cache. After clearing both, the issue was resolved. The update mentioned by @bradvin contains some improved logic around our caching to prevent this occurring again from our plugin’s side.

    Thanks

    Plugin Author steveush

    (@steveush)

    Hi @hannahha,

    To be honest I’m not 100% sure what the issue may be seeing as clearing the CSS cache resulted in no change. Could I ask you to please log a ticket to our PRO customer support by sending an email to support.foogallery(at)fooplugins.com, just replace the (at) with @. Even though you’re a free user we’ll pick it up on our end and continue there as I think the next step would probably involve you providing us a temporary login so we could take a look first hand, and that’s definitely not something to discuss on this public forum.

    Thanks
    Steve

    Plugin Author steveush

    (@steveush)

    Hi @greentreefrog,

    I’ve completed the patch, it fixes both the ordering and the back tab issue, it should go out in a release later this week once we’ve completed testing on our side.

    Thanks

    Plugin Author steveush

    (@steveush)

    Hi @hannahha,

    This is a bit of a strange issue, the CSS file for FooGallery is being served as HTTPS on some pages and being blocked by the browser as your site currently has no certificate. The JS and all images are being correctly served as HTTP, it’s just the CSS file which is being incorrectly served on some pages. For me your home page URL displays the issue consistently while the observations page was displaying correctly.

    Could you please try clicking the FooGallery > Settings > General > Clear CSS Cache button, then try reloading the pages you were seeing the issue on? Please let me know the result.

    Have you recently switched from using HTTPS back to HTTP on your site?

    Thanks
    Steve

    Plugin Author steveush

    (@steveush)

    Hi @greentreefrog,

    I see what you mean, we originally relied on the default browser tab ordering, however the lightbox markup was changed slightly not too long ago which has affected the natural DOM ordering. I’ll take a look at this and correct the tab ordering within the lightbox. I’ll need to check our release schedule but It should make it into the next update.

    I’ll update this thread once I’ve made the patch and let you know.

    Thanks
    Steve

    Plugin Author steveush

    (@steveush)

    Hi @milasguii,

    Unfortunately this is an issue we can’t replicate locally on our devices or desktops, however I think the problem stems from two methods in the lightboxes close code path that could potentially end up waiting for JS promises that are never fulfilled. As we can’t replicate the issue, I unfortunately can’t test a patch locally so this involves a little bit of guess work.

    Please try adding the following code snippet to your FooGallery > Settings > Custom JS & CSS > Custom Javascript option, it contains the changes I think should resolve the problem.

    // Temporary test patch for lightbox close cleanup.
    ( function( $, _, _is, _fn ) {

    if ( !$ || !_ || !_.Panel || !_.Panel.Area || !_is || !_fn ) {
    return;
    }

    _.Panel.override( "doClose", function( immediate, detach ) {
    detach = _is.boolean( detach ) ? detach : true;
    var self = this;
    self.isClosing = true;
    return $.Deferred( function( def ) {
    var closeArea = function( area ) {
    try {
    return area.close( immediate );
    } catch ( err ) {
    return _fn.reject( err );
    }
    };
    $.when( closeArea( self.content ) ).always( function() {
    var wait = [];
    self.areas.forEach( function( area ) {
    if ( area !== self.content ) {
    wait.push( closeArea( area ) );
    }
    } );
    _fn.allSettled( wait ).then( function() {
    def.resolve();
    } );
    } );
    } ).always( function() {
    self.isClosing = false;
    self.currentItem = null;
    self.buttons.close();
    if ( detach ) self.detach();
    self.tmpl.state.clear();
    } ).promise();
    } );

    _.Panel.Area.override( "close", function( immediate ) {
    var self = this;
    if ( self.currentMedia instanceof _.Panel.Media ) {
    var current = self.currentMedia;
    if ( !immediate ) {
    self.panel.trigger( "area-unload", [ self, current ] );
    return self.doUnload( current, false ).then( function() {
    self.panel.trigger( "area-unloaded", [ self, current ] );
    } ).always( function() {
    self.currentMedia = null;
    } );
    }
    self.panel.trigger( "area-unload", [ self, current ] );
    self.doUnload( current, false ).then( function() {
    self.panel.trigger( "area-unloaded", [ self, current ] );
    } );
    self.currentMedia = null;
    }
    return _fn.resolved;
    } );

    } )(
    FooGallery.$,
    FooGallery,
    FooGallery.utils.is,
    FooGallery.utils.fn
    );

    Once you’ve added the above to your settings and saved, clear any caches you might have (server & browser) and see if the problem persists. Please let me know the result.

    Thanks
    Steve

    Plugin Author steveush

    (@steveush)

    Hi @wpteknet,

    The carousel JS internally checks the current computed value for the CSS direction property of the gallery element itself to determine whether to display in RtL mode. As for the CSS it uses the .rtl class which is normally found on the body element.

    From your description it sounds like the .rtl class exists on one of the galleries ancestor elements (usually the body), this is normally set by the configured language in your WP settings, but either a theme or plugin could be adding it.

    If you could supply an example URL I could take a closer look for conflicts, at the moment my best guess is this is being caused by the .rtl class existing in the page when it shouldn’t.

    For testing I would also suggest disabling all other plugins and switching to a default WordPress theme and seeing if the issue persists. If it goes away then start re-enabling plugins/theme until it comes back so we can try narrow down possible causes.

    Thanks

    Plugin Author steveush

    (@steveush)

    Hi @astarich,

    Thanks for the feedback. I will fix the issue related to the incorrect cursor being displayed for captions when the gallery is set to not linked, however I don’t think we will change out the <a/> being rendered as it may break user customizations and it is valid HTML.

    Please note when set to not linked the <a/> does not have an href attribute and is used purely as a wrapper for the thumbnail image within the item. The <a/> will not take part in tabbing and should not register as an interactive element.

    Thanks

    Plugin Author steveush

    (@steveush)

    Hi @astarich,

    Thanks for letting me know about the issues, the first two regarding Image Viewer and Carousel I’ve already started to fix, however I’m not quite following your third point regarding caption text.

    If I’m understanding your third point, I think you have an issue with the way clicking an item (on the image or caption) either opens the linked url directly or within a modal. If this is correct, you should be able to prevent this behavior by changing the Gallery Settings > General > Thumbnail Link option to Not Linked. If I’ve misunderstood the problem, could you please elaborate on it a bit?

    Thanks

    Plugin Author steveush

    (@steveush)

    Hi @richtwebguy,

    I believe this has to do with the template you’re using, Carousel, and having max items set to 1. This template displays its items’ within a 3d virtual space, so it has width, height AND depth. Items that are hidden are stored at the maximum depth. The reason this is done is that with the expected usage of displaying multiple items, the current is centered and will show at full size and then the previous and next items are displayed on either side being “pushed” back slightly into the virtual space. This pushing back is what results in slightly smaller images as from your perspective it is now further away from you. So in your situation it is transitioning the next item from the back of the virtual space (hidden), to the front (visible), which gives the impression of it expanding slightly.

    There is a workaround you can use though, you can flatten the virtual space the items are pushed into, essentially setting it’s depth to 0. To do this please use the following CSS in your galleries Custom CSS metabox below the settings; please replace the placeholder gallery ID (XXXXX) with your galleries ID.

    #foogallery-gallery-XXXXX {
    --fg-carousel-perspective: 0;
    }

    To be honest I don’t think this is exactly the right template for what you are wanting, but the one I would suggest, Image Viewer, doesn’t support auto playing through it’s items. I’ll see if we can add auto play to it in a future update for users such as yourself.

    Thanks

Viewing 15 replies - 1 through 15 (of 201 total)