@tra.duong
I confirm your clarification 'tra.duong'. Both options mentioned does not convey the correct meaning and functionality that the module presents. And yes the context strings has popular use cases which makes it not possible to translate it in other forms. Are we clear 'yivanov'? Thank you.
tsotoodeh → created an issue.
Kindly consider 🐛 Configuration language is not adjusted after changing the site default language Active as an issue of similar type not this very page.
Is the bug report the same as #3336594: Multilingual support of strings in second language website?
Not all the issues reported here discussed, but the root issue is the same.
tsotoodeh → created an issue.
tsotoodeh → created an issue.
tsotoodeh → created an issue.
That was too optimistic to mark this issue as fixed.
Out of misunderstanding! glad that the team members are aware and noticed maximpodorov.
In my opinion, documenting context strings and implementing a filter based on these type of string is a necessity. Without proper documentation finding context strings is not an easy task, indeed.
Such situation would lead to over defining what is already at hand, The example would be a date format strings required (l, F j, Y - H:i) in multilingual website, many people create and customize a new format without knowing that the format string could be translated.
Could not reproduce under 9.5.3 and 10.0.3. Should be considered fixed by now.
There is a workaround if someone is not good at coding. Try to work with Views, the Views functionality is very handy and there are plenty of documentation regarding its functions available.
My suggestion to you is to try working with contextual filters of view to get the path and use whatever field you are required to show on the view. For example, if you need to have a breadcrumb of a taxonomy term page title and also it's vocabulary try to add contextual filters of the mentioned elements and get the title fields for the display. As simple as that! Works for small environment and minimal use cases were customization of default breadcrumb is required.
By saying this I myself think the breadcrumb function of Drupal should be feature rich at its core.
Either you have configured https redirects and did not update your theme base paths or there are modified references in your theme which points to required elements with http protocol in place.
I recommend go through your CSS style sheets and theme yaml files and check the paths, in addition do not modify your network protocol configuration from different points. For example, if you back your site with a CDN adjust the protocols over there and make no changes in htaccess. This way you could troubleshoot the access issues from one point and with more visibility.
I have experienced the same situation.
The created directory does not accepts the configuration synchronization export file when trying to import it from the module UI. I could not yet managed to work with it under shared webhosting where there is no access to Drush or Composer.
Wonder what causes the issue and how to resolve it?! Although no error logged in the database or php error generated, The synchronization UI settings is unable to complete the extraction and deployment process. Currently my workaround to this is to manually deploy the configuration files when required, as a comparison reference. If someone knows what causes this behavior I would be glad to know. Kind regards
The db itself is now over 700 mb even though the site has very little content or use.
Hey body,
Make sure you have a working backup and then try check for error log first. Clearing log files misses you chances of knowing what causes the issue. I recommend start by disabling suspected/problematic modules first. It is possible in Drupal 7 from database. Try to check php errors in the root www directory.
Also make sure for production site log rotation policy and log level adjust in an appropriate level. It is probably a malfunction of a module or database logging at debug level.
Charchil Khandelwal made their first commit to this issue’s fork.
Thanks for the commit, let me know if assistance required.
Visit: Automated Drupal 10 compatibility fixes 📌 Automated Drupal 10 compatibility fixes Fixed
Same issue here. Saw similar errors and the admin menu was broken on some Webform Results Download pages. Switching to Jsqueeze resolved the issue.
Digging on an old issue! Make sure your hosting provider enabled the extensions, otherwise it is better to submit a complete issue with required steps to reproduce the issue.
There are a number of contrib solutions, and larger sites will using something at the WAF/CDN layer.
Totally agreed on this. In my point of view, from the perspective of webmaster banning an IP address is not a webmaster task but rather the task of network administration of the project, which as you mentioned should be done at the WAF or CDN level. The task itself, with today's technology could be easily done and resolved when appropriate credentials are provided.
In addition, from the security stand point it is best suited to prevent the malicious/intruder traffic stopped at the edge not the production environment. Also there are more means to mitigate bad actors.
I suggest, Drupal as a content management system be more focused on providing modules that offer best digital experience.
Would be glad if one of the maintainers pays attention and replay back on this. Thank you.
tsotoodeh → created an issue.
Well, Well, Well. Content security policy is inserted in htaccess at the root level. This approach helps with minimizing load request, centralizing security controls, and downsizing maintenance tasks, in comparison with adding meta tags to all pages via a third-party module or directly in theme files.
How are you implementing your CSP?
The backing evidence provided by Opera and if you are thinking of a false positive please feel free to set it up and reproduce the result. It is expected from the module to request all the content from a secure channel, no matter the security implementation approach of a site is? How do you agree on this?
Sure, there is a saying and there is a motivation for this post discussion!
Could you kindly have a look at the supporting evidence attached to this post.
The screenshot of content security policy section of browser which proves an issue of loading in-secure content.
Ops, deprecated code!
The patched module is now operational. well-done.
Update:
The Blocktab menu is required to be placed on the block layout to be functional as a menu item attribute. After adjusting the settings the blocktabs are displayed.
tsotoodeh → created an issue.
tsotoodeh → created an issue.
Here is to report back compatibility of the module with the applied D10 upgradability patches.
By applying the mentioned patches:
Automated Drupal 10 compatibility fixes
📌
Automated Drupal 10 compatibility fixes
Fixed
it seems that the module is portable under Drupal 10 by modifying core requirement, but blocktab fails to recognize as menu item attribute.
Well, as far as I can see the Drupal multilingual efforts has come a long way from the time that i18n or internationalization and localization modules was once were.
To be truly multilingual the configuration translation and interface translation should be taken a second thought.
Updated task description to account for the fact that when you switch default language back to English, nothing happens, existing config language is never updated.
As you said, the the language switch should be respected both in terms of configuration of the elements of the site and also the contents. An architectural plan should be devised for this task. Currently the configuration in consistency after switching the language from default language are many to account.
That's good answer. By all means it would be good to warn the user1 holder to configure and customize the Admin profile extensions by the time module is installed properly. That would make Drupal aspect, secure as designed in every step of its life cycle. Keep the good work.
Just remove the commas and you'll be fine
That's right!
Does not happen to came across a extension definition which accepts space as a separator!
Regarding the security concern of defining * as the accepted format for Drupal user1, what are the justification from the security perspective behind this decision? Could you evaluate on this matter? Thank you.
tsotoodeh → created an issue.
Is there any roadmap for Drupal 10?
tsotoodeh → created an issue.
Hey guys
Same issue observed in 9.5.3 and 10.0.3 versions. Any workaround yet?
The same issue observed in 9.5.x, it is a core design issue, I opened a multilingual support issue:
Multilingual support of strings in second language website
🐛
Multilingual support of strings in second language website
Closed: duplicate
I Tried using configuration update manager module to adjust langcode from default language to primary language, time consuming process! Although the content is translated but it would not shown correctly in second language. Same issue here!
Content creation is impossible with installed calendar system module, so I raised the priority level to critical.
tsotoodeh → created an issue.
The URL has /en in the screenshot and the interface is in English. I do not understand the nature of the bug.
Hey cilefen,
Sure the interface UI detection is working fine, but how about the translated string in which it is supposed to be an English string?
The page language is English but the Vocabulary titles are in Spanish! Same for menu items, views titles as well.
Please find attached the supporting evidence.
tsotoodeh → created an issue.
If all the function compatibility has been taken into account that would be awesome! Would give it a try soon.
tsotoodeh → created an issue.
Is there any plan to port the module for Drupal 10?
tsotoodeh → created an issue. See original summary → .
tsotoodeh → created an issue.