I access the view from the default_domain page with anonymous user,
and it shows the nodes that are assigned the domain default_domain, but I need it to show the nodes that are assigned subdomain_1, subdomain_2 or subdomain_3
From my understanding you try to achieve something which in its result is rather "the opposite" of what Domain module wants to provide here. Domain module cannot operate in opposite logic for the same form. Domain simply does show content for selected nodes. If you want to show all nodes regardless of the domains they are assigned to you need a simply view ignoring the domain filter. If this is not working because of the circumstance that you do not call the nodes list in admin area but on a certain domain as not logged in user, well you fall into the case of Domain's supposed logic since the call from this domain restricts content to be shown from this domain only of course. To circumvent this for edge cases I usually recommend to serve one domain as "management domain only" which is always selected per default on each node. This way you have a domain which will show all content. No hacks or patches needed.
Thanks for all the work in here. But - Please do not review your own work. First of all patches and merges should be made against latest dev. Second, there are no further comments if anything of #20 & #21 has been addressed yet. Also I would like to read opinions if the attempts here overlap somehow with: 🐛 Fatal error: Type $value_value must be string DomainAccessCurrentAllFilter.php on line 0 RTBC
Same here. Tests with and without cache do not do anything on this. I just did not had time to test it yesterday no more. That are good news!
For rerference: I created this issue based on the worries raised in core issue 🐛 Container compile crash when a service decorates a destructable service Needs work affecting many contrib and regarding your comment in #25
Yes, the domain issue here is actually https://www.drupal.org/node/3425054 → -- though we still need to check these decorations:
domain.route_provider:
class: Drupal\domain\Routing\DomainRouteProvider
decorates: router.route_provider
decoration_priority: 10domain_config.library.discovery.collector:
decorates: library.discovery.collector
class: \Drupal\domain_config\DomainConfigLibraryDiscoveryCollectordomain_config_ui.factory:
class: Drupal\domain_config_ui\Config\ConfigFactory
decorates: config.factoryThose should be two issues in the Domain queue.
like described in the summary. Since so many contrib has been affected by this it was good that we made sure not being in row with this. So we got off lightly with that core issue affecting so many contrib.
Thanks @eswiderski good to now.
#22 @cpocket: Thanks for the review.
I get the following two variables need to be typed, likely due to when this patch was originally made.
public string $value_value;
public ?array $valueOptions;
I think this is related to: 🐛 DomainAccessCurrentAllFilter missing variable type inheritance Needs work and would be fixed there. I would encourage to commit the other first and then try to reroll this one here to be committed afterwards.
Please do not set RTBC by own patches without review of others.
Again: Thanks for the report and the work in here. Very much appreciated. But some nitpics:
- $items[] = ['#markup' => Link::fromTextAndUrl($label, $url)->toString()];
+ if ($domain->isActive()) {
+ $url->mergeOptions(['attributes' => ['class' => 'active']]);
+ }
+ $items[] = [
+ '#type' => 'link',
+ '#url' => $url,
+ '#title' => $label,
+ ];
These changes do not only add active class in case but also change/replace the ['#markup' => Link::fromTextAndUrl($label, $url)->toString()]; without documentation in the issue comments. This should be documented and explained even if obvious for the patch provider, so that follow up issues can better be tracked down and find its root causes.
Thanks for the report and work in here, very much apppreciated. +1
I had no time yet to look closer (review) but generally spoken: it is recommended to reroll patches always against latest dev. In this case 2.0.x-dev.
Is this issue still relevant in 2.0 branch? It is recommended to use latest beta 2.0 release and new patches against latest 2.0-dev since branch 8.x is not supported no more.
Despite of all the appreciated hard work in here I - sorry- cannot reproduce the issue.
Summary states:
If I click the Set as default link the theme is incorrectly set as default for all domains instead of just for the example domain.
This is not correct, at least not for latest dev and latest beta. It is correct that it "feels as if it would be set for all domains" because the selected domain jumps out of the select box by the page refresh on save, which is caused by another (not yet reported) issue: "select box does not keep selected domain after page refresh". But the setting is correctly made for the previously selected domain. At least on our tests here. You can circumvent this behaviour by selecting "remember last selection" in domain form settings.
So we maybe need to further investigate here before rerolling and committing to "not fix something which is not broken". Would recommend to collect more reports on this.
Needs reroll against latest dev.
@Chris64 and others: Sorry that I lost track of this issue while being busy and on business travel. Will hopefully get back on it soon. Thanks for the link @cosmicdreams, will take a look.
This looks completely unrelated.
@catch: Yes, it is... wrong issue, sry (mixed tabs, removed comment to prevent confusion)
Tested https://git.drupalcode.org/project/drupal/-/merge_requests/7959.diff on test 10.3 beta install with Domain.
The website encountered an unexpected error. Try again later.
Error: Call to undefined method Drupal\domain\DomainListBuilder::formBuilder() in Drupal\domain\DomainListBuilder->render() (line 318 of modules/contrib/domain/domain/src/DomainListBuilder.php).
Drupal\Core\Entity\Controller\EntityListController->listing()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 53)
Asm89\Stack\Cors->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 739)
Drupal\Core\DrupalKernel->handle() (Line: 19)
Added Domain to summary as a big contrib affected by this, since this will not only break one but all sites (domains) in the project.
Thanks at all tracking this so quick and raising prio. Contacted some bigger contrib checking against 10.3 beta to be aware of it. @catch: should we guide here for a quick fix? Is the green MR on top applyable to get rid of WSOD or is there still more to do for the quick fix?
Hello at all. And a special Hello to @aschiwi :) long time no see.
Thanks for all the reports and the detailed insides of each case in here. Much appreciated. We still cannot reproduce this TBH, so we need to find more overlaps in your cases to tackle it down. As #8 states we have tests on this. And we run multiple multi domain record projects where non of the issues described here happen. Nodes only appear on domains selected (checked) on the node edit form. We never had any other experience like this. But we have no other permission modules installed to make sure that nothing interfears here. So maybe we need a fresh Drupal install to test all together. Or are you willing to list all modules installed on your projects? Let me know and I will set up one instance for all of us.
And I would love to see you guys in #Domain channel I created some time ago for more detailed conversations regarding Domain upcoming final release. Maybe we can find the culprit in a quick meet up to move on here.
PPmnmi should be set with more clarification on the questions maintainers have. Backtrace is provided by OT. What leads you to the assumption that this is a Layout Builder issue? Otherwise, If you are sure about this please move the issue to Layout Builder so that core LB maintainers can take a look at it.
But consider the following: Apart from that issue here I think ShareThis is not 100% ready for Layout Builder yet. It confusingly shows 3 options of ShareThis to be addable as a Layout Builder section block on a node manage display layout. But one is only clickable but not addable (the widget), the other is addable as a field block but causes the error described here, which turns this manage display admin page into WSOD only able to get back by uninstalling ShareThis and the 3rd option is the default ShareThis block like provided on the Block layout pages. Which is recommended to use here on this node layout? It should be made clear which block should be used in a node manage display layout. Most would assume it should be the field block to provide the required context but this is the one breaking the form.
Since Layout Builder is the go-to core module today to build node displays (not mine but for others is) you should also consider to raise the issue prio. But I leave it up to maintainers to decide.
- Upgrading drupal/duration_field (dev-2.x cdf331a => dev-2.x 20674f7): Checking out 20674f7714 from cache
This commit causes:
[error] Cannot add field 'node__field_duration_hms.field_duration_hms_weeks': field already exists.
... when updating 2.0 dev from previous 2.0 dev and this breaks the site if it is part of a project update process since non of the required db updates can run being interrupted by this error.
Thanks @nicxvan! Very much appreciated that you still keep track on this. +1 . And I fully see your shared time issue. Same here. :) I try to make Conditional Fields stable as soon as possible as a newly added maintainer while I am not using it at the moment. I run 3 Drupal test installs (9/10/11) for it on our servers. It is good to split efforts so that single contributors do not run out of time on it, so, we can try to find others to help on tests as long as you could keep track on that patch you provided. :) That would help me a lot in case of new reports coming in on this patch :)
And thanks @all others for keeping up reporting. This is very important top move on. Just please try to make your reports understandable as much as possible so that any misunderstandings can be prevented and others who want to help can clearly follow your report.
Also - a comment to some previous contributions in here (a little bit longer ago) it is not helpful to post patches in here which fix individual user problems with certain versions or even worse with merged patches from other issues. Next contributors pick on this and run into confusion... Please let us work together on latest dev so that I can merge this into the upcoming BETA release I plan, where most of the users in here can go on with then.
Thanks at all! Keep it coming!
Thanks for coming back clarifying. Very much appreciated. +1
In short: you actually did a manual re-roll of the merge/patch to make it work in 4.0.0-alpha5, which In fact (the merge/patch) is just an added return. Glad that you was able to fix it for your scenario and thanks for taking the time to contribute.
Still we need to make sure that your case is really part of this issue here. We still need testers for latest dev version to go on.
In your scenario for example the question is:
I have field A which is a radio box with option 1 and option 2.
Also, I have field B that should be required and visible if option 1 is checked on field A
Is field B still required when it gets hidden by option 2?
Then, field C is required and visible if field A has option 2 checked.
Is field C still required when it gets hidden by turning back to option 1?
Both question contribute to the issue here but are not clear for me yet. In both cases you wouldn't be able to save if the required fields are empty (not filled).
Got the same issue.
What do you refer to? The original report? The last comment?
The changes works but I couldn't apply.
Attaching the new patch that I could apply to 4.0.0-alpha5 module version.
Thanks.
Sorry I have no clue what you are trying to say ... Couldn't apply? How can it "work" if you couldn't apply?
@#175: the latest MR only fixes the type hint nit pick mentioned before. So your issues probably indicates that the whole patch as-is from before has flaws and needs further testing or you run into something else mixed with this here. Please provide more backtrace or error report logs and how exactly you humbled into this.
Thanks for clarifying where it came from @nicxvan! +1
I am fine with MR or patches or both, what ever contributors prefer to help in the issue queue. I try to prepare another BETA release any time soon and I appreciate all help, because it was a huge attempt to clean up the issue queue over the last weeks.
While type hinting isn't a deal breaker I just think: Beside if you use autocomplete software like some IDEs, type hinting and writing the doc string aside from being a good practice for understandable code, will immensely help such tools to actually write the whole function almost itself. Writing good doc string and type hinting is doing all devs a favor. How often we have type error issues in all the issues queues ... countless. Great to see this clarified.
I do not want to turn down progress here but wouldn't it be great to have tests here on such a big addition? Anyone who could chime in here?
Can't find the issue in the rush but I know there is another issue here around targeting the behavior that Conditional Fields only works if any of corresponding fields are in any of the forms, mostly at least in default form. This seems to be a requirement - or let's say - "as it works" in the moment the way Conditional Fields is build, and I am not sure if we rather need refactoring here in a bigger scope to fix this and for all other issues related and how this patch here interferes progress on this. I would prefer that Conditional Fields do not require to have any of the conditional fields in any form to be kept because rebuilding content editing UI sometimes require to move fields around and disable them here and there. In the moment Conditional Fields sometimes removes the setup then completely if a field of this condition is disabled.
Before I review and commit this I would like to get more opinions on this and of we maybe need a META to solve this from the ground up.
Thanks for the report and work in here! +1
Please test if this happens only if Inline Entity Form is used which is assumed by reading the report as-is. If yes then the title and summary needs to be more specific. I changed it accordingly in assumption that it is so, but please, remove this if it not the case.
Some nit picks: please do not use abbreviations in issue summaries. Drupal.org is a multi-language user base driven community and some people have a hard time to follow texts with abbreviated words. Especially if not used consequently in the same way (edited issue summary).
Apart from that this issue has some overlaps with another issue regarding hidden fields which are required. (Can somebody please help me to find it and link, refer here, no time atm)? - Please try to read/follow both issues to understand that there are different opinions on how Conditional Fields should handle this and incorporate patches from here and there.
Thanks for all the reports, all the hard work and efforts in here. It seems we are close before committing but there are still some fishy nit picks to clarify:
In the first patches from #65 - #87
the function parameter type definition in the line changes near 242/335 look like this:
* Note that you don't need to manually set all these options, since default
* settings are always provided.
*/
-function conditional_fields_attach_dependency(&$form, &$form_state, $dependee, $dependent, $options, $id = 0) {
+function conditional_fields_attach_dependency(&$form, &$form_state, $dependee, $dependent, $options, $id = 0, $paragraph_info = []) {
From #98 and after it looks like this:
* Note that you don't need to manually set all these options, since default
* settings are always provided.
*/
- public function attachDependency(array &$form, &$form_state, $dependee, $dependent, array $options, $id = 0) {
+ public function attachDependency(&$form, &$form_state, $dependee, $dependent, $options, $id = 0, $paragraph_info = []) {
Which indicates that another issue or patch committed added array type definition into this line which has been removed in this patch history here again. I am not deep enough into it to know how to handle this, so I set it PMNMI with the hope that some of the ones who worked on the patches can clarify this for me.
After that I will go on reviewing and testing and discussing the commit with other maintainers.
EDIT: Oh and what about tests? Such a big addition needs tests. Anyone?
Awesome work in here +1!
That would be great news and +1 for what @WimLeers sad: If the scope of this issue is already covered in core let's move on and close this. Would be great if @Nuke_Luke can confirm this. Apart from that I will go and test now to confirm. Other users who can confirm that is works already would be helpful too. Regarding our policies → I set it to PMNMI for now(?)
@JSchref: please do not change the issu summary on top of this thread. It is important introduction text for the underlying issue and is mostly written by the original reporer and/or changed by maintainers for tracking of issues, changes, and later backtrace of new issues.
Glad to see this rolling! +1 for all the hard work in here. Also RTBC from me by local testing.
Great to see that you keep working on it +1! Thanks. I just added an issue summary now.
Apart from that: Removed issue tags. Before adding tags read the issue tag guidelines → . Do NOT use tags for adding random keywords or duplicating any other fields. Separate terms with a comma, not a space.
The issue had no summary so I updated it to what I think the reporter is referring to .Feel free to extend if I am mistaken or forgot something.
Apart from that: Removed the issue tags. Before adding tags read the issue tag guidelines → . Do NOT use tags for adding random keywords or duplicating any other fields. Separate terms with a comma, not a space.
Patch looks good so far. Thanks for keeping on working on it! 1+ Any more users to review?
Descriptions of the Priority → and Status → values can be found in the Drupal project issues → documentation.
Same here like in #2:
I cannot reproduce the issue. Look at the screen cast I did for you guys. But only for latest 4.x dev, since we do not have no Drupal 7 test environments no more and most 7.x issues which do not have a reviewable patch or progress will be closed since Drupal 7 EOL is in Jan. 2025.
So by saying: Thanks for the report and all the efforts in here. But due to upcoming EOL of Drupal 7, I will close this issue on the way by cleaning up the issue queue.
Feel free to re-open as "Needs review" if you found a solution or have a patch to be reported and ported to help others on this outdated version.
If you think this issue or missing feature should be addressed in a newer Drupal core 8 and above compatible version of this project, then please file a new issue to the latest dev with a detailed report to reproduce and work on. Thanks for understanding.
Please re-roll against latest dev.
In fact I see now there is already a starting point @todo placed in the code of src/Conditions.php
// @todo Add support to these states:
/*
'relevant' => $this->t('Relevant'),
'!relevant' => $this->t('Irrelevant'),
'valid' => $this->t('Valid'),
'!valid' => $this->t('Invalid'),
'touched' => $this->t('Touched'),
'!touched' => $this->t('Untouched'),
'!readonly' => $this->t('Read/Write'),
'readonly' => $this->t('Read Only'),
*/
Side note: Date range is no core field. And disabled and readonly are two different HTML input behaviors. There is a readonly state attribute for HTML input fields doing exactly what you want, so you can REALLY make the field readonly without acting as disabled, not only simulate it with CSS. This part is missing in the patch.
Apart from that: The solution provided in this issue here is a great idea and actually should be a feature request since it implements an interesting new feature (originally as a work-around created by issue reporter but actually a great idea for a new feature). So let me sort the issues out and convert this issue here into a feature request with your patch as starting point. It also a great temporary work-around for the issue with dependency settings getting lost when a from field widget gets disabled under manage form display, like tracked in this issue: 📌 Refactor the concept of how dependency settings are assigned to fields and entity bundles Active
Thanks for the report and hard work in here. Changed issue summary and title/scope accordingly.
@Mohd Sahzad: Please do not copy patches and create merge requests without necessity or request/plea to save resources and clutter on D.O. and Gitlab. Thanks for understanding.
dqd → changed the visibility of the branch 3426265-update-version-tag to hidden.
Haven't read yet over all comments but found parallel thougths of what brought me here in the intial issue summary point 1.) and in comment #3 or nod_ while I was fixing library.yml version issues in contrib modules.
What if we simply use the module version created by packaging script as /?version-path-suffix for library files and deprecate the tag for library files completely? Is that possible? (Drawback: no manual override possible then. But for what should that be needed?) This could be a solution for both, contrib and core (at least in my head)
Changed the issue summary accordingly for better understanding what this issue used to be about.
What widgets refers this issue to and would should they do? I assume we talk about field from widgets and the input of a certain value as condition? Change title accordingly.
Here the list of plugins and therefor core form field widgets already supported for "has value" input condition:
- Core:
-
- Checkbox
- DateDefault
- DateList
- DefaultStateHandler
- EmailDefault
- EntityReference
- EntityReferenceTags
- LanguageSelect
- LinkField
- Number
- OptionsButtons
- Select
- TextAreaFormated
- TextDefault
- Contrib:
-
- LinkAddressfield
- Shs
Apart from that: I think adding support for core field form widget "has value" input is like hunting the white rabbit. It is not only node but also user fields, media fields, and so on. And there will be surely more in the next year or some will be removed from core... and so on. I am not sure if this is a good idea to run this as META tagged for a final release. This will be an endless issue. For maintainability I would rather suggest to close this in favor of single issues to be created when a user realizes that his widget is not 100% supported yet and a lot users wishes to implement it. So the module can grow healthy without maintainer burn out.
We have far more to do yet to fix some major problems on the base of the project and should concentrate on that for a final Drupal 10/11 release.
Reports like this ...
In our case, it seems most issues are related to the default value (require/optional) of the field itself, so they are not really caused by this module.
For me i have content types which have droplists that show selectable entity relations to other nodes.
After i activated the above modules, i also migrated these selectable nodes and i think it might started to work after that.
and man others ...
.. indicate that this issue has turned into a weird mixed issue from users who report that something is not working for them in the it used tow work in D9. This is not how we can handle issues and fix them. I have a very hard time to track all this in here and would kindly ask you to please think twice before posting. We need an issue for each case and each case needs a helpful traceable and reproducible report. Thanks for understanding.
this issue is for general 4.x branch compatibility with D10
The 4.x branch is compatible with D10 and we run many test sites with it.
No it is the upgrade issue here, where users want their settings back from D9 and expect them to work like before. Which in fact still has some base flaws and missing direction in here and very mixed reports, yes, but is not a general D10 compatibility issue. Which is far too generic anyway, because then you can count all issues into it. An alpha release has flaws yes, but is cannot be handled in a Drupal 10 compatibility issue. This is not how we can fix issues and track them.
This is related to a huge task I have started (maintainer) some minutes ago. 📌 Refactor the concept of how dependency settings are assigned to fields and entity bundles Active
Please join this issue too and help us fixing this for the upcoming beta releases I have planned.
dqd → created an issue.
Thanks for the report but...
#14 Clean standard Drupal 10.2.4 + Conditional Fields 4.0.0-alpha5 installation.
... what does that has to do with this issue which is about issues of already existing dependencies in an Drupal core update between 9.5 to 10?
Also, in issues please always test also against latest 4.x dev to get it fixed for upcoming releases. Apart from that: I cannot reproduce what you tested. simplytest.me is not always a good way to test issues because it has limitations and own issues. It is good to tryout modules but not the best to test against bugs.
@RichardDavies: it's rather pointless to keep it. Sorry, not meant any offensive, but: Why do you use (waste) your resources for a destructive discussion on this? To not open a new ticket? I open and close many tickets a day... I tried to explain why. And I can't take too much time for further explanation. The code base of Drupal 9/10 we hook into is completely different, Conditional fields 4.x is completely different because of that, the PHP version support has drastically changed and simply not one single comment in here would help it nor is here any patch or code to keep. Any references we maybe build to other issues will be in the 8++ universe, build on top of Symfony. Drupal 7 is a complete other software, you know that, right?
I reviewed / responded / fixed / closed / commented / committed / cleaned up all together all over ~200 issues including 10 RTBC's over last weekend with about maybe less than 2 or 3 hours sleep and it became more issues the last two days on top to make the first Drupal 10 ready BETA release. And I have inflammations in the eyes, shoulder and hand and my laptop smokes... I have to close the Drupal 7 version of this project until January 2025 and just wanted to make sure that all leftovers not fixed before in D7 life circles will come over to the next generation.
Is that enough explanation for you? Would you please then be so kind and help me by doing what I have very kindly asked you for? Thanks for understanding.
Apart from that you brought my eyes back in this issue and there are questions raising:
Then as an other user having another role (who has edition rights on my test node of course), I edit the node. I can't have access to the boolean field with this role, but the boolean was set to false when I saved it as admin.
... indicates that this issuemaybe is not in the CF's scope. So, for anyone reading please:
File a new issue for the latest 4.x dev, show exactly how to reproduce that CF is not working with the field permission module and (in best case) give us an idea where to look at and what to change to get this fixed.
Thanks for understanding...
Awesome work in here! +1 Thanks for the reports and the patches rolling and rolling. Very much appreciated. You rock!
Can somebody involved please re-roll against latest 4.x dev asap? I plan beta1 release end of this week and final 4.0 release is around the corner. And EOL of Drupal 7 is in Jan. coming year. I would love to commit the awesome work made in here any next time soon.
#20 Please read the comment before yours and test with 4.0.0-alpha1 - You can update CF later after the migration.
Thanks for the report and efforts in here +1
Short code review: Code looks good, in patch there where trailing white space and new lines in which need to be removed but in patch #3 they are gone. +1
Please provide patches always against latest dev because upcoming releases are always based on the latest dev with the latest fixes. Thanks for your work on it! This patch needs a re-roll against 2.x-dev
Thanks for the report and efforts in here +1
+++ b/datatables.module
@@ -148,6 +148,10 @@ function template_preprocess_views_view_datatables(&$variables) {
+ break; ¶
Short code review: Code looks good but there is a trailing white space in line 154 which need to be removed. And please provide patches always against latest dev because upcoming releases are always based on the latest dev with the latest fixes. Thanks for your work on it!
Added 📌 Support field turning hidden by condition to loose its required status Needs work to the Beta2 release task group.
Thanks for all the efforts in here but there are very different reports in here. We need to clean up the issue and need a status of what is wrong and what is right and a better issue summary. What is left? What is mistakenly considered to be a issue and what is simply wrong setup. Anyone involved willing to clarify? Thanks!
Last patch looks good. +1 Better than before because it does not remove/replace anything existing in code and sits on the right spot now. Thanks for all the efforts and work in here. +1
We need user tests on latest dev and foremost we need test coverage for this newly implemented feature. Gitlab testing CI is no the way but not ready yet. And I would love to see confirmation of multiple users testing in the wild that it does not break other features of this project.
Thanks for the report @RichardDavies. Very much appreciated.
Since Drupal 10 and Conditional fields 4.0 are very different new branches with different code, I recommend to please open a new issue with a report, a summary and steps to reproduce. And make sure that no other module with issues is in the way. And please file issues always against latest dev branch, because this is the branch where upcoming releases are based on. Thanks for your efforts and please keep posting. +1
Thanks for the report and the efforts in here +1
Removed tag. Before adding tags read the issue tag guidelines → . Do NOT use tags for adding random keywords or duplicating any other fields. Separate terms with a comma, not a space.
At the moment maintainers cannot reproduce this issue, tested with default Drupal 10.2 core and Claro setup (watch screen-cast). Please provide more reports and a screen-cast showing setup, themes and modules installed, so that we can make sure that this is really caused by CF.
Note: It makes a difference if the image field was set as required by default or not before, or if the checkbox has been checked already before or not for testing. To be able to turn off the required mode is already an issue because this is not working at the moment for good reasons. Therefor please follow: 🐛 URL validation of link field doesn't work Fixed or 📌 Support field turning hidden by condition to loose its required status Needs work .
This "dirty fix" in here committed caused many trouble including 📌 Support field turning hidden by condition to loose its required status Needs work So I reopen this issue to discuss a better solution.
Very much appreciated and motivating, thank you @star-szr. And: you're welcome.
Regarding ?? vs !=NULL see following code test example: https://3v4l.org/McavC
Thank you! Please keep posting. I viewed the image before already but I haven't seen an error there popping up. What do you mean by you have debugged. In your IDE? So this error is not thrown in Drupal but only in your debug environment?
EntityDisplayRepositoryInterface has been introduced with Drupal 10.1 so it is not that new, so I am not sure what has caused this in your case and I sadly cannot reproduce it at the moment in a Drupal install. I will take a look at it in your IDE and will try to reproduce your debug experience.
I actually wanted to make a beta release start of this week. But now I hesitate.
I changed the issue in this regard a little bit if you don't mind. Feel free to change back if you think this is not what you want. Apart from that META issues are no Support requests. Plan or Task would suite best. Feel free to edit to your liking. Just wanted to chime in and help while humbling over this issue accidentally.
If site is monolingual - both modules are possible.
If site is multilingual and configuration has to be different in different languages - config_pages.
If site is multilingual and configuration is the same in different languages and need just translate it - site_settings.
I think this sh/c/ould be part of the project page, @scott_euser.
And it should be outlined here one more time how supportive and community-embracing your awesome attitude is in here as project maintainer. Very much appreciated! And a good example how it should be handled which I would love to see in other issue queues. Heads up! +1
There another player in the woods we need to put in the list -> https://www.drupal.org/project/eck_site_settings →
This module enables the use of Entity Construction Kit (ECK) entities as global, site-wide setting entities. It's an alternative for modules like Site Settings and Labels or Config Pages.
Thanks for coming back on this and your efforts in here! +1 Very much appreciated. I was asking because of we both are no native tongues :) and you have mentioned "dev" in the issue summary shortly without further details. So, do I understand correctly, that you refer here rather to core dev? Could you please try to rephrase the issue summary a lit bit so that it is better understandable what it is about? That would help a lot because it still reads somewhat confusing... Thank you.
And can you please review the patch provided regarding your reports intention?
Great finding and thanks for the report! +1