Hi @phpsubbarao,
Sorry, I opened MR, instead of updating the patch. The automated test was failing as it was expecting ckeditor config for spellcheck to be FALSE. I have updated the test case and raised MR for the same.
mehul.gada → made their first commit to this issue’s fork.
Hi @COBadger,
I guess we don't need to replace URL placeholder from ":url" to "%url". If we use "%variable", it is also getting processed by placeholderEscape() and that adds "" tag around the placeholder variable. For replacing URL, we should specifically use ":variable", so that it is filtered for harmful URL protocol and at that same time "" tag is not added. In our case, the URL variable is used within the anchor tag in the warning text and if we use "%url", it is getting surrounded by "" tag, causing the anchor tag HTML to break (see attached screenshot) and accordingly breaking the unit test. So, I guess we should close this issue without fixing it.
Ref - https://chromatichq.com/insights/drupal-code-standards-t-function/
Since MR should not be raised for the 9.4.x branch, I have rerolled the patch for 9.5.x and accordingly raised MR https://git.drupalcode.org/project/drupal/-/merge_requests/3706
mehul.gada → made their first commit to this issue’s fork.
Here is the patch to check if the private files exists or not and accordingly set the default value.
mehul.gada → made their first commit to this issue’s fork.
PHP warnings fixed as mentioned in Issue statement.
mehul.gada → made their first commit to this issue’s fork.
Hi @NicolasGraph,
Could you please provide some more information? I tried to replicate the issue on my local environment with PHP 8.0.8 and it was not replicating. The installation went through smoothly with default optional modules selected and the site was working absolutely fine post-installation.
Hi @summit
Please ignore the merge request. This issue is a duplicate of https://www.drupal.org/project/ctools/issues/3336655 📌 PHP 8.2: ${var} in strings is deprecated Fixed and it is already fixed.
mehul.gada → made their first commit to this issue’s fork.
Hi elimw,
The next release of this module will have menu creation functionality (on each context creation/update) will be removed as part of Issue https://www.drupal.org/project/context/issues/3280556 → . So you can either wait for the next stable release or apply the attached simple patch. Sorry, I could not raise MR as the branch created from 8.x-4.x already has the menu creation code removed.
Hi vitaliych,
The issue is neither with the Admin Toolbar menu nor caching issue. It is an issue with the Context menu. When the machine name for given context is changed, it is adding a new menu instead of updating an existing one and a bug report - https://www.drupal.org/project/context/issues/3284359 🐛 Renaming context does not update admin menu Needs review is already open for the same. Let me push a quick fix there and you can close this request.
Thanks
mehul.gada → made their first commit to this issue’s fork.
Usually, the error mentioned in the issue will not occur, unless the Redirect URL at logout is set empty somehow. To fix this, I have added a small patch to pass /user/login as the default redirect URL if it is set to empty in the configuration. MR for the same is raised for review.
mehul.gada → made their first commit to this issue’s fork.
Hi @mornel,
You need to add a date field (authored on or changed for the node or similar other entity) in your search index. Without that, you can't decide how to boost the date field. Once you add any of these date fields, you see them under "processor settings" and the PHP warnings will be gone away.
Hi @artatac
"tippy" is not a standard HTML tag. I guess you are trying to use "tippy.js" library to create nice-looking tooltips and it works on the specific class ("tippy-tooltip-text" in your case). So, why not use a span tag instead?
Drupal is doing XSS filtering to skip harmful text and that's why tippy tag is getting stripped. This tag list is maintained in the core file - web/core/lib/Drupal/Component/Utility/Xss.php. Modifying this file is not recommended as you need to patch it. Alternatively, you can create a twig file in your custom theme to modify the field output. You can create a specific twig file with the name views-view-field--[view_machine_name]--[page OR block machine_name]--[field-machine_name].html.twig and add your custom HTML tags. But the best option will be to use the span tag instead as that would mean no custom code and not patching.
The given module is using YAML parser to parse the token. Till Symfony 5.0 version, YAML 1.1 specifications were used which was converting strings starting with 0 to octal numbers and strings starting with 0x to hexadecimal numbers. From Symfony 5.1 onwards, the representation of the octal number changed to "0o..." and that will fix the issue mentioned here.
So, we have 2 options here:
- Upgrade to Drupal 10 as it uses a higher version of Symfony (not possible for all web projects and needs more efforts)
- While using a token in field config, enclose it in quotes as mentioned in comment #3 🐛 Leading Zero in URL Query Causes Error Active to fix the issue.