In the Feed: Style options, the Copyright field is a text field, which doesn't allow the data to be driven through views data. Copyright should be treated like all other fields.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | podcast-copyright_from_view.patch | 1.43 KB | geoffreyr |
Issue fork podcast-3033706
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
e0ipsoThanks for this report @winn. I was tempted to implement this on the initial implementation. I discarded the idea because I didn't think it make a lot of sense to manage different copyrights from the same view. I thought that even if a single site managed many podcasts, different copyrights would probably mean different views.
Is that not your use case? If it it not, have you tried altering the view with the corresponding hooks?
Comment #3
geoffreyr commentedI actually have a use case where I'd need this; where I have a single Drupal installation controlling multiple podcasts, and Podcast and Podcast Episode are treated as individual content types. I've attached my patch that implements this.
Comment #4
geoffreyr commentedComment #5
e0ipsoI would still like to support the old behavior, otherwise we'll break existing sites.
I'm torn on how to best implement this.
Comment #6
shane birley commentedIn my use case, I have a single Drupal site that produces six different podcasts -- in which all information for feeds and the display pages are being produced by a single view.
Does it not make sense for this field to be treated like all others but implement a feature in the selection for a text field or "custom text".
Just a thought.
Comment #7
jrearickI'm finding a need for this as well. I'm making one view that manages multiple podcast shows and may need different copyrights. I don't know if it is feasible to do with what @Shane Birley suggested and offer the choice of the existing plaintext or field option for copyright (and maybe generator too?). Maybe in a 2.x version of the module it could be implemented as fields?
I might just take this patch and run with it for now.
Comment #8
rodrigoaguileraThe points raised by @e0ipso are quite important as applying this would break the copyright field for existing sites.
I see two options:
What do you think?
Comment #9
rodrigoaguileraI just thought about a pattern that is used in the webform module when you are filling the values that a handler is going to use, for example the email address that receives the submission. There is a select with the fields available and an additional option to make it static.
I think this is way better than the two options from my previous comment, no need for update hooks.
I am open to commit a patch that implements that idea.
Comment #10
dwwI also need this. My use case is that I'd rather use Twig to define the copyright, so the year can be dynamic. E.g.:
2007-{{ "now"|date('Y') }} Whatever The Owner IsA dynamic year is essential, since no one wants to go in and update Views config every year. 😅 However, it's impossible at the moment.
I'll probably work on fixing up the patch early this week...
Thanks,
-Derek
Comment #13
pcambraWhat @rodrigoaguilera mentions is what I thought some of the fields should be the first time I installed the module: a select or other. I've added a dependency to https://www.drupal.org/project/select_or_other so we can leverage an existing and establish form element, I've added support for the copyright field (we might want to add additional issues for other fields), and handled the validation/form handling for elements that are the special case of _field.
I didn't want to change the module drastically, I like the _field distinction still, we might want to change it for 2.x or something, so I've added an update that changes the copyright to copyright_field, the style form should be generic enough to handle existing values as "other" from the select or other.
Ready for review, I think I need a second pair of eyes on this one :)
Comment #14
rodrigoaguileraThe code looks good to me. The only bit I am missing is some lines in the post_update that enable the new module. Or does Drupal enables dependencies automatically now?
Comment #15
pcambraThat's a great point @rodrigoaguilera, I've just fixed that.
Comment #18
pcambraMerged, thanks all!
Comment #19
Anonymous (not verified) commentedPosting this here as this appears to b related to the change introduced here and the Select (or other module.
In Views, when viewing the settings for the “Podcast RSS Feed” format settings, PHP errors are thrown.
This occurs if pointing the Copyright to a field or using the “Other” option to directly enter text.
Drupal: 10.2.4
PHP: 8.1.27
Podcast (using Views): 8.x-1.9
Select (or other: 4.1.0
Comment #20
pcambraThose are warnings, not errors, I'll open a separate task for these
Comment #21
pcambra