edanzer

Cemal – we found your bug report. You’re good. No need to resend. I’ll review and follow up shortly.

Cemal – I hate to ask you to redo that work, but yes, if you can, just send me an email directly at the address above. I’ll also check with my team to figure out why your bug report hasn’t been received in our ticket inbox.

Hey Cemal –

To answer one of your questions above, just having a lot of galleries is not in itself a concern.

To provide some context, we DO make a somewhat complicated query, including joining, when fetching images. We’ve done that for years. The alternative is to make more queries. So we either do one more complicated query, or we do simpler queries but need 2x or 3x the number. In the past, query volume has been more of a concern for hosts and users, so we’ve optimized for that (even though one could make the objective case that more but simpler queries would be more performant.

But an important point is that we also cache all displayed galleries on the front end. So we run the image queries to fetch data for images when a gallery is first loaded. After that, the data is cached. We do not re-run the queries on each page load.

That means if you have 500 galleries but you don’t change most them after the first page load for each gallery, the structure of queries would be moot. You won’t be running the queries in the first place.

I’d also add that nothing about this behavior has changed in a long time, so whatever changed for you in the last month is likely not the result of any code changes or releases on our side.

–
Our sense from talking about your case is that either you’re doing something that frequently clears front end gallery cache for a lot of your galleries, or you are doing a lot of image management on the back end (we have to fetch the same image data for the manage gallery pages in the admin, and we don’t cache those, but those are also less frequently accessed).

I’m also wondering if you are using random galleries anywhere, which are more intensive and harder to cache.

In any case, I’m wondering if you can open a bug report with us. Please put “For Erick” in the title so I’ll see it.

https://www.imagely.com/report-bug/

I’d like to ask a bunch of questions about your site that might help us understand why you’re seeing this, and why you’re seeing it now when you weren’t a month ago.

If we can’t seem to identify something, I’ll ask for creds and get a dev to take a look.

@ptg2018 – Yes, we hid the upload tab on mobile devices in this update. That’s because it wasn’t working and we didn’t want to display functionality on mobile that wasn’t working. To be honest, we’re surprised this was working for you before.

We do plan to address this. But NextGEN uses a third party library, plupload, for uploading images. The issue is inside that third party library. So we’ll need to update or change that library. Because uploads are so sensitive, we didn’t want to update/change the upload library as part of our broader design update. A great deal of emphasis was placed on keeping the redesign perfectly stable.

Now that the redesign is out and stable, we’re planning to look at this. But until we resolve it, you won’t be able to upload from your ipad. That’s a significant limitation, we know. We’ll elevate the priority for it.

@dmason – Thanks for the update. We’ll also have our devs take a look and see if there’s any way to safely resolve that conflict from our side.

I do want to confirm that I just tested to this be sure that if I:

1) Insert an album
2) Go to edit that album it is still listed in the drop down above.

I just wanted to confirm that NextGEN isn’t somehow stripping prior inserted albums from that drop down when you go to edit.

“I would use the “import folder” function which is very handy” – I suspect that’s why it was working. The folder functionality should be fine, it’s just the main importer.

We agree wholeheartedly that we should be supporting image uploads on mobile by the way. It’s not something we took away. It just wasn’t woking before. And there’s not much point exposing functionality that won’t work. And again, we didn’t want to mess with the long-time uploader, which could have all kind of ramifications.

Once we’re sure the 3.0 release is steady and solid, which it appears to be, we’ll start looking at updating the uploader NGG has been using for years.

In the meantime, it sounds like in your case the main issue because we’re hiding the whole upload tab, it means the folder portion of that tab, which you were using is no longer visible.

To fix that, we’d need to more selectively hide only the upload tab until such time as update the uploader. I’ll make an issue for that, and review with team when we can add/adjust that for you.