Account created on 20 November 2009, almost 16 years ago
  • Media technologist at WebCoo 
#

Merge Requests

More

Recent comments

🇳🇱Netherlands megachriz

I've addressed all remarks of mine from #9.

Most important changes:

  • The http_headers setting is now saved as array instead of a string. So if you had used a previous diff, you would need to reconfigure your feed types/feeds. I do have made it so that the forms still work if the setting was saved as string.
  • There is now test coverage for this feature.
🇳🇱Netherlands megachriz

@skaught
Thanks for helping, could the improvements be added to 2928904-media-target as well? Or do the changes from #127 not build on top of what is in 2928904-media-target? I see that the branch '2928904-127-feeds-combined-media-fix' is based on a very old Feeds version (8.x-3.0-alpha11, almost 4 years ago).

I have planned to look more closely to this issue in September/October this year. (Though I've also a few projects left to make Drupal 11 compatible, which I've also planned for that period.)

🇳🇱Netherlands megachriz

I see this is still an issue. It looks like that can only experience this issue when you configured the "Feeds item" to be displayed on an imported entity with the formatter set to "URL of the feed item" (the default formatter). By default, the "Feeds item" field is hidden, so that's why I did not noticed this issue myself before.

I expect that the provided MR fixes the issue. Hopefully all tests pass.

🇳🇱Netherlands megachriz

megachriz made their first commit to this issue’s fork.

🇳🇱Netherlands megachriz

I quickly scanned the code of EntityProcessorBase in the web interface and cannot find that second account switch right now. But I was pretty sure that I had made that. Did I perhaps only implement that for the D7 version of Feeds? 🤔

🇳🇱Netherlands megachriz

If I'm not mistaken, Feeds does a second account switch (to the owner of the item) when you enable the "Authorize" option. I'm on mobile right now, so it's harder to check for me now if that is the exact option that triggered the second account switch, but at least there exists a second account switch in the code.

🇳🇱Netherlands megachriz

Thanks for the review! I merged the code.

🇳🇱Netherlands megachriz

I think that adding Attribute does require Drupal 10.2?

Because \Drupal\tamper\Attribute\Tamper extends \Drupal\Component\Plugin\Attribute\Plugin. The latter class is not available in Drupal versions before 10.2.

🇳🇱Netherlands megachriz

I think that adding Attribute does require Drupal 10.2? Anyway, the Attribute code could be updated in 📌 Add attributes alongside annotations Postponed , though there is a good chance they would need to be updated again when 📌 Make Tamper plugins tell if they require a tamperable item Active gets merged.

@ptmkenny
If you like and have the time, there are a bunch of Tamper issues updated that can be reviewed/tested. :)
I keep track of issues that I work on in a spreadsheet: https://docs.google.com/spreadsheets/d/1cn4vmHosTfxgyI0zlvVv_ce94715eH-m...

🇳🇱Netherlands megachriz

megachriz changed the visibility of the branch attributes to hidden.

🇳🇱Netherlands megachriz

I think it is nice if we can add support for attributes now, so I'm reopening this. I do think of dropping Drupal 9 support after the next release.
Also because for Drupal 12 it will be required for plugin types to support attributes: https://www.drupal.org/node/3522776 .

🇳🇱Netherlands megachriz

@kopeboy
I tried the eca_tamper module and I see that the Hash plugin indeed does nothing there. That's because eca_tamper doesn't pass a tamperable item and currently the Hash plugin cannot work without an item.

So in the MR I provided an option to hash the input value instead of the item. And if no item is passed (in case of eca_tamper), the plugin will fallback to the input value as the data to hash.

Other hash options

I like the addition of other hash options that are provided in the code from #9, but I found out that hash_hmac('md5', 'Foo', ''); does not provide the same result as md5('Foo');, so that change would break backwards compatibility. Because of the amount of complexitity these options would add, I left this out for now.

Creating a hash from other fields on the item

Proposed in #6. This would be a nice option to add too, but I left that also out for now.

🇳🇱Netherlands megachriz

I've added the fallback option. 🙂

