@maurizio.ganovelli
This was my inclination as well when I reviewed the code. I've created a patch for anyone who wants to try this solution.
I was able to resolve this by implementing the solution defined in the change log.
https://www.drupal.org/node/3458551 →
You are correct; it should be a lowercase "t", but in the Intercept codebase, it's an uppercase "T"
@attheshow
That's correct; if you use the field UI to add a field to the User entity that allows more than one value to be added, clicking "add another item" will cause an error. You should be able to test that pretty easily.
That does sound like a neat feature to connect directly to the database; we don't have any use cases for that at the moment. If you write a new connection type plugin that supports it, I would be okay with merging that into the project.
This is just a custom version that has many customizations.
That's correct, we're using this on another site which makes a lot of customizations. They've introduced event templates, and those templates use the same event content type, just with a template boolean. We don't want dates to be stored with the template.
Sorry, the above patch was missing code and will not work. This patch addresses that.
I refactored the JavaScript code to support select, checkbox, and radio elements. It's working for me within a paragraphs architecture.
droath → created an issue.
Upon further reflection on this issue, there are two potential solutions for using Entity Extra Fields to render Views. A developer can implement this using either the Views or the Block plugin within the Entity Extra Field module. I currently do not recommend supporting views being rendered in the block plugin when we have a Views plugin available. I've added some additional code to the Views Plugin within the Entity Extra Field module to address this issue. Please let me know if this addresses the issue you're personally experiencing.
@hoegrammer
That's interesting; we committed a patch that was supposed to address that exact issue, as most people were experiencing the problem where the configuration naming was set up incorrectly, which was introduced in a previous patch that was committed some time ago.
Can you confirm that after the upgrade you run `drush updb`?
Sorry this has taken so long to get merged in; much appreciated.
I wasn't able to get the MR to apply. Are you able to reroll?
I finally decided to confront this issue myself and began investigating what was happening, while also trying to recall my thoughts during the initial development process. Based on the current architecture of the Drupal condition API, it seems that core conditions are at least managing negation within the evaluation method of the condition plugin. I believe this was the standard that most developers were using within contrib. has well.
With that in mind, it makes more sense to wait for guidance from Drupal core. If they decide that condition plugins shouldn't handle their own negation, then we can patch the code accordingly. However, until a decision is made, I think the best approach would be to use the Drupal core patch https://www.drupal.org/project/drupal/issues/2535896 🐛 ConditionManager::evaluate() should not negate results itself Needs work to address this issue. Checking the `$condition->isNegated()` method and negating the value ourselves could introduce more bugs, as there is no clear way to determine whether the condition evaluation method has implemented the negation within the evaluation or not.
@anybody, this change appears to be a duplication of https://www.drupal.org/project/entity_extra_field/issues/3440365 🐛 Unable to edit existing extra field or render any public site pages Active . Can you confirm?
Closing, as it appears to be a duplicate of #3440365.
I'm currently in the process of getting the module approved by the Security Advisory. If anyone who uses this module has some time and would like to review the application, it would help push this process through faster. That would be much appreciated.
https://www.drupal.org/project/projectapplications/issues/3468193 →
I've updated the default branch in GitLab.
@Grevil! Much appreciated, I've been waiting to implement this feature for a while! :)
@Anybody Yes, once those issues are resolved and marked as reviewed by the community, I'll merge this into the dev release.
Much appreciated, I couldn't agree more with this change.
Great, I will check out the CLI tool and make sure to account for that in my next release.
@anish.a
I don't believe this error in the log is caused by the Entity Extra Field module, as it's not in the stack trace. I've come across this error often before during updates but have never pinpointed the cause. I suspect it may be related to caching. I suggest trying to resolve the error by clearing the cache first. If more detailed instructions on reproducing the issue are available and it is indeed a bug in this module, then I will investigate further.
@Vacilando
Could you please provide more details on when you encounter that error? I am unable to replicate it. The patch that has been merged appears to be functioning correctly for me on a fresh Drupal installation.