Forum Replies Created

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Support danbidev

    (@danbidev)

    @internetzer22

    Thank you for sharing the test results.

    The current situation is quite unusual. Since the ACF Local Fields are disappearing, one would expect the same symptoms to appear on other pages as well. The fact that this issue is isolated to a single page suggests there might be a complex conflict at play.

    First, if you are using any caching, please clear everything (Object Cache, CDN, and Site Cache). Then, try creating a brand-new Password Reset page and insert the block there to see if the issue persists.

    Based on the current circumstances, I suspect the issue lies within the server or site environment rather than the plugin code itself.

    Please let me know the results of these tests. I’ll be waiting for your reply 🙂

    Plugin Support danbidev

    (@danbidev)

    Thank you for your interest in the plugin.

    Based on the symptoms of this issue (email field not visible), it seems the form has been registered, but the corresponding local field was either not registered correctly or is not being recognized during the form output process.

    Could you please check if the field is also not displayed on the Account > Change Password page, which outputs local fields in a similar way?

    If it’s not displayed there either, it suggests an issue where the local field you registered in ACF is not being recognized.

    Could you please confirm if the symptom persists after temporarily deactivating all plugins except ACF and Advanced Members, and also check the status when you switch the theme to a default theme?

    Thank you.

    Plugin Support danbidev

    (@danbidev)

    Thank you for the great suggestion.

    I think applying access control to entire CPTs is worth considering. However, the approach would differ depending on whether the CPTs were created via ACF, PHP code, or other methods. It also relates to WordPress’s default capability system for CPTs, particularly the ‘Read’ capability. For these reasons, implementing this feature may be challenging in the near term.

    In the meantime, you can achieve similar functionality by using taxonomy restrictions linked to your CPTs. Please keep this in mind as a workaround.

    Thank you for your continued interest in the plugin.

    Plugin Support danbidev

    (@danbidev)

    Thank you for your interest in the this plugin and for sharing this great idea!

    Currently, the plugin focuses on the core functionality of connecting user registration and account information with custom post types. While we don’t currently support bidirectional updates between CPTs and user profile fields from the backend admin area, this is definitely an interesting feature request.

    The frontend Account page functionality you mentioned works differently from what you’re looking for – it’s designed for users to manage their own profiles rather than for administrators to edit member profiles from the backend.

    We’re always looking at ways to enhance the plugin’s capabilities, and backend meta box support for administrator-managed member profiles could be a valuable addition in the future. However, this specific feature isn’t currently on our development roadmap.

    We appreciate your feedback and will keep this suggestion in mind as we continue to develop and improve the plugin. If you have any other questions about the current features or need help with your current setup, please don’t hesitate to ask!

    • This reply was modified 7 months ago by danbidev.
    Plugin Support danbidev

    (@danbidev)

    @greghy

    This issue is fixed on version 1.2.4 🙂

    Plugin Support danbidev

    (@danbidev)

    Thanks for the report. @greghy

    We’ll look into the issue and include a fix in the next version soon.

    Plugin Support danbidev

    (@danbidev)

    @splaquet

    I also just discovered that if you add the User Email or User Bio field to a CPT, they aren’t saving content in the backend. Although, they do appear to be saving content as expected on the front end.

    The “User Email” and “BIO” fields are designed to sync with the user profile, not to be saved as Custom Post Type (CPT) meta.

    Please use general email and textarea ACF field for CPT

    Thanks!

    Plugin Support danbidev

    (@danbidev)

    @splaquet

    Just found this and wanted to report. It can be found on the bottom of the page, just below the next line…

    Thanks for the report!

    We’ll see this issue and reply here soon.

    • This reply was modified 8 months, 3 weeks ago by danbidev.
    Plugin Support danbidev

    (@danbidev)

    We are currently working on our user manual, and while our developer documentation has not been written yet, we would be happy to prioritize it internally if you can let us know the specific types of hooks you need.

    In the meantime, to give you a brief overview, we have adopted a hook system similar to the one used in ACF. The naming convention follows the format amem/form/xxxx or amem/form/xxxx/type=xxx and our included modules adhere to this as well.

    We appreciate your feedback.

    Best Regards.

    • This reply was modified 9 months, 1 week ago by danbidev.
    Plugin Support danbidev

    (@danbidev)

    We’ve just released version 1.2.2, which includes a fix for this issue.

    Please update the plugin to the latest version and let us know if the problem is resolved

    Plugin Support danbidev

    (@danbidev)

    Thanks for the suggestion!

    We’ll consider adding an option for auto-login after registration, either in the form settings or as a global setting, in a future release

    Plugin Support danbidev

    (@danbidev)

    Thanks for your updates for this issue.

Viewing 12 replies - 1 through 12 (of 12 total)