🇳🇱Netherlands megachriz

I experience only a single issue with this plugin and that one is handled in 🐛 Multiline Find/Replace Adds Carriage Return Active , so I'm setting this issue back to fixed. If you still get other errors while using this plugin, maybe it's better to handle that in a new issue.

🇳🇱Netherlands megachriz

It looks like this use case would fit better in the Rewrite plugin. There's a feature request to add an option to the Rewrite plugin to only rewrite if empty: Rewrite value using another field value only if empty. Needs work

Recently, also a Twig plugin was added (to the dev version as of now), so you could also use that one for conditionally setting values too.

🇳🇱Netherlands megachriz

We already have the "Trim" plugin that could be applied after the "Explode" plugin.

🇳🇱Netherlands megachriz

Tamper has been running on Drupal 11 for a while, so I think that this is fixed.

🇳🇱Netherlands megachriz

I provided a simple solution + test coverage: submitConfigurationForm() just replaces "\r" with an empty string before the text is converted to an array.

🇳🇱Netherlands megachriz

After this issue was posted, some changes were made to the boolean plugin in #3322750: Some plugins do not implement submitConfigurationForm() correctly - Add UI tests .

I found one case where the plugin did not work as expected: when the "If no match" was set to "True". In this case the value was returned as is instead of a TRUE value. That's because PHP evaluates the following condition to true when $this->getSetting(self::SETTING_NO_MATCH) is TRUE:

$this->getSetting(self::SETTING_NO_MATCH) == 'pass'

And this resulted into the original value being returned instead of TRUE.

Changing this to

$this->getSetting(self::SETTING_NO_MATCH) === 'pass'

fixes that issue.

I have reworked the tests to find this bug. I believe the issue reported originally in this issue got fixed by the changes in #3322750: Some plugins do not implement submitConfigurationForm() correctly - Add UI tests .

@thomasmurphy
I could not reproduce your issue. When I set the "If no match" to "Null" and I import something that does not match the "Truth" or "False" setting, I see in the Feeds log that the item's field really equals null:

{"title":"Nothing","bool":null}

So I assume the value gets modified later in the process. Either by a FeedsTarget plugin or by the field that the data gets written to.

🇳🇱Netherlands megachriz

I've provided a solution for this issue! Even though the tests are not passing yet, this is now ready for review and testing.

It works as follows:

  1. Tamper plugins that work with a tamperable item (like the Rewrite plugin), provide a list of source fields they use on the item.
  2. Feeds Tamper checks if any of these source fields are provided by FeedsSource plugins. This is the case for all "Feed entity" sources, that are listed for the Rewrite plugin as "[parent:*]" tokens.
  3. Feeds Tamper loads the data for FeedsSource source fields.

Be sure to test it in combination with 📌 Make Tamper plugins tell which properties they use of a tamperable item Active . That issue provides changes for the Tamper module, so that plugins can provide a list of source fields that they use. Changes don't apply on the latest Tamper release, so you should apply them on the dev release. The Tamper dev release also contains other improvements for the Rewrite plugin.

🇳🇱Netherlands megachriz

This sounds like an UX issue in Feeds Tamper, so moving it to that project.

The way Feeds Tamper currently works:

  1. It sorts all Tamper plugins by weight.
  2. Then it loops through all Tampers and groups them by source field.
  3. It loops through all source fields with Tamper plugins.
  4. Per source field, it applies all Tamper plugins for that source field.

So I think that the issue is is that the tampers for source 'Y' are handled later than those for source 'X'. This means that when Feeds Tamper applies tampers for source 'X', the value for the temporary target is not yet available.

A short term solution would be to set the weight of the first Tamper plugin for source 'Y' to a lower value than for source 'X'.

A long term solution would be to redesign the Feeds Tamper UI, so it becomes clear which source is taken care of first. Even better would be to change the processing logic so that tampers are not executed strictly per source in sequence. Instead, tampers from different sources could be interleaved according to their weights, allowing you to apply a tamper to source X, then one to source Y, and then another to source X within the same run. But that change has more impact and could cause BC breaks.

