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?
I would like to bring this module up to Drupal 10 and become a maintainer
Tested #13 on Drupal 10.2.3 and 8.x-1.5 of this module and it seems to work, can see the 3DS data on the Braintree transaction now, which wasn't there before.
#14 worked for me on Drupal 10.2.2 & advagg 6.0.0-alpha1, thanks @savage2003.
Maybe we should stand with innocent people on both sides? Rather than this cheap displaying a flag for "support". When you say you stand with Ukraine, does that include supporting the government that was bombing Russians in Donbas? Or is it just the CIA installed 2014 Ukraine government you support?
Created a patch until this gets accepted.
Tested and works for me.
I'm using Drupal 10.2.2 and this issue still exists for me. Not able to apply patch from D10 issue, or this issue.
@emircanerkul sorry no, no resolution was found at my end, another Dev picked up the work from me and he hasn't reported back what worked, I'll try get them to confirm if they fixed it.
See this issue - https://www.drupal.org/project/path_redirect_import/issues/3410487 🐛 "Drupal\migrate_tools\Commands\MigrateToolsCommands" not found PathRedirectImportCommands Postponed: needs info
Thanks Kevin, it does look like you found the issue i.e. conflicts drupal/migrate_tools (<= 5) , but I will try confirm.
This issue seems to be related - https://www.drupal.org/project/path_redirect_import/issues/3276865 🐛 Compatibility with Migrate Tools ^6.0 Fixed
@Nicolas S - could you explain in more detail what worked for you? As it could help others.
I'm also seeing this error on a site that is in the progress of being upgraded to D10. It happens when I try to run a drush command like drush uli.
I've checked the module versions and they are correct it seems:
Path redirect import: 2.0.8
Migrate tools: 6.0.2
PHPstorm isn't showing any issues with the extending of MigrateToolsCommands, i.e. Drupal\migrate_tools\Drush\MigrateToolsCommands; is found.
Error: Class "Drupal\migrate_tools\Drush\MigrateToolsCommands" not found in /var/www/html/web/modules/contrib/path_redirect_import/src/Drush/Commands/PathRedirectImportCommands.php on line 29 #0 /var/www/html/vendor/composer/ClassLoader.php(576): include()
#1 /var/www/html/vendor/composer/ClassLoader.php(427): Composer\Autoload\{closure}('/var/www/html/w...')
#2 [internal function]: Composer\Autoload\ClassLoader->loadClass('Drupal\\path_red...')
#3 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(192): ReflectionClass->__construct('\\Drupal\\path_re...')
#4 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(174): Drush\Runtime\LegacyServiceInstantiator->instantiateObject('\\Drupal\\path_re...', Array)
#5 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(131): Drush\Runtime\LegacyServiceInstantiator->create('\\Drupal\\path_re...', Array, Array)
#6 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(60): Drush\Runtime\LegacyServiceInstantiator->instantiateServices(Array)
#7 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(257): Drush\Runtime\LegacyServiceInstantiator->loadServiceFiles(Array)
#8 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(233): Drush\Boot\DrupalBoot8->addDrupalModuleDrushCommands(Object(Drush\Boot\BootstrapManager))
#9 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(236): Drush\Boot\DrupalBoot8->bootstrapDrupalFull(Object(Drush\Boot\BootstrapManager), NULL)
#10 /var/www/html/vendor/drush/drush/src/Commands/core/LoginCommands.php(71): Drush\Boot\BootstrapManager->doBootstrap(5)
#11 [internal function]: Drush\Commands\core\LoginCommands->login('', Array)
#12 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array(Array, Array)
#13 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#14 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#15 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(391): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#16 /var/www/html/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /var/www/html/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#18 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#19 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#20 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#21 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#22 /var/www/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run(Array)
#23 /var/www/html/vendor/drush/drush/drush(4): require('/var/www/html/v...')
#24 /var/www/html/vendor/bin/drush(119): include('/var/www/html/v...')
#25 {main}
Error: Class "Drupal\migrate_tools\Drush\MigrateToolsCommands" not found in include() (line 29 of /var/www/html/web/modules/contrib/path_redirect_import/src/Drush/Commands/PathRedirectImportCommands.php).
Tried with MySQL 8.0 but same error -
[error] SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 3072 bytes: ALTER TABLE "draggableviews_structure" CHANGE "args" "args" VARCHAR(1024) NULL DEFAULT '' COMMENT 'Makes the order unique for a given set of arguments'; Array
[error] Update failed: draggableviews_update_8105
Hi, this happened before upgrading to Drupal 10, as well as after the upgrade to Drupal 10, currently at 10.2.1.
Tried on a server to see if it was something strange happening with my local ddev environment but the same issue exists.
Joe Huggans → created an issue.
#21 - legendary, thank you!
This still isn't working for me, I've tried manually adding a requirement for psr/http-message for version 1.1 but still seeing this when trying to send a test message -
No php-http message factories found. Note that the php-http message factories are deprecated in favor of the PSR-17 message factories. To use the legacy Guzzle, Diactoros or Slim Framework factories of php-http, install php-http/message and php-http/message-factory and the chosen message implementation.
Doesn't look like this is in Drupal yet, as of 10.1.5.
Wasn't sure how to use it either in my EntityListBuilder class for my custom content entity, so just did.
public function render(): array {
$this->limit = 150;
}Patch doesn't work anymore due to a name change from Command to Drush. Corrected for this.
Apologies for my casual English, I was not clear. This solution above worked for me perfectly, after trying to get it to work for some time. Looks like the problem was I was not using the file_url_generator service.
Thanks for this, couldn't get it to work
Drupal 10 did the following:
function MY_MODULE_preprocess_views_view(&$variables) {
if ($variables['view']->id() === 'MACHINE_NAME_OF_VIEW') {
$variables['#attached']['library'][] = 'media_entity_browser/view';
}
}#13 Seems to work for me. Great additional feature. Thanks all
Found the issue, it was because I didn't want the interface to change from the default language when on a page which is a translated page, because all my content editors are English.
So I turned off "Language from the URL (Path prefix or domain)." for the detection method for the interface.
I assumed Webforms would be classed as content for translation.
Tried uninstalling all contrib modules, tried uninstalling the webform module and reinstalling, not working. If there are any things I can try to shine light on this I'm happy to try them out.
Just tried on a different Drupal site with the same version of Drupal and Webform and it works.
I'm not sure what is causing this, I have tried creating a new webform with just one text field and the issue persists.
If I figure it out or how to replicate I will report back.
joehuggans → created an issue.
Also found this issue on a site in a /us sub directory.
I have an ajax view and after making a change to the exposed filters, and then editing the node in the list of the view, the destination didn't include the /us part of the URL.
Doesn't happen if you don't touch the filter.
olli's patch fixes it, thanks!
Seeing this in Drupal 9 also, works fine if not using Ajax on your view.
The ajax command viewsShowMore seems to be running twice, the second time it runs $($.parseHTML(response.data, document, true)) is empty.
But then even if you force it to just run once, there is still the issue of it not showing the last page, which #7 fixes but not sure if this is the proper way to handle this.
This module is broken when using AJAX.
Could we get a merge for this?
joehuggans → created an issue.
Suggestion for this
joehuggans → created an issue.