There are quite a few this time, though there are good reasons for this... 
XF\Service\Attachment\Preparer::insertDataFromFile() - argument 2 is now a $userId (instead of a user entity)
Only the user ID was used here and it can make it easier to work with outside of the "normal" context. (You can turn the user ID back into an entity if you extend this method for any reason.)
XF\Attachment\AbstractHandler::validateAttachmentUpload() now requires a XF\Attachment\Manipulator object as the second argument
This allows more advanced constraints to be applied to the attachment upload.
XF\Db\AbstractAdapter: update() and delete() now both require you to pass a value for their $where arguments
This prevents you from accidentally forgetting to pass a where into these arguments and updating/deleting an entire table contents. (Not something we've ever done in development, of course...
) If you want to maintain this behavior, pass an empty string or null for the $where argument.
XF\Template\Templater::renderTemplate() no longer attempts to infer the template type; you must explicitly pass one
Previously, this method would attempt to infer a template type (public, admin, email) if you called it without providing one. A type could only be inferred when the call was triggered while another template was being rendered so this created inconsistent behavior and situations where errors were hidden. As you must now explicitly provide the template type, errors should be much more explicit.
Note that including a template or calling a macro from within a template will continue to infer the template type (based on the template type they're called from).
XF\Import\Importer\AbstractImporter::resetDataForRetainIds() - new abstract method
If writing a custom (non-forum) importer, you will need to implement this method. It handles any data removal needed to retain IDs, if you require it. In most cases, you can have an empty method but, as an example, XenForo includes 2 dummy nodes that need to be removed to ensure that IDs can be retained.
Note that this still only applies when canRetainIds() is true.
XF\Import\Importer\AbstractImporter::validateBaseConfig() and validateStepConfig() signatures changed
These methods now pass their config arguments by reference. Any importers will need to change their signature for these methods.
XF\Import\Data\AbstractData::importedIdFound() - new abstract method
This method will be called when save() is called but we found that this content has already been imported via the import log table. This should be used to note the new ID in your data (should it need to be used later in the step).
In most cases, you'll be inheriting from one of the other abstract data handlers that implement this, so you won't need to do anything.
XF\Import\Data\EntityEmulator::write()/writeUpdate() renamed to insert()/update()
If you use these classes directly (not through AbstractEmulatedData), you'll need to update your calls to these methods.
XF\Service\Attachment\Preparer::insertDataFromFile() - argument 2 is now a $userId (instead of a user entity)
Only the user ID was used here and it can make it easier to work with outside of the "normal" context. (You can turn the user ID back into an entity if you extend this method for any reason.)
XF\Attachment\AbstractHandler::validateAttachmentUpload() now requires a XF\Attachment\Manipulator object as the second argument
This allows more advanced constraints to be applied to the attachment upload.
XF\Db\AbstractAdapter: update() and delete() now both require you to pass a value for their $where arguments
This prevents you from accidentally forgetting to pass a where into these arguments and updating/deleting an entire table contents. (Not something we've ever done in development, of course...
) If you want to maintain this behavior, pass an empty string or null for the $where argument.XF\Template\Templater::renderTemplate() no longer attempts to infer the template type; you must explicitly pass one
Previously, this method would attempt to infer a template type (public, admin, email) if you called it without providing one. A type could only be inferred when the call was triggered while another template was being rendered so this created inconsistent behavior and situations where errors were hidden. As you must now explicitly provide the template type, errors should be much more explicit.
Note that including a template or calling a macro from within a template will continue to infer the template type (based on the template type they're called from).
XF\Import\Importer\AbstractImporter::resetDataForRetainIds() - new abstract method
If writing a custom (non-forum) importer, you will need to implement this method. It handles any data removal needed to retain IDs, if you require it. In most cases, you can have an empty method but, as an example, XenForo includes 2 dummy nodes that need to be removed to ensure that IDs can be retained.
Note that this still only applies when canRetainIds() is true.
XF\Import\Importer\AbstractImporter::validateBaseConfig() and validateStepConfig() signatures changed
These methods now pass their config arguments by reference. Any importers will need to change their signature for these methods.
XF\Import\Data\AbstractData::importedIdFound() - new abstract method
This method will be called when save() is called but we found that this content has already been imported via the import log table. This should be used to note the new ID in your data (should it need to be used later in the step).
In most cases, you'll be inheriting from one of the other abstract data handlers that implement this, so you won't need to do anything.
XF\Import\Data\EntityEmulator::write()/writeUpdate() renamed to insert()/update()
If you use these classes directly (not through AbstractEmulatedData), you'll need to update your calls to these methods.
