Thanks @pcate. Using your instructions I have managed to recreate the error, and it is fixed by checking if $form['#webform_id'] is empty.
@tr do you require a test for these circumstances also?
I'm able to recreate the error from #29 with a CLOSED webform, but unable to replicate by changing the access setting for the Webform.
I will add a test, not sure exactly what to test for but this test checks that the filename has not been altered for the honeypot field.
Yes, we need to check $form['elements'] exists, I tried to create a new MR but made a mess of it, sorry.
@tim_dj
good call, I've made a change and also fixed some phpcs issues.
I think the _cspell_unrecognized_words.txt file mentioned is generated by tests, so it must have been committed by mistake.
Do we need to think about people who might update the module but forget to run the database updates? So check that $this->config->get('time_limit_message') isn't NULL before setErrorByName?
Getting some failures with the HoneypotFormCacheTest, not able to replicate the failure locally, not much of an idea currently what could be causing it.
joe huggans → made their first commit to this issue’s fork.
Declared property, please review when you get chance.
joe huggans → made their first commit to this issue’s fork.
This has been included now in 1.1.34 -> https://www.drupal.org/project/bootstrap5_admin/releases/1.1.34 →
Marking this as fixed
I have 1 critique, I don't believe you should remove {@inheritdoc} from inherited methods.
joe huggans → created an issue.
Looks good to me, surely this can be merged
I'm just trying to help out with testing.
But I can't replicate the issue, credit_card seems to be the default for the Stripe Payment Element plugin and it isn't causing an error on the update 8103.
Hopefully someone else can confirm, sorry
Ahh understood yes, thanks. That would be a nice feature to pass the commit ID for the diff though.
I had Stripe Payment Element enabled previously for the payment gateway plugin, it looks like I should have tested with Stripe Card Element?
However, I'm having issues creating such a payment gateway, seeing this error -
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /admin/commerce/config/payment-gateways/add?ajax_form=1
StatusText: error
ResponseText: The website encountered an unexpected error. Try again later.TypeError: array_map(): Argument #2 ($array) must be of type array, null given in array_map() (line 303 of modules/contrib/commerce/modules/payment/src/Plugin/Commerce/PaymentGateway/PaymentGatewayBase.php). Drupal\commerce_payment\Plugin\Commerce\PaymentGateway\PaymentGatewayBase->buildConfigurationForm() (Line: 16)
Drupal\commerce_payment\Plugin\Commerce\PaymentGateway\OnsitePaymentGatewayBase->buildConfigurationForm() (Line: 170)
Drupal\commerce_stripe\Plugin\Commerce\PaymentGateway\Stripe->buildConfigurationForm() (Line: 105)
Drupal\commerce\Plugin\Commerce\InlineForm\PluginConfiguration->buildInlineForm() (Line: 130)
Drupal\commerce_payment\Form\PaymentGatewayForm->form() (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm() (Line: 66)
Drupal\commerce_payment\Form\PaymentGatewayForm->buildForm()
call_user_func_array() (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 375)
Drupal\Core\Form\FormBuilder->rebuildForm() (Line: 633)
Drupal\Core\Form\FormBuilder->processForm() (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)
I've fixed the phpcs and stylelint warnings.
cspell:
There are a lot of spelling issues related to URLs for external libraries, I'm not sure how to tell the job to ignore these, I would have expected these to be ignore already by core .cspell.json. I've added some ignored words to the .gitlab-ci.yml. There are some French words, I'm not sure where these are coming from as I can't find them when I search the module.
The eslint would probably need it's own issue as there is a lot going on, or just leave it for now.
I'll fix the dependency injection issues for phpstan and then wait for feedback.
joe huggans → created an issue.
Theres just a phpcs issue on line 122 of ManagedAdBlock.php, it's whitespace on the empty line. I'm not able to fix this myself on the branch, maybe this is by design.
Tested and works well for me.
I can confirm this fixed the issue for me also
Thank you for the help! All seems to be passed now.
Created MR with patch from #4, and corrected some phpcs stuff.
The 2 tests that are failing are already failing in the same points before this patch is applied, not sure what the module maintainers want to do about this? Do we need a new issue to fix these? Or is there one already open that I missed?
Tested in Drupal 10 and no error occurs when resetting password.
joe huggans → made their first commit to this issue’s fork.
joe huggans → made their first commit to this issue’s fork.
@grimreaper I just noticed myself earlier that it's possible to get a diff file by clicking on "Plain diff" on the MR, handy feature if it works.
I've tested this on a new install with a database prefix and was not able to replicate the error with commerce_stripe_update_8103, not sure why.
However, I tested the patch and tried to db update again and it went through successfully.
I don't believe this is fixing anything, it just appears to be because the error message goes away or doesn't go away.
I've found you need to clear the cache twice to be sure, no further clearing of the cache creates the error if the folder name is correct
To create this error consistently I have found you need to
1. Create a view as a views slideshow
2. Go to the page with the slideshow
3. Clear cache twice to check if the error happens.
4. Clear the cache again to be sure
I have found that it does happen when the folder in question is called jquery.hoverIntent but not as it originally is as jquery.hover-intent
Some tests provided, let me know if I can improve these in any way or if I've done anything wrong and I will fix it.
I'm not sure how to get past the phpstan failure in the tests.
Created new branch (3134078-for-2.2 ) from 2.2, and opened MR (merge request !56) for 2.2. Will work on tests next.
The tests are failing for this because the $form['elements'] array does not always exist, it exists for webforms but not necessarily other forms.
I'm not sure if there is a consistent way to check if a form element exists, can we assume they are always in either $form or $form['elements']?
If not, would it be better to just add a random suffix to the end of the name of the field?
I may have opened an MR into the wrong branch (2.1), apologies and please advise if so. I can create some tests if you need?
joe huggans → made their first commit to this issue’s fork.
This is not an issue I don't think with the Webform module because it will prevent 2 fields having the same ID on the same page by adding a suffix i.e. id="url--2".
It looks like there is another issue open which would fix anyway - https://www.drupal.org/project/honeypot/issues/3134078 ✨ Conflicting name with other element(s) Needs review
I've made another edit to the annotation, let me know if I can make any improvements. Thanks
Provided a patch for easier testing and use until this gets accepted
Tested this myself, and it does get rid of the error, seems to be working fine now as far as I can tell.
Changing the key name of the problematic filter field key also worked for me, not sure why.
@tim_dj
Thanks for the reply, maybe we should add those properties in a separate code example because above the one in question it states "If you want a default country you need to do this:".
But as far as I am aware, the following are not required in order to set a default_country?
#countries
#exclude_countries
#geolocation
#preferred_countries
I actually opened this issue myself @tim_dj, I've provided an MR already
@nikarika.s - I don't think this works, because the JS in the module looks for these data attributes, so it would break the field to remove them.
The only thing needed here is to update the annotation.
My first suggestion wasn't working and was causing an error.
rather than using !empty($input['full_number']), use isset($input['full_number']), otherwise the field will fallback to the default value if the field is left empty.
Patch for anyone who needs this in the meantime.
I have looked at how other elements in Drupal core handle this such as the Number field, and based on this, I propose changing the valueCallback to:
public static function valueCallback(&$element, mixed $input, FormStateInterface $form_state): mixed {
if (!empty($input['full_number'])) {
return $input['full_number'];
} elseif (!empty($element['#default_value'])) {
return $element['#default_value'];
}
return NULL;
}
joe huggans → created an issue.
joe huggans → created an issue.
Tested this and it works well. Nice one!
Apologies I have made a bit of a dogs dinner of this issue description.
I just want to report however that the following is working for me, I can turn off the setting for BOTH 1st and 2st level paragraphs.
I don't know enough about this module to feel comfortable making a MR on this, and I don't think adding the library here is probably correct.
In summary, the getThirdPartySetting method was not correct, I changed it from
$widget->getThirdPartySetting('paragraphs_ee', 'paragraphs_ee', 'drag_drop')
to
$widget->getThirdPartySetting('paragraphs_ee', 'paragraphs_ee')
I then checked for the 'drag_drop' key value in the returned value, and I add the class 'drag-drop-buttons'.
I am adding the "paragraphs_ee/paragraphs_ee.drag_drop" library outside of the if statement because it doesn't seem to work on an AJAX call (when the nested paragraph is opened.)
public static function registerWidgetFeatures(array &$elements, ParagraphsWidget $widget): void {
$elements['#attached']['library'][] = 'paragraphs_ee/paragraphs_ee.drag_drop';
if ($settings = $widget->getThirdPartySetting('paragraphs_ee', 'paragraphs_ee')) {
if (isset($settings['drag_drop']) && $settings['drag_drop']) {
$elements['#attached']['drupalSettings']['paragraphs_ee']['widgetTitle'] = $widget->getSetting('title');
foreach (Element::children($elements) as $key) {
$elements[$key]['top']['#attributes']['class'][] = 'drag-drop-buttons';
}
}
}
}
joe huggans → created an issue. See original summary → .
That sounds good both, I can help out with the tests. I was going to work on this myself as my original message stated but then I noticed a lot of work already gone into the dev version of the module so didn't want to step on your toes.
If a new ticket can be created I will help out the best I can.
Apologies, I searched but failed to find this. Many thanks
joe huggans → created an issue.
For the time-being, if anyone wants to disable the contextual link to the clone form, then using this in a custom module works. (You have to log out and back in and possibly clear cache for it to take effect)
/**
* Implements hook_contextual_links_alter().
*/
function MODULE_contextual_links_alter(array &$links, $group, array $route_parameters) {
if ($group == 'paragraph') {
if (isset($links['paragraphs_edit.clone_form'])) {
unset($links['paragraphs_edit.clone_form']);
}
}
}
Patch provided for anyone needing this before the MR is approved.
joe huggans → created an issue.
Do we need the template_preprocess_views_view_table preprocessing for the views_bootstrap_grid hook?
Because it seems to work without these, but I haven't tested with Grids extensively.
Please test this patch - Drupal 10.3.6
After some further testing I believe this is working, I'm not sure what was causing the onNotify method to not run previous.
However, I think we need 2 Signing secret fields, for test and live mode.
Joe Huggans → created an issue.
Joe Huggans → created an issue.
Joe Huggans → created an issue.
My pleasure, thank you for the instructions, I am still learning.
Joe Huggans → created an issue.
I have opened a branch for this, and added a check for the uuid, please review.
This error occurs when the setting "Create a new revision of the existing node" is on at /admin/config/content/node_export.
If you select this option to replace then on the site that you are importing into this module reads the node id in the json and tries to load that node, but if you have had people working on this site, they may have used that node id on another piece of content, which in our case is probably a different content type, meaning the field is missing.
Created a patch also for use for the time being
Joe Huggans → created an issue.
I have been seeing something similar:
Problem 1
- Root composer.json requires drupal/domain_menu_access ^2.0 -> satisfiable by drupal/domain_menu_access[2.0.0].
- drupal/domain_menu_access 2.0.0 requires drupal/domain_access * -> found drupal/domain_access[dev-1.x, dev-2.0.x, 1.0.0-alpha1, ..., 1.x-dev (alias of dev-1.x), 2.0.0-beta1, 2.0.x-dev (alias of dev-2.0.x)] but it does not match your minimum-stability.
Drupal version: 10.2.6
Domain: 2.0.0-beta1
Command run to install: composer require 'drupal/domain_menu_access:^2.0'
I think this problem is because the Domain module is in beta??
Changing "minimum-stability" to "dev" in my composer.json file allowed domain_menu_access to be installed.
For what it's worth, my composer.json file
{
"name": "drupal/recommended-project",
"description": "Project template for Drupal projects with a relocated document root",
"type": "project",
"license": "GPL-2.0-or-later",
"homepage": "https://www.drupal.org/project/drupal",
"support": {
"docs": "https://www.drupal.org/docs/user_guide/en/index.html",
"chat": "https://www.drupal.org/node/314178"
},
"repositories": [
{
"type": "composer",
"url": "https://packages.drupal.org/8"
}
],
"require": {
"composer/installers": "^2.0",
"drupal/admin_toolbar": "^3.4",
"drupal/backup_migrate": "^5.0",
"drupal/bootstrap5": "^4.0",
"drupal/config_ignore": "^3.3",
"drupal/core-composer-scaffold": "^10.2",
"drupal/core-project-message": "^10.2",
"drupal/core-recommended": "^10.2",
"drupal/domain": "^2.0@beta",
"drupal/domain_menu_access": "^2.0",
"drupal/entity_update": "^3.0",
"drupal/mail_safety": "^2.0",
"drupal/metatag": "^2.0",
"drupal/object_log": "^1.1",
"drupal/paragraphs": "^1.17",
"drupal/paragraphs_ee": "^10.0",
"drupal/redirect": "^1.9",
"drupal/twig_tweak": "^3.3",
"drupal/ultimate_cron": "^2.0@alpha",
"drush/drush": "^12.5"
},
"conflict": {
"drupal/drupal": "*"
},
"minimum-stability": "dev",
"prefer-stable": true,
"config": {
"allow-plugins": {
"composer/installers": true,
"drupal/core-composer-scaffold": true,
"drupal/core-project-message": true,
"phpstan/extension-installer": true,
"dealerdirect/phpcodesniffer-composer-installer": true,
"php-http/discovery": true
},
"sort-packages": true
},
"extra": {
"drupal-scaffold": {
"locations": {
"web-root": "web/"
}
},
"installer-paths": {
"web/core": [
"type:drupal-core"
],
"web/libraries/{$name}": [
"type:drupal-library"
],
"web/modules/contrib/{$name}": [
"type:drupal-module"
],
"web/profiles/contrib/{$name}": [
"type:drupal-profile"
],
"web/themes/contrib/{$name}": [
"type:drupal-theme"
],
"drush/Commands/contrib/{$name}": [
"type:drupal-drush"
],
"web/modules/custom/{$name}": [
"type:drupal-custom-module"
],
"web/profiles/custom/{$name}": [
"type:drupal-custom-profile"
],
"web/themes/custom/{$name}": [
"type:drupal-custom-theme"
]
},
"drupal-core-project-message": {
"include-keys": [
"homepage",
"support"
],
"post-create-project-cmd-message": [
"<bg=blue;fg=white> </>",
"<bg=blue;fg=white> Congratulations, you’ve installed the Drupal codebase </>",
"<bg=blue;fg=white> from the drupal/recommended-project template! </>",
"<bg=blue;fg=white> </>",
"",
"<bg=yellow;fg=black>Next steps</>:",
" * Install the site: https://www.drupal.org/docs/installing-drupal",
" * Read the user guide: https://www.drupal.org/docs/user_guide/en/index.html",
" * Get support: https://www.drupal.org/support",
" * Get involved with the Drupal community:",
" https://www.drupal.org/getting-involved",
" * Remove the plugin that prints this message:",
" composer remove drupal/core-project-message"
]
}
}
}
Hello. Why is the patch so large?
I have tested this patch myself also and it is working.
I've been playing around with this and seems to work well, apart from if you have guest checkout enabled and "Create a new account for an anonymous order" also enabled, sometimes the new user is not created, and looking at the orders, the order remains stuck in cart.
I'll do some more testing and hopefully if I figure out what's causing it, report back.
Tested this and it works well for me. Thanks
Incidentally, should I be creating these branches on the dev branch? Apologies if so.
Joe Huggans → created an issue.
I've opened up an issue ticket here 📌 Ability to collect billing address Active for adding the functionality to collect a billing address
Joe Huggans → created an issue.
Joe Huggans → created an issue.
Can I ask why you wouldn't use the name from the billing profile if available for this rather than the username?
Works for me, thanks Aaron!
For anyone who has installed this module before applying the patch above.
I managed to fix this by deleting these 2 lines from config in system.site.yml:
site_disable_page_node: true
site_disable_page_node_404: false
So I did a config export, deleted these 2 lines, then did a config import.
This could also be added to the .module file to handle this when the module is uninstalled:
/**
* Implements hook_uninstall().
*/
function disable_page_slash_node_uninstall() {
// Load the system.site configuration.
$config = \Drupal::configFactory()->getEditable('system.site');
// Remove the unwanted configuration lines.
$config->clear('site_disable_page_node');
$config->clear('site_disable_page_node_404');
// Save the updated configuration.
$config->save();
}
Also seeing this, saving the form at admin/config/people/accounts doesn't work even after uninstalling this module.
Using v 1.4 of this module.
I applied the changes above to the module, uninstalled the module, and this allowed me to then save the form at admin/config/people/accounts.
Here's the patch from #41 re-rolled working with Drupal v 10.2.6.
Thanks for this, just what I needed when using the Paragraphs Previewer module widget.
However, in Drupal 10 hook_field_widget_WIDGET_TYPE_form_alter() is replaced by hook_field_widget_single_element_WIDGET_TYPE_form_alter().
I have provided a patch for easy use via composer patches, and tested at my end, working without any issues.
Not sure if I am seeing the same issue but the patch did not work.
I am unable to make changes to the form at /admin/config/regional/content-language
For example, if I turn off translation for redirect, save the form, the page reloads and the translation for redirect is still turned on.
Drupal core 10.2.4
I'm seeing issues with the CSS from this module breaking Bootstrap modals and even in the admin theme the background colour of the breadcrumb is being set to white.
It seems that for receipts to work you must include the customer email in the transaction.
See - https://developer.paypal.com/braintree/articles/control-panel/transactio...
And - https://developer.paypal.com/braintree/docs/reference/request/transactio...
I have created a patch which seems to work.
Joe Huggans → created an issue.
Drupal 10 Release needed by the maintainers, doesn't look like they are responding...
#69 working with Drupal 10.2.3
Our issue was specifically with forward slashes in an argument.
Sorry for the non-response on this alecsmrekar! I am now looking to get this module compatible with Drupal 10. Are you still using this module? Would you like to be a co-maintainer?