Same here with a D10.5. No additional settings appear either in menu edit or in block layer.
Patch #3 worked and didn't work. Let me explain: my case is a site in French (fr, default), English (en) and German (de), with prefix detection of the interface language. Although the site's default language is French, the admin language is English. I have the problem of saving the configuration. My workaround was to export single configuration, change the values (max width and height) and reimport the single configuration.
After installing the patch, First step I changed my values in the default language (fr). It didn't save. Then I noticed there was a new tab to translate the colorbox config. I changed the values in the English language and this time values were saved and new values were available in all three languages. So, I can say patch worked.
As I wasn't sure if the translation tab was the fact of the patch or if it was there before applying it, I decided to remove the patch and see what happens (I was expecting the tabs were from the original module and wanted to play with them and see the difference of behavior with the patch). After removing the patch and clearing caches the translation tabs disappeared, I so had confirmation that the translation tab was installed by the patch. But now, without the patch, the settings are saved! It is like installing and removing the patch, it repaired the config saving problem. Strange... I suspect this operation changed something in the configuration storage language but what ?
This was pretty easy to do. Here is the code if someone wants to make a patch. Just put this in the render function before the $element array. For a full solution, we'll also have to create a new field 'login_label' in the settings form to hold the 'Login to add your @bundle_label' chain int the way the 'Add a new entry' is done in defineOptions() and buildOptionsForm(). For those who can't wait for a patch, the same can be achieved in hook_preprocess_views_view: filter on $variables['display_id'] and work the $variables['header']['add_content_by_bundle'] array.
// Start new code
if (!$access) {
$bundle_info = \Drupal::service("entity_type.bundle.info")->getBundleInfo($entity_type->id());
$bundle_label = $bundle_info[$bundle_type]['label'];
$this->options['label'] = $this->t('Login to add your @bundle_label', ['@bundle_label' => $bundle_label]);
$url = new Url('user.login', [], ['query' => $params]);
$access = $this->accessManager->checkNamedRoute('user.login', [], $account);
}
// End of new code
// Assemble elements into a link render array.
$element = [
'#type' => 'link',
'#title' => $this->options['label'],
'#url' => $url,
'#options' => [
'attributes' => ['class' => $classes],
],
'#access' => $access,
];
Thank you for your reply. It is fantastic what we can do with blazy hooks. The thing is that we have no way of knowing if colorbox is active or not (mobile detected or not) unless we dig into the javascript. I tried setting a breakpoint in Slick/Splide optionset at the same width as the Colorbox mobile detection setting, but again I don't think we can know which is the active breakpoint as it is handled on the browser side. I'm wondering if the solution could not be CSS-breakpoints in order to show/hide the colorbox div.
erwangel → created an issue.
Sorry for the long post that follows but I found this is the most mature issue resolution and I hope my test and comments may contribute to further clarify the problem and improve its solution.
It seems that menus are displayed in their original or interface language or content language according to their provenance (how where they generated). In some cases this can lead to mixture of translated and untranslated menus. But the problem is not only in menus, displaying of block titles, field labels can also create a language confusion.
I am of the opinion that switching content language should not affect the interface (menus, blocks titles and content, any links, etc.) and only change the main content (node or views listing), not event the entire page content (related blocks and other extra content), i.e. only change what is called the "Main page content" in block layout. This opinion because users may be able to read an article in various languages but have a preferred language for the user interface and the rest of the content. They just occasionally prefer read an article in a language different of their usual language. An American-spanish-speaken citizen may want its site in English but if an article is published in both English and Spanish he may prefer read the article in Spanish without seen the entire site switched in Spanish. I think that is the main reason for separating interface and content translation.
Now here my observations on a D10.4 installation before applying the patch.
Configuration: fr (french default), en (English), de (Deutsch - German)
Interface detection: from url (path prefix)
Content detection: content language (request parameter 'language_content_entity')
In order to avoid fastidious repetitions, I defined tree types of menus:
- TYPE 1: menu links provided by the Standard module (ex. "Home" link) or by Views or by Taxonomy Menu module (you can not edit nor translate them in "admin/structure/menu")
- TYPE 2: menu links provided by nodes ("Provide a menu link" option in node's edit page and you can also edit/translate in "admin/structure/menu") or empty links ( to display link text only)
- TYPE 3: any other menus manually created and translated in "admin/structure/menu" either with internal path or a node link they
Cases:
* Interface FR (default), no request param
- url: /page-fr-url (aliased on node's title) => content, content field labels, menus, blocks in FR as expected
* Interface FR (default), language_content_entity=FR
- url: /page-fr-url?language_content_entity=fr => same as above as expected
* Interface FR, language_content_entity=EN (or DE)
- url: /page-fr-url?language_content_entity=en
- Content is displayed in content language (EN), field labels too, block title and content are in interface language (FR)
- Menus TYPE 1 titles: respect the interface language (fr)
- Menus TYPE 2 titles: they follow the content language (en).
- Menus TYPE 3 titles: they follow the content language (en)
- All Menu urls are build according to the interface language (fr is default so no prefix in url)
- Local task tabs respect the Interface language (fr)
As Result: A confusing mixture of menus translated in one or other language!
* Interface language EN, no request param
- url: /en/page-en-url (aliased on node's title)
- Content shows in default FR (content lang) but field labels in EN! (interface lang), block titles in interface language EN
- Menus TYPE 1 respect the interface language (EN)
- Menus TYPE 2 and 3 are in... default FR! even when both the menu text the linked page have a translation in the current interface language
- All Menu urls are build according to the interface language (/en/___)
- Local tasks respect interface (EN)
--- Note 1: In untranslatable and in untranslated nodes, same behavior as above (mixed translations)
--- Note 2: In Views pages, all menu types are displayed as expected in the interface language
Conclusion: it is like the lack of language_content_entity parameter has a fallback to the default content language.There may be some logic here too but ths leads to unexpected result: having make no choice about content language one could expect that the entire page would be in the interface chosen language.
* Interface language EN, language_content_entity=FR (default)
- url: /en/page-en-url?language_content_entity=fr => Same as with no request parameter
* Interface language EN, language_content_entity=EN
- url: /en/page-en-url?language_content_entity=en => everything is in English
* Interface language EN, language_content_entity=DE (default FR language is not implied in interface nor in content)
- url: /en/page-de-url?language_content_entity=de
- Content displays in the content language (DE), block titles are in interface language EN even those placed inside content with layour builder (I think they should be consistent with the rest of node's content, i.e. have the content language DE)
- Menus TYPE 1 respect the interface language (EN)
- Menus TYPE 2 and 3 follow the content language (DE)
- All Menu urls are build according to the interface language (/en/___)
- Local tasks respect interface (EN)
Conclusion
There is no validation of language_content_entity's value at least from user's point of view. You can set manually whatever you want, numbers, letters, special characters, you never get an error message.
In views content (pages and blocks): In views you have different choices for the Rendering Language, but titles will display according to the interface language.
Content blocks:
Added on a page with block layout (/admin/structure/block): title in interface language, content in content language.
Added in a node with layout builder (/node/nid/layout): no way to translate the title, content in content language
In node's full mode: title and content they display in the content language but field labels and views blocks inserted with layout builder are in the interface language. If I a am able to understand the content in one language I am able to understand the fields labels and the block titles too no? Are Field labels and block titles part of the interface or do they belong to the content ? (I am for the second option)
Menus: titles obey to the interface language if links were generated by a module, but they obey to the content language if they were generated by a node or "by hand". In any case, the underlying url is build according to the interface language. So you can have a link whose text is in German but the url is the English one. Once you click it the interface will switch to English. Not necessarily what is desired.
What can we do ?
I know there have been long discussions about content and interface translation. Looking to the current situation and the several patches here and there that try to resolve one or an other problem, It doesn't seem like it clarified anything. I think we have to radically simplify and consider that
1) Only menus, action links and buttons are part of the interface and they should behave according to the interfae language regardless their provenance.
2) Block title and Field label's function is to announce what follows, i.e. content. So they should be considered as content and display according to the content language
3) Have the option to apply content translation only to what is called the "Main page content" in block layout or to the entire page
4) Menu link titles and underlying urls should be language complaints
4) Verify that language_content_entity value validates against the available language, otherwise throw an error
MR!3 worked for me on Drupal 10.4.7 + forum 1.0.2 and forum names (Taxonomy terms) appear in the right language.
However topic titles still appear in the original/posted language. This has for effect to user to loose his interface language. My use case is to have forum/taxonomy terms translated; forum nodes are not translated but author can chose the content language.
Let's say we have lang1 as default language and lang2 as second language code.
Whatever the interface language is, topics are listed as follows:
Forum title is displayed in the interface language (after applying the patch, now it works as expected)
Topic 1 published in default language has aliased url1: forum/the_topic_1_title
Topic 2 published in lang2 has aliased url2: lang2/forum/the_topic2_title
If a user navigates the site with the default language and clicks on topic 2 title (url2) all his interface language will switch to the lang2.
Same if he uses lang 2 interface and he clicks on url1, his interface will switch to lang1.
This is because interface detection is done from url's lang_code which I think is the most used case.
I think the correct display of topics listing should be:
If interface language is default (lang1)
Topic 1 published in default language has aliased url1: forum/the_topic_1_title
Topic 2 published in lang2 has unaliased url2: /node/nid2
If interface language is lang2
Topic 1 published in default language has unaliased url1: /lang2/node/nid1
Topic 2 published in lang2 has aliased url2: /lang2 /forum/the_topic_2_title
erwangel → created an issue.
This issue is still present in current version. Although setting a boolean field on/off to show/hide office_hours field works as expected in node's edit form, this has no effect on display modes.
As a temporary workaround I used hook_node_view to test the boolean field and unset the office_hours field when boolean is null.
Thanks to cptX (#58), I have no more "page not found" errors. My site is multilingual but comments translation is not enabled. It was a disaster for SEO as every permalink was giving a "page not found" when not in the default interface language. I don't see a solution for this in the last patch (#62).
The function on404(ExceptionEvent $event) states that it "Handles 404 errors specifically for quiz-related routes."
Or, no test is done on routes. In result dblogs are plenty of 'Caught 404 exception.' thrown by $this->getLogger('quiz_subscriber')->warning('Caught 404 exception.'); on every 404. Please see the function on403() route tests and apply accordingly to on404().
Indeed, I'm using the latest 10 stable version (10.4.7). I changed the version in issue's settings.
erwangel → created an issue.
Also I would be nice to set the link in a container so we can theme it easier.
// Assemble elements into a link render array.
$element = [
'#type' => 'link',
'#title' => $this->options['label'],
'#url' => $url,
'#options' => [
'attributes' => ['class' => $classes],
],
// Add wrapper
'#prefix' => '<div class="$some_classes">,
'#suffix' => '</div>',
//
'#access' => $access,
];
erwangel → created an issue. See original summary → .
erwangel → created an issue.
erwangel → created an issue.
erwangel → created an issue.
MR!15 worked for me too on Drupal 10.4.4 with Custom breadcrumbs 1.1.2. Thank you. Indeed you have to create a custom breadcrumb for each language and there is no fallback mechanism (by default it will use the Drupal breadcrumb).
@godotislate I attached the yml file with the field.storage.node.myfield in its default language (fr). I added the translations of each value so the file is not directly importable as config.
Error message "Value field is required" still present after patch with MR!11000 over Drupal 10.4.4. My field was inherited after migration. It is a translatable field on a multilanguage site and the error occurs when I uncheck the "Users may translate this field" checkbox, and, indeed, in "Allowed values" there is "0" key.
Perhaps this is the tutorial of the wrong link above
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
Anyway I hope this helps some who come here and get trouble with the mandclu's message #2.
That said, I agree with cassio #3, the error message after drush enabling the starter kit is not clear enough. What has been altered by the installation and what not ? Checking the modules list in admin/modules we can see that the module wasn't installed but the dependency module "add_content_by_bundle" it was installed. I don't know what the consequences will be of uninstalling it.
Yes, the closest issue I found is the one reported in "related issues" but as this issue summarizes several other related issues I found it hard to follow it. That's why I created a new one focusing to just one point: comment dispaly with the interface language change. As for the Drupal version I thought we had to report the version in use, not the version where changes are made on. But I understand your the backporting logic.
erwangel → created an issue.
Thank you sidgrafix (#3). Updating symfony/cache first permitted to update the rest of drupal. No issues noticed after that while generating Video Thumbnails.
erwangel → created an issue.
if (empty($vocs)) {
$query = $this->entityTypeManager()
->getStorage('taxonomy_vocabulary')
->accessCheck(FALSE)
->getQuery();
Should be
if (empty($vocs)) {
$query = $this->entityTypeManager()
->getStorage('taxonomy_vocabulary')
->getQuery()
->accessCheck(FALSE);
Otherwise you get "Call to undefined method Drupal\taxonomy\VocabularyStorage::accessCheck"....
This MR worked for me. I don't have the "Only one 'enable_page_level_ads' allowed per page" error any more.
I now have this Deprecated function: urldecode(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\adsense\Controller\CseResultsController->display() (line 77 of /path_to_site/web/modules/contrib/adsense/src/Controller/CseResultsController.php). Not sure it is related to the MR but I haven't noticed this before.
erwangel → created an issue.
I tried the patch from #25 on D10.3.10. Patch applies but does not work.
Sorry to reopen this but I find this wording very confusing: To add a translation, you must modify the configuration. Which configuration ? I had to check all kind of settings/configurations, in structure (content type, content type field), in settings (region and languages, content language and translation, configuration translation), in module settings (I faced this problem while translating meta settings with metatag module) etc., before I realize that I just had to change something in a field of the present form!
So I suggest to change this message to To add a translation, you must modify at least a field on this form.
erwangel → created an issue.
erwangel → created an issue.
Don't worry about my previous (#7) message. Composer reacted this way because I had manually modified a file to resolve the "parent url not translated issue" ( https://www.drupal.org/project/media_parent_entity_link/issues/3316244 🐛 Generated URL of parent entity is not translated Postponed: needs info )
8x.1.3 works now with responsive images. Thank you for the quick fix!
I had some trouble with composer require 'drupal/media_parent_entity_link:^1.3' who asked to Discard changes [y,n,v,d,s,?]? especially when the composer help is nos so helpful: should I "discard changes and apply the update" or "stash changes and try to reapply them after the update" ? I answered yes to the first option but if such question may be useful with "composer update" I think we should avoid this question with "composer require" which is supposed to download the entire project over the old version.
erwangel → created an issue.
Tested #22 on Drupal 10.3.6. Patch applied and everything looks okay.
Thank you. I've seen you released a new version so I updated and everything looks good nnow.
erwangel → created an issue.
The error still occurs when formatting media entities with colorbox. In my case media field in views.
Warning: Undefined array key "#entity_type" in Drupal\colorbox\Plugin\Field\FieldFormatter\ColorboxEntityReferenceFormatter->settingsForm() (line 213 of /path_to_site/modules/contrib/colorbox/src/Plugin/Field/FieldFormatter/ColorboxEntityReferenceFormatter.php).
I'm still getting this error when editing remote video type (admin/structure/media/manage/remote_video)
Deprecated function: Calling static trait method Drupal\oembed_providers\Traits\HelperTrait::disabledProviderSecurityWarning is deprecated, it should only be called on a class using the trait in oembed_providers_form_media_type_edit_form_alter() (line 61 of /path_to_site/modules/contrib/oembed_providers/oembed_providers.module).
Using: oEmbed Providers 2.2.0, Drupal core 10.3.6 , php 8.3.12
erwangel → created an issue.
Sorry, in the above 1st case it was my fault, I had [view:total-rows] instead of [view:page-count]. So the problem is that [view:page-count] displays [view:current-page] + 1 instead of the 'The total page count'.
Other info that may be of interest: if I use Header > Global > Result summary tokens "@current_page -- the current page number" and "@page_count -- the total page count", they display correctly.
I applied the MR. [view:current-page] seems to be correct now. [view:page-count] gives inconsistent results.
- On a view with a total of two pages, it gives (mini pager)
It looks like there is a relation between the items/page setting and the displayed 'page-count'
[items per page 16]
first page 1/17 (1 + 16 ?)
second page 2 /26 (16+9 ?)
[items per page 10]
1st page: 1/11 (1 + 10)
2nd page: 2/21 (11+10)
- On another view with a total of 4 pages, it displays (full pager)
1st page: 1/2
2nd page: 2/3
3rd page: 3/4
and so on
- Same as previous with another view with 576 page (same behavior with full and mini pager)
1/2, 2/3, 3/4, ..., 574/575, 575/576
I agree with Vasike. I'm using this almost daily. Very useful to update nodes between development/stage/live sites, especially when one uses content nodes as landing pages with layout_builder and its settings accordingly.
No more have had this problem since 3.0.3
Patch worked for me.
erwangel → created an issue.
erwangel → created an issue.
erwangel → created an issue.
erwangel → created an issue.
I know this is an old tree but I think it's time to wake it up. As the patch is for 7.x which comes to end of life, I changed version to 2.0. Any chance to see this feature ported to views_infinite_scroll 2.0 (Drupal > 10) ? Combining infinite scroll and manual load link is a really useful feature especially for sites having a lot of pages and could complete the "Initially load all pages up to the requested page" option which can lead to page crash if the requested page is a high number.
erwangel → created an issue.
I came to the same error while uninstalling the deprecated module (in D10.3.1) layout_builder_expose_all_field_blocks with drush pm:uninstall.
TypeError: Cannot assign Drupal\mail_login\AuthDecorator to property Drupal\security_review\Plugin\SecurityCheck\NamePasswords::$userAuth of type Drupal\user\UserAuthInterface in Drupal\security_review\Plugin\SecurityCheck\NamePasswords::create() (line 67 of /path_to_site/web/modules/contrib/security_review/src/Plugin/SecurityCheck/NamePasswords.php) #0 /path_to_site/web/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(21): Drupal\security_review\Plugin\SecurityCheck\NamePasswords::create()
Then while accessing admin/config/security-review: WSOD with the following
TypeError: Cannot assign Drupal\mail_login\AuthDecorator to property Drupal\security_review\Plugin\SecurityCheck\NamePasswords::$userAuth of type Drupal\user\UserAuthInterface in Drupal\security_review\Plugin\SecurityCheck\NamePasswords::create() (line 67 of modules/contrib/security_review/src/Plugin/SecurityCheck/NamePasswords.php).
No problem to access admin/config/people/mail-login
Rules has now a 4.0 version.
I followed vselivanov way (#5 of Closed #3463528: cannot install 6.0.0-alpha8 on drupal 10.3.1) but Quiz is still blocking any module update with composer. I am on Drupal 10.3.1 and I had previously updated Rules to the 4.0 branch. Here is what I get:
Problem 1
- Root composer.json requires drupal/quiz dev-3463528-cannot-install-6.0.0-alpha8, it is satisfiable by drupal/quiz[dev-3463528-cannot-install-6.0.0-alpha8] from vcs repo (git https://git.drupalcode.org/issue/quiz-3463528.git) but drupal/quiz[dev-4.x, dev-5.x, dev-6.x, dev-6.0.x, dev-7.0.x, 4.x-dev (alias of dev-4.x), 5.x-dev (alias of dev-5.x), 6.0.0-alpha1, ..., 6.x-dev (alias of dev-6.x), 7.0.x-dev (alias of dev-7.0.x)] from composer repo (https://packages.drupal.org/8) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
Same issue with "request_path" plugin after updating to D10.3.1. This is very blocking issue. We need a quick fix by the rules maintainer as downgrading to previous drupal version is not an option while this implies database looses, and moving to ECA not an option either when other modules rely on rules.
Patch doesn't apply on gin login 2.1.3. It was working before update.
Same problem here, with facet 3.0.0-beta1, search_api_solr 4.3.3 and drupal 10.2.6. Unable to save the form at admin/config/search/facets, getting wsod with the message above
Begging of the debug trace:
Drupal\facets\FacetListBuilder->submitForm()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 224)
Drupal\Core\Form\FormBuilder->getForm() (Line: 94)
Drupal\Core\Config\Entity\DraggableListBuilder->render() (Line: 23)
Drupal\Core\Entity\Controller\EntityListController->listing()
call_user_func_array() (Line: 123)
There are two sources relying to View Solr Search (page, and block), there is not so much to configure a part the Filter key. Fields are present by default in solr index but I see no way to add a facet block in block layer.
erwangel → created an issue.
The new dev looks fine. It works on all my media types. I had a look in your code and it seems the right approach. However it produces the default language links as pointed in issue 3316244 (url not translated) 🐛 Generated URL of parent entity is not translated Postponed: needs info . Have a look there; I commented it and proposed a working solution.
Also I noticed that $formatters are defined in InitialSettingsService as ['image', 'responsive_image']. I tested and it's okay with both of them, but what about other formatters that modules may add (I have blazy and colorbox, but also image_field_tokens, I don't know where the last comes from perhaps token module). I understand we can't plan ahead what formatters may be available there. Perhaps make it clear in documentation and presentation page that the module acts only on core 'image' and 'responsive_image'.
Blazy is widely used and it may be worth having some kind of compatibility. I tried to add 'blazy' in the $formatters array, the 'link to parent' option appeared in formatter's settings but it had no effect on display. I was not surprised as Blazy has it's own 'link to' called 'Media switcher' but it's mostly for switching to colorbox or other lightboxes supported by this module and anyhaw it lacks an option to 'link to the parent'.
I think we can consider the $sources issue fixed and if you think a solution to make the module compatible with other formaters is possible, perhaps open an other issue.
What about this ?
// ------ Added line ( 45 of last dev - media_parent_entity_link_media_view() )
// to get the current language then set the right translated link
$language = \Drupal::languageManager()->getCurrentLanguage();
foreach ($components as $componentkey => $component) {
if (!empty($component['third_party_settings']['media_parent_entity_link']['link_to_parent'])) {
if ($entity->_referringItem) {
if ($entity->_referringItem->getParent()) {
if ($entity->_referringItem->getParent()->getParent()) {
/* @var \Drupal\Core\Entity\EntityInterface $parententity */
if ($parententity = $entity->_referringItem->getParent()
->getParent()
->getValue()) {
if (!$parententity->isNew()) {
try {
// ------ Set the right translated link here ------
//$url = $parententity->toUrl();
$url = $parententity->toUrl('canonical', ['language' => $language]);
}
catch (Exception $exception) {
$url = FALSE;
}
if ($url) {
...
In some of my tests it gives the right links
No more warnings after applying #4 on ffs-2.0.x-dev and D10.2.6.
Confirmed working by me too.
"Private images" appeared as an extra media type in my settings after the upgrade from Drupal 7 to 9. And I think one has to create this type if he wants to store images in a Private file system path (see settings @ /admin/config/media/file-system). The image field (field_media_image) of media image type doesn't permit to chose the storage on uploading; you have to define it in settings (see @ /admin/structure/media/manage/image/fields/media.image.field_media_image). So if for some of your images you want a private storage (outside of site root) you have to define a new media type (p.e. private_images) and set the appropriate storage. You can still access private images for display through styles but not directly by their url.
I'll come back in a few days to test the new dev version. Thank you for making it.
Footnotes 4.0 works fine with no dependency to fakeobject. Not sure but, if I noticed well, it (or composer) even removes fakeobjects and Ckeditor 4 while updating from fn3 to 4
I tried MR 8 on a Drupal 10.2.6 which applied with no problem on ffs 2.0.x-dev. Using it on a media module image field (admin/content/media) as well as directly on a node with media field, the remote image is downloaded and listed in admin/content/files but when saving the media or the node I get:
Error: Object of class Drupal\media\Entity\MediaType could not be converted to string in Drupal\Component\Render\HtmlEscapedText->__construct() (line 31 of /path_to_site/web/core/lib/Drupal/Component/Render/HtmlEscapedText.php).
I can confirm #147: with smart_trim module enabled, try to format a body field in views using smart_trim formatter and you get the error.
The error also occurs with several other modules. I'm not using them but I landed on their issues while seeking a solution to this error message. I set some of them for reference in "relationships".
Thank you for the quick reply. So quick that I haven't seen the 3.0.4 was already up including the fix; I was trying to patch the 3.0.3 until composer shows me it was updating to 3.0.4! Everything is working perfectly now.
erwangel → created an issue.
erwangel → created an issue.
patch #30 worked for me (gin_login 2.0.4 on D core 10.2.5)
erwangel → created an issue.
erwangel → created an issue.
Although that's confusing for people wanting to install the module. You require it with composer as "front" but you have it to enable it with drush as "front_page". confusing and not very intuitive when drush tells you "Unable to install modules front due to missing modules front." I had to look in the modules's directory to realize that its "real" name was "front_page" and not "front". I think a quick fix will be useful so more people could install it and you could gain more feedback.
Still not working. With the suggested changes I was able to access the settings page but once I validated the form I got again a wsod and was logged out with a RuntimeException: Failed to start the session. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 173 of /path_to_site_root/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
Cache rebuild didn't help, it just permit access to the login page but once the credentials validated, white scren again. I had to uninstall the module to get the site back.
In the php logs Maximum execution time of 40 seconds exceeded and Allowed memory size exhausted as well as Warning: session_start(): Failed to decode session object. Session has been destroyed in Drupal logs which just explains the symphony session failure.
#4 worked for me, especially after watching the video (it helps to place the two js lines). Thanks pradipmodh13
Sorry, this was due to a drush&devel issue as I had upgraded devel just before.
See issue and solution @ https://github.com/drush-ops/drush/issues/5941
erwangel → created an issue.
I tested patch from marco.aresu (#10) and it works but page attachments remain in http. For the moment I used hook_page_attachments_alter to correct this with a str_replace("http:", "https:", $url) looping through
$attachments['#attached']['html_head_link'][1][0]['href']
I suppose the other patches don't correct this either.
erwangel → created an issue.
Problem encountered with user account fields on Drupal 10.2.4.
- Sites's default language is "fr", and two other languages activated "en" + "el"
- In admin's profile Language settings: "Site language" is "fr", "Administration pages language" is "en".
- Field settings "Users may translate this field" is "off"
The problem doesn't occur on all custom fields, but on newly created fields.
Newly created custom fields take original language "en"
Example creating a new "text plain" field. I add translations for "en" and "el"
As all my other fields have original language "fr" (they come from a D7 migration, D7 site wasn't multilingual and had default language "fr"). Wanting to have coherence through languages, I set the newly created field to original "fr" by executing
drush cset field.field.user.user.field_test_text langcode fr
drush cset field.storage.user.field_test_text langcode fr
Result: I have language original "fr" but "en" translation disappeared while "el" is preserved and is still here. I click to add translation "en". The modal window opens but when I save the translation I get
Status message
English translation was not added. To add a translation, you must modify the configuration
I understand that I have to edit the field (supposed to be now in original "fr") and so do I. After saving it, apparently it has been saved in "en" instead of "fr" because I get
Warning message
The configuration objects have different language codes so they cannot be translated:
field.field.user.user.field_test_text: fr
field.storage.user.field_test_text: en
Similar issue with metatag field.
- My conclusion is that whatever the original language is, when the field settings page is saved, drupal reverts the original language to the admin's "Administration pages language". There is some logic there although I could expect save a "fr" version when I edit a "fr" version. But what happens when your site has two admins with different setting for "Administration pages language" in their profile ? Field's original language will be reverted in the admin's language each time one edits the field and such erasing the other admin's translation.
- My recommendation: drupal should respect the field's original language even when the admin's language is different. Perhaps we should have a language selector for the original/default field language at field level like in multilingual content types in case one wants to change the original language instead of the drush "cset" command.
- That said, I don't understand why this happens only to newly created fields and not on old ones (those coming from the D7 migration).
The Ajax issue is still present on 10.2.4. In a custom module I have a very simple form, I simplified the ajax response to jus say "Hello", I switched to the default Olivero theme to be sure there is no interference with any other jquery or ajax call. This form was working with no problem on 10.1.2.
What I noticed in the console display of he error is that whatever the context of my form is used (and so producing variable ajax responses), it always has a "settings"; nul' in the response text. This quote after nul sounds suspect to me.
message: '\nAn AJAX HTTP error occurred.\nHTTP Result Code: 200\nDebugging information follows.\nPath: /path_to_the_calling_page?ajax_form=1\nStatusText: parsererror\n
ResponseText:
[
{"command":"update_build_id","old":"form-rjF70Nh6-v5uOijTmG0ZX6MHU8dDqTYYjLsJzf79Stk",
"new":"form-LHnajKIYq8szIGH0kkk-4vqtqzU_FsZmY2tLXUHqkqc"},
{
"command":"insert",
"method":"replaceWith",
"selector":"#my_ajax_form_element",
"data":"Hello",
"settings":nul'
name: "AjaxError"
stack: "@https://my_site.com/core/misc/ajax.js?v=10.2.4:196:32\n@https://my_site.com/core/misc/ajax.js?v=10.2.4:1916:3\n"
<prototype>: Error:
ajax.js:196:32 etc.
Extra line-breaks are mine to make it evident that there is a malformed json array, probably due tho the nul'.
I tried patch 10.2.1 from #35, it worked on the first call of the form (a click on submit button), but it didn't work on the next calls although there was no error displayed on the console.
Changed title to better reflect the issue
Hmm... A bit long the new description. Metatags are not only in content types; we found them in taxonomies, in users, in views, etc... Why not set a second permission ? Two permissions are not too much and could avoid long explanations to say what a permission does and what it does not. Example : the current permission "Who controls the per bundle Metatags settings. And a new one for "Who controls the Metatags content".
Metatags demands quite technical skills or at least knowing to what they serve. Or in a site with large audience, the presence of this field can be confusing to users. For example, in my site I have content types that are reserved to accredited authors. Okay they can be informed and trained on the usage of metatags, but other content types are open to all registered users while some other content types (like forums) are open to even anonymous users. We usually fill default metatags, eventually with tokens. We can not trust all these users that they will fill correctly the metatag fields.
Imagine you have a recipe type where users can post their preferred recipes (I hope you like cooking), SEO is important for this kind of content. You activate default metatags + Schema.org: Recipe. Users will then be faced with several dozens of metatags to fill. And if they search some help clicking the "available tokens" link they will really be... lost in translation.
I think that access of metatags to users should be only an option and by default users should not have access. Metatags is too powerful to leave in the hands of just anyone. I think metatags should behave by default like the other "system" fields (authored, promoted, sticky, alias, ...). I'm not sure but I think this was the case in Drupal 7, anyway I don't remember having to deal this kind of problem in D7.
I was confused by the "admin meta tags" permission scope. Your answer makes it much clearer now. Thank you for taking the time for this.
Damien, I understand that I have to manage permissions but as I wrote "the permission to 'administer meta tags' is set to admin only". Isn't that enough ? With this setting, I don't understand why any other registered user has access to field_metatag too. Secondly, if I remove the field from the user entity, admins will not have access any more. Tercio, what is the benefit of users managing metatags by themselves? Metatags are used mainly for SEO purpose, and seo is not a user's concern.
erwangel → created an issue.