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.
CR: https://www.drupal.org/node/2183531
Quite a few of these have already been converted.
Also time to kill webform_variable_get().
Comment | File | Size | Author |
---|---|---|---|
#10 | replace_all-2500799-10.patch | 4.13 KB | Anonymous (not verified) |
#7 | replace_all-2500799-7.patch | 3.93 KB | Anonymous (not verified) |
#4 | replace_all-2500799-4.patch | 3.93 KB | Anonymous (not verified) |
Comments
Comment #1
fenstratCommitted and pushed a first pass to 8.x-4.x
This takes care of all the straight forward ones, there are a handful of trickier ones left, leaving open to finish up those.
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous at FFW commentedI'll try to do patch for this.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous at FFW commentedHere is patch. Please review.
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous at FFW commentedComment #6
sumitmadan CreditAttribution: sumitmadan commentedreturn drupal_tempnam(\Drupal::config('webform.settings')->get('webform_export_path'), 'webform_');
should be
return drupal_tempnam(\Drupal::config('webform.settings')->get('export_path'), 'webform_');
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous at FFW commentedI have fixed it. Thank you. Please review again)
Comment #8
fenstratThanks for the patches @bobrov1989!
These also need to be added to webform.schema.yml
The old webform_table variable is going to be removed as we'll be removing support for the old hard coded table listings and only offering their new views equivalents (which is already the default in 7.x-4.x). However I guess that's out of scope for this issue so a simple replacement for now is ok.
Is
temporary://
still the correct default here in D8? I imagine it is but would like to be sure.This is incorrect as before it was looking for the "global"
'date_format_' . $type_name
variable yet here you're looking in webform.settings. Additionally I'm guessing the date module's changed the way it stores date formats (i.e. is it actually stored in'date_format_' . $type_name
?) so it will probably need to be adjusted for that.Comment #9
Anonymous (not verified) CreditAttribution: Anonymous at FFW commentedOk, I'll fix it.
Comment #10
Anonymous (not verified) CreditAttribution: Anonymous at FFW commentedThank you.
1. I've added it.
2. Still the same for this task, you can create a new one and we'll remove this.
3. According to core\includes\file.inc this path is still correct in d8 for now.
4. I look closely and I've noticed that d8 stores date formats in core.date_format.FORMAT_NAME config objects.
Please review.
Comment #11
fenstratCommitted and pushed to 8.x-4.x.
Thanks for your answers in #10 @bobrov1989.
table is a boolean and should default to false (again it will be removed in the near future once views support is ported). This also made me open #2504493: Standardise config types and defaults.
I can also confirm that \Drupal::config('core.date_format.non_existent_format')->get('pattern') returns NULL, so all good there too.
I'm a little hesitant to leave the default 'D, m/d/Y' hard coded there, however as it differs from the default 'medium' format I think it's ok to do so.
Also no need to call config->get twice, instead I just assigned it to a local variable, fixed on commit.
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous at FFW commentedGreat))) thx