Major changes in this release
Imports are ran as the feed author or user 1
When running imports, Feeds now switches to a different user. This is done to reduce field validation issues and to minimize the difference in (validation) results between importing using the UI and importing using cron.
When attaching the importer to a content type, Feeds switches to the author of the feed node. If the author is anonymous, Feeds switches to user 1 instead.
When using the standalone import form, Feeds switches to user 1.
When the "Authorize" option is checked (setting for the node processor), an extra account switch happens for every item that gets imported. Feeds then switches to the author of the item.
While test coverage exists to make sure Feeds switches back after it's done, this change could in theory have regressions.
Improvements for field validation issues
Some improvements have been made to fix common field validation issues (that were introduced in 7.x-2.0-beta4). The following improvements have been made:
Feeds now only validates mapped fields.
Less validation issues for Organic Groups reference fields.
A hook called hook_feeds_prevalidate() has been added to workaround validation issues: with that hook you can fix up the entity being imported right before it is validated.
PHP 7.2+ support
Most issues have been fixed that caused PHP notices or warnings on PHP 7.2 and above. You do may still get PHP notices/warnings when using the Date module. These issues may be fixed in the Date 7.x-2.11-beta3 release however. If not, please help on #2867810: Plan for Date 7.x-2.11 release!
Function feeds_alter() is removed
This function was deprecated 6 years ago and was removed because it did not work properly on recent PHP versions.
The signature of FeedsProcessor::entityValidate() changed
The signature of the method FeedsProcessor::entityValidate() changed. It now has a second optional parameter. If you override this method in your module, you need to update the parameters so that it matches with FeedsProcessor::entityValidate().
See the change record for details.
feeds 7.x-2.0-beta4
Release notes
Note
If you are having trouble running database updates, make sure that the Feeds module is enabled. See #2911711: FeedsHTTPCache class could not be found: 7.x-2.0-beta4 database update can only run if Feeds is enabled
In this release a big issue is fixed: downloaded content is no longer cached in the database! An other improvement is that you can now see on the import page when Feeds will run the next import. For this release there is also a small chance of a backwards compatibility break if you use a custom fetcher. Read on for more details.
Methods have been added to FeedsFetcherResult
The base class for fetcher results, FeedsFetcherResult, has had a few changes: methods have been added to this class and it now implements the magic method __sleep(). This means that this will break custom fetchers from which the fetcher result class has methods implemented with the same name. It can also break fetcher result classes that have private properties. For more information, see the change record.
Downloaded content is no longer cached in the database!
Yes! No more data size issues if you use a cache backend like memcache, for example. If you are using the default cache backend instead, your database will also grow less big.
Previously HTTP downloaded content was cached in the database and that could add up a lot of space, especially when you are fetching images via HTTP. This data is now cached on the file system instead, while the headers are still saved in the database. To keep the cached headers in the database in sync with the cached content on the file system, a cache class called 'FeedsHTTPCache' is added for the cache bin 'cache_feeds_http'.
Want to use a different cache class for the cache_feeds_http bin?
This is still possible. The cache logic in Feeds is made so that even when you would use a different cache class for the cache_feeds_http bin, the content is still cached on the file system. Be aware though that if you use a different cache class, cached files are not immediately cleaned up when you clear caches. To work around this problem, Feeds will check each six hours if there are orphaned files in the cache directory and cleans them up if there are (you can optionally in- or decrease the check interval by setting the 'feeds_sync_cache_feeds_http_interval' variable). Do not put other files in the Feeds cache directory, as Feeds will delete these!
See the change record for more information.
Also new in this release:
hook_feeds_config_defaults()
With this hook you can add additional configuration to the importer. Handy if you want to add some options via a form alter hook.
For the HTTP fetcher, you can optionally disable caching downloaded data.
Feeds will warn you if it detects invalid or obscure configuration for the following cases:
The content type/bundle selected on the processor no longer exists.
The language selected on the processor no longer exists.
The importer is attached to the same content type as the content type selected on the processor (a common mistake that newbies make).
Process in background is turned on, but import on submission is turned off (and using the standalone form). In this case, Feeds will do nothing when submitting the import form (other than saving the source).
On imports field validation checks are performed. This decreases the chance of SQL errors and invalid import data. In rare cases, it can also cause that some data is not being imported, while it imported without problems in previous releases (because the Field API now marks it as invalid).
drupal-spider
commented
3 years ago
feeds 7.x-2.0-beta5
Major changes in this release Imports are ran as the feed author or user 1 When running imports, Feeds now switches to a different user. This is done to reduce field validation issues and to minimize the difference in (validation) results between importing using the UI and importing using cron.
When attaching the importer to a content type, Feeds switches to the author of the feed node. If the author is anonymous, Feeds switches to user 1 instead. When using the standalone import form, Feeds switches to user 1. When the "Authorize" option is checked (setting for the node processor), an extra account switch happens for every item that gets imported. Feeds then switches to the author of the item. While test coverage exists to make sure Feeds switches back after it's done, this change could in theory have regressions.
Improvements for field validation issues Some improvements have been made to fix common field validation issues (that were introduced in 7.x-2.0-beta4). The following improvements have been made:
Feeds now only validates mapped fields. Less validation issues for Organic Groups reference fields. A hook called hook_feeds_prevalidate() has been added to workaround validation issues: with that hook you can fix up the entity being imported right before it is validated. PHP 7.2+ support Most issues have been fixed that caused PHP notices or warnings on PHP 7.2 and above. You do may still get PHP notices/warnings when using the Date module. These issues may be fixed in the Date 7.x-2.11-beta3 release however. If not, please help on #2867810: Plan for Date 7.x-2.11 release!
Function feeds_alter() is removed This function was deprecated 6 years ago and was removed because it did not work properly on recent PHP versions.
The signature of FeedsProcessor::entityValidate() changed The signature of the method FeedsProcessor::entityValidate() changed. It now has a second optional parameter. If you override this method in your module, you need to update the parameters so that it matches with FeedsProcessor::entityValidate(). See the change record for details.
feeds 7.x-2.0-beta4
Release notes Note If you are having trouble running database updates, make sure that the Feeds module is enabled. See #2911711: FeedsHTTPCache class could not be found: 7.x-2.0-beta4 database update can only run if Feeds is enabled
In this release a big issue is fixed: downloaded content is no longer cached in the database! An other improvement is that you can now see on the import page when Feeds will run the next import. For this release there is also a small chance of a backwards compatibility break if you use a custom fetcher. Read on for more details.
Methods have been added to FeedsFetcherResult The base class for fetcher results, FeedsFetcherResult, has had a few changes: methods have been added to this class and it now implements the magic method __sleep(). This means that this will break custom fetchers from which the fetcher result class has methods implemented with the same name. It can also break fetcher result classes that have private properties. For more information, see the change record.
Downloaded content is no longer cached in the database! Yes! No more data size issues if you use a cache backend like memcache, for example. If you are using the default cache backend instead, your database will also grow less big. Previously HTTP downloaded content was cached in the database and that could add up a lot of space, especially when you are fetching images via HTTP. This data is now cached on the file system instead, while the headers are still saved in the database. To keep the cached headers in the database in sync with the cached content on the file system, a cache class called 'FeedsHTTPCache' is added for the cache bin 'cache_feeds_http'.
Want to use a different cache class for the cache_feeds_http bin? This is still possible. The cache logic in Feeds is made so that even when you would use a different cache class for the cache_feeds_http bin, the content is still cached on the file system. Be aware though that if you use a different cache class, cached files are not immediately cleaned up when you clear caches. To work around this problem, Feeds will check each six hours if there are orphaned files in the cache directory and cleans them up if there are (you can optionally in- or decrease the check interval by setting the 'feeds_sync_cache_feeds_http_interval' variable). Do not put other files in the Feeds cache directory, as Feeds will delete these! See the change record for more information.
Also new in this release: hook_feeds_config_defaults() With this hook you can add additional configuration to the importer. Handy if you want to add some options via a form alter hook. For the HTTP fetcher, you can optionally disable caching downloaded data. Feeds will warn you if it detects invalid or obscure configuration for the following cases: The content type/bundle selected on the processor no longer exists. The language selected on the processor no longer exists. The importer is attached to the same content type as the content type selected on the processor (a common mistake that newbies make). Process in background is turned on, but import on submission is turned off (and using the standalone form). In this case, Feeds will do nothing when submitting the import form (other than saving the source). On imports field validation checks are performed. This decreases the chance of SQL errors and invalid import data. In rare cases, it can also cause that some data is not being imported, while it imported without problems in previous releases (because the Field API now marks it as invalid).