By the way, sorry for the very late reply. I'm walking through the bug reports for Tamper to see what should be fixed for a stable release.

🇳🇱Netherlands megachriz

I merged the code!

🇳🇱Netherlands megachriz

@codebymikey
Thanks for your review! I did not notice it earlier, since the issue did not get updated.

I merged the code!

🇳🇱Netherlands megachriz

I have been using this plugin for a while and did not detect new issues with it. Code looks good too. Merged!

🇳🇱Netherlands megachriz

Alright, I tested the code on a D11 instance and on a D10 instance. It looks good to go. Merged!

🇳🇱Netherlands megachriz

@calbasi
It would be good to also check for extra spaces on the definition of the CSV sources, on the "Custom sources" tab. Especially check if there are extra spaces in the "Value" field of a CSV source. Extra spaces for "Label" do no matter.

"Custom sources" tab:

Check "Value" field of a CSV source:

🇳🇱Netherlands megachriz

@calbasi
When I inspect the text that you posted I see:

codi_sigpac [space] [tab] codi_sigpac

So can it be that you added an extra space when you defined the source? codi_sigpac != codi_sigpac.

In 🐛 CSV headers with extra space don't get mapped to correct fields Needs work there is being worked on trimming CSV column names (during parsing and during entering column names), so that accidentally additional added spaces don't cause that the CSV column names do not match.

🇳🇱Netherlands megachriz

I plan to work on this in the next few weeks.

🇳🇱Netherlands megachriz

This was already reported before in 🐛 Rewrite plugin does not work after Explode Closed: duplicate . However, I just closed that one as a duplicate too because a fix for this issue is now available in a combination of two other issues:

  • 🐛 "Rewrite" plugin doesn't work right Active
    This ensures that the data of previously applied Tamper plugins (thus before the Rewrite plugin) is written back to the item. The Rewrite plugin then finds the most up to date data on the item.
  • Rewrite plugin: iterate through values to rewrite Needs work
    Among other things, this adds support for arrays for the Rewrite plugin. If your initial source value is for example Foo,Bar,Qux and you explode that using a comma as separator and then use the Rewrite plugin to add a "x" to it, you'll get ["Foox","Barx","Quxx"] instead of ["Foox","Foox","Foox"].
🇳🇱Netherlands megachriz

A fix for this issue is now available in a combination of two other issues:

  • 🐛 "Rewrite" plugin doesn't work right Active
    This ensures that the data of previously applied Tamper plugins (thus before the Rewrite plugin) is written back to the item. The Rewrite plugin then finds the most up to data on the item.
  • Rewrite plugin: iterate through values to rewrite Needs work
    Among other things, this adds support for arrays for the Rewrite plugin. If your initial source value is for example Foo,Bar,Qux and you explode that using a comma as separator and then use the Rewrite plugin to add a "x" to it, you'll get ["Foox","Barx","Quxx"] instead of ["Foox","Foox","Foox"].

Closing this as a duplicate now.

🇳🇱Netherlands megachriz

I've provided a fix and I've updated the issue summary to clarify what the problem is.

🇳🇱Netherlands megachriz

Moving this to Feeds Tamper now.

🇳🇱Netherlands megachriz

@starlight-sparkle
Thanks for your contribution! Can you put your changes in a MR? The testbot on drupal.org no longer looks at patches, so changes need to be in a MR now if you want that the code eventually gets added to the module.

🇳🇱Netherlands megachriz

I've paused moving projects to Drupal 11 at the moment. I have planned to look at this again in September and October this year. In my notes I see that 🐛 Allow premium message pseudo-field to be hidden Needs review should be resolved.

🇳🇱Netherlands megachriz

@codebymikey
If you are interested, I am giving the Rewrite plugin a major overhaul in Rewrite plugin: iterate through values to rewrite Needs work . It supports array replacements, and using nested values as replacements. There is probably some overlap now with the Twig plugin in terms of functionality. Maybe I went a bit too far in expanding the Rewrite plugin, but in my defense the majority of it I had already written before this issue was opened, it just took me some time to polish it.

