5.2.23 Released

  • Bug fix: CSV export. If the column is missing in underlying data then add a dummy field.
  • Bug fix: Only display users on the stats table if they still exist in WP Users table.
  • Bug fix: Correct display Pro Plus license price from Yeken Data feed.
  • Bug fix: Only tell YeKen of license deactivation when one actually occurs.
  • Bug fix: Fixed wpdb->prepare() errors thrown on user search.
  • Reviewed data santisation and where required called relevant WordPress functions to sanitise user data.
  • Removed redundant files.
  • Removed commented lines of code.

5.2.22 Released

  • Bug fix: Only display users on the stats table if they still exist in WP Users table.
  • Bug fix: Correct display Pro Plus license price from Yeken Data feed.
  • Bug fix: Only tell YeKen of license deactivation when one actually occurs.
  • Reviewed data santisation and where required called relevant WordPress functions to sanitise user data.
  • Removed redundant files.
  • Removed commented lines of code.

5.2.19 Released

  • Bug fix: If measurements enabled, ensure one or measurement fields have been enabled before rendering form fields.
  • Added a hidden tool to fix the accuracy of Stones and Pounds to Kg.

5.2.18 Released

  • Improvement: Added options to allow admins to specify a fill colour and opacity under the weight line on charts.
  • Improvement: Added new options to allow admins to specify font family and colour for charts.
  • Updated Chart.js to 2.7.1

5.2.16 Released

  • Improvement: Added additional argument for [wlt] shortcode that disables the check to see if [wlt] has already been placed on the page. Some users (and clashing plugins) were causing it to fail.
  • Bug fix: Allow decimal entries for pounds (when in stones and pounds).
  • Bug fix: When display comparison values, a rounding to one decimal place was causing the difference values to be slightly out. This has been changed to two decimals.

5.2.12 Released

  • Improvement: Refactored User preferences code so it can be extended.
  • Improvement: Added new filters “wlt-filter-admin-user-sidebar-top”, “wlt-filter-admin-user-sidebar-middle” and “wlt-filter-admin-user-sidebar-bottom” to allow developers to add HTML to user sidebar in “Manage Data”.
  • Improvement: Added new filter “wlt-filter-js-ws-ls-config” to allow developers to filter JS config.
  • Improvement: Added new filter “wlt-filter-user-settings-below-aim” to allow developers to add to the User settings page.
  • Improvement: Added the filters ‘wlt-filter-user-settings-db-formats’ and ‘wlt-filter-user-settings-save-fields’ to allow a developer to save other user preference fields.
  • Bug fix: Stopped [wlt-calories] and [wlt-macronutrients] throwing an error when the user was logged out. Thanks @MARKONEX
  • Big fix: Fixed a bug where “Your modifications have been saved” message was always being shown on [wlt-table] shortcode.
  • Database schema changes for future releases.

Why not create a registration wizard?

I recently created a site called TrackYourWeight.co.uk and as outlined here, it serves as a demo site as well as a tool for real people! Building the site, gave me the opportunity to the plugin in the way a web developer / customer would. One feature I found missing that would benefit the plugin was a “Registration Wizard”. Ideally, before allowing people full use of the site, I wanted them to complete a three step sign up process. This process will ensure the user completed their “About You” fields, latest weight and finally their target.

So, using the new [wlt-if] shortcode I started by building a “Registration Wizard” page! The page would have three steps:

  • Step 1: Complete “About You” fields.
  • Step 2: Set your target weight.
  • Step 3: Enter your current weight.

The new [wlt-if] shortcode is a clever and not well publicised shortcode. In essence, it allows you to show and hide content depending on whether a Weight Tracker field has been populated. So using the brief above, I was able to develop a wizard page (paste this into the content section of a WordPress page):

(the above code can be copied from this GistHub page)

The content contains three nested [wlt-if] statements. The first statement ensures Height, Date of Birth, Activity Level and Gender have been specified. If they haven’t, Step 1 is shown of the wizard  – the User Settings form. When the page reloads, the second [wlt-if] checks if the user has specified a Target Weight – if not, the target form is displayed. The third and final [wlt-if] checks whether or not a Weight entry has been added – in the event it hasn’t the weight entry form is displayed. Finally, if everything has been completed, a [wlt-progress-bar] is shown!

Of course, this relies on the person staying on the wizard page. They could easily click away and never come back – defeating the point of the Wizard! So, I went onto write a little bit of code to put in my theme’s functions.php:

The code (can be copied from this gist) is simple really. On every page load in the front-end several checks are performed. If it’s deemed necessary the user is redirected back to wizard page. Some notes:

  • Line 15 checks the user is not on the wizard page, but they are on a page or post and they are logged in. If this isn’t the case, we ignore the visit and do no further work.
  • Line 20 does the hard work, the function ws_ls_shortcode_if_value_exist() checks whether the user is logged in and has entered the relevant fields. If not, they are redirected back to the wizard url.
  • Remember to modify line 15 and replace /wizard/ with your page slug e.g /the-slug-of-your-wizard-page/
  • Modify line 21 to include the URL to your Wizard page.

If you have any questions, please pop them into the forum! 🙂