Dear all,
If you are upgrading or have just upgraded amr-users, please ‘rebuild nice names’ immediately after upgrading.
The improved (I hope) query uses the wp_query facility as much as is possible depending on the nature of the fields you want to extract. To do this, some cleverness was required – the cleverness begins in the nicenames.
In fact it is a good idea to rebuild this any time you add other plugins that create user data or add possible field values to your existing data. Remember unless there is a meta data record with a value in it, the plugin will not ‘know’ about your new field, so when adding new fields it is helpful to have a test user with a value for each field.
The new nicenames admin screen
The update also moves some of the hard work away from php towards mysql. Very large user meta databases with very complex queries may find this a bit of a challenge for th wp-query logic!. Please do let me know at the forum if this happens to you. It is helpful to know the sorts of things people are trying to do. Already some ‘interesting’ requests have come through!
Please describe the type of data and the type of query as well as you can. The forum is the best place for now.
I updated to version 3.0 and now the first, last and address is not displaying. Is there something else i need to do?
Thanks in advance.
Have you rebuilt your ‘nice names’ ? then rebuild cache?
I have wp first name and last names showing no problem, and other meta data, which i assume is what you ‘address’ is?.
Any chance that this new update allows the administrator to specify the CSV delimiter character? When end-users add a suffix to their last name (e.g. Smith, Jr.) the ‘,’ in that user fields skews the columns in the CSV download.
Hi Dutch,
That update does not. (No one asked for it yet – and while I try (at the risk of ever expanding scope) no way do I think of every thing up front, so it is really good if people give feedback and put some requests in.
Now it is on the list and may make it into the next update.
Thanks for noting it.
Technically, CSV should wrap fields that contain a comma in simple double quotes. That should take care of situations like that. The only complication is when you have a text field with double quotes inside them. Although scripts that read in CSVs should – again, according to the presumptive standard of RFC 4180 -pay close attention so as to only recognize as delimer “,” the reality is many importing scripts just grab the first double quote they see and run with it as a delimiter. That’s why I like TSVs; tab-separated text files, with the .txt extension and not .csv so as to avoid MS Excel reading problems with UTF-8 and multi-byte characters (when you open or import a .txt file in Excel it’ll accept non-ASCII / ANSI files and read them as such). And with the combo quote-tab-quote the chance of picking on a field with that combo in it are rather slim, much more so than the quote-comma-quote sequence.
If you’re interested at all, there’s currently a decent write-up in Wikipedia of CSV formats. You’ll see it’s very complicated from a programmer’s POV (e.g. the “intelligent” placement of quotes). I suppose the quick solution is to just plop quotes around every field, i.e. not just the first or header row. I’ve also suggested the good people at YM to consider adding TSV but… I’m not optimistic about support for that @#$% serialized usermeta crud.
My kingdom for a usermeta cleaner!