1.4.8: Single Image edit mode bug that returns to batch edit after apply. #933
Comments
|
Hm, we actually thought we had fixed that recently … At the moment I cannot reproduce the issue or I am not using the same settings. The order on the backend is just the backend display order and independent from the actual image order set via the album or gallery options. |
|
Ok, album is sorted by Date, Descending. Batch edit on this one album was set to Title, with 10 images per page. I edited the 6th image, changed something, hit apply and it went to batch edit mode. I then changed the batch edit sort to also be Date Descending, re-edited that single image, hit apply and it stayed on the single image. I then decided to edit the 11th image in single edit mode. Changed something, hit apply, and then it went into batch edit mode with the 1st image of the album at the top. |
|
Ahhh crap... nevermind. I need to pay better attention to which local gallery I am working with. Sigh. It works fine. Feel like dumbass now. |
|
Ok, I need to keep testing. It did just do it in the 1.4.8 version. |
|
Ok, what I described above is indeed happening to me in version 1.4.8 [3e3fac4] code. I was just testing using my other local gallery that was still 1.4.7. The 1.4.8 one is indeed doing the same thing. |
|
I was able to reproduce it once. Whatever I tried afterwards worked as it should. Weird ! |
|
OK, I edited admin-edit.php around line 844:
When I first edited the image, the output was: Array After I hit apply, this was the output: Which did not contain the image I was editing, so it went into batch mode. |
|
Here's my cheesy workaround for now where I just force the image into the array:
|
|
Ok, thanks so far. Will try to reproduce and look into the code. |
|
I have tried your scenario above but I sadly was somehow not able to reproduce it so far … Neither goes anything from the single edit to the batch edit page nor does the "back" button arrive on the wrong page… |
|
I can reproduce it at will with any album I have, even with the latest master. It never doesn't do it to me. I have an album with more than 5 images in it. I have the batch edit mode set to 5 images per page and sorted by Filemtime (descending) for example. I then have the Album sorted the same way, Filemtime (descending). I then view the 6th image:
Change something and hit Apply:
Unless I force the image into the array it opens in batch edit mode at the 1st image of the album. |
|
I do believe you that you encounter the issue. I will try again and let you know. |
|
I went ahead and upgraded the code on my other gallery so that both local development ones are running 1.4.8 and it has the same issue. Thanks for looking at it again. |
|
I sadly still cannot reproduce the issue … Do I miss any details maybe somewhere? No matter if I set the album sorting or the display sorting the same or different the image is in the array on the single edit page. Same if I change them around. I tried with changing images per page (my test album has even 500+ image) nothing unwanted happens. I am still never taken wrongfully to the batch edit from the single edit page. I display the array and the image I am editing is always in there, too, on the right position within its batch edit page … |
|
Sigh.. are we even running the same code? I can't get it to not happen and you can't get it to happen. The default batch edit is 10 images per page. I have 15 images per page in the gallery. If I pick an image on say the 2nd page to view then edit the image (single image edit), hit apply, then it goes into batch edit at the 1st image of the batch edit sort and not to my image. Happens with all albums in both my galleries. I guess I'll just keep my work around in the code and leave it at that. If you can't reproduce it, you can't figure out what's going on. I'll go ahead and update my production galleries anyway. Maybe I'll try some different themes and see what happens. I dunno. Hmm I could make a video of what is happening. |
The theme value uses a different option than the batch edit display and should not be related @fretzl also tried again and it didn't happen again for him, too. I tried a lot back and forth. Really strange. The only way to make that happen is to rename the filename of an image. But then it makes sort of sense. Make that video, maybe we are missing a detail or something. |
|
Here's a quick video I made. No audio though. https://www.youtube.com/watch?v=PBX-KcDrOIU If it needs audio explanation let me know. Try to figure out this recording software to only grab what I want. |
|
Thanks, it gives at least the missing detail that you come from the frontend. I did try from the backend only! |
|
Yep. I can reproduce it coming from the frontend. |
|
Oh, you guys were clicking on the edit all image data link from within the bulk image edit. LOL, I've never used that. I didn't even realize that was there. I was asking myself "what's the backend way?". Glad fretzl was able to reproduce it. Wish I had described it more clearly initially. Glad the video helped. |
|
That's why every tiny detail is important ;-) Now I can reproduce it as well and it makes sense since without the backend batch edit page it indeed uses the frontend order internally. |
…nd bulk edit subpage and jumps to the image.
This happened with 1.4.7 and still does. Reference to this thread: http://www.zenphoto.org/support/topic.php?id=1409016
Go to single image edit, change something in the description (or anything) and it goes into batch edit mode and no longer on the same image after hitting apply.
Whether or not it returns to the single image edit or the bulk image edit depends on the sort order of the bulk image edit vs the sort order of the album itself. If I edit a single image that happens to be in the top X of the bulk image edit sort, then it returns to the single image editor. Seems to be related to that bug with the single image edit before that I put on here.
I just hadn't caught it before because normally I am editing the most recent images which matches the sort in both places. I was editing an older image that I noticed it.
The text was updated successfully, but these errors were encountered: