LGTM
Actually scrap that, I think it's better if we avoid the needless conversion back and forth in the first place.
i.e.
jquery_update.module
- 'migrateMute' => variable_get('jquery_update_jquery_migrate_warnings', FALSE) ? 'false' : 'true',
- 'migrateTrace' => variable_get('jquery_update_jquery_migrate_trace', FALSE) ? 'true' : 'false',
+ 'migrateMute' => variable_get('jquery_update_jquery_migrate_warnings', FALSE) ? FALSE : TRUE,
+ 'migrateTrace' => variable_get('jquery_update_jquery_migrate_trace', FALSE) ? TRUE : FALSE,
Doesn't seem like I have permission to code review, but I'll comment here instead.
Looks like it needs some sort of string to bool conversion.
e.g.
js/jquery_migrate.js
- jQuery.migrateMute = Drupal.settings.jqueryUpdate.migrateMute;
- jQuery.migrateTrace = Drupal.settings.jqueryUpdate.migrateTrace;
+ jQuery.migrateMute = (String(Drupal.settings.jqueryUpdate.migrateMute).toLowerCase() === 'true');
+ jQuery.migrateTrace = (String(Drupal.settings.jqueryUpdate.migrateTrace).toLowerCase() === 'true');
Other than that, works as expected in my manual testing.
That would be an even nicer solution, for sure.
Are you using Ajax, if so checkout 🐛 Ajax forms fail with: missing-input-response Active .
MustangGB → created an issue.
Fantastic replies.
I did consider #18, but didn't have enough information to know if this was thorough enough.
I think #19 is what I was originally asking for, so I will do #19, #18, and 🤞.
But #17 would be the ideal, for both the less technically competent, or (like me) time limited.
Seeing as 🐛 Reduce the number of field blocks created for entities (possibly to zero) Fixed has been closed, I'll ask here.
How are you meant to know if you can turn this module(/feature flag) off?
Is there a way to list all instances of field blocks being used where their layout builder option hasn't been enabled?
Hurray, great addition.
Just hard to view the diff when it's 20k lines long.
Save the kittens!
If anyone is still interested I've grabbed a snippet of code from a custom module, at least might give you a starting point if you wished to implement something like this.
/**
* Implements hook_menu_site_status_alter().
*/
function MODULE_menu_site_status_alter(&$menu_site_status, $path) {
// Before a switch user take note of the original user.
if (substr($path, 0, 12) === 'devel/switch') {
global $user;
global $original_user;
$original_user = $user;
}
}
/**
* Implements hook_user_login().
*/
function MODULE_user_login(&$edit, $account) {
// After a switch user bypass TFA.
global $original_user;
if (!empty($original_user)) {
$_SESSION['tfa'][$account->uid]['login'] = TRUE;
}
}
Urrm no, the point of administrators having access to user switching is to bypass access checks, otherwise they could just login normally.
Just to mention there is another slight "problem" with mathieuviossat/arraytotexttable.
That being it effectively prevents PHP 8.2 usage.
Reason being that drupal/core-recommended wants psr/container v2.
Whereas mathieuviossat/arraytotexttable wants psr/container v1.
It "kind of works" because laminas/laminas-servicemanager v3.15.0 (which is a dependency of laminas/laminas-text which is a dependency of mathieuviossat/arraytotexttable) allowed for psr/container v1/v2, however this was quickly realised as BC breaking and rolled back.
However as a side effect laminas/laminas-servicemanager v3.15.0 also has PHP 8.1 as a restriction.
The end result being the only option for using drupal/core-recommended and mathieuviossat/arraytotexttable is to use the "broken" laminas/laminas-servicemanager v3.15.0, therefore no PHP 8.2 option.
That being said there is a laminas/laminas-servicemanager v4.0.0-rc2 that does support psr/container v2 and PHP 8.2, so this could be resolved soon-ish.
Thanks.
@pjflopes
This is not really the best place to ask.
But you can either disable it globally with $conf['javascript_use_double_submit_protection'] = FALSE;
Or presumably on a per form basis with a hook_form_alter() and removing form_process_button from the relevant submit button #process arrays.
It looks like you went with the second option: Or add color-X support back for tables.
Can I ask what the problem with the first option was, because if there is a choice of approaches this seems to be preferable as it can just use the built-in Bootstrap CSS rather than requiring additional special case CSS: Either add way to change color-X to table-X for tables.
Has anyone followed the reproduce steps yet?
i.e. Does the table at /admin/reports/updates have the correct colors?
Any maintainers able to chime in on ✨ Add hook_field_schema_alter() RTBC ?
This is still working great, including the change to support *.install added in #127.
#129 is the patch to review.
Of course, identical.
Correct me if I'm wrong, as I've not tested the patch.
But it doesn't look like the user is given any indication that this is happening.
I expected to see something along these lines:
$('.form-actions input', $form).attr('disabled', true);
Can remove:
protected function validate($code) {
<snip>
}
Because it was added to tfa 7.x-2.x as timingSafeEquals() in
#3183248: Use hash_equals instead of === →
.
MustangGB → created an issue.
Rebase and updated to v6.1.0 (to match HEAD).
And a patch for use with cweagans/composer-patches.
MustangGB → made their first commit to this issue’s fork.
And the patch.
Add Drupal\Core\Link as per
#11
🐛
Error when using markdown module with PHP 8.1 on Drupal 9.3
Needs review
.
MustangGB → made their first commit to this issue’s fork.
If you're taking requests, in no particular order:
- #1217394: Change notice: "Display even if view has no result" not working →
- #1362524: add GROUP_CONCAT aggregate function; and move aggregate function helpers to a query extender? →
- #2700535: Inconsistent field_views_field_label() sort order →
- #2823738: Filter groups incorrectly ordered →
- #3108068: $form['#autocomplete_input'] views_handler_filter_user_name.inc →
- #2438213: Enable "allow empty" filter by default for Numeric →
- #2867734: REGRESSION: Single ajax checkbox filters are broken →
Re-upload of existing patch to check tests.
@joseph.olstad Thanks for your hard work.
I leave the decision to the module maintainers, I just make my requests.
Seems to be okay now.
Re-opening this to ask if the commit intentionally changed arrays to use the short syntax.
Drupal 7 supports PHP 5.2.5 and short array syntax wasn't added until PHP 5.4, so as a general rule no-one else is doing this in D7.
Re-roll with very minor whitespace fix.
MustangGB → created an issue.
I originally considered jquery_update.autocomplete.fix, meaning all fixes related to autocomplete.
But as the thing that changed was the functionality of position() thought it made more sense to go with jquery_update.position.fix, meaning all fixes related to position, it just so happens that the only place we've found to fix so far is in autocomplete, but in theory fixes for other elements could also go in this file.
I'd not considered jquery_update.autocomplete_position.fix, because as previously mentioned I wanted to keep the door open to other fixes relating to position() to have a place to go.
If you're still sure you'd like to change it I will update the patch, please let me know.
Simple? Not sure about that.
Are you sure you tested with the autocomplete in a table?
Nevertheless, added some more in-depth repro steps to the description.
Thanks.
It's already on the priority list #3207851: [meta] Priorities for 2021-06-02 release of Drupal 7 → , we don't need to update the labels anymore.
@Ronino
For D7 please comment in
🐛
[D7] node_access filters out accessible nodes when node is left joined
Postponed
and perhaps the maintainers will see it, also there is a more recent re-roll.
Hey thetwentyseven, please see 🐛 [D7] node_access filters out accessible nodes when node is left joined Postponed for the D7 backport.
Opened 🐛 [D7] node_access filters out accessible nodes when node is left joined Postponed to track the D7 backport.
Patch looks good to go and #13 has been addressed.