🇳🇱Netherlands megachriz

I think it would be good to add tests for this. The tests should cover the following:

  • When periodic import is configured for a feed type, the date for the next import should be displayed.
  • When periodic import is NOT configured for a feed type, it should say "Not scheduled".
  • When periodic import is NOT configured for a feed type, but an import in background is started, it should say "On next cron run" (or something similar, refer to the D7 version of Feeds for that).

Since I think that case 3 is currently not working, setting this issue to "Needs work".

🇳🇱Netherlands megachriz

It depends on the current user time zone for how the date is displayed. For example, I have for one feed displaying the following:

do, 01/01/1970 - 00:59

I think it is better to fix this in FeedViewBuilder and replace the date with the text 'Not scheduled'. This is also consistent with how a similar issue was fixed in the D7 version of Feeds.

It will then look like this:

🇳🇱Netherlands megachriz

megachriz made their first commit to this issue’s fork.

🇳🇱Netherlands megachriz

Setting the action to resolve the issue in the issue title.

🇳🇱Netherlands megachriz

I've tested the MR this way:

  • Tried to import a CSV file with nothing in it: no items were cleaned. This is good.
  • Tried to import a CSV file that did not exist (404): no items were cleaned. This is good.
  • Tried to import a CSV file that did not change (304): no items were cleaned. This is good.
  • Tried to import a CSV file that has only a header row: all items were cleaned. This is good.
  • Tried to import a XML file with zero items in it: all items were cleaned. This is good.

I went through the code one more time and only made some small changes to code comments.

So I think all is good. Merged! Thanks all for contributing.

🇳🇱Netherlands megachriz

I had the code running for more than a week on a live site, I did not notice any regressions so far. I merged the code!

🇳🇱Netherlands megachriz

Setting this issue back to "active", because there is a way to reproduce it.

🇳🇱Netherlands megachriz

It sounds like this is an issue in the Gin Admin theme:
🐛 Sticky action buttons from a dropdown button set can't be clicked Active

As far as I can see, there is no mistake in Feeds in the definition of the dropbutton. But I leave this issue open, should a change in Feeds be needed to fix it.

I do see that in Gin, the submit buttons are rendered outside of <form>, so perhaps that causes issues with reapplying the right form actions.

🇳🇱Netherlands megachriz

Perhaps the Gin Admin theme (version 5.0.3) with the "Enable sticky action buttons" feature turned on doesn't work well with dropbuttons?

On Gin 4.0.6 (also with the "Enable sticky action buttons" feature turned) I noticed that the import buttons weren't displayed at all.

🇳🇱Netherlands megachriz

I think that the issue your reported here is covered by Rewrite plugin: iterate through values to rewrite Needs work . Can you confirm?

Closing this as a duplicate for now. Feel free to reopen if Rewrite plugin: iterate through values to rewrite Needs work doesn't help to resolve this. (I realize I reply two years later, but I only now get to address issues related to the Rewrite plugin.)

🇳🇱Netherlands megachriz

I think that the issue was that previously the Rewrite plugin displayed the labels of sources instead of keys. This has been resolved in #3185029: Rewrite plugin: use keys of source definition in replacement patterns in november 2022, so I assume that this issue is no longer a thing. Feel free to reopen if I'm wrong.

🇳🇱Netherlands megachriz

Array replacing is now supported.

If the source data is:

[
  'name' => [
    'foo',
    'bar',
    'qux',
  ],
  'ext' => [
    'jpg',
    'png',
    'gif',
  ],
]

And you apply a the Rewrite plugin to the source 'name' using the text [name].[ext]

You will get:

[
  'name' => [
    'foo.jpg',
    'bar.png',
    'qux.gif',
  ],
  'ext' => [
    'jpg',
    'png',
    'gif',
  ],
]

I've also been working on supporting nested data, if you use the text [name].[ext.1] instead, you should get:

[
  'name' => [
    'foo.png',
    'bar.png',
    'qux.png',
  ],
  'ext' => [
    'jpg',
    'png',
    'gif',
  ],
]

