I made sure the module works with neither core logger backend installed. With a fresh D10 installation, I installed restfullogger only. In the console I ran:
// Get the CSRF token.
$.ajax({
url: '/session/token',
success: (data) => {console.log(data);},
});
// Use the logger.
$.ajax({
type: 'POST',
url: '/dblog/logger?_format=json',
headers: {
'Content-Type': 'application/json',
'X-CSRF-Token': '<insert token>',
},
data: JSON.stringify({
'message': 'Test message',
'path': '/',
'severity': 'notice',
}),
success: () => {console.log('yay!');},
dataType:'application/json',
});
This worked as expected. The log message succeeds and fires the content off into space. I then installed and configured syslog and the same two steps resulted in the logs being sent to the designated log file.
lkacenja → created an issue.
Forgot to close. Sorry for the chatter.
This looks good to me. Thanks @rymcveigh.
Since Drupal 8 was EOL November 17, 2021, it feels ok to drop support there. I am not honestly sure if the module would still work with that codebase or not.
We deployed a patch with the contents of this MR to our development environment and ran it through automated tests. Everything seems good to us. Moving this to needs review.
I opened an MR that I believe fixes the problem. Here is what it looks like on that branch.
lkacenja → created an issue.
Removing the `#error_no_message` from the number input and then removing the no longer necessary Price::moveInlineErrors method seems to fix the issue for me. See https://git.drupalcode.org/issue/commerce-3400651/-/tree/3400651-inline-...
lkacenja → created an issue.
I'm not an expert on Drupal's Gitlab CI boilerplate and setup, but I see that all the linting jobs and unit tests are running green on this merge request. Previously, it seems like there were no pipelines. This seems great to me. Thanks!
lkacenja → made their first commit to this issue’s fork.
This seems great to me. I don't see any issues. I also see the relevant steps showing up in pipelines now. Thanks for adding the good confidence builders!
I can confirm that this MR makes the README file adhere to Drupal's guidelines. I also don't see any mention of the permissions copy. So that seems good as well. This looks good to me. Thanks!
The README and project page both seem to follow their respective recommendations. Also, the tests are looking good. This seems great to me.
I tested this on a staging environment with the patch applied. I tried required and non-required fieldsets. All the classes seem to appear correctly. Thanks!
I looked this over and presume that the reason for creating a "doMail" method was to facilitate easy wrapping of the rather lengthy business logic that was formerly in the "mail" method. We do want to make sure we catch all the SendgridExceptions raised in that code. Creating a new method prevents the "mail" method from taking up extra horizontal space, but I do see the virtue in not adding new methods willy-nilly. I think either creating a new function (as authored) or wrapping all the contents of the original mail method and not creating a new function are both fine.
In my opinion, if a "doMail" method is added it should be protected. Otherwise, the intention of the original interface is violated.
I tested this on the 2.0 release and then with this branch's updates on a clean install. I used Drupal 9.5.2 and webform 6.1. Autosaving is now happening with file input changes and file fields are not inhibiting changes in other fields from triggering autosave. Thanks for all the good work on this!