Custom Field Map All Attachments not working

Thanks for your report and especially for taking the time to dig through the WordPress log and include the message text, which is really helpful.

It looks like this statement comes from another plugin, EWWW Image Optimizer. Are you running that plugin?

If so, I would suggest deactivating it long enough to try the “Map All Attachments” task and see if that improves things. Give it a try and post an update here. Thanks for your help and for any additional details you can provide.

David, the good news is that deactivating EWWI Image Optimizer seems to have solved that problem. I should have realized it was the cause when I saw the name in the error message.

Now when I try to run it, it gets just so far then quits with a 400 bad response from the server. I suspect this is caused by my crappy server. But it seems to start over from the beginning every time. I think that I could get it to work eventually if I had a “Continue from where you left off” option. I’ve tried it four times and it got as far as 60% at one point, but then it craps out. This last time it said 1,250 completed, 1,250 unchanged, 0 succeeded (because they had already been processed). Is there some way I can start it from a certain record?

By the way, no error in the WP error log. There’s probably something in the Apache error log saying that the server timed out, but I haven’t looked.

Thanks for the update regarding EWWI. I found this explanation of the HTTP 400 error:

HTTP 400 Bad Request

which suggests a browser problem (95%). If you know how to use the Developer Tools in your browser you may get more information on the problem.

The current MLA version doesn’t have a “start from item X”. I will look into adding that and post an update here.

In the interim you could try changing the “Bulk Chunk Size” on the Settings/Media Library Assistant General tab. Try 50, or 10, or 34 to see if you can get past the problem.

If the update always stops in the same place it is possible you have a damaged Media Library item. Maybe you can find the last item that has the custom field set and the first item that failed. Try sorting your Media/Assistant submenu by the ID/Parent column.

I will look at the “start from item X” enhancement. Try the check size experiment and damaged item search and let me know what you find. Thanks for you patience.

I have just uploaded a new Development Version that lets you “start from item X”.

If you click on any mapping operation, then click “Cancel” in the progress display you will see a new “Resume” button and a text box with the current offset. You can just click Resume to continue the mapping, and you can change the number in the text box to skip over (or re-process) items.

You will see a summary of the items skipped or re-processed as the mapping continues.

Step by step instructions for installing the Development Version can be found in this earlier topic:

MLA errors when using plugin

Please let me know if you give this a try and/or if you have found the cause of your problem. Thanks!

David,

I installed the Development Version and it worked, with some persistence.

1) I got the first bad request from the server at 1300 complete.
2) It wouldn’t let me cancel at that point. So I tried to refresh the screen and got bad response from the server for about 30 seconds.
3) Then the refresh worked. I started it again, then stopped it immediately and got the resume options. I told it to start at 1300.
4) It broke again at 2400, but I repeated the above until all 4240 records completed.

And that’s it. I really appreciate your taking the time to put in the resume. I think that it’s going to be a big help to folks who have large image repositories.

By the way, I love Media Library Assistant and don’t think that I could handle our large image repository without it.

Thanks for all your good words and for this progress report. I am very happy the Resume function was able to help you get through the entire Media Library.

Of course, it would also be great to know why the errors occur and if they can be fixed. If you have the time and interest, it would be interesting to see of you re-ran the entire job and got the errors at the same places, e.g., at 1300 and 2400, or whether they move around. If you got a failure at, say, 1300, you could try “backing up” and re-running from 1250 to see how that goes. There’s no harm in backing up and re-processing some of the records.

It would also be interesting to see the network traffic, which you can do with the Developer Tools in most browsers. I knoe that may be more trouble than it’s worth.

Either way, Thanks for your help and for your interest in the plugin. I will leave this topic unresolved until the Resume function goes out in the next MLA version.

I have run it several times and it doesn’t always stop at exactly the same spot, but close to. For example, 1225 rather than 1300, etc. I just think that it’s my crappy provider. When I get a chance, I’l check the network traffic.

I have a related question, though, but perhaps it should be a separate post. Anyway, even though I have “Enable custom field mapping when updating media metadata” checked and saved, the MLA screen doesn’t update the custom field value when I make a change and refresh.

I’ve set up a custom field to help me identify super large files via sorting, then I edit the image, change the scale, and save. When I returned to MLA I was expecting the image I just fixed to have its custom field (file size) updated, but that’s not happening.

Thanks for the additional information about the network errors. If you do run more experiments and capture the network traffic, let me know.

Regarding the custom field mapping, I ran some tests and found some interesting results. When you click the “Scale” button, the rules DO run and the custom fields in the database are updated. However, the Edit Media screen does not refresh and the values in the Custom Field meta boxes on the screen are not updated. If you leave the Edit Media screen without making other changes or clicking “Update” the new value will appear in the Media/Assistant submenu table.

