cnelsonjeffers

Thanks Giri! I am away from the office now for a few weeks but will try the code as soon as I return and post the results.

I like it. It was effective in enabling me to upload an alternate avatar image to the user account, which successfully over-rode the Gravitar image.

So, in a case where a user is tied to a single Place, it allows the user image appearing to the left of the Place listing to be updated to be something more appropriate, however it still does not solve the issue of the same User avatar appearing on multiple Place listings entered by the same User (specifically in the Supreme theme – granted it is a theme design issue).

To me at least, it makes more sense that there be the ability to upload an image that would appear as the circular “profile” image to the left of the listing. Again this would most likely be a logo-type image in the case of a business, secondary to the banner or Featured image, and would be an image specific to that listing, not reflecting the user owner of that listing.

With the latest round of updates (Aug 16,’14), the problem seems to have gotten worse instead of better – at least for me.

The first thing I noticed after upgrading the GD core and GD plugins, was that the Featured image for a Place showing in the category list had arbitrarily changed to a different image among the images loaded for that Place.

Logging in and attempting to re-arrange the images to make the desired one the first-position (Featured) image did not work. After re-arranging and saving, the images APPEARED to be in the correct order in the back-end, however upon examining the listing in the front end the change was gone with one of the other images showing, and on going back into the back-end the change was gone there as well.

I attempted re-arranging images in both the front-end interface and the back-end interface, with the same result.

I deleted ALL of the images except for the desired Featured (first-position) image, which then showed as desired in the front end category listing and in the Place listing – however when then re-uploading the other images, saving, and closing the record, the desired Featured image was displaced again and one of the other images was arbitrarily used.

Prior to the upgrade, the image order of the original upload and save would remain, although if the images were subsequently shuffled then the one being moved out of the first position would break. Now the image being moved doesn’t break, but the one that ends up in the first position after saving and closing the back-end record seems to either revert to the previous image, or if the previous image is deleted, becomes a different one out of the available set – seemingly at random or arbitrarily.

Ok – glad at least that it’s not just me :-). Much easier to fix if you can reproduce the problem on your end.

Correct. I am seeing that the image in the first position is being automatically copied into the Media folder (or at least, shows up in that control panel).

If the order of the images is subsequently shuffled so as to put a different image in the first position, it appears to be automatically copied into (displays in) the Media folder, and the previous “first position” image no longer appears in the Media folder – however the image moved FROM the first position is now broken and does not display.

Shuffling other images into the first position leaves each image that was previously in the first position, broken.

An update to the above. I just had it happen to me again, while working with a Place that had multiple images (well within the image limit set for their listing level).

This time, the only thing I had done after initially uploading the images and testing the view in a different browser window (not logged in), was to go back to the record to re-order the images so that a different one was the Featured Image.

Immediately when I refreshed the viewing browser window to see the update, the images disappeared (broke) as described.

Which might make it something to do with moving the display order of the images, then Saving.

[Further Test]: If I upload the images, then re-arrangement BEFORE saving, there is not a problem. If I go back into the record and re-arrange the images again then re-Save, the problem occurs immediately.

As Stiofan suggested, it appears that it was indeed an issue related to changes in the latest PHP version – so absence of an issue might either mean that the host has not upgraded to php 5.4, has not forced the non-affected account to use 5.4 instead of an earlier version, or has done something different with their configuration that did the same thing as the code Stiofan recommended adding to the functions.php file.

I’m glad for the simple fix!

I’ve seen in the past with the reporting provided by Wordfence, just how often sites get probed. I’ve particularly seen a real surge right after I put up the domain. It seems to trickle off for the most part once the bots figure out that it’s not a soft target.

Thanks Stiofan — I’m going to look into integrating the recaptcha into the registration form, and implementing Askimet for comments.

I noted in a different thread back in May someone listed Wordfence as being currently compatible with GD, so I’m not sure why my install kicked out the error as other threads elsewhere have suggested that it was an update to the core WP and a subsequent WF update back in 2013 that started the problem of the missing arguments from a custom registration form.

Perhaps there is a setting in WF to disable the reg form scan. I’ll look into that also.

Other threads I found seemed to indicate a similar error occurring with various captcha plugins which would expand the scope of the compatibility problem beyond WF to potentially include any component that interacts with custom reg forms.

Would it make sense to modify the custom form in some way so that the arguments WF is missing get supplied by the form, even if they are not strictly necessary for the creation of users by GD?

Paolo made a good point about the performance load of security plugins like WF, but WF does a lot more to monitor, scan, and block attacks than just registration and comment spam, and I’m uncomfortable not using it or something very similar.