Fixed in 1.0.4 release.
Hi @yevko, nice to see you.
No, both sites have the default language as English.
Our system.site.yml has
_core:
default_config_hash: yXadRE77Va-G6dxhd2kPYapAvbnSvTF6hO4oXiOEynI
langcode: en
uuid: 01602f5c-032b-4c67-a1da-b7bba1207a45
name: 'Example site'
mail: 'noreply@example.site'
slogan: ''
page:
403: ''
404: ''
front: /node/1
admin_compact_mode: false
weight_select_max: 100
default_langcode: en
mail_notification: noreply@example.siteBut indeed the language negotiation has been set so that the site by default opens the Finnish site and not the English one in language.negotiation.yml:
_core:
default_config_hash: uEePITI9tV6WqzmsTb7MfPCi5yPWXSxAN1xeLcYFQbM
session:
parameter: language
url:
source: path_prefix
prefixes:
en: en
fi: fi
domains:
en: ''
fi: ''
selected_langcode: fiMy feeling is that because the site's default language is set to English sometimes Drush takes that as the default language and changes Finnish labels into English. This does not happen the other way around that English site shows Finnish labels. The problem still gets fixed by clearing all caches in the admin UI.
Unfortunately my comment from #51 was not the final verdict. We have still seen this issue after deployments. Mostly the problem still happens with the multisite where term names and field labels are in wrong language after deployment. Everytime a manual cache clear from the UI fixes the issue. It seemed like the patch from 🐛 Configuration being imported by the ConfigImporter sometimes has stale original data Fixed might have even made the problem more visible because with that patch we were also seeing wrong labels in the default site when usually they are limited to the multisite instance.
I'll report more findings if we are able to track down the issue further. Of course any debug or test instructions that we can run and report here would help.
Excellent. Thanks a lot for the extremely quick response!
Great. I can ask one of my colleagues to test the patch and mark it RTBC if everything looks good.
We have a couple of projects where we have been planning to take this feature in to use but I don't know the timetable yet. Most likely during the autumn. It would make it easier to plan for the feature if there was an official release available but we can live without it for now.
Hi @jhuhta,
I opened a MR to add support for textareas with summary. It seemed like it was enough to allow text_textarea_with_summary in the SUPPORTED_FIELD_WIDGETS.
Happy to add any additional changes to feel like would be. I didn't yet touch the CHANGELOG.MD for possible changes.
Also I was wondering if you have any plans to release an alpha version? In our projects we usually set the minimum Composer requirement higher than development release so I am wondering if you have plans to make an official alpha release of this module?
Thank you @anisha. I failed to find that issue when searching for the issue list and it does indeed fix the issue.
I was able to solve the problem with the instructions from #3. I think this issue could be closed and perhaps document this in the module readme.txt.
I was trying to figure out the same thing but failed to achieve it yet. I also tried it with Better exposed filters module but it doesn't seem to catch it.
I tested this patch to be able to translate the default All options in the filter but it seems like after this patch is applied all the terms in a vocabulary where terms are in two levels are displayed in a single select list. Without this patch it works as intended and I get two different select elements where I first select the first level term and then the second level term.
I suspect that the patch might create a regression in the normal select filter but might work in a links / checkboxes version.
I am marking this as Needs work unless I missed something critical.
the_g_bomb → credited heikkiy → .
Tested this patch also and it seems to work fine. One small issue I did notice is that in the normal dropdown widgets the All / Any option is first option in the select list. But in the SHS widget the Any option is last in the select list.
So basically the select list code looks like this:
<select>
<option value="1">Term 1</option>
<option value="2">Term 2</option>
<option value="All">- Any -</option>
</select>
If I have several exposed filters in the same view, it's a bit weird UX that in some of them the All option is first and in some it's the last.
I did a bit more testing and I can still reproduce the issue but it seems like it only happens in the content type where the option value is still in use.
I was able to save the field settings in a second content type where the field UI doesn't have theCannot be removed: option in use. warning. Basically it's a second content type utilizing the field but there is no content created in this environment. I was also able to add a completely new field with zero as the machine name.
So my problem might be related to some additional validation that happens when there is existing content where the option is used.
That being said, in hindsight at least in my case the correct field type should have been List (float) instead of List (text) but there might still be other cases where the zero should be a valid machine name also for a text list.
I tested this quickly today and at least in my case the patch did not yet immediately fix the issue. It was still giving me the required field error with Drupal core 10.2.7. There might be some other contrib module involved here because I remember bumping into problems related to the new list field edit UI and perhaps Field permissions module. I wasn't immediately able to find the relevant issue but disabling field related modules like Conditional fields and Field permissions didn't resolve the issue for me yet. I'll see if I can figure out the problem in our environment.
I encounted this same problem with Drupal core 10.2.7.
We have an existing List (text) type field which has been used to select a VAT value. The values stored there have been 0, 10, 14 and 24 to correspond with the Finnish VAT values. I was trying to add a new value there to take into account a new allowed value in Finland. Now I noticed that with the new list UI I am not able to store the value 0 anymore. The value gives a validation error that the field is required because the value 0 is most likely interpreted as an empty value.
The key itself has been working fine for us and in our case it would be perfectly valid and good value for the select element and any other value would require code changes and also changes to a lot of existing content where the 0% has been the default value.
This looks good to me.
Excellent. It would be good to act fast because it seems like it is already used to distribute malicious code based on https://github.com/polyfillpolyfill/polyfill-service/issues/2873#issueco....
We have encountered this issue in at least two client projects. While investigating the issue, the issue can be fixed temporarily by clearing caches and this allows the content to be saved again. But after the content is saved again, the second revision is visible again and it blocks saving the content a second time with the same error related to untranslated fields not being editable.
I opened a MR for this for easier review and commenting.
I tried to improve the code a bit and made some small improvements. Here is an attached patch with following changes.
1. Added a check for $route_object being null to avoid potential errors.
2. Used instanceof instead of is_a for checking if $arg is an instance of EntityInterface.
3. Some small style changes.
Tested that the issue is still resolved.
I found this issue when installing Notification message to our side crashed a view with contextual filters in the URL.
The error in our case was this
The website encountered an unexpected error. Try again later.
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "arg_0" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 139 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).
Drupal\Core\Entity\EntityTypeManager->getHandler() (Line: 192)
Drupal\Core\Entity\EntityTypeManager->getStorage() (Line: 129)
Drupal\notification_message\Cache\Context\RouteEntityUuidCacheContext->attachViewRouteEntities() (Line: 86)
Drupal\notification_message\Cache\Context\RouteEntityUuidCacheContext->entityCacheTagsFromRoute() (Line: 60)
Drupal\notification_message\Cache\Context\RouteEntityUuidCacheContext->getContext() (Line: 123)
Drupal\Core\Cache\Context\CacheContextsManager->convertTokensToKeys() (Line: 244)
Drupal\Core\Cache\VariationCache->createCacheIdFast() (Line: 175)
Drupal\Core\Cache\VariationCache->getRedirectChain() (Line: 35)
Drupal\Core\Cache\VariationCache->get() (Line: 71)
Drupal\Core\Render\RenderCache->get() (Line: 113)
Drupal\Core\Render\PlaceholderingRenderCache->get() (Line: 317)
Drupal\Core\Render\Renderer->doRender() (Line: 493)
Drupal\Core\Render\Renderer->doRender() (Line: 240)
Drupal\Core\Render\Renderer->render() (Line: 475)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 122)
__TwigTemplate_a80a95a6a8c5a3904dde60ae71cea77e->block_page_pre_content() (Line: 171)
Twig\Template->displayBlock() (Line: 130)
__TwigTemplate_f0b5e2f7c622ad70fb53191694409337->doDisplay() (Line: 394)
Twig\Template->displayWithErrorHandling() (Line: 367)
Twig\Template->display() (Line: 61)
__TwigTemplate_a80a95a6a8c5a3904dde60ae71cea77e->doDisplay() (Line: 394)
Twig\Template->displayWithErrorHandling() (Line: 367)
Twig\Template->display() (Line: 39)
__TwigTemplate_9e59da2f5f2329765a9dfd034cd52843->doDisplay() (Line: 394)
Twig\Template->displayWithErrorHandling() (Line: 367)
Twig\Template->display() (Line: 379)
Twig\Template->render() (Line: 38)
Twig\TemplateWrapper->render() (Line: 39)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 480)
Drupal\Core\Render\Renderer->doRender() (Line: 240)
Drupal\Core\Render\Renderer->render() (Line: 475)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 81)
__TwigTemplate_cba7f8237d6b6745d5fea617efe7d916->doDisplay() (Line: 394)
Twig\Template->displayWithErrorHandling() (Line: 367)
Twig\Template->display() (Line: 39)
__TwigTemplate_f020d8f0b6dad9d1f81515d1f59f880c->doDisplay() (Line: 394)
Twig\Template->displayWithErrorHandling() (Line: 367)
Twig\Template->display() (Line: 379)
Twig\Template->render() (Line: 38)
Twig\TemplateWrapper->render() (Line: 39)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 480)
Drupal\Core\Render\Renderer->doRender() (Line: 240)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
call_user_func() (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
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: 704)
Drupal\Core\DrupalKernel->handle() (Line: 19)
The patch in this issue fixed the problem. I would be willing to mark this RTBC and mark it Major or even Critical because it causes a crash. I will see if I can come up with another suggestion how to fix this.
@joshahubbers-0 Can you change the MR from Draft to an actual MR?
Also there are a couple of comments to the MR which would be low hanging fruits like adding the core requirement and PHP requirement to composer.json.
Agreed. We can review these with @kekkis and approve the MR as soon as possible.
Running the project through PHP Compatibility tests finds more deprecations. I tested the module with PHP 8.3 but the deprecations are old.
---------------------------------------------
FOUND 11 ERRORS AFFECTING 3 LINES
------------------------------------------------------------------------------------------------------------------------------------------------------
36 | ERROR | Function mcrypt_get_iv_size() is deprecated since PHP 7.1 and removed since PHP 7.2; Use OpenSSL instead
36 | ERROR | Extension 'mcrypt' is deprecated since PHP 7.1 and removed since PHP 7.2; Use openssl (preferred) or pecl/mcrypt once available instead
36 | ERROR | The constant "MCRYPT_RIJNDAEL_128" is deprecated since PHP 7.1 and removed since PHP 7.2
36 | ERROR | The constant "MCRYPT_MODE_CBC" is deprecated since PHP 7.1 and removed since PHP 7.2
37 | ERROR | Function mcrypt_create_iv() is deprecated since PHP 7.1 and removed since PHP 7.2; Use random_bytes() or OpenSSL instead
37 | ERROR | Extension 'mcrypt' is deprecated since PHP 7.1 and removed since PHP 7.2; Use openssl (preferred) or pecl/mcrypt once available instead
37 | ERROR | The constant "MCRYPT_RAND" is deprecated since PHP 7.1 and removed since PHP 7.2
41 | ERROR | Function mcrypt_encrypt() is deprecated since PHP 7.1 and removed since PHP 7.2; Use OpenSSL instead
41 | ERROR | Extension 'mcrypt' is deprecated since PHP 7.1 and removed since PHP 7.2; Use openssl (preferred) or pecl/mcrypt once available instead
41 | ERROR | The constant "MCRYPT_RIJNDAEL_128" is deprecated since PHP 7.1 and removed since PHP 7.2
41 | ERROR | The constant "MCRYPT_MODE_CBC" is deprecated since PHP 7.1 and removed since PHP 7.2
------------------------------------------------------------------------------------------------------------------------------------------------------
Sounds good @silviaddweb. Added it.
This is now merged and new 2.1.2 version released.
Thank you for the report @dressedk!
I can verify your bug report and I created a MR to fix the issue.
We discussed this issue in Slack and I tested the latest patch from 🐛 Configuration being imported by the ConfigImporter sometimes has stale original data Fixed against 10.2.6 to solve the issue. At least in our staging environment which was suffering from this issue, the patch seems to now solve it. Our symptom was that taxonomy term and select list values in frontend were showing in wrong language after Drush deployment. Previously I tried the patch from this issue and 🐛 Wrong language field labels after `drush cr` because of Drush language negotiation Needs work to solve it.
We discussed this issue in Slack and I tested the latest patch from 🐛 Configuration being imported by the ConfigImporter sometimes has stale original data Fixed against 10.2.6 to solve the issue. At least in our staging environment which was suffering from this issue, the patch seems to now solve it. Our symptom was that taxonomy term and select list values in frontend were showing in wrong language after Drush deployment. I was also able to remove the patch from 🐛 Add multilingual support for caching basefield definitions Needs work without it having a visible regression.
We are experiencing the same issue. We are updating to Drupal core 10.2 and at the same time updating from Config split 1.x to 2.x. We have two sites where the update seemed to go fine initially but config sync and drush deploy seem to fail with this same error. Drush deploy faisl for us but also switching branches between 1.x and 2.x version of the module and trying to sync configuratin seems to also produce the same error in local development environment.
I think this is a critical issue because it breaks the whole deployment flow.
I was partly able to solve the problem by installing Config filter as a dependency with Composer to the project but it doesn't seem like a proper fix because the automated update process should handle this without needing to do an extra step.
Confirmed that all PHPUnit tests pass now.
Thanks for the fixes!
The original test report was sent to @joshahubbers-0 through e-mail. The module was audited in collaboration with Cookie information who owns Piwik Pro currently. I will add the PHPStan and PHPUnit test results here so that we have the completely history also in Drupal.org.
The original audit was done for level 9 but that is probably too strict level because even core doesn't validate for that. Looking at https://github.com/mglaman/phpstan-drupal/blob/main/phpstan.neon it seems like level 8 would be good. I will test your changes and report any findings.
------ -----------------------------------------------------------------------------------------------------------------------
Line piwik_pro.module
------ -----------------------------------------------------------------------------------------------------------------------
17 Function piwik_pro_help() has no return type specified.
17 Function piwik_pro_help() has parameter $route_name with no type specified.
37 Function piwik_pro_page_attachments() has no return type specified.
37 Function piwik_pro_page_attachments() has parameter $attachments with no value type specified in iterable type array.
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iter...
56 Function piwik_pro_page_top() has no return type specified.
56 Function piwik_pro_page_top() has parameter $page with no type specified.
------ -----------------------------------------------------------------------------------------------------------------------
------ --------------------------------------------------------------------------------------------------------------------------------------------------
Line src/Form/PiwikProAdminSettingsForm.php
------ --------------------------------------------------------------------------------------------------------------------------------------------------
23 Method Drupal\piwik_pro\Form\PiwikProAdminSettingsForm::getEditableConfigNames() return type has no value type specified in iterable type array.
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iter...
30 Method Drupal\piwik_pro\Form\PiwikProAdminSettingsForm::buildForm() has parameter $form with no value type specified in iterable type array.
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iter...
30 Method Drupal\piwik_pro\Form\PiwikProAdminSettingsForm::buildForm() return type has no value type specified in iterable type array.
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iter...
102 Method Drupal\piwik_pro\Form\PiwikProAdminSettingsForm::validateForm() has no return type specified.
102 Method Drupal\piwik_pro\Form\PiwikProAdminSettingsForm::validateForm() has parameter $form with no value type specified in iterable type array.
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iter...
106 Parameter #1 $string of function rtrim expects string, mixed given.
112 Parameter #1 $string of function strtolower expects string, mixed given.
118 Parameter #2 $subject of function preg_match expects string, mixed given.
123 Parameter #1 $string of function trim expects string, mixed given.
127 Parameter #2 $subject of function preg_split expects string, mixed given.
128 Argument of an invalid type array|false supplied for foreach, only iterables are supported.
140 Method Drupal\piwik_pro\Form\PiwikProAdminSettingsForm::submitForm() has no return type specified.
140 Method Drupal\piwik_pro\Form\PiwikProAdminSettingsForm::submitForm() has parameter $form with no value type specified in iterable type array.
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iter...
145 Parameter #1 $string of function substr expects string, mixed given.
------ --------------------------------------------------------------------------------------------------------------------------------------------------
------ ----------------------------------------------------------------------------------------------------------------------
Line src/PiwikProSnippet.php
------ ----------------------------------------------------------------------------------------------------------------------
83 Method Drupal\piwik_pro\PiwikProSnippet::getScript() return type has no value type specified in iterable type array.
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iter...
97 Parameter #2 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
97 Parameter #3 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
97 Parameter #4 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
100 Parameter #2 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
100 Parameter #3 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
109 Method Drupal\piwik_pro\PiwikProSnippet::getScript() should return array but returns null.
131 Parameter #2 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
131 Parameter #3 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
131 Parameter #4 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
137 Method Drupal\piwik_pro\PiwikProSnippet::getSyncScript() should return string but returns null.
145 Method Drupal\piwik_pro\PiwikProSnippet::getVisibilityPages() has no return type specified.
155 Parameter #1 $string of function mb_strtolower expects string, mixed given.
------ ----------------------------------------------------------------------------------------------------------------------
------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Line tests/src/Functional/PiwikProSnippetTest.php
------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------
53 Property Drupal\Tests\piwik_pro\Functional\PiwikProSnippetTest::$config (Drupal\Core\Config\ImmutableConfig) does not accept Drupal\Core\Config\Config.
71 Parameter #1 $account of method Drupal\Tests\BrowserTestBase::drupalLogin() expects Drupal\Core\Session\AccountInterface, Drupal\user\Entity\User|false given.
80 Method Drupal\Tests\piwik_pro\Functional\PiwikProSnippetTest::testPiwikProConfiguration() has no return type specified.
93 Method Drupal\Tests\piwik_pro\Functional\PiwikProSnippetTest::testPiwikProHelp() has no return type specified.
96 Call to an undefined method Drupal\Tests\WebAssert::pageTextContains().
100 Call to an undefined method Drupal\Tests\WebAssert::pageTextContains().
106 Method Drupal\Tests\piwik_pro\Functional\PiwikProSnippetTest::testSnippetVisibility() has no return type specified.
110 Parameter #2 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
111 Parameter #3 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
113 Parameter #1 $text of method Drupal\Tests\WebAssert::responseContains() expects object|string, mixed given.
117 Parameter #2 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
122 Parameter #1 $text of method Drupal\Tests\WebAssert::responseNotContains() expects object|string, mixed given.
128 Method Drupal\Tests\piwik_pro\Functional\PiwikProSnippetTest::testSnippetVisibilityPagesInverted() has no return type specified.
133 Parameter #1 $text of method Drupal\Tests\WebAssert::responseNotContains() expects object|string, mixed given.
136 Parameter #1 $text of method Drupal\Tests\WebAssert::responseContains() expects object|string, mixed given.
142 Method Drupal\Tests\piwik_pro\Functional\PiwikProSnippetTest::testSnippetVisibilitySyncSnippet() has no return type specified.
148 Parameter #2 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
155 Method Drupal\Tests\piwik_pro\Functional\PiwikProSnippetTest::testSnippetVisibilityChangedDataLayer() has no return type specified.
162 Parameter #3 ...$values of function sprintf expects bool|float|int|string|null, mixed given.
169 Method Drupal\Tests\piwik_pro\Functional\PiwikProSnippetTest::testSnippetVisibilityInvalidSettings() has no return type specified.
205 Method Drupal\Tests\piwik_pro\Functional\PiwikProSnippetTest::testSettingsForm() has no return type specified.
207 Call to an undefined method Drupal\Tests\WebAssert::statusCodeEquals().
208 Call to an undefined method Drupal\Tests\WebAssert::pageTextContains().
209 Call to an undefined method Drupal\Tests\WebAssert::elementExists().
------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------
[ERROR] Found 57 errors
Also the PHPUnit test results were the following
Piwik Pro Snippet (Drupal\Tests\piwik_pro\Functional\PiwikProSnippet)
✔ Piwik pro configuration
✘ Piwik pro help
│
│ Behat\Mink\Exception\ResponseTextException: The text "Piwik Pro is a GDPR-proof tracking tool that allows you to track user visits." was not found anywhere in the text of the current page.
│
│ /var/www/html/vendor/behat/mink/src/WebAssert.php:907
│ /var/www/html/vendor/behat/mink/src/WebAssert.php:293
│ /var/www/html/tests/src/Functional/PiwikProSnippetTest.php:100
│ /var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:729
│
✔ Snippet visibility
✔ Snippet visibility pages inverted
✔ Snippet visibility sync snippet
✔ Snippet visibility changed data layer
✔ Snippet visibility invalid settings
✘ Settings form
│
│ TypeError: Behat\Mink\Element\TraversableElement::findButton(): Argument #1 ($locator) must be of type string, Drupal\Core\StringTranslation\TranslatableMarkup given, called in /var/www/html/web/core/tests/Drupal/Tests/WebAssert.php on line 143
│
│ /var/www/html/vendor/behat/mink/src/Element/TraversableElement.php:97
│ /var/www/html/web/core/tests/Drupal/Tests/WebAssert.php:143
│ /var/www/html/web/core/tests/Drupal/Tests/UiHelperTrait.php:78
│ /var/www/html/tests/src/Functional/PiwikProSnippetTest.php:215
│ /var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:729
│
Time: 00:13.857, Memory: 4.00 MB
Summary of non-successful tests:
Piwik Pro Snippet (Drupal\Tests\piwik_pro\Functional\PiwikProSnippet)
✘ Piwik pro help
│
│ Behat\Mink\Exception\ResponseTextException: The text "Piwik Pro is a GDPR-proof tracking tool that allows you to track user visits." was not found anywhere in the text of the current page.
│
│ /var/www/html/vendor/behat/mink/src/WebAssert.php:907
│ /var/www/html/vendor/behat/mink/src/WebAssert.php:293
│ /var/www/html/tests/src/Functional/PiwikProSnippetTest.php:100
│ /var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:729
│
✘ Settings form
│
│ TypeError: Behat\Mink\Element\TraversableElement::findButton(): Argument #1 ($locator) must be of type string, Drupal\Core\StringTranslation\TranslatableMarkup given, called in /var/www/html/web/core/tests/Drupal/Tests/WebAssert.php on line 143
│
│ /var/www/html/vendor/behat/mink/src/Element/TraversableElement.php:97
│ /var/www/html/web/core/tests/Drupal/Tests/WebAssert.php:143
│ /var/www/html/web/core/tests/Drupal/Tests/UiHelperTrait.php:78
│ /var/www/html/tests/src/Functional/PiwikProSnippetTest.php:215
│ /var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:729
│
ERRORS!
Tests: 8, Assertions: 75, Errors: 2.
Failed to run phpunit : exit status 2
I encountered the same issue while updating from Config split 1.x to 2.x. The problem in my case was that during the upgrade process I had mixed up 1.x and 2.x configuration files for the splits when switching development branches.
Basically in my config_split.config_split.environment.yml file I still had the old blacklist and graylist keys instead of the keys that 2.x is using. Config export was expecting to find an array but because the key was missing, it gave the error.
The error was fixed by adding the correct keys to the config split configuration file:
complete_list: { }
partial_list: { }
We encountered the same issue in our multisite environment. We have had the default site working for over a year now without issues but the new multisite was experiencing this issue. It seems like Administrator role is not affected but basic editors are.
Clearing the cache solves the issue as expected. We are now waiting if it will be reported again.
+1 for this feature. We have encountered the issue several times now. It even doesn't necessarily involve several developers but a single developer might have hard time figuring out what the conflict with the structure data YAML file is.
We have used Fixed block content module in another project and it splits for example each block config into a separate file and we haven't had the same issue there.
I think it would make sense here also because each block, taxonomy and menu is a separate configuration in core also so you would have a linked structure file for it.
The patch from #5 does not seem to apply anymore against the latest alpha 3. Marking this as Needs work. I will test if the related issues could also solve the issue.
I can confirm that updating Field permissions module to 1.3.0 fixed the issue for us also.
This seems to fix the issue for us. Marking as RTBC.
Excellent. Thank you very much for the quick response.
We encountered the same issue also and it broke the content type view form completely with the following error:
Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/web/modules/contrib/field_formatter/src/Plugin/Field/FieldFormatter/FieldWrapperBase.php on line 194
The latest RC version of the module is quite old. Would it be possible to make at least a new RC release where this is fixed? 3.0.0-rc2 was released 16 December 2022.
True, sorry about that.
There is an older similar issue 📌 DomPDF vulnerability Fixed in PDF API where the requirement is more strict to make sure a safe version is installed.
The change is making sure it installs a safe version https://git.drupalcode.org/project/pdf_api/-/merge_requests/18/diffs.
I can also confirm that #30 solves the issue. We had a confusing list of duplicated content in the admin/content listing when we added an exposed filter for the Author to be able to find the content for certain user more easily.
This should be now ready for review.
The basic functionality works and it also adds support for custom iframe blocking if the needed data attributes are already available in the iframe. In this case the iframe blocking logic is skipped.
I also added context to all module translated strings because they were missing from all t() functions. This should be mentioned in the change log when we release the next version.
After this is merged we can continue with ✨ Allow the administrator to define the message and button text for blocking iframes Active . We need to decide how we can support the dynamic cookie category in the iframe functionality and custom message with translation support. Perhaps we can for example separate the general message that can be customized from the category information.
@maxilein You can get the patch file from the MR: https://git.drupalcode.org/project/field_group/-/merge_requests/44.patch
Note that it's always recommended to save the patch file in local repository and use it from there. The MR patch can change if new commits are added to it might break existing functionality and it's also a possible attack vector because someone could slip malicious code to the MR.
Just want to comment that glad this issue is now RTBC. We have been experiencing also mysterious situations where paragraphs are not rendered on the page. We originally installed this patch because had some cases where the Paragraph Library submodule was causing issues where it was rendering the same element in multiple places at the same time.
In the current project we have been having this issue, we don't have Paragraph library yet enabled but we installed this patch because the feature was planned to be implemented.
In our case we were also thinking the reason could be Quick node clone module which can also clone the same paragraph content multiple times.
In our case the symptom was that the paragraph content went missing from anonymous users but it was visible for logged in users. So it definitely seemed like a cache issue. The issue gets solved when you save the node again.
I am happy with the RTBC situation and I can report back if we still experience the issue with paragraphs with the latest patch. But I also want to point out that there might be edge cases that contrib modules are cloning or rendering the same element many times in different places (Paragraph library and Quick node clone for one). In Quick node clone there is an open issue 🐛 Nested paragraph support RTBC where the cloning doesn't revision the cloned parent paragraph correctly which in part might explain some edge case bugs.
We are currently using the patch from #155. I compared that patch to the latest MR and there seems to be just differences in tests.
@jhuhta Thanks for clarifying it up. I will see what we can do. We are in the process of testing different AI powered translation options and this module came up as a suitable candidate. We will see if we end up needing the feature in the current project and we can then contribute to submitting a patch.
We have encountered a similar report from our client. We have had the module installed for a couple of years now and no huge issues with it.
But recently we received a bug report where a content that should not be indexed in the search appeared there for a moment. Now it has again disappeared from the index. I wonder if there is some gap between the indexing process where the content might appear in the search results before it gets unindexed again?
I was also leaning towards some configuration issue or that the exclude checkbox would have been unchecked. I used the Diff-module to compare the content revisions and it seems that the Exclude entity checkbox has been on the whole time.
Our relevant versions are
Drupal core: 10.1.15
Search API: 1.29
Search API Solr: 4.3.0
I would personally want to migrate the setting to a select option where you can make only one selection. Form validation can of course also work but I vote we create a follow up ticket, I would make a new select option to use Google consent mode v1 or v2 and map the old setting to the new select value if it exists.
Created the first MR to add the missing consent types.
Fixed conflict and merged. Thanks @aelfendir.
HeikkiY → created an issue.
I can confirm that #175 works but #176 does not. We were previously using the patch from #171 and it doesn't work with core 10.2.