🇺🇸United States @drpldrp

Okay, last one: this version doesn't use synch xhr, adds data-entity-alias attributes on form load, and removes them on downcast.

There's a minor issue with switching text formats between no-ckeditor5 and ckeditor5.
The alias addition on form load is set to happen for ckeditor5.
If switching from ckeditor5 to no ckeditor5, the data-entity-alias will show up.
Conversely, if switching from no ckeditor5 to ckeditor5, the aliases will not be populated in the link balloon.

One method to address this is the same way the editor js calls xss filtering on text format changes.
In fact, the data-entity-alias form preload could probably all be handled in js anyways like that.

Is the linked entity data saved in the source, for example title/label, updated when the linked entity is updated?

I apologize if this is covered in the comments, I tried looking for it and didn't see it.

I recently wrote a method for linkit to show path alias ✨ Show URL alias after autocomplete selection instead of internal route (e.g., /node/123) Needs work in the ckeditor5 link form view (ie. preview/edit link balloon) using synchronous xhr because I thought it would be bad if the info saved to source isn't updated when the linked entity is updated.

Moved some things around so there's fewer changes and easier to understand.

The buildPath() signature change can break extending classes (eg. media_link_enhancements) ... but it seems silly to repeat that code as a new function with just the path processing change.

I'm also aware that the synchronous call is maybe not ideal and throws a warning.

If someone were inclined to do this without the sync call:

The problem is on the editor initial load with existing links.

Link upcast/downcast occurs and there's no alias info in the source data where upcast/downcast usually get its values from.
And the source data shouldn't have alias info because we don't want to save alias data into markup.
And, at least for me, I want to use LinkIt matchers but not the LinkIt url converter because it's not compatible with links on drupal-media images; extra data attributes like those required for url conversion are consumed off the link.

Possible solution is to find where to generate alias info from the source data and make it available to the upcast/downcast and before the editor is available for users to start clicking around. Maybe it can be done in the field widget initialization.

Only attaching a patch for 6.1.x because that's what I'm using.

It should return alias on selection, downcast to internal path for the source, and upcast to alias when editing.

I did see some errors thrown related to tooltip or something but it seem to affect functionality so I didn't bother fixing it.

drpldrp → made their first commit to this issue’s fork.

drpldrp → created an issue.

This change affects migration.

It can cause required comment field on node edit form to display no default value.

Attached example image is node edit form comment field for a migrated node that had comment=1 (Closed).

drpldrp → created an issue.

The changes in this commit https://git.drupalcode.org/project/views_migration/-/commit/2f3d58570609... are relevant to the config key value mismatches.

Here's an alternate patch that targets the MigrateViewsRelationship plugin specifically.

Not really sure how the difference affects other types of relationships or which is considered better for inclusion.

But it both seem to work for my use cases.

Ran into this too.

I compared the view config export between d7 and d10.3 and the field values were different:

old:

relationships:
  field_ref_author_target_id:
    id: field_ref_author_target_id
    table: node__field_ref_author
    field: field_ref_author_target_id
    relationship: none
    group_type: group
    admin_label: 'Content entity referenced from field_ref_author'
    plugin_id: standard
    required: false
    ui_name: ''
    label: 'Content entity referenced from field_ref_author'
    target_type: node
    field_name: field_ref_author

new:

relationships:
  field_ref_author:
    id: field_ref_author
    table: node__field_ref_author
    field: field_ref_author
    relationship: none
    group_type: group
    admin_label: 'field_ref_author: Content'
    plugin_id: standard
    required: false

The patch sets field to field_name for relationships.

Fixed in 2.0.0-beta6.

Fixed in 2.0.0-beta6.

I don't think I want to be responsible for maintaining compatibility with other modules.

Perhaps you could add this as a new contrib module.

