There are two fields that show details of date of registration.  When the plugin started I wanted to see a human based ‘days ago’ view as I found that much more helpful to assess how long a user had been a member.

Thus that is the real wordpress registration date fields default formatting.  If one hovers over the field full details of the actual date will show.

It is also possible for you to write your own formatting function to format the date any way you would like.   For those people who are unable to write their own functions from the example and just want to display the registration date, there is a ‘pseudo’ field created which is called ‘Registration Date’ – it is not a real field though and does not sort well.

Days ago for registration date

Registered days ago

• real registration date field formatted using wordpress’s human time difference date time function
• has hover text so you can see the actual date
• will sort by date
• will display the date in the csv extract

Registration date

• pseudo field created on the fly in display only
• doesn’t sort.  Sort by the ‘days ago’ field and then remove the display order to hide the field
• doesn’t show in csv

Registration and days ago in excel

Future

In the future there may be the possibility for one to choose from a range of formats. For  example I can imagine a number of possibilities:

• a range of date formatting options using php date format options
• human time diff, days ago
• birthday (no years)

Advanced Shortcode Parameters

From version 3.4.4, Parameters are available to overide list settings. If you are not a farly expert wordpress user, please use the settings rather to avoid confusing yourself. The parameters are for more expert users or more complex requirements. For example they allow one to reuse a single list on multiple pages but with different sort or filtering criteria.

Example of shortcode with parameters

• show_headings=1 (or 0)
• show_csv=1 (or 0)
• show_refresh=1 (or 0)
• show_search=1 (or 0)
• show_totals=1
• rows_perpage=n
• sort=columnname, can be used with
  • dir=SORT_ASC (or SORT_DESC)
• filter=show (or hide to hide the filtered column), must be used with
  • columnname=value       eg: first_role=Subscriber
    
• (or ONLY when you have a complex multifield column): fieldnamefilter=columnname, must be used with
  • fieldvaluefilter=value

Parameter to show total records

Examples:

URL Parameter use opens up some possibilities that have been requested. EG: currently search only allows one to search the fields that are in the list. One can now add fields to the list, then ‘hide’ that field by adding a filter ‘*’ (display all with values) to it. Then the search will include that field, but not display it. (Personally I do not recommend this as i think it’s confusing.)

 filter=hide columnname=*

Special parameters:

• start_empty=1,
  • should be used with a search or filteroption to start with a blank list. See example blank user list at start
• show_randompage=1,
  • start at a random page (when transient html updates). Eg: (using url parameter to test) http://directories.wpusersplugin.com/simple-user-list/?show_randompage=1.     Note if you are logged in as admin and see an exclamation mark – the cached html is still being shown.  Click on the exclamation mark to refresh.
• shuffle=1,
  • shuffle the results on a page (ie not the whole list). Eg: http://directories.wpusersplugin.com/simple-user-list/?shuffle=1.    Please read https://wpusersplugin.com/3545/v3-5-randomness-emptiness-and-a-fix/

Several add-ons have been developed to extract data created by third party plugins and not stored in the wordpress user and user meta tables.

Request an add-on (charges apply) or If you some php skills, use the example plugin to write your own addon.

If you have a custom table that has user data in it, you can pull it into a list by writing a little site specific plugin and making use of some of the hooks available in the amr-users plugin.

The hooks you may need are:

• amr_get_fields (to add custom fields to the list of fields in usermeta table)
• amr_get_users (to add users to the list of existing  users) or
• amr_get_users_with_meta (to add data to array of existing users)

Read the filter documentation and see the add-on plugins to see how to use these hooks.  Many of the add-ons use them to add data from a variety of different styles of tables.

See https://wpusersplugin.com/2940/filters/#examples

More details

See one of the add-on plugins or thee xample site specific plugin.  Do NOT cut and paste the code here. It is meant to inform only and will NOT  work as is.

 add_filter('amr_get_fields', 'amr_add_my_fields', 1);

 add_filter('amr_get_users_with_meta', 'amr_get_my_users_data', 1);

function amr_add_my_fields ($keys) {

// write code here to return the list of additional fields
// you'd like to see in your user lists. 
//IE these are fields in your custom table that are 
//NOT in wordpress user or usermeta table.

// the function will be passed the existing list of fields 
//and should add the additional fields to the array.  eg: 

$keys[] = 'newfield';

return ($keys);

// then return the array $keys

}