For this I've not added test coverage yet. Marking as "needs work" for additional test coverage.

🇳🇱Netherlands megachriz

I think that the issue actually is in Feeds Tamper:

  1. Say you have a source item with the following data:
    [
      'phone' => '123/456-7890',
    ]
    
  2. On the source "phone", you apply the Tamper "find_replace", replacing / with )
  3. Also on the source "phone", you apply the Tamper "rewrite", with the following text: ([phone]

With Feeds, the result becomes:

[
  'phone' => '(123/456-7890',
]

That's because Feeds Tamper now writes the result back to the source at the end of the chain and not in between.

  • Branch 3323381-rewrite-tests_only changes ChainedTamperTest to mimic Feeds Tamper's current behavior.
  • Branch 3323381-rewrite-test-updated changes ChainedTamperTest to mimic what Feeds Tamper's behavior probably should be.
🇳🇱Netherlands megachriz

@lindsay.wils
Can you try to reproduce your issue on a clean install? I cannot help fix the issue if I don't know how it occurs.

🇳🇱Netherlands megachriz

Nice work so far! I've some remarks:

  1. I think that we should avoid <code> tags in translatable strings.
  2. On the feed form, it would be useful to see what the default configured headers are, maybe as a placeholder for the textarea.
  3. I think it would be better if the configured http headers are saved as an array instead of a string. For both the feed type and the feed.
  4. Needs tests.

Test coverage

  • Functional test for configuring a feed type with http headers:
    • Assert that misconfigured headers result into a validation error.
    • Assert that empty lines are ignored and not saved as configuration.
    • Assert that configured headers are saved.
  • Functional test for configuring a feed with http headers override: test the same things as for configuring a feed type with http headers.
  • Unit test for asserting the expected headers when they are configured on the feed type.
  • Unit test for asserting the expected headers when they are configured on the feed.
  • Unit test for asserting the expected headers when they are configured on both the feed type and the feed.
🇳🇱Netherlands megachriz

To summarize:

  • You have three feed nodes using the same feed type.
  • The content item that got unpublished was only imported by one feed, not by the other two.
  • The content item that got unpublished was present in the source file and even updated during the import.

Is there a way for you to reproduce the issue on a clean Drupal install? Because else it would be very hard to find out what exactly is causing this bug.

🇳🇱Netherlands megachriz

@joelpittet
Good catch about the exception throwing during clean(). I think if one of the plugins throws an exception, the remaining plugins should still be called. I have adjusted this. (In practice, only the processor plugin in Feeds implements CleanableInterface, but in theory, there could exist contributed modules that implement it for the other plugins).

Also, is there any risk that one plugin’s clean() call could mutate shared state on the feed in a way that affects how later plugins behave within the same loop?

Yes, each clean() receives the same state object, so they could manipulate that. I'm not sure yet if that is a concern. At least, that behavior doesn't change with the code changes.

🇳🇱Netherlands megachriz

Wow! This looks great. In the code I could only spot that some of the code comments and names of methods could be improved. And that there are a few unrelated fixes. Ideally these should be handled in a separate issue, but I do appreciate getting these fixed too. 😀

I'm going to apply the changes on a live site that uses Feeds just to see if that results into any regressions.

Thanks for the work so far!

🇳🇱Netherlands megachriz

Very well made! I merged it.

Possible improvement for a follow-up: allow arrays as replacement patterns. The Rewrite plugin also is limited in this regard.

Let's say you have two sources called "name" and "extension" and you have the following lines in the CSV:

name,extension
foo|bar,jpg|png
baz,gif

You might want that to result into:

I assume that is what is 🐛 The rewrite plugin renames multiple values with the same (first) row Active about.

🇳🇱Netherlands megachriz

This is a great addition! I do wonder if we should fallback to strtotime() when parsing the date fails. Maybe provide that as an option? "Fallback to strtotime() if the date could not be parsed.". What do you think?

If you have applied the Tamper "String to Unix Timestamp" to the source "date" and set the date format to "d/m/Y" and then import the following CSV:

title,date
Foo,2020-09-01
Bar,01/11/2011
Qux,01-10-2011

This is the result after import (using the latest dev releases of Feeds and Feeds Tamper):

🇳🇱Netherlands megachriz

Alright, so the following is a different issue for you:

title,url,status,title2
I see the issues here are:

  • title2 appears at last, even though it is used on the first mapping row.
  • title still appears in the template, even if it is no longer used in the mappings.

Expected CSV template should have been:

title2,url,status

Can you be more specific with the issue that you experience and provide a step by step plan with how to reproduce it?

🇳🇱Netherlands megachriz

I merged the code! This issue took a long time to resolve, because in the past years I had put most of the time into getting Feeds to a stable release.

For the most optimal experience the latest dev of Feeds is required. Allow parsers and event subscribers to mark an item as invalid Needs work has been merged as well.

When this gets into a release of Feeds Tamper I plan to create a new Feeds release on the same day.

🇳🇱Netherlands megachriz

Navigation Extra Tools doesn't make any difference for me. The button "Save and import" still works for me. Could it be theme related? Or are there perhaps JS errors on the page?

🇳🇱Netherlands megachriz

I also tried to reproduce the issue on Drupal 11.2.2, but I also did not encounter the reported issue with that version.

🇳🇱Netherlands megachriz

I tried to reproduce this issue on Drupal 11.1.8 and PHP 8.3.10, on a clean install, but for me the button "Save and import" works fine on the feed add page.

Steps that I took:

  1. Installed Drupal using the standard profile (via drush si).
  2. Enabled modules "Navigation", "Feeds" and dependencies.
  3. Added a feed type with the HTTP fetcher and the RSS/Atom parser.
  4. Added mappings: "Title" to "Title (title)", "Item GUID" to "Feeds item (feeds_item): Item GUID", "Description" to "Body (body): Text".
  5. Added a feed with title "Feeds" and feed URL " https://www.drupal.org/project/issues/rss/feeds ".
  6. Clicked "Save and import".

The import went fine and imported 50 items.

So I think this needs more steps for reproducing the issue, try to reproduce it on a clean install.

🇳🇱Netherlands megachriz

Interesting issue. As I'm not familiar with the Trash module yet, I'm not sure what the best way is to solve this problem. If possible, I would like to avoid the soft dependency on the Trash module, because making sure the Trash specific code keeps working would require tests and a dev dependency on the Trash module. Also, I'm aiming for a pass on PHPStan. With the current implementation, I think that will mean that eventually all child classes of FieldTargetBase would need to pass the Trash service instance to the parent. See 📌 (PHPStan) Add dependency injection for FieldTargetBase and add deprecation warnings Active for other services I've planned to inject in FieldTargetBase in the future (and require them in Feeds 4.x).

One thing we could do instead, but I'm not sure if that's enough, is add a query tag to the query that Feeds executes, for example:

$query->addTag('feeds_unique_query');

This tag would then always be added.

In theory, you could then implement hook_query_TAG_alter() to perform the Trash specific code, though I don't know if adding another query tag in such implementation has the desired effect.

🇳🇱Netherlands megachriz

Feeds only aims to support targets for fields provided by Drupal core, so therefore I'm moving this issue to the Redirect issue queue.

There is already an issue there about it, so closing this as a duplicate as well.
Feeds: redirects_source field target class. RTBC

🇳🇱Netherlands megachriz

I see that the unit tests for the Copy plugin were a bit weak. Thanks for the improvements! I merged the code.

I hope to look at your other contributions soon.

🇳🇱Netherlands megachriz

megachriz made their first commit to this issue’s fork.

🇳🇱Netherlands megachriz

Thanks for providing code and tests! Looks good at first glance.

I think that the tests fail because of the following warning:

1 test triggered 1 PHP warning:
1) /builds/issue/tamper-3530101/vendor/twig/twig/src/Template.php:345
Array to string conversion
Triggered by:
* Drupal\Tests\tamper\Unit\Plugin\Tamper\TwigTest::testTwig
/builds/issue/tamper-3530101/tests/src/Unit/Plugin/Tamper/TwigTest.php:93

