🇳🇱Netherlands @firfin

This is a pretty long thread. But would it be fair to summarize it as: for D11 use version 2?

And in that case can we add a summary to the OP?

Finally, a link to the issues stopping a official / non-beta release would be helpful, so people can help with those.
Because not everyone is capable or able to use beta-releases ( not skilled enough with composer, government compliance, etc.)

Works fine for me, might be the Drush version, I was using
Drush version : 12.5.3.0

firfin → created an issue.

I did not have this problem when installing without CKE4.
Also no activity from OP, so I think this can go on the closed pile :-)

Thanks for fixing this, no more fakeobjects or ckeditr(4) needed!
Another step closer to getting sites working on D11!

So for example
file_copy( $imgFile,'public://', FileSystemInterface::EXISTS_REPLACE );
gets replaced with
$imgFile = \Drupal::service('file.repository')->copy( $imgFile,'public://', FileSystemInterface::EXISTS_REPLACE );

And
$file = file_save_data($handle, 'public://$value');
becomes
$file = \Drupal::service('file.repository')->writeData($handle, 'public://$value');

Diving into the code of Preflight (which throws this error) I found this is thrown if $alteredRoot and $root do not match. So a mismatch in where the files are and where they should be according to composer.json. This is the case in most of the problems mentioned before I believe.

Hacking the error thrown by the code showed me that $alteredRoot was now /my/project/dir/web/web and $root was /my/project/dir/web , so somehow an extra /web was attached to the path.

Searching for this symptom led me to https://drupal.stackexchange.com/questions/303922/drush-10-is-not-workin... and same as the original poster I had an extra composer.json in my /web dir.

Removing that superfluous file fixed the problem for me.

I do not know why this was not a problem on D9 / Drush 10.6.2 but at least it's working now.

Nice suggestion, unfortunately did not work for me. Composer reports:

    - drupal/core 10.2.0 conflicts with drush/drush 11.6.0.

Also checked the setting below (tried both ./web and web/ ) my webroot is in de web directory (not using doc-root or something)

Any other suggestions?

    "extra": {
        "drupal-scaffold": {
            "locations": {
                "web-root": "./web"

firfin → created an issue.

Used this link with composer-patches and seems to solve the problem.
This approach is also the recommended way to solve this according to core issue 🐛 Log an error message when library definitions have a license with no URL defined Needs work

Use of the MIT license seems a correct assumption also (from https://github.com/briancherne/jquery-hoverIntent/blob/master/jquery.hov... ) :

* You may use hoverIntent under the terms of the MIT license. Basically that
* means you are free to use hoverIntent as long as this header is left intact.
* Copyright 2007-2019 Brian Cherne

Don't think we need tests for this, but might be wrong. Marking this RTBC anyway.

Link used for patch:
https://git.drupalcode.org/project/views_slideshow/-/merge_requests/8.diff

A solution for the Undefined array key "url" is (being worked on) here: https://www.drupal.org/project/views_slideshow/issues/3387913 🐛 missing license URL RTBC

Just saying in case people stumble upon this thread.

Changing your projects minimum-stability to dev is a workaround at best I think. Running a production site with minimum-stability anything less than stable is asking for trouble IMO.

Personally I would rather install the needed JS libraries using: drush dl-cycle-lib

Somehow that option has disappeared from the documentation, addressing that in https://www.drupal.org/project/views_slideshow/issues/3405728 🐛 Updating documentation Needs work

Don't know if we truly need dev versions of the JS libraries, that is a question better suited to the maintainers or other JS/library experts. But requiring those is a problem with composer.

firfin → created an issue.

I had the same problem but it disappeared after re-saving the view ( I turned autoplay in the Views' format:slideshow:cycle settings off and on) and rebuilding caches

This was after I reinstalled the JS libraries to the correct folders, I was still using the old versions (and locations). You can try drush dl-cycle-lib for installing (again).

Please make sure the newest versions are installed and recognized correctly before re-saving the Views.

If this does not help, please provide steps to reproduce.

Linked to some_path on briarmoon which redirected to nickdickinsonwilde.ca site, I put in the correct link directly now.

This was causing a browser error about the SSL certificate (~~ nick... is not valid on briar...) , thus needing to add an exception manually (which is not even possible anymore on some browsers). This is confusing and unnecessary.

Dev version seems to have solved it for me.
I did have to install extra_field_plus by hand first (because of incompatible stability)

composer req drupal/extra_field_plus:^3@dev
composer req 'drupal/pseudo_title:dev-2.x'

The MR is the same as the rector patch in the issue I mentioned.
Your response adds nothing, please don't contaminate issue queues.

I got this after upgrading to D10 (from D9.4.8, module from 8.x-1.8-beta1 to 2.0.0-beta1 )

In my case the problem was the directory seemed to have moved ( libraries/datetimepicker -> libraries/jquery-datetimepicker)
After reading the README.MD properly my problem was solved using require "wikimedia/composer-merge-plugin":"^2.0" and adding the following to composer.json :

"extra": {
  "merge-plugin": {
    "include": [
      "[web-root]/modules/contrib/single_datetime/composer.libraries.json"
    ]
  },
}

Just leaving this for future reference.

I just installed this on D10 to replace field_formatter_conditions (fico) module which does not have a D10 version.
I never got any field to have it's visibility altered (not on display nor on edit).

Also using Display Suite module, so that might be part of it too.

@Martijn de Wit comment 29 Enabling Field Layout from core does not fix this for me. Any other settings needed that you know of?

@Moser comment #24 patch does not apply to 3.0 version for me, any chance to get a patch for this version?

For now I just made my own module with this code in it, thanks.

Have you tried the patch at https://www.drupal.org/project/fico/issues/3287494 → ?

I had the same problem on Lando (local dev environment) runnig the default 'drupal7' recipe.
That apparently installs Drush 8.4.8 problem was fixed when using Drush 8.4.12

( add drush: '^8.4.12' to the .lando.yml file )

Gábor Hojtsy → credited firfin → .

firfin → created an issue.