macdev_drupal → created an issue.
We got 200+ Spambot Submissions this night. We have rate limting active so that they did submit one post every three minutes that came through. It some kind of bitcoin spam:
betreff: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
e_mail1: emiliogervacio02@gmail.com
hausnummer: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
ihr_anliegen: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
nachname: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
ort: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
plz: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
strassennamen: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
telefonnummer: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
vorname: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'Sadly Modsecurity did not capture the post requests as no rule was triggered.
I wonder if it would be an option to add a factor to the antibot-key dynamically based on time of the form get.
At the moment it looks like the key is static for the same ip-adress. Okay, this would impact caching but then the bot would need to use the new key each time a form is submitted.
Okay, I tried using an action handler: Lock submission when submitted. This is one of the options provided by Webform.
After pressing the submit button, the submission is successfully locked. However, when the user opens the tokenized URL and re-edits the form, the lock is removed, and the values can be changed.
I believe this might be a bug. Or is it intended behavior that a locked submission can still be edited?
We are facing a similar issue. It would be beneficial to have an option to mark a Webform submission as "frozen" once a draft is submitted.
Currently, we provide an anonymous user with a tokenized URL to allow them to return later and continue editing the draft. However, once the form is finally submitted, the submission should no longer be editable, at least by the anonymous user.
The problem is that as long as the token URL remains valid, the submission can still be edited, even after it has been marked as submitted. This creates a situation where users can modify what should be a finalized submission.
Having a way to lock or freeze submissions after they are marked as complete would resolve this issue.
Maybe this could be achieved with a webform handler? Maybe there already is one?
Drush hands over to the local module. So I think this should be addressed there.
Just checked
web/core/modules/locale/locale.fetch.inc
web/core/modules/locale/locale.batch.inc
the methods there are just triggered from drush locale:check and the business logic is in those methods.
Maybe there could be a fall back, before deleting / renaming .po files locally.
macdev_drupal → created an issue.
Same here. It fails for a part of our code base:
hm-medien.de > [warning] Trying to access array offset on value of type null HandlerBase.php:724
hm-medien.de > [error] A valid cache entry key is required. Use getAll() to get all table data.
hm-medien.de > [error] Update failed: views_post_update_taxonomy_filter_user_context
hm-medien.de > [error] Update aborted by: views_post_update_taxonomy_filter_user_context
Will investigate further.
Had some config changes after core / module Updates in views config ymls which have not been commited yet.
On the main part of our code base the update did run well.
+1
Currently trying to Upgrade the config modules and after there seems to be a a patch for splits and config ignore, since config_split_ignore is not using the new api, I am now stuck again with:
Problem 1
- Root composer.json requires drupal/config_filter ^2.6, found drupal/config_filter[dev-2.x, 2.6.0, 2.x-dev] but these were not loaded, likely because it conflicts with another require.
Problem 2
- drupal/webform_config_ignore is locked to version 1.3.0 and an update of this package was not requested.
- drupal/webform_config_ignore 1.3.0 requires drupal/config_filter ^1 -> found drupal/config_filter[dev-1.x, 1.0.0-beta3, ..., 1.x-dev (alias of dev-1.x)] but it conflicts with your root composer.json require (^2.6).
Sorry, I think it just messed up things here because we did have 8.x-1.21 running with 10.2 (but not tested yet) and the incoming merge with 8.x-1.22 broke it, and I couldn't figure out the problem, which obviously should have something to do with one of the updated modules.
You are right.
Maybe it's better to do it like what we did when upgrading from D9 to D10 like here: "drupal/csv_serialization": "4.0 as 3.0".
This will make composer.json merge conflicts easier to handle if other modules will follow to lock support.
macdev_drupal → created an issue.
Hi, I am trying to explain our use case.
We have a large multisite installation and custom and contrib modules which are used only by specific customers.
So, for example, we enable basic_cart only for some of them by enabling a split.
This is where config_split_ignore comes in.
It is used primarily to protect the settings of a split against being overridden. This couldn't be done with config_ignore because the general configuration doesn't know anything about the split.
dependencies:
module:
- config_split_ignore
third_party_settings:
config_split_ignore:
entities:
- basic_cart.checkout
- config_pages.type.basic_cart_settingsdependencies:
module:
- config_split_ignore
third_party_settings:
config_split_ignore:
entities:
- 'he_dba.settings:custom_tables'
id: config_map_feuerwehrIf the settings of a split are not in the config because one cannot set them to ignore, they will be deleted at a drush cim during the deployment of a new release, as long as they wouldn't be exported with drush cex. Exporting them would, on the other hand, lead to conflicts with other site settings that differ.
Hope this explains the pain we are in a bit :-)
macdev_drupal → created an issue.
Looks like the project is now "unsupported". Any chance that someone will be able to merge the D10 automated fixes into a release? There are now broken dependencies form basic_cart module.
Are there any plans to do so @maximpodorov - as config_ignore 2.x seems to be unsupported now?
Closing this issue.
Yeah I understand.
We just stumbeld upon this when a content creator was trying to set up a webform in a different language in a non multilingual drupal site.
Our distro doesn't support that at the moment but people always try to hack funny things.
So maybe we will use a config page and use a form alter hook to let them translate it in the UI somehow.
macdev_drupal → created an issue.
Same here. We got several requests like this which came through the form within under a minute. So either it is remote post or a client with selenium I guess. But they would have to record this before. Anyway they got past Antibot.
The requests contain some SQL Injection patterns.
Cookie: M1R4X=1700663570xCaY4D9A6Vmrb; SSESS90efd8bd784fa77255ffa5094c2e07f7=dp1%2CS2R0Iv-hC5RvWNZJrsVnoCE6J2ey9ZCFZfjvrOMPL0Ns
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
--e862924b-I--
anrede%5bselect%5d=%5fother%5f&anrede%5bother%5d=1&vorname=gjIjhtUZ&nachname=gjIjhtUZ&ihre%5fe%5fmail%5fadresse=testing%40example%2ecom&url%5fbzw%5fquellenangabe%5fder%5fbarriere=1&beschreibung=1&antibot%5fkey=c5vdMtXZaktbnbWNUD7JIFgSxV31bEBrDmJ%5f2VHUuYI&form%5fbuild%5fid=%2d1+OR+2%2b215%2d215%2d1%3d0%2b0%2b0%2b1+%2d%2d+&form%5fid=webform%5fsubmission%5fbarriere%5fmelden%5fparagraph%5f7180%5fadd%5fform
HTTP/1.1 303 See Other
Location: https://drupal.website.de/webform/barriere_melden/confirmation?token=mkgaCOgK_gh6Q4oQO04FcY_95SavIlL7yffSJoY0uZw
We did capture this with modsecurity.
Maybe somone with deeper knowledge of Antibot could shine some light on this.
And eventually improve the module.
Got it working for a menu link field that way.
$form['title']['widget'][0]['value']['#maxlength'] = 25;
$form['title']['widget'][0]['value']['#attributes']['data-maxlength'] = 25;
$form['title']['widget'][0]['value']['#maxlength_js'] = TRUE;
Guess you just need to add that 'data-maxlength' to your example above.
For my case it needed to be inside of $element['widget'][0]['value'] to get it working.
The documentation says it different.
Sorry for bothering you Jake! Did test it on simplytest.me and it works like designed. So it must be somewhere in our 34+ custom modules an 50k+ lines off code. Closing the Issue.
Okay, changed description_display to 'before' here but doesn't make a difference. https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/lib/Drupal/C...
Will investigate this further.
macdev_drupal → created an issue.
Confirm - 2.0.2 is broken with 9.5.9 Drupal Core
Have the same error after updating to php 8.1.20 and drupal core 9.5.8
We set the identiy from settings.php, as we run more than 100 sites with the same drupal build, with:
$config['system.logging']['error_level'] = 'all';
$config['syslog.settings']['identity'] = '';
$config['syslog.settings']['format'] = '!base_url|!timestamp|!type|!ip|!request_uri|!referer|!uid|!link|!message';
After a drush cr is run the first visitor would se the red deprecation warning.
Therefore I would upvote for this to be fixed in core.
Not sure if it is the same problem but downgrading from 3.0.0-beta3 to 3.0.0-beta1 fix this issue for us.
It seems like the embed and includes do no loger work like that.
{% block content %}
{% include '@hw_radix_standard/navbar/navbar-brand.twig' with {
prefix: site_name_prefix,
Twig\Error\LoaderError: Template "@hw_radix_standard/navbar/navbar-brand.twig" is not defined in "themes/custom/hw_radix_standard/templates/block/block--system-branding-block.html.twig" at line 26. in Twig\Loader\ChainLoader->getCacheKey() (line 98 of /var/www/html/vendor/twig/twig/src/Loader/ChainLoader.php).
Twig\Environment->getTemplateClass('@hw_radix_standard/navbar/navbar-brand.twig', NULL) (Line: 205)
Drupal\Core\Template\TwigEnvironment->getTemplateClass('@hw_radix_standard/navbar/navbar-brand.twig') (Line: 381)
Twig\Environment->loadTemplate('@hw_radix_standard/navbar/navbar-brand.twig', NULL) (Line: 333)
Twig\Template->loadTemplate('@hw_radix_standard/navbar/navbar-brand.twig', 'themes/custom/hw_radix_standard/templates/block/block--system-branding-block.html.twig', 26) (Line: 199)
__TwigTemplate_0c5736a4f96b51b76a13058fbc5c6d5f___75412211->block_content(Array, Array) (Line: 182)
Twig\Template->displayBlock('content', Array, Array) (Line: 79)
__TwigTemplate_8841fceebceb03af7747f1ab821ed205->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array, Array) (Line: 190)
__TwigTemplate_0c5736a4f96b51b76a13058fbc5c6d5f___75412211->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 69)
__TwigTemplate_0c5736a4f96b51b76a13058fbc5c6d5f->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/custom/hw_radix_standard/templates/block/block--system-branding-block.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('block', Array) (Line: 433)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 446)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 178)
__TwigTemplate_83b2ac2dc15fc1e2e161799ddba49516->block_branding_top(Array, Array) (Line: 182)
Twig\Template->displayBlock('branding_top', Array, Array) (Line: 60)
__TwigTemplate_83b2ac2dc15fc1e2e161799ddba49516->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/custom/hw_radix_standard/src/components/page/page.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('page', Array) (Line: 433)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 132)
__TwigTemplate_b3a54b59fb991600ee3d43e44ae0a08d->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/custom/hw_radix_standard/src/components/system/html.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 433)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
Drupal\Core\Render\Renderer->render(Array) (Line: 162)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 163)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 174)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 191)
Drupal\page_cache\StackMiddleware\PageCache->fetch(Object, 1, 1) (Line: 128)
Drupal\page_cache\StackMiddleware\PageCache->lookup(Object, 1, 1) (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
We had some similar issues when updateing to 1.4 because the "Enable on this site" Checkbox was not checked by default. Maybe this could be the same reason?
The logouts happend not predictably in this state:
https://www.drupal.org/project/autologout/issues/3363875
🐛
Autologout disabled after 1.4 Upgrade
Closed: works as designed
macdev_drupal → created an issue.
For me, it seems like this new Base_url field in entity_print 2.11 does not work for us.
We have differences between stages, we are coping with like installations which can not curl themselves at all, installations which can curl only via localhost, installations which can resolve their domain names and docker / ddev for development.
And then there is multisite, we have to deal with. Further, we are using it with webform, which has some special issues when private files and the signature field are used.
I got it working in ddev / docker, but not at installations which can call themselves only via localhost. It, too, seems that the file:/// syntax is not supported.
If the patch is applied against 2.11 it doesn't work either. I guess the base_url field form module needs to be overridden to bring back the previous behavior.
Meanwhile, I'll roll back to the patched 2.7 and try to figure out if a differently patched 2.11 would be an option.
Running with Core 9.4.10, entity_print 2.11.0 and webforms 6.1.4 with Patch #3 I do get the error:
Error generating document: Failed to generate PDF: The CSS selector 'summary::marker' is not valid
When I apply patch #2 it works.