Version 1.2.0

• This release provides basic support for additional field types in Salesforce, including: multipicklist, picklist, date, datetime, and URL (results may vary depending on how WordPress plugins handle their custom field equivalents). Thanks to WordPress user @ilanabit for reporting this.
• This release also forces InnoDB on the field_map table because MyISAM gets errors on the index length. Hopefully most users are already on InnoDB by default, but this will help any users who are not.

Version 1.1.2

• Clarify the documentation, and the code, for the following developer hooks:
  • object_sync_for_salesforce_add_more_wordpress_types
  • object_sync_for_salesforce_remove_wordpress_types
  • object_sync_for_salesforce_wordpress_object_data
• Thanks to WordPress user @justanothercoder for asking about this, leading to the fix.

Version 1.1.1

• This release removes the screen_icon() method from admin.php. It has been deprecated apparently since 3.8, but in 4.9 it officially throws PHP Notice messages in WP_DEBUG mode.
• This release also updates the supported WordPress version.

Version 1.1.0

• This release gives users a way to clear the cached data for this plugin only, even if they are using an object cache method. Most importantly this resolves the problem of new fields being available in Salesforce or WordPress and not being visible in the list of mappable fields when creating or updating a fieldmap.

Version 1.0.11

• Fixed a bug in which a blank post object was created in the event that pull calls were blocked, then unblocked. Thanks to GitHub user @charmoney for the report and much of the fix.
• Fixed a bug in which post meta fields were not pushed to Salesforce. Also as part of this, added basic support for WooCommerce order post types. Thanks to WordPress user @ratputin for the report.

Version 1.0.10

• This avoids repeatedly queueing Salesforce objects by initializing rather than aggregating the queue before saving. This reduces memory use and database size significantly.
• Plugin now updates the pull sync timestamp for the data type after every successful record queue. This provides a correct starting point for the next pull to begin in case of a fatal error.
• Thanks to GitHub user @charmoney for the report and the pull request.

Version 1.0.9

• This fixes a bug in which upserting a custom post type would incorrectly create a standard post, rather than the desired custom post object.

Version 1.0.8

• 1.0.8 (2017-08-14)

  • This checks a mapping's configured allowed sync triggers before queueing a record for pull processing, rather than as a part of the WordPress record's create or update. This resolves an issue. Thanks to GitHub user @charmoney for the report and the pull request.
  • This release also fixes a bug related to 1.0.7, which after the fix was still incorrectly checking the post_content and post_title values.

Version 1.0.7

• This sets up admin notices that always show above the plugin's admin tabs if: 1) the plugin is not authorized, 2) there are no fieldmaps, or 3) there is no schedule set up for the plugin. This is so users understand they have to do these things before the plugin can properly work.
• Fixed a bug where wp_insert_post failed if the post_content or post_title values were not passed, but the map row was still created. This passes empty values for both fields if they aren't present. It also throws a WP_Errror object if either wp_insert_post or wp_update_post fail.
• Also fixed some code formatting issues

Version 1.0.6

• This builds a basic interface for object map rows that failed to be fully created to map objects between the two systems, and have a temporary ID for either WordPress or Salesforce.
• If any of these rows are present in the database, it creates a Mapping Errors tab at /wp-admin/options-general.php?page=object-sync-salesforce-admin&tab=mapping_errors.
• For each row, it shows the WordPress ID, WordPress object type, Salesforce ID, and when it was created. Users are able to edit each row's WordPress and/or Salesforce ID, in case the data they need to map does actually exist, and are also able to delete each row individually in case they just want to let the plugin run again.
• This should further solve the issues raised in #97, as it gives users a non SQL way to manage those error rows, on top of the previous PR on this branch that kept them from preventing further syncing.
• Noteworthy change: in salesforce_mapping we now filter the $posted array so it only contains the columns in the database table for object maps, plus the action parameter that we filter out later. I've verified that the various create_object_map methods do not contain other parameters that we need to preserve for similar use to the action.