Is there any support here
We are working on a fix for this. Downgrading to a version before 2.9.10.2 should resolve the issue. The status of a resolution can be tracked here: https://github.com/pods-framework/pods/issues/7001
When will be the next version in which this problem will be fixed.
Just did some testing and updated the GitHub ticket based on the finding that this field was last working in 2.6.11.2. I’ve chatted with Scott about your desire for a fix. As the source of the problem is unknown, the fix date is also unknown, but now we do know that we should find a solution somewhere in the difference between 2.6.11.2 and 2.7.0.
For now, you can get the field working by downgrading the plugin, either by deleting and installing the lower version via command line from your WordPress install’s root directory with this command:
rm -rf wp-content/plugins/pods && wp plugin install https://github.com/pods-framework/pods/archive/refs/tags/2.6.11.2.zip
Or by deleting the plugin and uploading the previous version’s zip through the GUI with this link to the 2.6.11.2 zip, or by using the WP Rollback plugin.
@abdulazizsobh Thanks for your patience, we have finally tracked down the exact cause for this and there’s a fix coming in Pods 2.9.12 when that gets released. I don’t have an exact ETA as there may be more things we are hoping to tackle this week to include fixes for but I do hope it will be by the end of this week or next week.
The workaround solution is to name your avatar field something other than “avatar”. This will prevent the bug from occurring through the special internal Pods handling of the “avatar” field it tries to take over for.
