Problem/Motivation

As discussed in #1839468: [Followup] Replace aggregator rss parsing with Zend Feed, we want to switch RSS to use Zend. Since Views is already using Serializer::serialize to get serialized data, it would be good for the RSS output in Views to use the same pipeline.

Proposed resolution

Create a thin wrapper around the Zend framework's RSS library so that the REST Export can be used to output RSS as well.

Comments

linclark’s picture

Issue tags: +REST, +WSCCI, +serialization

tagging.

linclark’s picture

In talking about this with Crell and Damian, it seems that the best way to implement collections like RSS is to have an EntityCollection object which Views populates and then passes to Serializer. This object would have setters for common required properties such as title, but would not have setters for properties which aren't in the other spec.

Required feed-level properties from RSS are:

  • title
  • link (the URI)
  • description

Required feed-level properties from Atom are:

  • atom:id (which must be an IRI)
  • atom:title
  • atom:updated

HAL collections should have the link URI.

damiankloip’s picture

Issue tags: +VDC

Missing the most important tag ;)

linclark’s picture

Status: Active » Needs review
StatusFileSize
new12.78 KB

I attempted this. My approach was to add the RSS support to the Serializer service that we register in the container. This would make requests with an application/rss+xml accept header return RSS, both within Views and outside of Views.

I'm attaching a patch which demonstrates this pipeline. The patch adds an EntityCollection class and an RssEncoder. The RssEncoder is NormalizationAware because we are using the ZendFeed Writer to assemble the RSS, rather than passing around arrays as the Normalizer interface expects. For a similar example, look at Symfony's XmlEncoder.

The end goal would be to replace the logic in all of the various Views RSS plugins with simple calls to Serializer::serialize(). There are two ways to do this.

Least disruptive
Remove the rows plugins, such as RssFields. Move the form for custom mappings which is in RssFields::defineOptions to the RSS style plugin. Then, replace the hardcoded RSS row plugins for things like Node with style plugins. These entity-type-specific style plugins would extend the RSS style plugin, only providing default mappings.

Better
Provide a mapping layer for RSS in general. This would make the mappings available to the serializer even if serialize is not being called from Views.

To be honest, I don't think that we can finish this by API freeze, so if this is considered an API change, I think it will have to be D9.

Status: Needs review » Needs work

The last submitted patch, 2003108-05-views-rss.patch, failed testing.

linclark’s picture

Status: Needs work » Needs review
StatusFileSize
new12.78 KB

Reroll.

dawehner’s picture

How much do you think has to be done to at least allow maybe contrib to provide a proper implementation?

+++ b/core/modules/rest/lib/Drupal/rest/Plugin/views/style/Serializer.phpundefined
@@ -126,7 +127,15 @@ public function render() {
+    // @todo Use the real description.
+    $collection->setDescription('foobar');

The rss style plugined had a getDescription() method back in the days, not sure whether this is still the case. Maybe getting the collection should be moved to a separate method so it can be easily overridden in a subclass. I guess we need a subclass anyway ?

+++ b/core/modules/serialization/lib/Drupal/serialization/Tests/RssEntitySerializationTest.phpundefined
@@ -0,0 +1,58 @@
+class RssEntitySerializationTest extends DrupalUnitTestBase {

Is there a reason why this is not a unit test?

linclark’s picture

How much do you think has to be done to at least allow maybe contrib to provide a proper implementation?

I'm not familiar enough with Views to know for sure. However, I believe that consolidating all of the various plugins into the RSS style plugin, and then subclassing that to provide default mappings for node, etc, would be the way to do this.

The rss style plugined had a getDescription() method

I didn't check to see whether there was a getDescription method, I can check.

Is there a reason why this is not a unit test?

Do you have an example of using the TypedData API from a PHPUnit test? My impression was that if you were using Entity API, you couldn't use PHP Unit.

Status: Needs review » Needs work

The last submitted patch, 2003108-07-views-rss.patch, failed testing.

dawehner’s picture

Maybe I just got confused because the test didn't added any kind of entity into the collection.

eric_a’s picture

I'm guessing the fatal error is related to this:

diff --git a/core/modules/serialization/lib/Drupal/serialization/Tests/EntitySerializationTest.php b/core/modules/serialization/lib/Drupal/serialization/Tests/EntitySerializationTest.php
index 46ad0cc..63c36ff 100644
--- a/core/modules/serialization/lib/Drupal/serialization/Tests/EntitySerializationTest.php
+++ b/core/modules/serialization/lib/Drupal/serialization/Tests/EntitySerializationTest.php
@@ -63,7 +63,7 @@ protected function setUp() {
     $this->entity = entity_create('entity_test_mulrev', $this->values);
     $this->entity->save();
 
-    $this->serializer = $this->container->get('serializer');
+    $this->serializer = $this->serializer;
 
     $this->installConfig(array('field'));
   }
linclark’s picture

Thanks for taking a look. This issue is not yet at the point where we need to work on making the tests pass because we still need to hash out the architecture.

linclark’s picture

I created a separate issue to handle the EntityCollection stuff, #2100637: REST views: add special handling for collections.

damiankloip’s picture

Good plan Lin, I like the sound of that.

Crell’s picture

Version: 8.0.x-dev » 8.1.x-dev
Issue summary: View changes

I don't think the committers would approve this for 8.0 at this point, but it feels 8.1-friendly. There's no functionality change, just changes to the internal implementation, which should be fine for 8.1.

mikeker’s picture

Status: Needs work » Postponed
Related issues: +#2296885: Remove format_xml_elements()

Based on #16, moving this to Postponed. Also added a related issue: #2296885: Remove format_xml_elements().

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

Status: Postponed » Needs work
Issue tags: +Needs reroll

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

vacho’s picture

The last patch for this issues is very old. So I write by now the changes that is need to update in code for update the last patch.

/core/modules/rest/lib/Drupal/rest/Plugin/views/style/Serializer.php
Has been moved to /core/modules/rest/src/Plugin/views/style/Serializer.php

/core/modules/rest/lib/Drupal/rest/Tests/Views/RssTest.php
Is a new file, currently exist similar but in deep diferent code /core/modules/taxonomy/tests/src/Functional/RssTest.php

/core/modules/serialization/lib/Drupal/serialization/Encoder/RssEncoder.php
/core/modules/serialization/lib/Drupal/serialization/EntityCollection.php
/core/modules/serialization/lib/Drupal/serialization/Tests/EntitySerializationTest.php
/core/modules/serialization/lib/Drupal/serialization/Tests/RssEntitySerializationTest.php
Is a New file. Now lib folter is missing for all modules it is a old structure.

/core/modules/serialization/serialization.services.yml
Needs update with new service for RssEncoder

/core/modules/system/tests/modules/entity_test/lib/Drupal/entity_test/Plugin/Core/Entity/EntityTest.php
Has been moved to /core/modules/system/tests/modules/entity_test/src/Entity/EntityTest.php

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

xjm’s picture

Status: Needs work » Postponed

We may be deprecating our dependency on Laminas (formerly Zend) Feed; if so, this issue should be marked wontfix. Postponing for now on #3118154: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 10 core by 9.4.0-beta1.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

alexpott’s picture

Status: Postponed » Closed (won't fix)

We've deprecated the writer service - #2919215: Deprecate feed.bridge.writer. This would depend on the service so it looks like we won't do this. Updating status accordingly.