🇨🇭Switzerland @ayalon

vrancje → credited ayalon → .

I can confirm the issue. An anonymous user does not have a domain assigned, and therefore the access is denied.

Every anonymous user should at least be granted the current domain. Else there is no way to ever access a webform.

ayalon → created an issue.

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

Thanks for the fix. I have merged it.

Thanks for the fixes. I have merged your proposal.

Awesome! Thank you!

Maybe we need something like that.

Attached a possible patch.

@kevinquilen:
I have tested the module with Drupal 11 and it is not yet compatible.
The function menu_ui_form_node_form_alter() does not exist anymore under Drupal 11.

The hook as been moved to src/Hook/MenuUiHooks.php

Basically, all node form edits end up in a fatal error if you have this module installed.

Attached a patch:

Sorry, wrong patch file.

Attached a patch that adds Drupal 11 compatibility.

ayalon → created an issue.

Unfortunately, it is not yet working. It seems, that the artifact_deployment is still in https://packages.drupal.org/8 available.

The URL is still working and causes the drush command to be installed wrong with composer.
https://packages.drupal.org/files/packages/8/p2/drupal/artifact_deployme...

Fetching a specific tags shows this issue:
Root composer.json requires drupal/artifact_deployment 1.0.0-beta3 (exact version match), it is satisfiable by drupal/artifact_deployment[1.0.0-beta3] from composer repo (https://repo.packagist.org) but drupal/artifact_deployment[dev-1.0.x, 1.0.0-beta1, 1.0.0-beta2, 1.0.x-dev (alias of dev-1.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.

Can the module fully be removed from the https://packages.drupal.org/8 repo?

ayalon → created an issue.

Thanks for the feedback. I have adopted all suggestions.

ayalon → created an issue.

THanks for the improvement! Merged

Awesome! @dieterholvoet you can start now creating a new module! We are desperately waiting for this! :-) Thanks a lot for the efforts.

ayalon → created an issue.

The patch did not cover the new submodules. I will create a new task and also push some code cleanup.

I have added Drupal 11 compatibility and cleaned up some code issues.

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

Thanks for your valuable contribution. I will merge the fix manually because gitlab refuses to merge without giving a notice why.

Thanks for your valuable contribution.

Thanks a lot for the work and the merge request.
@anybody: Apart from reviewing the code, I also have tested the functionality on a live system and successfully translated nodes and other things with TMGMT with a Deepl Pro API key.

I did not encounter any issues.

The MR can be considered as reviewed and tested.

Thanks!

Thanks!

I have merged and included all the improvements. Thanks for the valuable feedback and the effort to improve the starterkit.

Thanks for your valuable feedback. I have implemented this feature. If you do not provide an API key, you still can continue, but image display and upload will not.

rokka.io setup (Image transformations and CDN)
-------------------------
1. I have a rokka.io account and can provide an API key
2. I have no account and want to create one for free
3. I want to skip the rokka.io setup. Images and image upload will not work
Please select an option (1, 2, or 3): 3
Skipping rokka.io setup. Images and image upload will not work.

Thanks for the patch. I went for option 1 because I want to stay with symfony mailer lite. It has better inline image support.

I will leave the check in for now. It is better to give a hint why it possible fails. On WSL2 it also does not work properly side by side.

It took me hours to figure out the same issue:

Go to "/admin/config/search/simplesitemap/entities" then to "*Configure" and then you have to select the "Content" Settings for each domain individually.

As soon as you have something selected for at least one entity type it will be generated.

@richarddavies

Thanks a lot for the SQL queries. This helped me.

I have added you as a co-maintainer.

There will not be a GraphQL 4 Update sponsored by Liip. We completely dropped everything related to layout builder and open sourced our in page editor called blokk.li based ion the starterkit with blokk.li → .

For GraphQL we build https://www.drupal.org/project/graphql_core_schema → as an easy upgrade path with an autogenerated schema.

If you plan to go into the layout builder direction, you will have to build your own upgrade path for GraphQL 4 module.

Yes! To keep the schema as small as possible for performance reasons, you should only enable the features you need.
You need to enable "Formatted Date and Time" to use this type.

This module solely depends on the official ElasticSearch php library. It has a robust indexer supporting also custom fields like nested objects, geofields and other complex fields.

The module has a proper developer API with EventListeners that allows a developer to implement and react on all kind of events.

The module has a plugin system and implements 2 kinds of authentication providers.

It has to be proven to scale well in large enterprise websites.

The module is now Drupal 11 compatible.

I have the same error for all user login in. Drupal 10.3.8

I have backported all changes from the upstream module. Thanks for the patch.

Fixed and released

Fixed and closed

Here is a rerolled patch against 3.2.1

Here is the latest MR as a diff for composer patches

We have doumented this under security:
https://graphql-core-schema.netlify.app/basics/security.html

There you can also see an example of a custom module. Because we claim to be secure by default, I would like to avoid any code that could possible expose data, that is not accessible via core.

I recommend using the proposed hook:

/**
 * Implements hook_ENTITY_TYPE_access().
 */
function MY_MODULE_menu_access(EntityInterface $entity, $operation, AccountInterface $account) {
  // Grant view access to the main menu to everyone.
  $id = $entity->id();
  if ($operation === 'view' && $id === 'main') {
    return AccessResult::allowed();
  }

  return AccessResult::neutral();
}

Thanks a lot! This is a great improvement.

We also found this issue but decided to not fix it in GraphQL Core Schema.
We rely fully on Drupal Core in terms of routing. The issue is an underlying bug in Drupal core.

You can find the issue here:
https://www.drupal.org/project/drupal/issues/1255092 🐛 url() should return / when asked for the URL of the frontpage Needs work

If you use for example the patch in #41, the issue is solved.
https://www.drupal.org/files/issues/2022-03-31/1255092-41.patch →

What do you think?

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

Fixed

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

I have released a 3.0 release with monolog 3 support.

I have released a 3.0 release with monolog 3 support.

Thanks for the contribution!

Great improvement!

Awesome contribution! Thanks!