Nice, just add the https://posthog.com/docs/configure/initialization-configuration link to section in the README also for details. Then this is fine for me!
Hi @jurgenhaas and thank you for the rapid response!
I also thought about this and indeed there are tricky ways to to this stateless, but they also become risky. I'm not sure yet, what's more kind of "the ECA way" for per-user-states or using user.data store service for a solid stateful implementation.
If only sending one reminder, this is tricky enough stateless, but stateless logic becomes even trickier (and harder to understand and maintain for the site owner) if there's a defined process of emails being sent out, until the final reminder is reached or the user verifies his account / logs in.
This escalation process would at least be easier to understand and maybe is more robust using a stateful approach. The user might get flagged with a something like an "escalation step" + date user.data variable, so we wouldn't have to mess around with special cases like older accounts and non-running cron.
But I have to admit, I have no idea yet, what this means for ECA and if a by-user-process would be a good idea, that might start with the registration, maybe.
If you had this requirement, how would you solve it in ECA?
(Sorry to ask this dumb question without providing much input on the solution myself yet, but I'm using ECA for the first time and am totally unaware of all the details and best practices)
Give it a try in a MR and we can have a look.
anybody → created an issue.
Thank you so much!!
@oksana-c could you please tag a new D11 compatible release with priority?
@heine could you prepare a MR for that?
Merged, to get this done.
Happy to merge this, once it has tests and is reviewed by experienced members of the community. Won't have the time to review this myself in the near future.
@megakeegman totally agree ,could you create a MR please?
Done!
Nice, thank you @jfeltkamp! :) Looking forward to that! Should you need assistance, feel free to ping us.
Needs work on the texts.
@adamps could you maybe tell if my assumption is correct or add an example?
We could just override the #maxlength from core here: https://git.drupalcode.org/project/layout_options/-/blob/8.x-1.x/src/Opt...
If we don't want to wait for the core fix.
There's no limit implemented. Once again it's just inherited from Drupal Core's (not helpful) limit: ✨ Increase or remove default textfield #maxlength=128 Active
I think we should directly go up to 512 chars, times of expensive space are over...
Yes!
Okay, yes I think "profile updated" is very very minor, as the consequences are unclear. But many of the other events have business meaning.
LGTM! I didn't try it myself yet, just reviewed the code. Due to the API changes in the hooks this will need at least a minor, if not even major release for compatibility with eventual custom modules?
I very much like the new array implementation!
Fixes for the deprecations also look fine.
Please decide to wait for further feedback from people who already tested the running code, set back to Needs review then.
Great work!!
Thank you very very much @steffenr! :) Going to review this ASAP!
Thank you @danchadwick that's great :)
Mhm I don't think there's anything we should or could do here?
PS: Of course many events will also be available in the ECA integration as alternative, but this is more lightweight.
No it doesn't because we need a clear conversion for a successful (and confirmed) registration. This is one of the most important conversions.
We care, because these are important events or conversions for analytics. If you want a report on how many users were blocked in month X or how many accounts were deleted, you need this information.
What do you mean by
updated their credentials
? I can't see that requiremen above.
But the events you listed are all of minor importance, while the issue summary lists the most important events.
Let's keep it at "posthog_php_events" for now. We could also rename it to "posthog_events", to also have access to the js.
Definitely yes, tracking JS events is not a Drupal think and it's easy to be done. We're providing a DRUPAL specific submodule here, which adds events for typical DRUPAL events, that's the point. We're not creating an events SDK. Maybe that was unclear.
A super important one is confirming the email address (= registration) ( ✨ Add server-side tracking for registration confirmation Active ) which means showing the page after clicking the password confirmation link. That's the only place where you can be sure that this conversion (registration) was really finished.
All the other events beside these 4 above are quick-wins which already have Drupal hooks and should be easily implemented in 3 lines, that's why I think it makes sense. We can copy them from the billwerk module.
POSTPONED until it becomes available for the PHP SDK!
Clarification: One it becomes available on the Posthog side: https://posthog.com/docs/libraries/php
Yes we need to think about how to solve this and see if anyone already solved this for posthog in PHP or other languages!
Re #4: Maybe we should simply document this below the snippet and link to the posthog documentation? And maybe inform users about available integrations in Klaro and COOKiES? (That don't yet exist, right?)
@nofue still an issue with 2.x? Didn't see any other reports here.
@grevil could you finally check this for 2.x?
@jfeltkamp is this already fixed? Could you give us an update on the status or plan? Should this be a blocker for stable 2.0.0?
https://www.drupal.org/project/cookies/issues/3496407 📌 Review markup / CSS before 2.0.0 Active is fixed now, could you fix the tests @grevil?
This is an alternative approach if working with contextual filters on field values: https://www.drupal.org/project/drupal/issues/3209940 ✨ Allow contextual filters to optionally include results with NULL values for the specified field (as well as matches) Needs work
Great work all! I just created a MR from #19 and can confirm this works great and solves the issue for me.
Beside implementing tests, I'd really vote to improve the checkbox label a bit for users, because NULL is a bit too technical, I think. We should do that before the usability review, I think.
What do you think about:
- Skip this filter for empty (NULL) values
- Include results with empty (NULL) results for this contextual filter
What's more clear? Any other suggestions?
The field description could go more into (technical) ddetail, maybe?
Just ran into the same requirement and I agree it would be really useful! If the given field value is empty, it's often a requirement to ignore the contextual filter for the field. Maybe the label of the checkbox could be changed into that direction?
Super nice @grevil thank you! Works fine and as expected now. Please open a follow-up to reduce the confusion you described.
Next step (UX-wise) should be ✨ Inherit parent metatags as placeholder in override forms Active
I'm not currently using this anywhere, but if we get a community-tested solution RTBC'd by enough people, I'm willing to merge a fix!
@Grevil: Like just tested together I can not confirm this. Having an empty value leads to inheritance (as expected)!
Thanks, I'll check that!
Thanks! Postponed on ✨ Add: "View any unpublished [entity_type]" permission Needs work
We just ran into the same issue, this permission is definitely still missing. Anyway I agree with #17 - thanks for the patch @mkalkbrenner!!
So I'll set this RTBC for the maintainer to decide if this should be postponed or integrated already.
Perfect, thanks for the check @grevil!
@danchadwick This also works for other cases in Drupal, not just for Webform! @thomas.frobieter's example is a webform example, but adding the use-ajax class for links in Drupal also works to open the link in a modal!
See https://www.drupal.org/docs/develop/drupal-apis/ajax-api/ajax-dialog-box... →
It's just not well known, I think. And the required libraries have to be loaded on the page!
Sorry, I ddn't realize that order_report has a relation on the original order!
So this is fine, as you simply need to add a (required) relation in views from the order report to the order. That relationship can then be used to filter the view by status and everything is fine and works well!
Thank you!
Ok here's a new one and some tests are failing, so let's proceed again...
Failing tests look unrelated, let's open a separate issue for that.
Thank you very much @grevil! Nice finding and fix!
I'm a bit more in favour of MR!28 I have to say, looks cleaner to me. But let's see what @jacksacksick says!
Looks like a regression?
I can confirm we were not able to reproduce this, despite having ~20-30 entries in the logs showing this error. Interesting... Let's see if the log entry can tell us more in the future.
Still I think the trick from #2 is hard to find, so would be better to improve this in the module or document the workaround?
@maintainers: Could you maybe explain a bit how the module handles numeric values and if (or why not) raw values are used?
Currently this seems unusable for non-default number formattings used in the view output, as described in the example.
We'd like to help, but it would be great to have a better starting point on how and where this should be fixed and which impediments you see. Thank you!
Thank you so much for your hint @jrochate! That saved my. I created 🐛 Doesn't play nice with number formatting - should use raw values Active for further improvements, when using international number formattings (not EN)
FYI: I won't have the time to implement something here in the next month, but I'm happy to review a final MR that has been approved by the community.
Drupal 9 is EOL, I think we could require Drupal 10 as minimum, maybe even 10.3!
Thanks @divyansh.gupta! Great work. I think now a maintainer should decide, if all important information is given and if it's all fine!
Let's set this RTBC! :)
@thomas.frobieter can you adjust the test here in a MR? Maybe otherwise @Grevil can help? Nice chance to take a look at the tests and how simple they work.
Nice @niklp!
https://git.drupalcode.org/project/iconify_field/-/commit/0ccf3125574b0c... looks like a change worth trying! Could you prepare the MR accordingly?
@grevil this is the wrong area (the zip code input you're looking for is below the cart on /cart!)
And I can't see you selected a country in the screenshot.
Moving this to Drupal.org project ownership (2209259) as of #34 for clarification. Thanks all! :)
Confirming RTBC! 🚀
Ok, drop it!
@eleonel could you please tag a new stable release for this critical issue? Thanks!
Patch #14 does not apply anymore with latest quick_node_clone. So should we maybe close this and switch over to ✨ Support cloning of paragraphs by integrating with popular contributed clone/replicate modules Active ?
Patch from 🐛 Cloning Entities with Layout Paragraphs breaks structure and moves subparagraphs into Disabled Items RTBC does not apply anymore. So should this be a good moment maybe to finish this one? :)
@larowlan: #13 sound like this might be added to all submit buttons in Drupal 11 - which are affected by this bug by design.
What do you and the others think?
Hi and thank you very much for your helpful feedback @mdusza - may I ask, if you know and ckeditor5 project that might fit better or already provides this functionality?
Older Drupal versions had this functionality and it was really helpful for us.
I added the point from #36 / #37 to 🐛 Update YoastSEO JS to recent version Needs work FYI
As written in 🐛 The page freezes while the Real-Time SEO module runs script Needs work this should also include removing jQuery dependencies (using vanilla JS instead) and ensuring there's nothing blocking in JS like it was in the past.
@kul.pratap I thought the same, but there is: https://git.drupalcode.org/issue/office_hours-3497658/-/blob/3497658-fie...