🇳🇱Netherlands megachriz

I'm kinda waiting for a new release of Role Delegation, because tests currently still fail on PHP 8.4 most likely (but not 100% sure) only because of PHP 8.4 errors in that module. 📌 Nullable types must be explicit Active was recently merged. But if a release on their side takes too long, then perhaps it would be good to create a new release that is at least partly PHP 8.4 compatible.

🇳🇱Netherlands megachriz

If you could add tests for it too, that would be great! (A unit test and a functional test are required in order for the code to be merged.)

🇳🇱Netherlands megachriz

Sounds like a good idea! Do you need any pointers to start with writing such a plugin?

🇳🇱Netherlands megachriz

A feed gets in a locked state as soon as an import for it gets started. It gets unlocked again when the import successfully finishes. When an import ends abruptly (for example because of a PHP fatal error), the feed remains locked.

The easiest way to get a feed in a locked state (and have it be in that state for a bit longer) is to go to a feed, click on "Import in background" (/feed/x/schedule-import) and click the button "Schedule import". This will lock the feed and create a queue task. The queue task will be performed on cron runs. So long that you don't cron, the feed remains locked (unless you unlock it manually).

You can also manually lock a feed using the drush command 'feeds:lock':

drush feeds:lock 1

'1' is the ID of the feed to lock.

