🇵🇹Portugal @dxvargas

Account created on 23 November 2009, over 14 years ago
  • Owner, Project Leader, Web Consultant at Webzina 
  • Drupal consultant at Accenture 
#

Recent comments

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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?

🇵🇹Portugal dxvargas

This problem was fixed already in #3125505.

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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)
🇵🇹Portugal dxvargas

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

🇵🇹Portugal dxvargas

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".

🇵🇹Portugal dxvargas

What is the unclear/ugly error message?

🇵🇹Portugal dxvargas

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

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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.

🇵🇹Portugal dxvargas

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

Production build 0.69.0 2024