Pods: Extended media, grid mode edit: checkboxes aren't firing change events

[pglewis]

The dynamic saving mechanism in the grid mode edit listens for change events that aren't sent. Trigger the change event manually to ensure DFV checkboxes are saving properly there.

[pglewis]

PR: #5131

[pglewis]

Let me know if you're able to test this and verify the fix or not, @GitHubGreg

[GitHubGreg]

Thanks and sorry for the delay (baby duties). I've tested it and it doesn't seem to change anything. Changing a checkbox in the media modal window doesn't save the change.

[pglewis]

Thanks and sorry for the delay (baby duties). I've tested it and it doesn't seem to change anything. Changing a checkbox in the media modal window doesn't save the change.

No worries :)

You'll want to make sure the browser isn't caching the old javascipt that was updated in that PR. On Chrome the best way I've found is with Dev Tools open (and making sure the disable caching box is ticked).

I tested it multiple times from the main "Media" menu and everything seemed to be behaving.

[GitHubGreg]

I tried again without luck. I tried with disable caching in Dev Tools. I also tried in an incognito browser. And I tried with all functions disabled (I use some jQuery to control the display of the fields with conditional logic). In all cases the changes to checkboxes aren't saved.

I am going to the main Media menu (/wp-admin/upload.php) in grid view, clicking a PDF item and making the change.

[pglewis]

I failed to push the rebuilt bundle. Sorry for the run-around, the revised PR should work.

One oddity with saving per change event is each checkbox click does a round-trip save. If the network is slow it may look odd when you're clicking checkboxes quickly. You can see this in action in Dev Tools => Network => filter by XHR.

[pglewis]

One oddity with saving per change event is each checkbox click does a round-trip save. If the network is slow it may look odd when you're clicking checkboxes quickly.

I pushed a commit to debounce the change event so it'll only fire after a period with no further change events coming in, but there is still a glitch that needs to be worked out. When the change event is fired and during the period while the ajax result is pending you're still able to make more changes but they'll be clobbered when the ajax result comes in. Due to how WordPress does things here the most we may be able to do about this is disable the controls for changes while an ajax result is pending. I'm still working on that detail.

[GitHubGreg]

Thanks very much. I appreciate all the help. I tested what you have so far and it works, thank you.

[pglewis]

Do beware of the caveat above, you can get unexpected results with checkboxes simply due to poor timing with the ajax request and no fault of your own. I _think_ that's all we have left to address on it for the moment though, thankfully.

[pglewis]

I'll have some more changes to test here soon. I'd like to limit checkboxes to only saving when the focus leaves rather than per checkbox change. That took some experimenting with the events involved but I think I have a game plan together.

[GitHubGreg]

Thank you. Let me know if you want me to test.