🇳🇱Netherlands megachriz

Not that I know of. The file target in Feeds can currently only download the image from a url. So without custom code or additional modules the image would need to be downsized at the source.

I do have written an alternative file target that accepts a base64 string as input in my Feeds DEV sandbox project. But then you would still need to write Tamper plugins to download the image, downsize it and convert it to a base64 string.

It would probably be better idea to make a change to the image target in Feeds to respect the maximum image dimension setting. Too bad that setting is not evaluated automatically when storing images programmatically.

🇳🇱Netherlands megachriz

There should be a button called "Update" on the settings form. Theming issue? Try if you can replicate the issue with a different admin theme. If you then see the update button, the issue is likely theme related.

Screenshot from a Dutch site:

🇳🇱Netherlands megachriz

I see that this feature was completed when #2989279: Add a target to entity ID was done.

🇳🇱Netherlands megachriz

Thanks for working on this!

I think that the Expire feature should be able to work without requiring an import. So it should get triggered on cron runs by itself. Do you think that makes sense? Is that doable without loading all feed types on each cron run?

🇳🇱Netherlands megachriz

The Tamper "Unix timestamp to Date" requires indeed a number as input.

What you could do is the following:

  1. Map a blank source to your date (or text) field.
  2. Add the Tamper "Set value or default value" and set the value to "now".
  3. Add the Tamper "String to Unix Timestamp", this will convert "now" to the current time.
  4. Add the Tamper "Unix Timestamp to Date" (with for example the format "Y-m-d"). You'll get the current date.

If you set the mapping target as unique, I think you'll get one item each day.

Do note that you could possibly get duplicate items imported in case the item on day 1 is the same as on day 2.

🇳🇱Netherlands megachriz

Yes, this is possible. You just need to have a field on your content type that can be used as a unique identifier. That can be any text or number field. Using the node ID is also possible. Feeds Item GUID may not be possible, because I'm not sure if Devel Generate sets a value for that field, I would assume it does not.

On the mapping page you need to map to the field that can be used as a unique identifier and for that target, be sure to click the checkbox in the column "Unique":

🇳🇱Netherlands megachriz

This feature has recently be added to Feeds: Change RSS default importer to accomodate multiple values in Active

Currently it is only available in the dev version.

🇳🇱Netherlands megachriz

Feeds only aims to provide mapping targets for fields defined by Drupal Core. This looks like to request support for a field type by a contrib module, so the FeedsTarget plugin should be added to that module instead.

I see an issue already exist there, so closing this as a duplicate as well.
Feeds mapper Active

🇳🇱Netherlands megachriz

Alright. I tested the code myself by using chmod 000 on certain directories to see if the directory got displayed in the error message on import and it did.

I merged the code.

Production build 0.71.5 2024