Forum Replies Created

Viewing 15 replies - 46 through 60 (of 272 total)
  • Plugin Author Firelight

    (@firelightwp)

    @sonicgyn – Sorry for the delay. I just checked this today. A few notes:

    • The photonic galleries at the bottom of your page (‘campus party’, etc’) seem to be working for me on both web and mobile. Did you resolve this? Or are you just making sure to use settings that work (not php generated, lower resolution than “Large, 1024px longest side”)?
    • I installed Photonic locally. I tested only against native WP Galleries as I don’t currently have a Flickr account. The lightbox seems to be working well.
    • I did test the php vs javascript “Loading Mode”. For me – and with default WP galleries, the php loading loading mode works fine on desktop and also on mobile (ie, our lightbox opens fine on mobile). So I wonder if that setting is problematic only for Flickr galleries, or is interacting with some other setting.
    • I could not (yet) test the image size setting for Flickr galleries. It looks like I’d need to set up a Flickr gallery to test. I’ll probably do that, but there’s some extra work involved, so it’ll take me a bit.
      • You said that if you use a larger size, on mobile, and try to click on the image, the lightbox tries to open the image, but it just keeps spinning. I want to confirm that if you let that spinner go for a while, the image doesn’t eventually open. If you are trying to load the full size original images, and the images are large, and you are on a mobile connections, it’s possible that it just takes a while for the lightbox to load the full size image.
      • That being said, it sounds like the 1600px option isn’t working either, and that should certainly work. The only other things I can think of here is (a) the larger images don’t exists – I’m not sure where Photonic is pulling those image sizes from, WordPress or Flickr or (b) the markup of the gallery would need to change for large image sizes on mobile – our plugin depends on certain image markup being there to work. In any case, the would all need more testing.

    If you have further thoughts, let me know. Otherwise, it’ll just be in me to get set up with Flickr soon.

    Plugin Author Firelight

    (@firelightwp)

    Hi @tonyghaffari!

    No, if you add new images to the media library, this plugin won’t automatically add them to one of your galleries and then open them in the lightbox. You’d need to manually add them to each gallery or slideshow.

    One way to think about this is that our plugin doesn’t create or add, say, a gallery of images. Those galleries/images are added via a range of methods: the block editor (image or gallery block); plugins like Elementor, NextGEN Gallery, or Modula; or even via HTML. So our plugin doesn’t control which images are in a gallery at all.

    Our plugin just ensures that when you click on those images, they open in a large, nice, consistent lightbox, and also adds functionality to that lightbox once open.

    Let me know if you have other question!

    Since the original question is answered clearly (even if not the answer you may want), I’m going to mark this resolved. But please feel free to follow up!

    Plugin Author Firelight

    (@firelightwp)

    Glad you figured it out! And thanks very much for following up with an update!

    Plugin Author Firelight

    (@firelightwp)

    Hi! I’m happy to look at this and see what might be involved in getting it looking. Any chance you can share a link to a live page (if you’d like to keep it private, you can reach out at https://firelightwp.com/contact)?

    In the meantime, I can try to install Photonic and see how it works and, depending on the complexity/setup, see if I can duplicate your issue.

    Plugin Author Firelight

    (@firelightwp)

    Hi @fitsmartyou

    Thanks for the report and for sharing the link. It’s a nice site you have!

    1) Desktop: I can see what you are seeing for this – the white layer covering 75% of the document. This is not something I’ve ever seen before on any test site or customer site, so I have no idea what’s doing that. It’s very likekly to be something specific to your site. Can you describe to me in detail how you are adding the PDF to the page?

    2) Mobile: Unfortunately, opening PDFs with fancybox in mobile is known to have issues. This isn’t so much an issue with the plugin as it is an issue with the underlying fancybox script (fancybox is a JavaScript library – and our plugin just wraps it). See https://github.com/fancyapps/fancybox/issues/1542 for example.

    I’m working on a solution for mobile PDFs – I may integrate PDF.js or try loading PDFs using a different JS library when on mobile. Given the complexity involved, it’s possible this will be released as part of the Pro plugin rather than the free one. I’ll share here when there’s an update.

    In any case, it *should* work on desktop, so feel free to share details on that and we’ll see if we can figure out what’s going on there.

    Thanks!

    Plugin Author Firelight

    (@firelightwp)

    @courteneycox1 – When looking at the code, you have the nolightbox class on a div that is several layers up from the a tag or img tag. I’m not sure how you’re adding content – maybe Divi? But is there any ways you can apply the noligtbox class the the a tag / link?

    Plugin Author Firelight

    (@firelightwp)

    That would be great. You can reach out to us via https://firelightwp.com/contact

    Plugin Author Firelight

    (@firelightwp)

    @ws24 – if you have a site where the free version is working and providing nav arrows with Modula, please feel free to share the link and I’ll see if I can understand what’s happening there.

    But there’s never been an explicit effort to make the free version of our lightbox work with Modula. As far as I know, it’s always worked like it works now, and depends on the lightbox settings for any specific Modula gallery. With Easy Fancybox 1.9.9:

    – If a Modula gallery is set to use Modula’s lightbox, it will open with that. And you can turn on navigation arrows for Modula’s lightbox.
    – If you set your Modula gallery/images to have no link, they will not open at all.
    – If you set your Modula gallery/images to link to the media/image file, they will open in our lightbox because our lightbox tries to detect any image link, no matter where it comes from. But you won’t see navigation arrows – that requires logic to make fancybox ‘group’ images as a gallery. Again, I don’t think that ever worked in the free version, though I suppose it’s possible it worked accidentally with some combination of settings.

    You can download 1.9.9 (or other older versions) here to test. I just tested 1.9.9 to confirm. If you find something different than I’m saying above, definitely let us know!
    https://wordpress.org/plugins/easy-fancybox/advanced/

    (FYI – for the Pro lightbox version, we’re making a more deliberate and comprehensive effort to support Modula, including all Modula gallery types (free and pro) and all lightbox functionality. Be aware there is still some Pro functionality that’s not working yet. For example, the Pro lightbox won’t currently load EXIF/IPTC captions or camera data for Modula images, but that’s in progress.)

    Plugin Author Firelight

    (@firelightwp)

    Hey there – I actually just decided to release this. It’s included in version 2.3.9. Whenever you update, feel free to confirm the issue is resolved for you. Thanks again!

    Plugin Author Firelight

    (@firelightwp)

    Hi there! Yes, this is a grouping issue. Fancybox doesn’t know to group images based on Modula Galleries as a third party plugin.

    This capability is supported in Firelight Pro. The Pro Lightbox supports Modula Galleries out-of-the-box – just enable and go. If you want to continue using the free lightbox styles, the Pro Lightbox adds something called custom grouping for those lightbox styles. You just enable that, and add .modula-gallery to the list of selectors for grouping images.

    Plugin Author Firelight

    (@firelightwp)

    Update: I’ve pushed a fix for this. It will go out in the next release. I’m still trying to decide if this fix itself is worth a small release or if I’ll save the fix and package with other fixes or improvements in a week or two. If you have strong preferences to release a fix now, let me know and I can do so.

    Thanks!

    Plugin Author Firelight

    (@firelightwp)

    Hi – Thanks for the report! I wanted to confirm that we can duplicate ths. As you noted, it shows only on the widget editor screen. We’re working on a fix and will share updates here when we have them.

    Plugin Author Firelight

    (@firelightwp)

    @dll416 – Great information – that I missed. Thank very much for posting / sharing.

    Plugin Author Firelight

    (@firelightwp)

    Hey all – I forgot to follow up here yesterday, but I did push another release yesterday to address this. I wasn’t able to duplicate the issue with the last version, but there was a place where it was possible we were running translations early. Yesterdays small release addressed that and hopefully captured what the other two posters above were seeing.

    In any case, based on responses above, it sounds like this is fully resolved now. Thanks to both of you above for following up and confirming. Much appreciated.

    Side note: @oldrup, as you noted, this is quite a common issue following WP 6.7. My local dev instance has three other popular plugins generating the same warning right now.

    Plugin Author Firelight

    (@firelightwp)

    Hey all – I’m very familiar with the issue. It’s outlined here:
    https://make.wordpress.org/core/2024/10/21/i18n-improvements-6-7/

    To copy the relevant parts here:

    WordPress now warns developers if they are loading translations too early in a plugin or theme, before the current user is known. Existing functions like load_plugin_textdomain() and load_theme_textdomain() were updated to defer the actual loading to the existing just-in-time translation logic in core.

    And:

    Reminder: if your plugin or theme is hosted on WordPress.org and is still using load_*_textdomain(), you can remove this call. Since WordPress 4.6, plugins and themes no longer need load_plugin_textdomain() or load_theme_textdomain(). WordPress automatically loads the translations for you when needed.

    We did that second step, and removed these functions entirely from the code base. So the functions that trigger this warning simply *do not exist* in our plugin any more.

    Obviously that raises a question of how more than one of you is seeing the error. Right now, my guess is that the issue goes beyond what’s reported in the post above, and that if there’s any code trying to use any WordPress translation function before a certain point in WordPress execution sequence, it will still trigger the warning. I’ll check and see what may be going on there and follow up.

    Thanks again for posting here and raising the issue.

Viewing 15 replies - 46 through 60 (of 272 total)