Support » Plugin: amr users » Can’t Update Fields and Nice Names

  • Resolved CK MacLeod

    (@ck-macleod)


    I’ve successfully imported and configured (or re-configured) a list used in a staging installation to a production environment, but I am getting failures and odd results when I try to update “Fields and Nice Names.”

    Note also that I am using S2Member Pro.

    In short, the “Find any new fields” is finding a very large number of fields: 1751 of them, most of them generic s2Member Custom Fields that may be a residue of a WordPress users update, I’m not sure. It would be nice to be able to delete them, but I’m not sure exactly where I’d have to go for that.

    The second, more serious on the same page is that I cannot update the meta field Nice Names or Field types. I have repeated tried to change the names of, for example, “Wp S2m Pub City” to “City,” for the usual reasons (readability where the list label is used).

    I could work around both problems, I think, but I’m wondering if I’m going to run into more serious problems as I work with the lists or perhaps later on, beyond the inconvenience. Please advise!

    • This topic was modified 5 days, 6 hours ago by  CK MacLeod.
Viewing 3 replies - 1 through 3 (of 3 total)
  • (I’ll probably be attempting a complete re-installation of both S2Member and of AMR Users, starting with a backup of the Production site, but I’ll see if I can get a response first. Incidentally, when trying to deactivate and delete AMR users, I got a deletion failed message, even though the plugin and databases do appear to have been deleted.)

    Plugin Author anmari

    (@anmari)

    HI,

    In ‘excluded meta keys’ one can delete meta records (or do it via phpmyadmin) wp-admin/admin.php?page=ameta-admin-meta-keys.php, however fields nested inside a meta record cannot (unless you delete the whole record).
    You can tell the system to exclude them in ‘Fields & nice names’ …/wp/wp-admin/admin.php?page=ameta-admin-nice-names.php BUT if it is hundreds of unique ‘fields’ that no one would ever want to report on AND they have some consistent and identifiable naming pattern, I can add to the S2 member addon code that will exclude them – can you you send me a list or dump of them so I can see if that is possible? email anmari@nmari.com

    Inability to update can sometimes be because there are too many html input fields (form is too big) – like if you have 1000+ fields. Excluding meta keys & fields from the list will bring the number of input fields down. You could test this by temporarily excluding the s2member custom fields meta key which will hopefully get rid of those unwanted fields from the list and bring it down to a manageable level. If you can then update, then that is what it is -> too many input fields.

    If not that, sometimes when one can’t delete it’s due to inconsistency in settings from when you imported the settings. Best bet may be to note your desired list settings manually and then reset / do a clean config in your target system.

    If you’re using S@member custom fields you should note that in a planned future version that does away with cacheing, it will not be possible to sort or filter by fields that are nested in a meta record, only by fields that are ‘clean’ in their own meta record, for obvious reasons: imagine trying to write a SQL statement that sorts by the middle of a value. You may therefore wish to consider another plugin for the custom fields part IF you need to sort or filter by them. Purely listing them will still be fine.

    • This reply was modified 4 days, 8 hours ago by  anmari. Reason: Change sequence of text

    Thanks for your detailed reply. In the period between putting up my question and getting your answer, I reverted the installation/database to a backup, and re-ran the processes that filled in the S2Member accounts. So, though I do think some tools for cleaning the db or bulk-selecting/modifying/deleting found fields would be a good addition to AMR Users, I don’t think I need them or other solutions you have kindly provided at this time.

    I wouldn’t expect that the issue I encountered would be very common, but I suppose it might come up for other people who in one way or another complicate or misconfigure certain types of entries in user database tables, so, for any other users and for your own information, I’ll outline what I believe happened.

    When converting fields from one set of sources (Gravity Form “entry” data and Custom Post Type terms) into S2Member arrays for mulitiple selection checkboxes, my code produced numerous extra empty fields and in some cases also created complex arrays where simple arrays were expected. The presence of these empty fields did NOT interfere with display on front or back end – checkboxes were shown and remained accessible, checked or unchecked correctly, as expected – but the large number of extra empty fields (ca. 1,500) were detected by the AMR “finding” process, and remained (I believe) in the AMR tables even after the user database was cleaned up (all extra fields removed).

    Anyway, that appears to be what caused the difficulties and failures I originally described. So, I’ll mark this item as resolved, but bookmark it in case I need to address similar issues again in the future. Thanks!

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.