@Paul Dudink

Up to this point I have succesfully used the following:

function hook_form_config_split_edit_form_alter(&$form, &$form_state, $form_id) {
  // Support both old and new versions of the module
  if (isset($form['blacklist_fieldset']['theme'])) {
    $form['blacklist_fieldset']['theme']['#access'] = TRUE;
  }else{
    $form['complete_fieldset']['theme']['#access'] = TRUE;
  }
}

This no longer seems to work after I followed the upgrade path to Drupal 10.2 and version 2.0 of config_split.
I am not sure whether this broke due to the updates that have been applied to the database, or because the code works differently now.
The patch of the merge request also still applies, so I don't know what is wrong, but all sites in the multisite system now no longer seem to understand that a different theme should be used.

I am investigating this, but maybe some one already knows the answer / has a solution?

Never mind my previous comment. Looking at your commits I created a quick-fix patch for people who encounter this issue.

We have the same issue. So what is the fix at this moment? Can we safely checkout the dev branch or is there a patch available?

This may be worth investigating for anyone who has this issue:
I had a similar issue in some of our websites and after completely tracing the process that this module uses I found out that the module (in our case) was working correctly, but it broke because we had a bug in our own templates:
Due to something we did both the form and a wrapper div had the same HTML ID (i.e. id="user-pass"), because of which the Antibot module spoke to the div instead of the form.

The example at the end wasn't working, because the foreach wasn't actually looping the results.

I just stumbled upon this as well. As a quick fix have completely removed the check whether the unpublish field is in the past, because I don't see the point of it.
Without the check everything works fine. Also if the date is in the past and the node is published it will be unpublished by the cronjob like it should.

So in my opinion this check should be completely removed, or made optional just like with the publish date field.

Thanks guys! It may take a while, but we'll look into this.
I like the ideas to support both "core" and asymmetric translations. If you have more ideas let me know.
And ofcourse, any forks are welcome too ;)

Thanks for pointing that out. That sounds interesting, but can you provide any more information? I know about the Group module, but as far as I know that's mostly about permissions - ofcourse I may be completely off about that.

I've looked into "projects that extend Group module", but I don't see anything related to translations.

Can you point me to any documentation or module that provides asymmetric translations using the group module?

Thanks for this, I need this as well. I wrote my own patch which I was about to create an issue for, then I found this one.
Before this merge request should be accepted please note that I think there are several issues with this patch:

Get rid of the _addSubmitHandler function

The function _addSubmitHandler in menu_item_extras.module shouldn't be used. This can easily conflict with another module containing the same function.

I would suggest adding a method addSubmitHandler to the menu_item_extras.menu_link_content_helper service and call that method instead.

Refactor the entity type check

There are several issues with this code:

use Drupal\node\Entity\Node;
use Drupal\taxonomy\Entity\Term;

...

if ($parentEntity instanceof Node) {
  $uri =  'entity:node/' . $parentEntity->id();
}
elseif ($parentEntity instanceof Term) {
  $uri =  'entity:taxonomy_term/' . $parentEntity->id();
}

- The interfaces should be used instead
- A fallback / exception should be there for other entity types

I think it should be refactored like this:

use Drupal\node\Entity\NodeInterface;
use Drupal\taxonomy\Entity\TermInterface;

...

$uri = '';
if ($parentEntity instanceof NodeInterface) {
  $uri =  'entity:node/' . $parentEntity->id();
}
elseif ($parentEntity instanceof TermInterface) {
  $uri =  'entity:taxonomy_term/' . $parentEntity->id();
}
else {
  throw new \Exception('Entity type is currently not supported by the Menu Item Extras module');
}

Also I think it may be problemetic to simply refer the NodeInterface and the TermInterface like this, because these namespaces do not exist if either the Node module or the Taxonomy module is not enabled.

The Menu Item Extras module could depend on both modules, but I don't think that would be correct, because the module should be usable without the Taxonomy module. The best solution might be to move parts of this code to a menu_item_extras_taxonomy module, but that will be some extra work.

I quickly wrote a fix. We may also want to check if the parent object has a language() method, but for now I think we can expect it to.

I haven't looked into it yet, by it looks like the Sitemap module provides a way to add custom Sitemap generators (see /nl/admin/config/search/simplesitemap/types).

Paul Dudink → created an issue.

Paul Dudink → created an issue.

Paul Dudink → created an issue.

Paul Dudink → created an issue.

Paul Dudink → created an issue.

Fixed. Be aware to test this properly when updating the module to this 1.0.0-alpha5

Paul Dudink → created an issue.

Thanks, it has been merged and released.

@jrockowitz

I hesitate to change how a handler's postSave() method works. It will most likely cause issues for other people.

Just checking, because your answer seems to contradict what actually happened:
Our code has not changed for years, but suddenly broke after updating Webform and/or Drupal core.

If you know for sure that this change in handling the postSave() is being caused by a change in Drupal core, than I think it's fine to simply document it.
However if not, I think it still should be investigated as a bug, because contrary to what you say this possible bug most likely cause issues for other people; fixing it will fix it :)

Could you elaborate on your vision about this? Don't you think that a postSave() should be an actual post-save, and not a before-commit-save?

Paul Dudink → created an issue.

For now I have written a simple patch, that logs the Exception to the database as a warning. Maybe it should be an error even.

Paul Dudink → created an issue.