Sadly seems like it isn't. This was also my hope, as I just needed to import some new config files from config/install in a module. My expectation was that only these were imported and updated, but instead a lot of existing configuration was deleted.
Fixes here are NOT enough for D11 compatibility. Also 🐛 Drupal\config_import\ConfigImporterService::__construct(): Argument #4 ($event_dispatcher) must be of type Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher, Symfony\Component\EventDispatcher\EventDispatcher given Active needs to be merged and the test module needs to be set Drupal 11 compatible.
Attached MR fixes the issues with Drupal 11.
anybody → changed the visibility of the branch 3528881-fix to hidden.
I can confirm this issue still exists in 3.0.x-dev! Also the tests submodule is not marked D11 compatible.
anybody → created an issue.
This is still an open question that would be great to answer on the project page also. Thanks!
@liam morland: There's nothing to review yet. We should either fix both issues over at 📌 When scrolling, the modal window opens automatically Active or here. They are very closely related, nearly the same and surely have the same fix. As this one is closed, maybe better move over?
So ==> Further work here: https://www.drupal.org/project/webform/issues/3506020 📌 When scrolling, the modal window opens automatically Active <==
Test Error
Drupal\Tests\drowl_paragraphs_bs_type_video\Functional\GenericDrowlParagraphsBsVideoTest::testModuleGenericIssues
Drupal\Core\Config\PreExistingConfigException: Configuration objects (field.storage.paragraph.field_override_autoplay, field.storage.paragraph.field_override_controls, field.storage.paragraph.field_override_loop, field.storage.paragraph.field_override_muted) provided by drowl_paragraphs_bs_type_video already exist in active configuration
absolutely make no sense to me. They can't pre-exist, because they have not been existing in the past...
Maybe this runs in kind of a loop and tries to re-install them?
The update hook will never be called by the module, I guess so that shouldn't be the reason?
Ready for review @thomas.frobieter feel free to merge if it's fine and you won't add your code here.
@thomas.frobieter ready for review. Would you also like to add your code here or only the fields?
Scheduler submodule tests need to be disabled until it's working, currently it breaks CI.
@lrwebks the submodule currently breaks CI pipeline. Can we please comment out its tests in master, until this one is resolved? (Re-comment in in a MR here)
Thanks!
@lrwebks re #8: No, but let's solve that separately over there.
I'll merge this one now, thanks! It also fixes a regression in https://git.drupalcode.org/project/ad/-/merge_requests/9/diffs?file=a7ca...
@lrwebks please quickly add an update hook to set the new config value TRUE for existing installs. Afterwards let's merge this!
Thanks @joelpittet great work and test is green!
I left some final, minor comments, what do you think?
We're having these log entries day by day...
See our example boilerplate implementation.
Mind that there are two possible cases:
1. No matching ad generally exists for an ad block
2. The result of an existing ad is empty
I think we should not care for the second case.
There are two possible ways to solve this:
1. Checking if there is an ad for the block right before rendering the block at all (server-side)
2. Removing the block in JS if no ad is found for the block (client-side)
I'd tend to 1. because that also allows Drupal to hide the whole region that contains the block server-side
Might happen that we also need (2) later.
Add "Bypass ad tracking" permission is still relevant, because certain roles should not be tracked. But I think it should be fairly simple. At the place where the counter is counting, simply skip counting with this permission. Everything else stays the same.
@jsacksick any chance to merge this?
Maybe @lrwebks can take over here?
@alexrayu, @firewaller #8 and #5 have different results, can someone tell?
Just to leave a final note here: If further help is needed, contact me.
Thank you for the quick and extensive feedback @gausarts! Sorry I got that wrong and thanks for the explanations!
For the number formats https://www.drupal.org/project/advanced_number_format → might be a good starting point if we want to start in contrib.
Nice! This is definitely a huge improvement. Still the payer actions and redirects need further alignments, for example we saw in our tests that the redirect url doesn't seem to be set, so the client currently ends in an endless loop on paypal trying to fix the payment.
Details following by @grevil - anyway this should definitely be fixed asap, as the functionality seems incomplete or broken without the error handling.
Thanks @grevil. Back to RTBC.
Yeah let's use the base id prefix then, seems to be a good workaround.
Should now target 2.x - afterwards this should get merged, please.
Thanks @jan kellermann I guess this is for 🐛 External cdn script gets blocked, ignoring "block_unknown" completely Active
Very nice! :)
@gausarts just wanted to let you know that kenwheeler seems to have made a commit 5 days ago at https://github.com/kenwheeler/slick
Maybe you could try contacting him about this and maybe something like a co-maintainership for the project?
Thanks @maskedjellybean so we can keep this closed. Could someone have a look if we already have an issue for the required marking? (I think I saw one, but very busy currently - so maybe it could be linked here)
Perfect, thank you! That's a clear improvement on the current status.
Sorry I mixed this up, we don't even sue simplenews combined with checkout, so yes, you're welcome as co-maintainer, I'll add you.
Please stick to Drupal best practices and coding standards.
@afagioli feel free to sponsor development to move things forward. We currently have no client interested in development here, sorry.
anybody → created an issue. See original summary → .
Is already implemented!
rel="nofollow" on the ads is the right solution!
@clau_bolson: Ad channels might still be an interesting feature for the future, while I think ad groups logic will be solved as written in #7.
If you're still interested, please create a feature-request issue for ad channels and describe how they should work. We'd be happy to review MR or do some sponsored development on that. I'll keep this as postponed for now.
Please solve this in a contrib module or submodule (MR) if needed, if any hooks are needed, we're happy to provide them. Also see #7.
No further info provided.
Let's check if this still happens in 11.x - code-wise nothing big changed there, so I think possibly yes.
Please retry with 11.0 rewrite, once released. If there are still issues, please reopen or create a new issue with details.
Thank you!
If anyone is willing to sponsor the development, we'd be happy to implement this!
Should be adjusted finally right before the 11.0 release!
Fixed in 📌 [META] 11.x feature updates Active
Fixed in 📌 [META] 11.x feature updates Active by using SQL random :)
If this is still an issue, it will be a caching one, I think.
Fixed in 📌 [META] 11.x feature updates Active
If anyone needs this, please provide this as optinal submodule or solve it in contrib. We're open to provide an alter hook for example, if needed.
I don't think $_SESSION should be used. Generally I think this should maybe better go into a separate contrib module.
Fixed in 📌 [META] 11.x feature updates Active
Fixed in 11.x
Guess this will be fixed in 11.x soon!
RTBC for MR!25 - tests were failing before. Please tag a new release after merge, thanks!
D11 is out and stable for a long period of time now.
Feedback from @thomas.frobieter: Fine to merge this once ready.
@maintainers any chance for a D11 compatible release?
Nope, not using this any more.
So let's wait for final feedback how to finish this then, or any additions @damienmckenna?
Okay ready for review by @jsacksick! Thanks for the final adjustments @Grevil!
Confirming we just had this error on the following path:
https://www.example.com/user/register?_wrapper_format=drupal_ajax&ajax_f...
Backtrace:
TypeError: mb_strlen(): Argument #1 ($string) must be of type string, array given in mb_strlen() (line 332 of /web/core/lib/Drupal/Core/Form/FormValidator.php).
#0 /web/core/lib/Drupal/Core/Form/FormValidator.php(332): mb_strlen()
#1 /web/core/lib/Drupal/Core/Form/FormValidator.php(246): Drupal\Core\Form\FormValidator->performRequiredValidation()
#2 /web/core/lib/Drupal/Core/Form/FormValidator.php(238): Drupal\Core\Form\FormValidator->doValidateForm()
#3 /web/core/lib/Drupal/Core/Form/FormValidator.php(238): Drupal\Core\Form\FormValidator->doValidateForm()
#4 /web/core/lib/Drupal/Core/Form/FormValidator.php(118): Drupal\Core\Form\FormValidator->doValidateForm()
#5 /web/core/lib/Drupal/Core/Form/FormBuilder.php(593): Drupal\Core\Form\FormValidator->validateForm()
#6 /web/core/lib/Drupal/Core/Form/FormBuilder.php(326): Drupal\Core\Form\FormBuilder->processForm()
#7 /web/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm()
#8 /web/core/modules/layout_builder/src/Controller/LayoutBuilderHtmlEntityFormController.php(39): Drupal\Core\Controller\FormController->getContentResult()
#9 [internal function]: Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult()
#10 /web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#11 /web/core/lib/Drupal/Core/Render/Renderer..php(638): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#12 /web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext()
#13 /web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#14 /vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#15 /vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#16 /web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle()
#17 /web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#18 /web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#19 /web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle()
#20 /web/core/modules/page_cache/src/StackMiddleware/PageCache.php(116): Drupal\big_pipe\StackMiddleware\ContentLength->handle()
#21 /web/core/modules/page_cache/src/StackMiddleware/PageCache.php(90): Drupal\page_cache\StackMiddleware\PageCache->pass()
#22 /web/core/modules/ban/src/BanMiddleware.php(50): Drupal\page_cache\StackMiddleware\PageCache->handle()
#23 /web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle()
#24 /web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#25 /web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#26 /web/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#27 /web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle()
#28 /web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#29 /web/index.php(19): Drupal\Core\DrupalKernel->handle()
#30 {main}
No idea if it was a hacking attempt or what caused this, but the issue is real.
Just wondered, why GA (via google_tag) was not blocked on an older project using klaro and the reason was, that this update was missng.
Maybe Klaro should add a mechanism to update the default configs to ensure the relevant entries are up to date? (And better they exist than they do not?)
TL;DR: Voting for update hooks in such cases to add the relevant / new entries, if not yet existing. Should we open a follow-up for that?
After adding the new entries, Klaro blocked correctly, but this is a bit dangerous for "normal" users?
@maintainers: Any chance to merge this finally?
See: https://git.drupalcode.org/project/klaro/-/blob/3.x/README.md
For Google Tag 2.x you may consider to disable the noscript snippet (see #3106318).
Thanks for the super helpful and important investigations @grevil!
I think we should do two things:
a) handle the different link types (rel's: (information_link, payer-action, redirect, ...?) as described in
🐛
Needs to redirect users on UNPROCESSABLE_ENTITY > PAYER_ACTION_REQUIRED - No checkout possible
Active
in
✨
Print details from error messages returned by paypal
Active
so that if user action is needed, it works!
b) Try to reduce the cases where a user action is needed by default, e.g. might mean to include a default shipping (country) rate in the first call in the cart
Thanks @grevil. I'm not sure if we should track the point in time, when the order was paid in full as an additional base field or instead should calculate it based on the tracked payments (IF $order->isPaid() is true).
Let's wait for maintainers feedback on how they'd say it's best.
Which way ever we go, we need to ensure that the information is always consistent, for example if a payment was refunded afterwards.
Thanks @safetypin! Google found this for me: https://drupal.stackexchange.com/questions/55279/how-can-i-set-the-langu...
Great work for a great feature based on the work done by @vmarchuk! Thanks for the various important finding and fixes!
@vmarchuk will you or your team have a look soon so we don't lose focus here? Would be wonderful to have this feature released soon IMHO!
Works as expected in my testing! RTBC!