Support for Per User Language Settings Coming in Version 1.8.9

WordPress has supported per user language settings since version 4.7. This allows users to set their preferred language under their profile settings. If you are running a multilingual website, this is a vital feature for those users who don’t speak the site wide language setting.

Up until now, Give has only supported the site wide language setting. This means that if you changed your profile’s language setting to another language, all core WP menu items would update but Give would still be using the site’s language setting. With the upcoming release of Give 1.8.9 this is no more. Now your users can enjoy Give in the language they prefer, providing that there is a translation available for that specific language.

How it Works

If you are using WordPress 4.7+ (and you should be) then your site users can now change the language to their preference in wp-admin:

Per User Language Setting

Per User Language Setting

When I change the setting to Deutsch, you’ll see Give’s menu update as well:

Prior to 1.8.9 this menu item would have been in English, the site setting.

As well, the donations forms will also respect the user setting:

Frontend Give for In German, the User's Language Setting

Frontend Give for In German, the User’s Language Setting

More i18n Extras

  • WPML has been fully audited for support with the help of their developer Vuk Vukovic. Thanks for that! You can also see our page here on their site: https://wpml.org/plugin/give/
  • Simplified load_textdomain() method within the main give.php file – the use of unload_textdomain() allows for the per user language setting to work.

Don’t See Your Language? Help Us Translate Give

We’re always looking for help supporting more languages with the plugin. If you are multilingual, please consider helping translate our plugin!

Help Translate Give »

 

Give 2.0 – Welcome Hint.css and Goodbye qTip2

In Give version 2.0+ we are deprecating  qTip2 (with backward compatibility, of course) and all tooltips (frontend + backend) will be generated with the new Give_Tooltips class. We’ve put a lot of work into this new class so it can handle all the various types of tooltips supported by hint.css, a pure CSS solution. Now you can create flexible tooltips based on your specific needs with a simple setup and the flexibility you expect from a professionally developed WordPress plugin.

Our hope is that this update frees you from having to spend time writing any complex code for your custom Give tooltips. As well, it will give your users a better experience and also add a little speed boost to your sites since no additional JS is needed. Finally, since this is a pure CSS solution, this update also reduces the chances of potential conflicts with other scripts. Let’s explore further:

The Types of Tooltips

You can create multiple types of tooltips by specifying different properties:

  1. Position:
    1. Top
    2. Top Right
    3. Top Left
    4. Right
    5. Left
    6. Bottom
    7. Bottom Right
    8. Bottom Left
  2. Status:
    1. Error
    2. Warning
    3. Info
    4. Success
  3. Size:
    1. Small
    2. Medium
    3. Large
  4. Display:
    1. Show always
    2. Show on mouse hover
  5. Style:
    1. Square edges
    2. Round Edges
  6. Animation:
    1. No animation
    2. Bounce animation

How to Create Tooltips in Give 2.0+

Here is a general code sample to create a tooltip with Give_Tooltip with Give 2.0+:

Give()->tooltips->render(array(
    // Tooltip tag.
    'tag'         => '',
    'tag_content' => '',

    // Set to link of anchor if tooltip tag is anchor.
    'link'        => '#',

    // Text for tooltip
    'label'       => '',

    // Value: top-right, top, top-left, right, left, bottom-right, bottom, bottom-left.
    'position'    => 'top',

    // Value: error, warning, info, success.
    'status'      => '',

    // Value: small, medium, large.
    'size'        => '',

    // Value: true/false.
    'show_always' => false,

    // Value: true/false
    'round_edges' => false,

    // Value: true/false
    'animate'     => true,

    // Attributes.
    'attributes'  => array(),

    // Value: true/false
    // If set to true then automatically core will set size for tooltip on basic of word count of label. 
    'auto_width'  => true,
));

There are also some helper functions to quickly create tooltips:

/* The function below also accepts an array */
// Output span with question icon.
Give()->tooltips->render_help(/* Tooltip Text */);

/* The function below also accepts an array */
// Output span.
Give()->tooltips->render_span(/* Tooltip Text */);

// Output link.
Give()->tooltips->render_link(array( /*tooltip setting values*/ ));

This update is just one of many optimizations we’ll be releasing in the next major version of Give. Stay tuned for more!

 

Give 1.8.9 Give_Notices Class Update

In Give version 1.8.9+ all core notices (frontend + backend) will be generated with the Give_Notices class. We’ve put a lot of work in refactoring this class to handle much more than just output. Now you can specify the type of notice, whether it’s dismissible, and of course customize the content.

Our hope is that this update frees you from having to spend time writing custom notice handlers. As well, it should give a little speed boost to your sites because all JS is included conditionally based on whether a dismissible notice appears or not. Let’s explore further:

The Types of Notices

  1. Auto dismissible notices: These type of notices will automatically hide after 5 seconds. These are useful when updating settings and showing a “Settings updated” notice or similar.
  2. Manually dismissible notices: These type of notices will be hide for specific time interval (24 hours, 1 week, etc) or permanently per user or for all users. These are useful for reminders or
    1. Quick (24 hrs.) dismissed notice.
    2. Permanently dismissed notice
    3. Custom (time interval in seconds) dismissed notice.

How to Create a New Notice

Example wp-admin notices types.

