🇵🇹Portugal @dxvargas

I'm now submitting a new patch with some changes suggested by @huzooka in the previous comment.

1. Done
2. To do
3. Done
4. Removed
5. Comment removed. I got into a situation where the entity was not an instance of FieldableEntityInterface, for that reason I'm not using your suggestion.
6. Done
7. Done
8. Done

I'm uploading a patch with the approach given by @claudiu.cristea, with a hook whose invocation returns a list of entity types that should have the publication date.
It's far from being a final patch but it works in a basic way and may be useful for next steps.

I think this should be optional. I don't agree that this field should be enabled without asking, just by enabling this module.

I agree with @claudiu.cristea that creating files on the fly is not a good idea.

Also, I don't see the reason to do this. Can you please explain?
Why not to do the storage updates immediately when saving the config?
I've done this experience and it worked. I can submit a patch.

About the config page, I don't see a problem with that.
Using hooks would also work but I actually prefer using the configuration page.

I'll reopen the issue for the discussion to continue and the patch to be improved.

dxvargas → created an issue.

I cannot reproduce this error.
After so much time without any replies, I believe the best decision is to close this issue.
@skitten, Feel free to reopen with more details if needed.

I've tested it and read the code changed, it's fine. I'll mark it as RTBC.
Not sure if it's a bug but anyways it's a good improvement.

The work is good so far and it's solving the problem that is being reported. Good.

But the method "\Drupal\file_url\FileUrlHandler::urlToFile" is where the problem started. It declares that it always returns a FileInterface but it can also return NULL. And there are other usages of this method that can also raise errors because the NULL case is not being handled correctly.
I think this should also be fixed. Here or in another D.O issue. What do you think?

This problem was fixed already in #3125505.

My patch shows also the corrupted characters when opening it here in the browser. Just like the patch in #3.
However, after downloading it I see them correct and I can apply #3 successfully.

This patch #3 from @viren18febS is working correctly. I put the issue as RTBC.

Thanks for the patch @viren18febS but I still see the corrupted characters.
I'll try to add my own patch and see how it goes. Please have a look.

dxvargas → created an issue.

It makes sense to not validate an empty source field.
I've tested with Drupal core 10, 1.x-dev and using a multiple taxonomy term reference field. Before when adding a new item I had this error. After applying the patch the error was gone.

I've tested the patch with success.

It is similar with the code existing in the module group except that:

1. it applies the change of owner to all revisions and
2. validates the entity before saving (otherwise it would raise an error)

Right @glaze, I forgot to check that, stupid me!
I close this issue. Thanks!

I've checked and there are several modules that use the "administer site configuration" to control their configuration page access. Examples:

• Devel
• Admin toolbar
• Purge UI
• Ajax comments
• Chosen
• Compact Date Range Formatter
• SPARQL Entity Storage

There are also modules having their own permission to control the access to their configuration page.

I think, since the configuration of this module is very basic, we can rely on the generic "administer site configuration".

dxvargas → created an issue.

What is the unclear/ugly error message?

I had the same problem. I found out that it was caused by not having the PHP extension for redis.

I fixed it by running:
sudo apt install php8.1-redis

The tests are now fixed in #32, good!
For the rest, it is the same fix as before (#25), that was already reviewed by the community.
Let's move back the issue to RTBC.

Search API was already fixed and the issue here should be fixed when using the updated version.
I close this issue, feel free to reopen if needed.

I agree with the changes.
I couldn't find the reason why dev was chosen. It was in a commit to make "user_fields_visibility" compatible with d10. There are no changes in recent versions of "field_permissions" that would be necessary for this. It seems a simple mistake.
I mark the ticket as RTBC.

dxvargas → created an issue.

The change fixes the issue in a good way and it's quite simple.
I mark it as RTBC.