Hello, thank you for catching it and fixing it. would you be inerested in becoming this module's maintainer? the project is open for a new maintainer (I think it is an automated thing caused by lack of activity).
Stupid me did not even notice that when creating a new translation we can choose which of the other existing versions to use as a source. This means we don't have to change the original language.
However should you still wish to change the original langauge there is a way to do this by altering some node related information in the database (tested on a Drupal 9.3 instance)
in the tables node and node_revision set the langcode column value to the new original language.
in the tables node_field_revision and node_field_data there are entries for all translations of the node.
on the entry that is the current original language:
- set the column content_translation_source to any of the other existing translations
- set the column default_langcode to 0
on the entry that is new desired original language:
- set the column content_translation_source to und
- set the column default_langcode to 1
clear cache after the change to see it reflected in the drupal interface
Have you managed to find a way to do this? after some research your post is the only one mentioning this that i could find. at this point my best guess is that it *might* be feasible by manually editing node attributes in the database.
I have been trying to alter drupal regular contact form fields placeholders and sizes and did not manage to find a single post that is up to date on that topic. All the documentation (outside Drupal site and on the official site) does not mention what happened to the ability to edit in hook_form_alter things like:
$form["message"]['#attributes']["placeholder"]
I am guessing that some architectural change has happened after Drupal 7 that removed this possibility. Where has it been moved to? The form elements widgets in drupal 10 only allow incomplete customizations.
This message is not a support request I know the many ways around this issue however the built in forms API documentation is severely lacking in this respect. Being 3 versions behind on documentation is a sign of something not working correctly in the procedures in place to update everything related to each major change that happens.
I have found a way to achieve the desired result (and its silly not to have thought of this in first place). Language neutral content will have its fields that have translations in all languages (taxonomy references or text lists that are fully translated) show in the current language (label and content translated). The only restriction is that it does not allow to have this on partially translated entries. Its either no translation and fields will be properly translated or having translations and fields will be in the language of the current translation being displayed.
vitch → created an issue. See original summary → .
This issue should not have been closed #13 is incorrect in stating that the other issue is a duplicate that proposes the proper solution. The discussion in the referenced presumed duplicate is about how to prevent this issue from happening in the future. People that such as myself reach this issue are usually seeking a solution to restore a wrecked instance.
#17 is a viable temporary workaround after which the views that would have been altered loose the ability to filter by language since they will only display content in the current site language. (an alterative to site language could be content default translation which is even more limiting in terms of being able to display content in the required language)
#8 proposes a database cleanup (which is the real solution to restore a Drupal instance to a properly functioning state) however the tables listed are far from exhaustive. I have attempted a more radical cleanup where i delete from all tables that have a langcode column all the entries that still have the langcode for the deleted language(s). This did fix the issue on the unaltered content listing views. (I am not sure however that this indiscriminate deletion did not break anything else).
A safer but possibly daunting solution would be to recreate the deleted languages (the langcode must be the same). This will restore all the views which can then be used to identify content in the languages that we want to delete and manually delete the translations before deleting the language again.
vitch → created an issue.
function_exists does not work for methods I just updated the plugin to v2.2.0 and tested this variant which worked fine:
if (method_exists($pdf, 'setLayerMethod') && is_callable([$pdf, 'setLayerMethod'])) {
$pdf->setLayerMethod(NULL);
}
Hello its my mistake composer automatically installed version 1.2.2 when i thought it would install the latest. it did not exist in that version which i mistakenly assumed was the latest.
Hello,
I just installed the module and required pdf-to-image library and after reading about the issue i checked the patch to apply it to apply it to pdf-to-image and noticed that it has been integrated to the latest release of this library. This is just to notify that the warning on the main page is not needed for new installs.
Hello,
I have recently encountered this issue and had to come up with a quick workaround:
inspect the page and add the following css:
td.tabledrag-hide {
display: block !important;
}proposed patch did not work with Drupal 9.3.9 and menu delete 8.x-2.3