Only installing the Pathauto → module is removing this blocker and non-admin user can do the regular URL alias updates and creation. (But Core fix is recommended.)
The code ensures compatibility with environments where \Stringable might not be explicitly implemented or reliably checked. For example, if there are inconsistencies in extending \Stringable (e.g., in older or custom implementations), this safeguard ensures the return type is met.
By explicitly handling \Stringable compatibility, the fallback to TranslatableMarkup guarantees compliance with the method’s return signature even in edge cases.
While I acknowledge that the base class is expected to comply with the return type, the explicit check is intentional to ensure compatibility, clarity, and robustness in a dynamic and customizable system like Drupal.
To update the formatMultipleViolationsMessage() method to maintain compatibility with both older and newer versions of Drupal core, you can adjust the return type to \Stringable and handle the MarkupInterface type from the parent. Here’s the updated code:
protected function formatMultipleViolationsMessage(string $form_element_name, array $violations): Stringable {
$parent = parent::formatMultipleViolationsMessage($form_element_name, $violations);
if ($parent instanceof TranslatableMarkup) {
return $parent;
} else {
// phpcs:ignore Drupal.Semantics.FunctionT.NotLiteralString
return $this->t((string) $parent);
}
}This is a broader type that includes MarkupInterface, making it compatible with the newer core return type.
If your code references \Drupal\update\UpdateSettingsForm, make sure its formatMultipleViolationsMessage() method is updated with the same logic to maintain consistency.
1. Clarify and Strengthen the Backup Recommendation:
Solution: Make the backup recommendation clearer and more consistent across both pages.
- Automatic Update Page: Start with a clear and firm recommendation. For example, update the text to:
- "It is strongly recommended to back up your database and site before beginning the update process." (Consider making this bold for emphasis.)
- Ready to Update Page: Phrase this as a friendly reminder, mentioning that the update is imminent. Example:
- "The downloaded assets will be applied to your site in the next step. This action cannot be undone. Please ensure you have backed up your database and site before proceeding."
2. Ensure Consistent Language:
Solution: Standardize the language between the two pages. Both should use "back up your database and site" rather than varying the recommendation.
- Automatic Update Page: Update the text to say "back up your database and site" for consistency.
- Ready to Update Page: Likewise, update this page to consistently recommend backing up both the database and site.
3. Ensure Backup Recommendation for Both Manual and Automatic Updates:
Solution: Add a backup recommendation for automatically triggered updates (via cron).
- Automatic Update Process (via cron): Add a reminder to back up your database and site before automatic updates are triggered. This can be phrased as a part of the notification when the update is initiated automatically:
- "Before proceeding with the automatic update, ensure you have backed up your database and site."
4. Improve Text Layout for Better Readability:
Solution: Adjust the typography to improve the visual hierarchy and readability.
- Ready to Update Page: Make the first sentence ("Drupal core will be updated...") stand out by using regular typeface rather than the bold type. The important part about the backup recommendation should be integrated smoothly into the text, without overemphasizing one part.
- For example, revise the entire block like this:
- "Drupal core will be updated to 9.3.15. This step cannot be undone. It is strongly recommended that you back up your database and site before proceeding. If you cancel the update process, the downloaded assets will be removed and need to be re-downloaded."
To address the problem of language discrepancies in Drupal's configuration when using the admin interface in a language other than the default, a clear and user-friendly solution is required to prevent confusion and errors. Here’s a structured approach to achieve this:
Solution 1: Add a Warning Message in Admin Interface
A simple but effective approach would be to add a warning message or notification in the admin interface, particularly when the user is working in a language other than the default.
• Where to Place the Warning:
- On pages related to enabling modules, adding fields, and configuring translatable content.
- In the configuration settings related to language and content translation.
- When exporting configuration to remind users of potential language mismatches in the configuration.
• Example Warning Message:
o "You are currently editing configuration in a non-default language. This may result in inconsistent language settings when exporting configuration. It is recommended to use the default language for configuration changes."
• Contextual Help: Provide a link to documentation or a "Learn More" popup explaining why configuration changes should be done in the default language and how it impacts the exported configuration.
Solution 2: Force Configuration to Save in Default Language by Default
Modify the configuration flow so that by default, the system saves configuration in the default language. This can help mitigate language discrepancies in exported configurations.
• Changes to Implement:
o During installation or setup, clearly identify the default language.
o Provide an option during the configuration process to enforce saving settings in the default language, even if the admin interface is used in another language.
o Optionally, allow users to override this setting with a warning, but default to saving in the default language.
• User Flow:
o When configuring a module, field, or other settings that are translatable, a default language selector is shown, and the system should always default to this language when saving.
o Provide a setting to force configuration changes to be saved in the default language even if the user interface is set to another language.
Solution 3: Lock the Admin Language to the Default Language by Default
Another solution is to lock the admin interface to the default language by default and only allow the user to switch to another language with clear warnings about the potential risks involved.
• How it Works:
o Upon logging into the admin interface, Drupal detects the default language and presents a clear notification or banner that the admin interface is set to the default language.
o Allow users to change the admin language if needed, but warn them of potential risks if the configuration might not align with the default language.
o Provide a toggle or setting to switch back to the default language automatically for all configuration-related actions.
• Example:
o A setting can be added during setup that forces the admin interface to use the default language unless the user explicitly opts out. If the user switches to another language, a prominent warning or notification should appear.
o “Warning: You are editing the configuration in a language other than the default. Proceed with caution. Changes may not be applied correctly when exporting configuration.”
Solution 4: Provide Clear Distinction Between Content and Configuration
Users sometimes confuse content (which is language-dependent) with configuration (which should be language-neutral or based on the default language). A clear distinction between configuration and content in the admin interface would help alleviate confusion.
• Visual Cues:
o Introduce a visual distinction between content and configuration. For example, use different colors or labels to clearly indicate when a user is editing configuration as opposed to content.
o Use tooltips or inline documentation to guide users and remind them that configuration changes should generally be made in the default language.
• Label Configuration Screens Clearly:
o Add a prominent label or header in the configuration screens like “System Configuration (default language)” and “Content (language-dependent)” to make it clear which type of content they are working on.
o In the content settings pages, clearly label sections for translatable fields or language-dependent settings, as well as the default language for configuration.
Solution 5: Better Installer Flow with Language Clarity
Improve the installer process to make the default language explicit and to give users clear guidance about how language settings will affect configuration.
• Enhancements to Installer:
o During installation, have a step that clearly defines the default language and explains that configuration should be saved in this language.
o Offer the option to force configuration to always be saved in the default language and explain the implications of changing this setting.
• Example Prompt During Installation:
o "We’ve detected the default language as [Language]. Please confirm that configuration changes should always be saved in this language to avoid inconsistencies when exporting configuration."
o “Do you want to lock the admin interface to this language? This is recommended for consistency across your site configuration.”
Solution 6: Documentation and Educational Resources
Provide clear documentation and educational resources for administrators and site builders on the topic of configuration and language settings.
• Educational Popups:
o When editing configuration, provide a small educational popup or tooltip that reminds users of the implications of making changes in a non-default language.