function amr_get_my_users_data ($users) {

// write code here to get the user data from the custom tables. Various approaches are open to you.  Either

• drive from array of user passed to the function, or
• from the array of user data from your custom table.. then add to the users array passed extradata = sql query to fetch data from custom table keyed by userid;

for each $extradata {

    $users[$userid]['newfield'] =  $extradata['newfield'];

// then return the array $users
    return ($users);

/pre>
Alternative (or to format nicely)
The function above has to process ALL the users.  The data will then be available in csv export.  If you only need the data to be displayed, then you could use a formatting function  rather.  The amr-users plugin will look for a custom formatting function for each column to be displayed for each user.
function ausers_format_newfield($value, $user) {

  $customdata_maybearray = code to get data ($user->ID);

  $html = implode (', ',$customdata_maybearray)

}
 
					

• Why Cache?
• When to cache? (settings)
• How does the auto cache work?
• Cache Storage
• Cache Log
• Cache Status
• On demand refresh (admin or public)

Why cache?

Cacheing is required because:

• we want to display, query, filter and sort the data BUT
• some plugins that create user data do it in ‘funny’ non wp standard ways
  • they stick all their user data in one user-meta record, sometimes as an object, sometimes as an array…. (eg: ym (yourmembers), although they appear to be moving to standard wp), so we cannot simply ‘select where meta = ‘
  • they store their user data in non wp tables, so that data has to be fetched separately.  This also means that the wp user update actions don’t fire.  So any recaching dependent on that may  not happen.

So the plugin grabs, extracts, does some magic and stores the data in a separate generic cache table.  Originally this was aimed primary at csv extraction.

When to cache? (settings)

Cache settings

Ideally the lists should be up to date when you see them. BUT for reasons above this may not always be possible.  So consider the following scenarios:

Internal admin access only?

• Consider switching off ALL auto caching.
• Only rebuild the data when you view the list.

Public lists, high level of user updates?

• Strongly suggest do NOT recache on every user update
• Cache at the greatest possible interval (less demand on sql database) – maybe daily ?
• Manual refresh can be made available via an icon link on user list page – see admin refresh link.

Public lists, very low level user updates?

• you must be sure about what plugins are causing user or user meta updates.  If you have a plugin that is tracking the pages people view, or their logins and storing the data in the user meta… do I need to say more?  Re caching on every user update would place a huge sql demand on your system.
• Consider caching on use update only – no scheduled caching.

How does the auto cache rebuild work?

(version 3.4.9 at time of writing)

The cache can be set to automatically update in the ‘background’.  This is achieved using standard wordpress cron features.  If you are new to cron, then basically all you need to know is that it needs some activity on your website to run.  eg: a page request.  A scheduled job will only run on the first page request after the jobs scheduled time.  If you have a very low traffic site, this could be quite late.

A cache update request is initiated via cron on the following wordpress actions:

•     add_action(‘profile_update’,’amr_user_change’);
•     add_action(‘user_register’,’amr_user_change’);
•     add_action(‘deleted_user’,’amr_user_change’); // also for wpmu
•     add_action(‘added_user_meta’,’amr_user_meta_change’);
•     add_action(‘updated_user_meta’,’amr_user_meta_change’);
•     add_action(‘deleted_user_meta’,’amr_user_meta_change’);
•     add_action(‘make_spam_user’,’amr_user_meta_change’);
•     add_action(‘make_ham_user’,’amr_user_meta_change’);
•     add_action(‘remove_user_from_blog’,’amr_user_change’);
•     add_action(‘add_user_to_blog’,’amr_user_change’);

If your install has a user update that does NOT trigger a wordpress action (eg: another plugin stores user data somewhere else), then the plugin has no way of knowing that a user update has happened.

If the other plugin uses its own update actions, you could add a custom function call on that action similar to the above calls.

Alternatively either a regularly scheduled update or a manual on demand refresh may be adequate.

The cache update request attempts to schedule a master cron job.  Many of these wordpress actions may trigger within milliseconds of each other.   The plugin therefore checks whether a cache update is scheduled within the near future to avoid duplicate work.

Master cache cron job shown in amr cron manager

The master cron cache job then schedules individual jobs for each of the reports.  They are scheduled to run separately, not concurrently.  In your cron manager plugin you should see an entry for each job.

When testing, you should therefore do a page request or two approximately minutes apart for each report that you have designed.  Check the cache log in between.

A cron run for each report

Cache storage

(version 3.4.9 at time of writing)

This may change at a later stage for installs that only  use standard wordpress user meta.  Other installs will need the current setupo to deal with their user data created by other plugins.

Currently a generic cache report table in csv format is created.  This made sense originally, however as the plugin became popular more features were requested.  This approach is not ideal for optimum efficiency (especially large high traffic installs).  If one is only using standard wordpress user and user meta data, then the lists could be more efficient.   To cope with non standard data, the curremt approach will have to continue.

Cache Log

The cache log will list the most recent cache rebuild activities.  If you are concerned or not sure how the cache updates are initiated, please pay close attention to the cache log when testing.  For more details see cacheing-the-cache-log

User Meta Update causes cron cache rebuild

Cache Status

The cache status page lists

• the size (lines) of a list
• when the cached list was last built
• how long it took to build the cache
• the peak php memory requirement while running the cache update
• some info on the list

It also has options to totally clear out the various cache records (in case your install gets in a knot), and force the plugin to start again.

Cache Status