Any progress on the fix for #122?
I also would love to drop dependency on this patch as @jsweetack has said. I inherited a site that has this patch and I have no idea why it needs it in the first place.
Since we are 6 months since #120 and 10.3 is in RC, am I correct to assume that the only real way forward is to migrate to a new Drupal install without this dependency?
PK2
I am able to confirm that patch in #11 has worked for me as well, thank you @codebymikey!
pumpkinkid2 → created an issue.
@saschaeggi
Thank you for the help, but I do not think that resolved the issue I am seeing. I am going to try using the dev versions of Gin and gin_toolbar and see if there is something else in my theme that is causing the issue.
I'll open up a new issue if I find anything.
I am finding that this issue is occurring on rc3. Any chance that something broke the fix?
Screenshot:
It would not be so bad, if I was able to change the text that is there. I don't mind doing this in the theme, but honestly I am not well versed enough in doing this to know how to do it without documentation.
pumpkinkid2 → created an issue.
Heh... don't mind me, I seem to have had some weird caching glitch somewhere... all of a sudden I was able to see the events again... All is good on the dev branch.
Ok, so far I've tried the dev branch and the problem persists. I rolled back to 2.1.1 ensured the events were showing as expected, then updated to 2.1.2 and the events are gone while I'm logged in, and back when I'm logged out. If anyone has any ideas on what I can try, please let me know, but I'm going through the code diff and seeing if I can spot the issue.
Also, I'm guessing this should be a new issue at this point since the patch seems to be unrelated.
I'm actually trying to troubleshoot an issue which I do not think is related to this patch. But since I was using 2.1.1 and updated with the patch to 2.1.3, I am not sure where the problem is coming from...
When I am logged in, I do not see the events, but when I log out, everything is fine...
I'll start by trying the dev branch and see if it resolves the issue.
Just here to report that I have used the patch on #14 and it seems to correct the same issue for me.
Hi matthieuscarset,
In my case, I happen to have two date fields, on two different node types, and they are not always guaranteed to have data.
I'm in the middle of rolling out a new feature for a site I am working on which depends on this module. Before we roll it out to production though, we will only use one of the two fields. After we migrate the current data over to the new field, I'll report back and let you know if this resolved the issue.
Thanks!
-PK2
I have not been able to chime in here as I have been busy with a migration to D10, but I have been checking occasionally and I appreciate the progress being made here.
I will test the patch as soon as I am able to.
I just want to chime in here as I am also seeing the same behavior. If I change the start time to be slightly different, it shows the events.
I found an issue for views that explains exactly what I am seeing...
https://www.drupal.org/project/drupal/issues/3034595#comment-15178526 🐛 Views contextual filters with multiple values do not work with arguments containing spaces Needs work
Thanks for your help, but it looks like the problem is not related to this module.
I've spent the last few hours troubleshooting an issue that came down to exactly what AaronBauman mentions in #26. In my case, the field has an equals sign (=). I may be able to come up with a workaround for my case, but a fix for this would be greatly appreciated.
Hmm, I'm starting to think this may have actually been an issue with views.
When I use the two values with the equal sign, the query parses like this:
('blahblahblah=+blahblahblah2=')
But when I remove the = I get:
('blahblahblah', 'blahblahblah2')
Would you agree with my assessment?
Hi drclaw,
Thank you for the quick response! I was actually looking at line 215 where the implode actually happens, however there may be a bit more to this as the change you suggested does not seem to resolve this.
My use case is a bit odd, due to a custom module we are using to populate data automatically.
We have two node types. One that has an entity reference field that contains a few entities and a multiple select value field that has reference IDs from a 3rd party system. This is the ID that has the = at the end of the value. The second node type just has a simple text field with the reference ID.
I am using a relationship and listing information from the referenced entities, and attempting to use your module to filter out those whose reference ID does not match the values on the multiple select.
I'm sure that was as clear as mud, so for now I am going to keep trying on my end and see if I just have the view misconfigured somewhere.
I appreciate the help!
pumpkinkid2 → created an issue.
@tannguyenhn - Thank you for your reply, I will look into this and see if this will help alleviate other issues we are having.
I was able to figure out how to start the process with an unmodified version of the module by calling the link in a specific way. It seems that I was just not understanding how the module was designed to accommodate for this use case.
I ended up having to add the domain to Allowed domains in the configuration, as I had suspected, however, the link had to be called as so:
/openid-connect//initiate?iss=https://www.domain.com
pumpkinkid2 → created an issue.
I'll throw my hat in the "#4 helped me also" ring.
I believe that this feature introduced a bug when cloning custom blocks.
I've updated to 2.0.0-beta3 and when we try to clone a block, the option for "Save cloned Custom block as published" appears.
If left unchecked, the block clones, and seems to work as intended, however, it is not visible to anonymous users. If checked, I receive a server error.
As far as I am aware, there is no "publish" state for custom blocks, so should the option even be available for that entity type? The feature is great for nodes though.
Thanks to both of you for the fix!
Sounds great! Thanks!
PK2
Hey mglaman,
Commenting out the debug line definitely stops the output. Not sure what it entails to properly fix if that shouldn't be happening with that line uncommitted, but I'm happy to help troubleshoot further if I can help.
PK2
pumpkinkid2 → created an issue.
@steinmb - It's been a while since I looked at this, in fact, I had not realized you had replied to me until just now when I thought to check if there had been any updates to my issue.
Is there anything I can provide to make it easier to find the cause of the issue?
I can provide a patch that applies my fix, which has been working for us since December, but I haven't had a chance to see what is actually at fault. All my patch would do is comment out the logic that was preventing it from working for us.