This one might be the cleanest but relies on addEventListener('input'.

drpldrp → created an issue.

drpldrp → changed the visibility of the branch 6.1.x to hidden.

drpldrp → changed the visibility of the branch 6.1.x to active.

Marking as Needs Review. Sorry if this is not the appropriate workflow, ie. this is missing tests or anything else.

CkEditor does special link handling if the element attribute data model name starts with "link", eg. "linkHref" or "linkWhatever".

LinkIt uses ['data-entity-type', 'data-entity-uuid', 'data-entity-substitution'] for both the attribute model and view names.

So because the model names don't start with "link", CkEditor thinks it should inherit the previous element attributes like for bold or other styling.

The fix is to split out the attribute vars so the model names start with "link" and the view names stay the same.

Attached patch tested with Drupal 10.1.8 and LinkIt 6.1.3.

Added to 3.6.1.

Fixed in 3.6.0.

Fixed in 3.5.5. Thanks.

I'll probably release these changes in a new version in a few weeks.

I noticed one more spot that should probably be altered:

src/Plugin/EntityReferenceSelection/DomainMenusSelection.php:

  protected function buildEntityQuery($match = NULL, $match_operator = 'CONTAINS') {
    $query = parent::buildEntityQuery($match, $match_operator);
    if ($this->moduleHandler->moduleExists('domain_access')) {
      $config = $this->getConfiguration();
      $menu_domains = $config['menu_domains'] ?? NULL;
      $domain_access_field = defined('DOMAIN_ACCESS_FIELD') ? DOMAIN_ACCESS_FIELD : DomainAccessManagerInterface::DOMAIN_ACCESS_FIELD;
      $domain_access_all_field = defined('DOMAIN_ACCESS_ALL_FIELD') ? DOMAIN_ACCESS_ALL_FIELD : DomainAccessManagerInterface::DOMAIN_ACCESS_ALL_FIELD;
      if (!empty($menu_domains)) {
        $group = $query->orConditionGroup()
          ->condition($domain_access_field, $menu_domains, 'IN')
          ->condition($domain_access_all_field, '1');
        $query->condition($group);
      }
    }
    return $query;
  }

I'm not totally clear on how to reproduce this, as it's unclear how you're displaying your menu and with what settings.

But I don't think this is a Domain Menus issue.

I might be able to help if you provide more information about how your menu is setup and displayed.

I like storing and restoring the submit actions.

Fixed in 3.5.4.

Oops, forgot a thing.

Use this one.

Yea, I'd rather not spin up a new thing and have to do update funcs and all that.

Try this patch and let me know how it goes.

Is it to be able to give users admin access to domain menus?

Yes.

Oh yea, forgot about that.

This is a bit more code than I would prefer.

What do you think about just storing a copy of the submit action array before the menu_ui_form_node_form_alter() and then restoring it after?

Looks good.

Fixed in 3.5.3.

Okay, sounds good.

Fixed in 3.5.3.

I'm having trouble reproducing this problem.

Could you please provide additional details?

Maybe a screenshot of your menu setup, domain assignment, etc and/or what your menu's form_id is that makes it not "menu_link_content_menu_link_content_form"?

Fixed in 3.5.2.

Would it be better to check against "administer menu" permission instead of "administer site configuration"?

I have verified on a clean standard profile d10 install with olivero theme that domain menus blocks do display.

The domain menu must have menu items for the block to display.

I'm not able to reproduce your issue given the amount of information you have provided.

But note that the domain menus are blocks and so you need to configure your blocks to see domain menus.

Calling menu_ui_form_node_form_alter() adds the domain menus options so removing it would break the feature.

Fixed the issue by removing the duplicate submit actions after the menu_ui_form_node_form_alter() call.

Fix added to 3.5.1.

Try this patch.

It removes a condition for $option['absolute'] in the outbound path processor. The condition prevented "absolute urls" from having the microsite path appended to the url. Redirect module "enforce canonical" setting does some logic based on absolute urls.

Unfortunately I can't recall if it was really necessary to exclude absolute urls from being altered with the microsite base path. I think my logic at the time was just that absolute urls should be absolute.

Looking into it.

There were some changes to the outbound path processing to use $option['prefix'] in an attempt to get things working with Language.

Might have to revert and abandon Language compatibility for Redirect.

Last one to fix some errors here and there.

One more for funsies.

This one also adds an "Export active" link to the Operations dropdown buttons on the configuration synchronization page.

Better version.

Just adding this here so it's available.

Just going to close this issue because the problem seems to be specific to our env. I think there's just some file write issue.

Patch #2 didn't fix it. I thought it made things work, but turns out it didn't.

drpldrp → created an issue.

I still can't reproduce your issue with the amount of info you've provided.

Using your example, you should expect to see your page at /my-first-micro-site/my-first-micro-site, because the processed path should be in the pattern of /microsite-base-path/node-alias.

What are the front page settings for both your parent domain and the microsite domain?

Also, Domain Microsite module doesn't do any redirects, so the issue might be caused elsewhere.

Domain Microsite just has an incoming path processor that removes microsite base path from the requested url, and outgoing path processors that prepend microsite base path to urls.

I'm not really sure I fully understand.

Regardless, maybe it's worth mentioning that Drupal and its core modules don't store data in a way that's per "domain".

So you should be using Domain Configuration module to set Basic Site Settings per domain if you aren't already.
It will let you do something like set a different front page per domain.

Also note that core Path Alias is shared across all domains.
You should use Domain Path module if you want aliases per domain.

$url = Url::fromUri('internal:' . $path);
$internal_path = '/' . $url->getInternalPath();

I think the issue is getInternalPath() throws an error when it checks for $this->unrouted.
$url is not created with any route values or options.

Maybe it should just be:

$internal_path = $url->toString();

By the way, please feel free to update with any improvements.

Thanks mlncn → .

Need more info to reproduce.

Make sure the user has Domain Access assignment. It is not the same as Domain administrator assignment.
The Domain Access field has the help text "Select the affiliate domain(s) for this user".

The code currently checks if the user has Domain Access (not Domain administrator) assignment, and one of the two Domain Menus permissions to edit menus.

drpldrp → created an issue.

That'd be great!

Please test and report any other issues.

Try the dev version → .

Thanks! Added to 1.0.0-beta3.