However, if you click “Update”, WordPress will carefully take the old, outdated value out of the Custom Field meta box and save it in the database, overwriting the updated value! That happens whether the Custom Field meta boxes are displayed or not.

I’m not sure how to prevent that, but I will ponder it. You can avoid the problem by either leaving the Edit Media screen or by clicking the “Map Custom Field Metadata” link in Save meta box at the upper right corner of the screen. I know that seems redundant, but it works.

Thank you for the pointer to the “Map Custom Field Metadata. If I take the following steps, everything is well.
1) Edit the image
2) Change the scale
3) Select “Map Custom Field Metadata” and wait for the refresh
4) Select Update and wait for the refresh
5) Refresh the MLA

It sounds like a lot of steps, but it doesn’t take long.

One more question. I’m running the development version of MLA now. Will it get update notices like the “live version?”

Thanks for confirming my suggestion about steps to ensure your custom fields get updated.

Unless you are making other changes in the Edit Media Screen you can eliminate step 4). When you do step 2), the new information is saved in the database. When you do step 3), a complete refresh of the Edit Media screen takes place after the mapping rules are run; there’s nothing else to Update.

You probably know that scaling the image changes the file name. It also changes the “sizes” array in image_meta; it removes any size larger than the new full size. If you “Restore Original Image”, all of the intermediate sizes are removed. I find this unhelpful, and it gave rise to plugins that force regeneration of intermediate sizes, etc., which have their own issues.

Regarding updates of the Development Version, the answer is yes. I don’t change the version number of the Development Version, I just add a date at the beginning of the plugin description so you can tell it’s installed. When the next official version comes out the version number changes and you get notified as usual.

Thanks again for working with me on this issue and for your support of the plugin.

Thanks for letting me know that step 4 isn’t necessary. I assumed that in order to get all of the other sizes rebuilt that I had to do the Update step. It’s nice to be able to eliminate one step.

I did not know that scaling the image changes the file name. At least on my site both the filename and the URL look the same to me before the scale as after and the image still appears in the post. Can you tell me how the filename changes?

What is lost is the “Inserted In” information on the MLA directory screen. I’ve never relied on this information because when you include an image in the Jetpack gallery it doesn’t recognize the fact that you’ve inserted it into that post. So the “Inserted In” information hasn’t been that helpful. I would be nice information if it had all the posts listed.

I’ll avoid “Restore Original Image”.

Here’s the reason I never use the WordPress Image Editor:

1. Go to Media/Assistant and display the Base Name column. Notice the natural-looking file names.
2. Insert an image in a post or page. Remember the file name.
3. Edit the image and scale it.
4. Go to Media/Assistant and look at the Base Name column.
5. Observe that the file name now has a long string of numbers added to it.
6. Edit the image and observe that the File URL (in the Save meta box) has changed (click in the text box scroll to the end to see the file name portion).
7. Go back to the post/page with the inserted image.
8. Observe that the image link goes to the original image, not the re-scaled version.

When you edit an image, WordPress changed the file name and leaves the original file untouched (in case you want to Restore the original image). WordPress does NOT go back through your posts and pages to change existing inserts that reference the image; they go to the original file.

You lose the “Inserted In” information because MLA uses the “sizes” array to get names to search for, and editing the image has destroyed the “sizes” information.

If you “include an image in the Jetpack gallery” MLA will report it in the “Gallery In” or “MLA Gallery In” column, depending on which shortcode you use to select the image. If that’s not working, let me know.

David,

Thank you for the excellent explanation. How very annoying. I’ll have to come up with an alternative to using the image editor to reduce the size of these graphics. If the reduced graphic isn’t the one being displayed in the post, then it doesn’t do any good whatsoever to do the scaling.

And of course my Jetpack issue was solved with your suggestions regarding the Gallery In. I just hadn’t gone up to the Screen Options to see what was there. It’s working great.

Thank you for your patience and help.

So here’s what I did to fix this…

1) Opened the image in Image Editor
2) Restored the original (the URL changes back to the original URL that matches the URL in the post)
3) Downloaded the original onto my desktop and used PS to reduce the file size
4) In Image Editor, used the “Upload new file” and uploaded the edited image
5) Checked in MLA and the URL is back to it’s original name and, by the way, the “Inserted In” is fixed as you would expect.
6) Went to the post and downloaded the image from the post to check it’s metadata to make absolutely certain that it was the modified file.

This is going to be a longer project that I had anticipated. Regardless, having the file size in the MLA will be a huge help in identifying the images that are in most need of reduction. Thank you for pointing out the error of my original plan.

I’m glad you’ve worked out a more effective process based on our dialog. You wrote “In Image Editor, used the “Upload new file” and uploaded the edited image” – I don’t see that option in my system. Are you using some other plugin to upload a file that replaces the original?