1. Admin notice:

General code sample to create a notice with Give_Notices

Give()->notices->register_notice(array(
    'id' => '' // Value: unique notice id
    'type' => '' // Value: error/warning/success/info/updated
    'description' => '' // Value: notice message content
    'auto_dismissible' => '' // Value: true/false. if set to true then notice will auto class in 5 seconds
    'dismissible_type' => '' // Value: null/user/all
    'dismiss_interval' => '' // Value shortly/permanent/custom
    'dismiss_interval_time' => '' // Value: time interval in seconds (only need if dismiss_interval set to custom)
));

2. Frontend Notices:

Example frontend notice types.

  1. Render inline notice:

    give_output_error( 'error message', true, 'error' );
    give_output_error( 'warning message', true, 'warning' );
    give_output_error( 'success message', true, 'success' );
  2. Render error stored in session:

    give_set_error( 'error_one', 'Error: one' );
    give_set_error( 'error_two', 'Error: two' );
    give_set_error( 'error_three', 'Error: three' );
    
    // Render all session errors with this function
    // Call this function according to your DOM structure.
    Give()->notices->render_frontend_notices();

Moving Forward

Once the new notices class is released in 1.8.9 we will be refactoring our add-ons to use the new class. This will help to make our code DRYer and ensure we’re setting a good example for future Give developers. We hope you enjoy the new notice class refactor coming soon!

 

What’s Coming Up in Give Core Version 1.8.9

Right now we’re in the middle of working through Give version 1.8.9 and it’s shaping up to be a pretty significant point release. Within this release there’s going to be a number important updates to the core codebase that we’d like to bring to your attention.

Deprecated Classes and Functions for Better Donation Terminology

If you’ve ever spent time working with our codebase you may have noticed words like “customer”, “store”, and “sale”. This is because when we first developed the plugin a lot of our code was previously being used for eCommerce transaction. Now, of course, it’s used to accept online donations. Hence, the code should reflect the appropriate terminology for its job.

To meet the goal of having a donation and nonprofit friendly verbiage we are deprecating many core classes, hooks, and functions. What’s this mean? Well, if you have WP_DEBUG turned on and an add-on or code you have implemented uses a deprecated hook or function you will see a notice telling you the function has been disabled and

Using a deprecated class will not trigger an error for backwards compatibility reasons and to prevent output errors like the header’s already sent.

Deprecated Classes

The following classes are being deprecated. The old classes will still work, and we’ve written unit tests to ensure that, but please don’t use them anymore within your code.

  • Give_Customer => Give_Donor
  • Give_DB_Customer => Give_DB_Donor
  • Give_DB_Customer_Meta => Give_Donor_Customer_Meta

Deprecated Hooks and Functions

There are a number of functions that are going away in 1.8.9. We initially tested our method for deprecating functions in the 1.8.8 and were happy with the smooth rollout. So, in 1.8.9 we’re deprecating a larger number of functions and hooks.

Functions

  • give_get_payment_customer_id => give_get_payment_donor_id
  • give_get_total_sales => give_get_total_donations
  • give_count_purchases_of_customer => give_count_donations_of_donor
  • give_get_purchase_stats_by_user => give_get_donation_stats_by_user
  • give_get_users_purchases => give_get_users_donations
  • give_has_purchases => give_has_donations
  • give_count_total_customers => give_count_total_donors
  • give_purchase_total_of_user => give_donation_total_of_user
  • give_delete_purchase => give_delete_donation
  • give_undo_purchase => give_undo_donation
  • give_trigger_purchase_delete => give_trigger_donation_delete
  • give_increase_purchase_count => give_increase_donation_count
  • give_record_sale_in_log => give_record_donation_in_log

Hooks

More Insight: To keep up-to-date on the deprecated classes and functions you can refer to this issue on GitHub. We took the first baby step to completing this issue in version 1.8.8 and now version 1.8.9 is a much larger step. The goal is that by version 2.0 all the terminology will be updated, including within the database.

Core Notice Urging Customers to Upgrade from PHP 5.2

Like our friends over at Yoast, we’ve decided it’s time to give our users a friendly nudge away from PHP 5.2 by asking them to update to at least version 5.6. In fact, Give runs great on PHP7 and ideally, that’s the version you want to be on. However, we understand there can be some conflicts still with some WordPress plugins.

In 1.8.9+, if Give is installed on a server running PHP 5.2:

  1. A dismissible notice will appear in wp-admin urging users to update
  2. Give core will still continue to work in PHP 5.2 but most add-ons will not
  3. If dismissed and the Give core remains active, the notice will reappear after 24-hours

Depending on how this goes, we may urge users using less than PHP 5.6 to update in the future. Note that Give core 1.8.9+ will work fine on PHP 5.2, we’ve fixed one bug preventing it from running that was introduce in version 1.8.

Additional Improvements and Bug Fixes

  • Strong passwords are now required to register a user with Give #1305
  • Added compatibility with XML Sitemap generator plugins (like Yoast SEO) when disabling single give forms views #1690
  • Better sorting of donation forms by amount #1253
  • Improvements to the “File” and “Media” field types #1758

That’s it for now! Check back or subscribe for more updates.

Want more? View the Complete 1.8.9 Milestone