Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
In this ticket we should introduce the minimal version of webform_submission_log
.
It would basically encompass adding the module itself, moving the table {webform_submission_log}
under its jurisdiction, migrating the WebformSubmissionStorage::log()
method to using actual Drupal logger and then implementing a logger service within webform_submission_log
module that would listen for 'webform_submission_log' channel only.
Comment | File | Size | Author |
---|---|---|---|
#36 | 3015180-37.patch | 76.06 KB | jrockowitz |
| |||
#36 | interdiff-3015180-33-37.txt | 14.83 KB | jrockowitz |
#33 | interdiff-29-33.txt | 4.21 KB | bucefal91 |
#33 | 3015180-log-submodule-33.patch | 64.98 KB | bucefal91 |
#29 | interdiff-26-29.txt | 1.25 KB | bucefal91 |
Comments
Comment #2
bucefal91 CreditAttribution: bucefal91 commentedHere's the minimal necessary amount of code to introduce
webform_submission_log
module with an update path.if this patch looks OK and get committed, as a next step I would refactor all logging related methods out from
WebformSubmissionStorage
class and would place it all within webform_submission_log module. Also, I'd refactor the tests so webform_submission_log submodule actually gets reasonable test coverage.Comment #3
bucefal91 CreditAttribution: bucefal91 commentedhere's the patch. phpunit tests passed on my localhost. Let's see what simpletests will say on d.org testbox infrastructure.
Comment #5
bucefal91 CreditAttribution: bucefal91 commentedLet's see if this one applies.
Comment #7
bucefal91 CreditAttribution: bucefal91 commentedLet's see if it passes this way.
Comment #9
bucefal91 CreditAttribution: bucefal91 commentedThis should get us a green light.
Comment #10
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedAll the submission_log settings in the UI need to have #access added to the element.
@see \Drupal\webform\Form\AdminConfig\WebformAdminConfigSubmissionsForm
@see \Drupal\webform\EntitySettings\WebformEntitySettingsSubmissionsForm
'#access' => $this->moduleHandler->moduleExists('webform_submission_log')
Maybe the webform_scheduled_email.module should require the webform_submission_log.module.
\Drupal\webform\Entity\Webform::hasSubmissionLog should check that the webform_submission_log.module exists.
The webform_update_8154() module should only enable the webform_submission_log module if the submission log is enabled globally or on any webform or webform_scheduled_email.module is installed.
Comment #11
bucefal91 CreditAttribution: bucefal91 commentedHey, Jake! :)
Things look more calm now in my life so here I am, trying to finish up this ticket.
I have implemented your feedback except for one point:
My idea was a little bit different. Let user enable/disable logging on the webform. Then it definitely gets logged into watchdog and in case
webform_submission_log
is enabled, it also gets logged into the dedicated table. Therefore in my vision::hasSubmissionLog()
wouldn't require thewebform_submission_log
submodule to be enabled.Does it make sense? I do not insist on my vision, I just want to confirm which way you prefer it?
And I am attaching a next iteration patch for your review.
Comment #13
bucefal91 CreditAttribution: bucefal91 commentedThis should get us full test pass.
Comment #14
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedThe patch is great. I am excited to get this committed so I decided to help complete a few more remaining tasks.
Changes
TDB
I completely agree with…
For websites that permanently retain all watchdog logs, they might not need or want the dedicated webform_submission log module or table.
If the 'webform_submission_log' is always enabled we need to consider the somewhat duplicate messages. We also need to be aware the 'webform_submission_log' messages include email addresses.
I am tempted to update the 'Enable submission log' checkboxes help text to state that more verbose and detailed message will be logged in 'Recent log messages'. We can also recommend that users enable the webform_submission_log.module.
Comment #16
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedNext steps
Todo
I can make these changes and write up a manual test script.
Comment #17
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedI think the next big change is to create a dedicate 'webform_submission' log channel and then change
\Drupal::logger('webform_submission_log')->info($message, $context);
to
\Drupal::logger('webform_submission')->info($message, $context);
Comment #18
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedUltimately we should be replace calls to and then deprecate
\Drupal\webform\WebformSubmissionStorage::log
Comment #20
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedFixing broken test.
Comment #21
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedChanges
Next steps
Explore deprecating \Drupal\webform\WebformSubmissionStorage::log and \Drupal\webform\Plugin\WebformHandlerBase::log
Comment #22
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedThis patch now calls the webform_submission log directly and use
notice
instead ofinfo
.Deprecated
\Drupal\webform\WebformSubmissionStorage::log
\Drupal\webform\Plugin\WebformHandlerBase::log
Comment #23
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedThe attached patch has some basic API cleanup and some additional code review.
Comment #25
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedFinal tweaks
Test script
Comment #26
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented…and I forgot to move all the log related help to the webform_submission_log.module.
Comment #28
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedComment #29
bucefal91 CreditAttribution: bucefal91 commentedHi, Jacob!
:)
That's a lot of diff right there in those patches :)
Mostly I am following you, but there are a few spots that I want to clarify:
In
WebformScheduledEmailManager
why do we sort of 'dynamically' pick up logging channel?My understanding was that from any point in code we can just do
\Drupal::logger('webform_submission')->info('Some message', ['webform_submission' => $webform_submission]);
and it would land into watchdog and (optionally) into{webform_submission_log}
table as long as logging is enabled on that webform.There is similar "game" with 'webform' and 'webform_submission' channels in
EmailWebformHandler
. I am not against it but neither I can say I actually understand why :) I seeWebformSubmissionStorage::doPostSave()
also may log into 2 different channels depending on the::hasSubmissionLog()
output.In
WebformSubmissionLogLogger
I believe it is better to write into DB untrasnlated string. I actually now understand I just silently did this change and did not bring it up earlier in this ticket and it was something worth discussing and stressing out. dblog writes it untranslated too. If we write untranslated string, we then can present the event in multiple languages (because translation happens at the time of displaying and not at the time of writing into DB). Also, in case translation is updated, the new translation becomes reflected on the submission log pages. In my original patch (comment #13) I was using 'data' column to store message placeholders and untranslated message in the 'message' column.And there are a few smaller things that I actually went ahead and coded:
WebformSubmissionLogController::webformStorage
had wrong @var comment.WebformSubmissionLogLogger
in its class comment carried outdated log channel of 'webform_submission_log' while with the recent patches of yours it has become 'webform_submission'.Comment #30
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedBy default, everything goes into the webform channel. Having a dedicated webform_submission channel allows people to isolate webform_submission transactions, which may contain user data, without the webform_submission_log .module. In some cases, the same message is logged in the webform and webform_submission channel. In the EmailWebformHandler, the user's email address is being logged in the 'webform_submission' channel and not the 'webform channel'.
I agree, but we should add a
variables
columns, similar to watchdog. Thedata
column is intended to store arbitrary data, possible the submission's serialized data or a remote posts response. This use case for the datacolumn
needs to be documented.Comment #31
bucefal91 CreditAttribution: bucefal91 commentedI see. With the explanation of why do we use 2 channels it makes sense.
I will add the
variables
column either today after working hours or tomorrow and will post a patch here. :)Comment #32
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedThanks. Reassigning this to @bucefal91
Comment #33
bucefal91 CreditAttribution: bucefal91 at Ocelot commentedHere's an iteration that adds 'variables' column and makes use of it to store translation variables so the message gets translated at the moment of displaying and not at the moment of DB write.
Update hook has this 'strange' woodoo ritual of creating a null-allowed column, writing an empty string to it, altering the column and making it not null. That's the most elegant way I can think of to add a not null blob/text column to a pre-existing table. I tested the update path to the best of my capacity and it works.
Cheers!
Comment #35
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedI will fix the tests now.
Comment #36
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedChange includes…
@bucefal91 Next week, I am planning on tagging the first stable release of the webform for D8 and I would like to get this merged in.
The last step is creating the change record. Do you have time available to do it?
It could be very simple like "Webform Submission Log moved to submodule." and list the deprecated methods with a code snippet or two.
Comment #37
bucefal91 CreditAttribution: bucefal91 at Ocelot commentedYowhoo! Stable release!
Yes, I will put up a change record now.
Comment #38
bucefal91 CreditAttribution: bucefal91 at Ocelot commentedThere we go https://www.drupal.org/node/3020595 I probably made it too developer-friendly. If you think that's too much of details, feel free to throw away all that dev gibberish :)
Comment #39
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented