When testing the scenario of deleting a translation and receiving the error, giving the browser a refresh, after encountering the error and pressing continue (on form resubmission) will result in the other translation being deleted as well.
So for example for a node with nid 4 on a EN/NL site with domain detection enabled.....
- * https://en.d10-ml.ddev.site/node/add/page and save
- * Go to https://en.d10-ml.ddev.site/node/4/translations
- * Press add under NL. You will go to https://nl.d10-ml.ddev.site/node/4/translations/add/en/nl
- * Add NL translation and save
- * Go to https://en.d10-ml.ddev.site/node/4/translations
- * Delete NL translation - You will go to https://nl.d10-ml.ddev.site/node/4/delete
- * Press "Delete dutch translation"
- * You will see "Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it."
- * The dutch translation is now deleted (check by going to https://en.d10-ml.ddev.site/node/4/translations in another browser tab, hit F5 to clear browser cache if you still see the dutch node)
- * Now go to the other browser tab with the error message and hit refresh of F5
- * Press "continue" on the popup "Confirm form resubmission"
- * Notice that https://en.d10-ml.ddev.site/node/4 does not exist and is also deleted.
This is probably logical because the second form submission goes to https://en.d10-ml.ddev.site/node/4/delete? But still it leads to data loss when a user perfoms these actions.
undersound3 → created an issue.
Thanks I tried increasing the memory earlier but even setting memory_limit = -1 is not helping.
Seems the difference is casuing this memory exhaustion. Using the same value for EN as NL makes the problem go away...
undersound3 → created an issue.
This issue seems to be an exact copy of https://www.drupal.org/project/facets/issues/3411582 🐛 facets not working when cache enabled Active . Please remove
@DamienMcKenna that command lives in the search_api_solr_admin module. Perhaps it was not enabled?
Perhaps a section can be made in the readme specifically titled "Updating configuration" or "Updating" to let this process stand out more in the docs or the current section "Updating Solr" can be enriched with a text that sumps up all the scenarios when to do update the config (and how to do this)
For example...
Updating configuration
--------------------------------
You need to update your config in the following scenarios:
1. When you update the module to a newer version
2. When you add a language
2. When you a add a custom Solr Field Type
Perhaps we can also mention how to deal with custom changes in relation to updating and version control?
Let's say I have added some synonyms to synonyms_nl.txt and are saving my custom config in a folder in the repo (e.g. config/solr) to use that later on in the deployment cycle. As far I understand when I run 'drush solr-gsc' I get a fresh copy of synonyms_nl.txt which does not include my custom additions.
undersound3 → created an issue.
undersound3 → created an issue.
Does anybody know if there is a problem to be expected when switching from Paragraphs (legacy) to Paragraphs (stable) widget for now.
We want to migrate later on by using the patch/functionality from this issue but for now sync all paragraph field widgets for consistency sake.
Also I have read that support for the legacy widget will end eventually. See https://www.drupal.org/project/paragraphs/issues/3331203#comment-15212442 🐛 Core 9.5.0 causing broken-looking styling (Legacy widget, with Seven) Fixed
I just tested this a bit more on Drupal 9.5.10 and Rest Menu Items 3.0.x and things seem to work fine.
I have noticed though the following though...
Adding a language next to the default language (in this example I use EN as the default language and NL as the second language) does not necessarily mean that /en/api/menu_items/{menu_name} is working. I was getting the same error as mentioned in https://www.drupal.org/project/rest_menu_items/issues/2893872#comment-13... ✨ Add language support Closed: works as designed
{
"message": "No route found for \"GET \/en\/api\/menu_items\/footer\""
}
The following links were working though
/api/menu_items/{menu_name}
/nl/api/menu_items/{menu_name}
It wasn't until I switched the default language from EN to NL that /en/api/menu_items/{menu_name} started to work.
Obviously because NL was now the default language. Then I switched the default language back to EN and all of the following links started to work.
/api/menu_items/{menu_name}
/en/api/menu_items/{menu_name}
/nl/api/menu_items/{menu_name}
So it seems changing the default language seems to change the endpoints available.
Besided this I am getting aliases returned like this:
EN
https://drupal9.ddev.site/api/menu_items/footer?_format=json
[
{
key: "04e0718c-2c0e-4f2c-a8d8-0b12cf5dee55",
title: "Article #1 EN",
description: null,
uri: "node/1",
alias: "article-1",
external: false,
absolute: "https://drupal9.ddev.site/en/article-1",
relative: "/en/article-1",
existing: true,
weight: "0",
expanded: false,
enabled: true,
uuid: "f54a223e-4682-470c-8c59-d70dd54c28c5",
options: [ ]
},
{
key: "d217e9f6-f1d2-4371-8d14-c883f7b0c78e",
title: "Article #2 EN - non translated",
description: null,
uri: "node/2",
alias: "article-2-non-translated",
external: false,
absolute: "https://drupal9.ddev.site/en/article-2-non-translated",
relative: "/en/article-2-non-translated",
existing: true,
weight: "0",
expanded: false,
enabled: true,
uuid: "bea04fee-d11a-4818-8a8c-a95f08dc4330",
options: [ ]
},
{
key: "18c38a8b-da0d-448d-834d-fd9eb2de911d",
title: "Front",
description: null,
uri: "",
alias: "",
external: false,
absolute: "https://drupal9.ddev.site/en",
relative: "/en",
existing: true,
weight: "0",
expanded: false,
enabled: true,
uuid: null,
options: [ ]
},
{
key: "c32a9f45-77f1-4112-9cfb-3d077d2d93ea",
title: "Untranslated menu item",
description: null,
uri: "node/1",
alias: "article-1",
external: false,
absolute: "https://drupal9.ddev.site/en/article-1",
relative: "/en/article-1",
existing: true,
weight: "0",
expanded: false,
enabled: true,
uuid: "f54a223e-4682-470c-8c59-d70dd54c28c5",
options: [ ]
}
]
NL
https://drupal9.ddev.site/nl/api/menu_items/footer?_format=json
[
{
key: "04e0718c-2c0e-4f2c-a8d8-0b12cf5dee55",
title: "Article #1 NL",
description: null,
uri: "node/1",
alias: "article-1",
external: false,
absolute: "https://drupal9.ddev.site/nl/article-1",
relative: "/nl/article-1",
existing: true,
weight: "0",
expanded: false,
enabled: true,
uuid: "f54a223e-4682-470c-8c59-d70dd54c28c5",
options: [ ]
},
{
key: "d217e9f6-f1d2-4371-8d14-c883f7b0c78e",
title: "Article #2 EN - non translated",
description: null,
uri: "node/2",
alias: "node/2",
external: false,
absolute: "https://drupal9.ddev.site/nl/node/2",
relative: "/nl/node/2",
existing: true,
weight: "0",
expanded: false,
enabled: true,
uuid: "bea04fee-d11a-4818-8a8c-a95f08dc4330",
options: [ ]
},
{
key: "18c38a8b-da0d-448d-834d-fd9eb2de911d",
title: "Front",
description: null,
uri: "",
alias: "",
external: false,
absolute: "https://drupal9.ddev.site/nl",
relative: "/nl",
existing: true,
weight: "0",
expanded: false,
enabled: true,
uuid: null,
options: [ ]
},
{
key: "c32a9f45-77f1-4112-9cfb-3d077d2d93ea",
title: "Untranslated menu item",
description: null,
uri: "node/1",
alias: "article-1",
external: false,
absolute: "https://drupal9.ddev.site/nl/article-1",
relative: "/nl/article-1",
existing: true,
weight: "0",
expanded: false,
enabled: true,
uuid: "f54a223e-4682-470c-8c59-d70dd54c28c5",
options: [ ]
}
]
I do see however that when a node has no translation the internal path is returned and not the alias of the node of the default language.
I guess we need to decide if that is the responsibility of this module or drupal core?
Thanks for the patch!
Works here on drupal 9.5.11 and yoast_seo 8.x-2.0-alpha10
FYI
After upgrading from drupal 9.5.10 to 10.1.3 facet items were not showing up anymore in the Facet Summary block (not sure if related but writing down here for completeness sake).
I was then updating this module from 2.0.6 to 3.0.0-beta1 to see if it fixed that. It did. But then pagination in a "Media Browser Entity" browser did not work anymore. Applying this patch fixed that problem and now pagination works again.
undersound3 → created an issue.
@smustgrave file permissions are indeed the most obvious. Thanks for clarifying and thanks @greggles for making it more clear on the project page.
undersound3 → created an issue.
Arrived here searching for this error.
We experienced this error on admin/content
Drupal 7.97
PHP 8.0.30
Aplying the patch fixed the error.
For those that are experiencing below warnings here is a small adjustment to the patch in #7
Warning: Undefined array key "#type" in _maxlength_children() (line 176 of /var/www/html/web/sites/all/modules/contrib/maxlength/maxlength.module).
Patch for 2.0-alpha2
Does anybody know if there is something like this available for 6.x or can we use this patch as a base to create a patch for the 6.x version?
@DieterHolvoet thanks for this.
I am testing this currently and I am noticing the following behaviour when applying https://git.drupalcode.org/project/paragraphs_asymmetric_translation_wid... to the 1.1 version of this module.
I have a site with two languages NL (default) and EN.
After running the migration via drush cim NL content is showing up in the the paragraphs on the english version of the node. I am expecting to see EN content here.
When applying https://www.drupal.org/files/issues/2022-12-23/2992777-paragraphs_asymme... → I am not experiencing this behaviour and things are working correctly. At least on the "frontend" part of things as I understand from your comment that new paragraphs/content was saved differently then it did until your fixes.
It seems is has something to do with this elseif statement because bringing that back in shows english content correctly within paragraphs on an english node version.
elseif ($paragraphs_entity->hasTranslation($langcode)) {
// If host entity translation refers to same paragraph entity, then
// fetch that instead. This is possible if Classic widget has been
// changed to Asymmetric widget with existing content.
$paragraphs_entity = $paragraphs_entity->getTranslation($langcode);
}
Also I am wondering how to verify if this new functionality https://git.drupalcode.org/project/paragraphs_asymmetric_translation_wid... is working as it should. Should the default_langcode of the, in my case english version of the paragraph, be set to 1?