Possible bug with user-meta at command line …

  • Resolved chuckingit

    (@chuckingit)


    10 years, 10 months ago

    Hi – i think i found a bug and not sure if it is with PODS or wp-cli or just the way things are ..??.. i’ve also reported this issue on wp-cli github but thought i should do similar here in case this is a PODS thing … details below … cordially, chuck scott

    ps – PODS ROCKS – thank you for such a powerful plugin :>)

    – note the link to the issue report on github =
    https://github.com/wp-cli/wp-cli/issues/948 … user-meta bug – field not updated despite success message

    and essense of my findings = i created a couple extra user fields using PODS and when i used wp-cli to update one of the fields, i consistently got “Updated custom field.” success message yet the field was not updated in db …

    in trying to understand what was going on, i ultimately found that the user-meta field does not like relationship type fields and once i set that field to a simple text field, voila – the wp user-meta set worked …

    background fyi … initially i used PODS to extend the User Profile by adding three fields – a membershiptype, an expire date, and expire date as number … the membershiptype field was originally a relationship field type with three pull down select options to choose from for ADMINS only …

    after i started getting false positives, i tried changing permissions on this field from required to none, from admin only, to anybody, etc … and in all cases the wp user-meta set came back with success messages although none were literally added to the db … so the false positives did not seem related to the PODS field permission settings …

    however once i changed the field type to text, then the db actually got updated …

    my other two fields, a date field and a text field, had no issues with being updated … so i’m thinking there is bug of sorts with either wp-cli or the way PODS registers the user fields or ..??..

    other background notes = i did install the PODS command line tool but realized that it was more suited for adding, removing PODS and not necessarily getting info within POD fields and mention only as fyi as having it installed or not had no impact on the false positives …

    purpose … my original goal in setting the PODS membershiptype field to a relationship was that i was hoping to avoid any typos if site admins were entering the value options manually thus thought “okay cool – i’ll create a simple relationship field that relates to a custom defined list with options so that admins can pick from one of a couple options. then i’ll make that option viewable to the user but not editable yada yada” …

    – fin –

    https://www.ads-software.com/plugins/pods/

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Contributor Scott Kingsley Clark

    (@sc0ttkclark)

    Did you have WP_DEBUG on? Do you see any other errors with error reporting on?

    Thread Starter chuckingit

    (@chuckingit)

    Hi Scott – i did not have WP_DEBUG on when i initially posted this so i went back today to see if i could recreate error / bug and turned on WP_DEBUG but no, it showed no error in the log file and still generated Success: Updated custom field … yet my field was not updated, actually it was turned to blank from the previous value thus ended with no value after i ran the wp user-meta id fieldname fieldvalue …

    on this page -> https://wp-cli.org/commands/user-meta/ – there is mention in example of using set but did not see that listed as subcommand so i tried using both update and set and got same – success message from command line but nada in the db table …

    the other thing that is a bit odd is that even if i try to update a non-existant field, i still get success message … note i was trying to update a field called membershiptype but in one of my tests i did typo and left out i thus had membershptype and still got a Success message ..??..

    so then i went back to my Pod and looked at my custom defined options and saw that i had spaces between the value | label … once i removed those spaces, value|label, then the user-meta update started to work … all of which kind of makes sense now why i was seeing blank in my db ..??.. however, if i did a user-update with a value not in the field list, i still got Success message but my previous value was returned to blank … meaning if the field table has three options (pro, rgular, disabled) and the user is set to pro, but then do user-meta update fieldname with value of dude (which is not in the list), then the pro value is removed, blank value is inserted and still a success message is generate which is a bit misleading …

    okay so what does all this mean … i think the really big issue was me having trailing blank spaces in my custom defined options list … hence maybe Pods can scrub (trim blanks) before saving the Pod ..??.. not sure what can be done about false / misleading success message but i guess one could also argue that anybody doing command line should know better and only enter real values and real fields regardless of their typo sensitivies or not :0

    i’m gonna mark this thread as resolved because the blank spaces were the culprit and the user-meta update works as planned provided one uses real field names with only one of the values in the custom defined list …

    cordially, chuck scott

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Possible bug with user-meta at command line …’ is closed to new replies.

Tags