🇧🇪Belgium @ericvl

Account created on 2 February 2019, about 6 years ago
#

Recent comments

🇧🇪Belgium ericvl

@erichhaemmerle I think that the problem is that you inslude all your files too in the export phase. Therefor the export file is getting too big for the max memory that is set in your php setting.
A solution could be to only export your entities and copy your files with a classic ftp program.
Therefor if you use the user interface, you could change the file src/Form/ContentExportForm.php around line 100 and change;
$serializer_context['include_files'] = 'folder'; to
$serializer_context['include_files'] = 'none';
This way, your exported file will be much smaller and you will provable have enough memory to get no errors.

If uou use drush then use the command to only export the entities.

Before you import the exported file on the other side, first copy all your files from the original site to the target site and then import the file. Otherwise, the files will not be found on the target site.
Good luck,
Eric

🇧🇪Belgium ericvl

Thanks for the modification.
This modification solves the issue now but the test fails again. I think, this has nothing to do with the modification but with the test itself. Some files could not be downloaded in intialisation of the test.
So I've put it on again on "needs work".
If the test is ok, it may be put in RTBC.

🇧🇪Belgium ericvl

You're welcome.
Check also my comment in this comment 🐛 TypeError in using Textoverlay Active if you don't want the issue that I had with the Textoverlay function. The comment is from yesterday and should still be implemented.

🇧🇪Belgium ericvl

Hello eveyone,

I was able to detect the real cause of the problem.
The real cause is a bug in the TextToWrapper.php file in the image_effects\src\Plugin\ImageToolkit\Operation\gd\TextToWrapper.php folder. The problem I've mentioned in the title I had it with PHP 8.2. Due that PHP 8.3 is more strict it generated an error in the assert(is_int()) function in the function translate() in image_effects\src\Component\PositionedRectangle.php.

In the file TextToWrapper.php on line 174 one should replace the line
$x_offset = round($x_delta / 2);
with
$x_offset = (int) round($x_delta / 2);
The round() function creates a non-integer and is detected in the assert(is_innt()).

Is someone able to change this in the merge branch? I am not capable to.
This is the only change that should be done. The previous changes may be deleted.

Thank you.

🇧🇪Belgium ericvl

Try

composer require "drupal/image_effects":"^4.0" "drupal/color":"^2.0" -W

🇧🇪Belgium ericvl

I tested the issue just by manually adding the two (int) casts in the file and checked of the issue still existed. And the test did well. What I don't understand is how the junit tests could fail after the patch in the MR was applied?
If this test fails now it should have been failed at release of the 4.0.0 version.
Strange...
Anyway, the two casts are the solution to this issue.

🇧🇪Belgium ericvl

@priti Then it is OK for me, thanks

🇧🇪Belgium ericvl

Why is the patch different from the diff of the merge request?
The patch covers 2 issues while the MR covers just one.
The MR works for me for the issue that is specified in the title but maybe there is a second issue in the file that is covered by the patch too that I can't test.

🇧🇪Belgium ericvl

Hello,
I found a tweak to be able to install Drupal on a local system:
In the root folder of your site there is a .htaccess file, open it in a editor and change the lines around line #30 from

<IfModule mod_php.c>
   php_value assert.active                   0
</IfModule>

to

<IfModule mod_php.c>
#  php_value assert.active                   0
</IfModule>

On my XAMPP local system it works. You can install Drupal again. I tested it with D10.3.10.
After installing, you could maybe edit the file again to the old version.

🇧🇪Belgium ericvl

Has nothing to do with WAMPP alone. Installing on XAMPP gives the same result.
And also not with Drupal 11. Installing D10.3 doesn't work too.
Only the move from PHP 8.2 to 8.3 is probably the reason.
Is ofcourse anouying for all those that want to install Drupal.

🇧🇪Belgium ericvl

The installation of Drupal 10 failt too if the php version is 8.3.

With php 8.2 it works perfect.

🇧🇪Belgium ericvl

@voleger
Correct. You can find my complete explanation in #24.
If you don't have a private setting in your setiings.php file, the only posssibility is to use the public:// scheme.

🇧🇪Belgium ericvl

I've checked all the views that I use and for me, the issue is solved.
Therefor, I've closed this issue.
Thanks

🇧🇪Belgium ericvl

Thank you.
Just one question: is the mofication that you did in #2 🐛 Position of the table header in the content and reaction lists are too low. Active still needed then? Because you did a general modificarion in #5 🐛 Position of the table header in the content and reaction lists are too low. Active .
Cheers

🇧🇪Belgium ericvl

Sorry to bother you again Alaa but there is still a tweek needed in the case of the permissions view.
Try admin/people/permissions.
The Permissions table of taxonomiterms does the same.
I didn't test all the views but these 2 are for sure wrong now.
Thanks

🇧🇪Belgium ericvl

Thank you very much for your quick response and fix.
It does the job perfectly.
Cheers

🇧🇪Belgium ericvl

@motame
Thank you to confirm my remark from 2 years ago :-)
It was correct then and is still correct now.
I"m using this module with this modification in a local patch since then.

🇧🇪Belgium ericvl

@flashwebcenter
Sorry, I wasn't able to contact you earlier.
Thank you for all your suggestions. It seems that it my problem is solved now.
I tought that this problem came from the solo theme because it was the only module or theme that had a separate "language/nl" folder under the "sync" folder.
I do not know why this is nessecary but this is irrelevant here. I can look it up in the documentation of configuration in core (if I can find it).

Thank you again for your time.
Greetings

🇧🇪Belgium ericvl

@alexpott
Thank you for helping me out. It works.
Sorry to bother you with such a stupid problem.
Thnx

🇧🇪Belgium ericvl

@alexpott
Thank you for the quick response but it doesn't work for me. I do not get the selectbutton for existing config.
I'm using Drupal 10.3.5. Maybe I should use the dev version?

What I do:
- export the configuration and import it back in so that the contents of the config_sync_directory mirrors what is in the database.
- remove the standard profile
- remove all tables in yhe database. Remark: the specs of the database are still in the settings.php
- I'm visiting the interactive installer by accessing the root of site (this redict to the installer)
- I can not select the existing config.

If you can spare a few minutes to look into this, thanks

🇧🇪Belgium ericvl

@elvin
Is there a way to install Drupal and getting the choise of selecting the "existing configuration" without making use of Drush? Just by the user interface.
I don't have Drush on my site. therefor one needs access to the shell and I haven't.

🇧🇪Belgium ericvl

You are all right.
This issue has nothing to do with this module.

I ran the scan in Upgrade Status on other modules and themes and got the same result.
The problem is in the core or in Upgrade Status. See the related issue in my previous comment.
That is why I changed the status back to RTBC instead of Active.
Sorry for the inconvenience.

🇧🇪Belgium ericvl

This could be a related issue. The errors could be generated by the Upgrade Status module.
I say could be. I'm not sure.

🇧🇪Belgium ericvl

This is what I use:
- Drupal core 10.3.5
- EU Cookie compliance 8x-1.24
- Upgrade Status 4.3.5
- PHP 8.2.12

Install the Upgrade status module and look at admin/reports/upgrade-status.
Select the checkbox besides the EU Cookie module and run only this scan with the button on the bottom.
After scanning I'm getting 68 problems for this module.
Most of them are on line 25 of vendor\symfony\deprecation-contracts\function.php and the error is:
Since twig/twig 3.12: Getting node "filter" on a "Twig\Node\Expression\FilterExpression" class is deprecated

There is nothing in the log trail.

I think that the problem is in the update of the core from 10.3.3 to 10.3.4.
Core 10.3.3 needed twig/twig ~v3.10.2 while core 10.3.4 needs twig/twig ~v3.14.0.

I know that this issue should probably be reported in core but Upgrade Status has assigned this module to be the faulty one.
Sorry if I wronly assigned this module to be responsible for the error but Upgrade Status is giving these eerors.
Greetings and thank you for looking into this.

🇧🇪Belgium ericvl

Only recently a new version of twig/twig is used in the core of Drupal 10.3 because of a security risk.

This gives me the following erro if I run the Upgrade moduke under 10.3:
Since twig/twig 3.12: Getting node "filter" on a "Twig\Node\Expression\FilterExpression" class is deprecated.

Probably this error should also be fixed before it could run under Drupal 11.
Therefor I've changed the Status back to Active.

Greetings

🇧🇪Belgium ericvl

I think I found a solution for this issue some months ago:

In the file at_core/forms/color/color_submit.php change the line 98 from

$paths['source'] = \Drupal::service('extension.list.theme')->getPath($theme); to
$paths['source'] = \Drupal::service('extension.list.theme')->getPath($theme) . '/';

I don't know if it will solve your problem but it solved mine.
Good luck

🇧🇪Belgium ericvl

@flashwebcenter
Thank you for your clear explanation.
I know, you have the capabilities of doing a good job.
I was just wandering if you checked this.
Thank uou
Eric

🇧🇪Belgium ericvl

I have a little remark here:
I see that all instances of "gab" are replaces with "gap" in version 1.0.10 of the code.
When I exported the configuration for the settings of my subtheme under 1.0.9 (with the wrong gab words in it) and imported these settings again in a 1.0.10 version, will this be OK?
Thank you for a reaction on this.

By the way: Great Theme.

🇧🇪Belgium ericvl

The merge request MR8487 proposed in the related issue works for me in Drupal core 10.3.1.
If you want to use it, this is the patch here.
It is supposed to go into the version 11 branch but it should be merged to the 10 dev branch too.

🇧🇪Belgium ericvl

I'm experiencing the same after upgrade from 10.2.7 to Drupal 10.3.1.
The version of admin_toolbar I'm using is 3.4.2.

After disabling the submodule admin_toolbar_tools of admin_toolbar, the error is gone.
After re-enabling this submodule the error apairs again.

Maybe this error should be debugged by the maintainers of the admin_toolbar module.
Greetings

🇧🇪Belgium ericvl

Sorry Matt. Now I can see the reference to the 7.1 build.
I was too quick to respond.

🇧🇪Belgium ericvl

Thank you, Matt for the new 7.1 release.
Just 1 question: why don"t we see the 7.x releases on the Home page of this theme?
I do not have a problem with that because i"m using composer to get my packages. But if someone likes to check the latest version and download it there, he can't.
Greetings
Eric

PS the 2 issues that you solved in this latest release can be closed AFAIK.

🇧🇪Belgium ericvl

I'm using this patch now for monhs. Can somebody merge this in the next release, please.
I've changed the version to the latest version. The original was 5.1.
Thanks

🇧🇪Belgium ericvl

I believe, this merge request is still not merged into the latest release(s) although it is a major problem.
The original version was 5.2 when this isue was discovered. I changed the version to 7.
Is it possible that a maintainer looks into this issue please.
I"m using a local patch now to have the same result.
Thank you.

🇧🇪Belgium ericvl

This issue is indeed not the fault of this module, you're right.
So, this issue can be closed by a maintainer.

Thank you for the clear explanation.
Greetings.

🇧🇪Belgium ericvl

@Blanca.Esqueda

Hello Blanca,

If you don't find the time to make a new D10 compatible version of this great module, could you delegate this work to someone else that can do it. Version 9 of Drupal core doesn't get any security updates anymore now for some months now. So, it is adviced that we upgrade to D10.
Thank you in advance.
Greetings
Eric

🇧🇪Belgium ericvl

Did you first uninstalled the module before you applied the path and then installed the module again?
Maybe a stupid question but never the less...

🇧🇪Belgium ericvl

@voloda86
I"m using the same versions but I added the replacement of stable too.
composer require "drupal/classy":"^1.0"
This module is dependent on drupal/stable and both modules will be installed. Probably, you don't need classy but this is my situation.
Then you can install drupal/adaptivetheme because this module is dependent on drupal/stable.

So at_tool is dependent on adaptivetheme wich is dependent on stable.

🇧🇪Belgium ericvl

@Blanca.Esqueda

Glad you're back.

Be carefull to merge the correct branch. There are a lot of try-outs and you need the correct one. It is merge request !10 in branch 3330173-drupal-10-compatibility-new.

The only 2 thinks that are still to be done before you can make a new release is, I think:
- look at this issue 🐛 Conflict in importing nodes with images from a local system to a live system. Needs review and check the patch in comment #7. With this modification, i'm using it for months now and it fixes the bug.
- changing the module's composer.json file so that it depends on a specific core version. The modifications should be:

"require": {
"drupal/core": "^9.4 || ^10.0"
)

It is not good to having no restrictions on the core version.

Both modifications are tested.

Regards,
Eric

🇧🇪Belgium ericvl

IMHO there are 2 issues here:
- the fact that "at_tools" is not renamed to "at_tool" because the new developers started to make a new module based on "at_tools" and called it "at_tool" but didn't renamed all occurences of "at_tools" and
- the fact that the theme is wronly based on the original D8 theme "stable" and not on the new D10 theme "stable9".
I still had the old (replacement of) the "stable" theme in my configuration when I tested the patch in #6 and it worked nicelly.
The fact that the D10 version of this module should work when it is bases on "stable9" is NOT tested here.
So maybe these 2 issues should be splitted now.
Just my idea
Greetings

🇧🇪Belgium ericvl

@Tobias März

I found that merge reauest !10 is ready and have all modification to be compatible to Drupal 10 and PHP 8.1 AND have the latest bug fixes.
If somebody that is capable to merge, merge this in the 3.0 branch, we could have a 3.0 development branch that is D10 compatible.
The problem is here probably that no one is capable of making a fix. What a pitty...
Anyone out there???

🇧🇪Belgium ericvl

@Tobias März

Thank you for your great work to make this patch but I have only one remark: this patch is based on an old beta version of Drupal 9. In the mean time, a lot of bugs were solved and modifications were done on the development branch that are not included in your version.
Is it possible to make a patch with your modifications so that the result is Drupal 10 compatible but based on the development branch?
Thank you.
Eric

🇧🇪Belgium ericvl

In fact this issue should be solved in the module https://www.drupal.org/project/at_tool .

In the module "at_tool", you should should modify the file "at_tool.module" and change the line # 23 from
$variables['#attached']['library'][] = 'at_tools/appearance_settings'; to
$variables['#attached']['library'][] = 'at_tool/appearance_settings';

I know, there are still some other mistakes in the code where the word "at_tools" should be changed to "at_tool" but this solution here is needed for the error mentioned in this issue.

🇧🇪Belgium ericvl

@Nitin Shrivastava
Now it is more correct but just still one question: did you check why the version was changed to 9.3 and higher before you will change it to 9 and higher?
I think it is because there are other limitations involved now if one wants to make a Drupal 10 compatible theme. It could be PHP versions or Drupal versions or somethong else. Anyway, the drupalversion 9.0.15-dev that you want this theme to support is out-of-business for a long time yet.
Just my idea.

🇧🇪Belgium ericvl

This is the change: core_version_requirement: '^9 || ^9.3 || ^10'

Sorry, but if it is compatible with all version above drupal 9, it is also compatible with all versions above drupal 9.3.
Or do I miss something?

🇧🇪Belgium ericvl

@zarexogre
See also comments #10 and #20 (returnvalue must be mixed)
Function denormalize of FileEntityNormalizer calls denormalize of parent ContentEntityNormalizer and there the retunvalue is mixed too.

🇧🇪Belgium ericvl

This issue may be closed because I think I found the error or misunderstanding.

When I use the outdated command, composer says the module has a new minor version available.
It is listed in red to mark it as minor version update.

When I then use the prohibits command on this new version like this:

composer prohibits drupal/image_effects 3.5.0
drupal/image_effects 3.5.0 requires drupal/core (^10.1)
drupal/recommended-project - does not require drupal/core (but 9.5.11 is installed)
drupal/image_effects 3.5.0 requires drupal/file_mdm (^3)
drupal/recommended-project - does not require drupal/file_mdm (but 2.6.0 is installed)

it can only be updated if I install Drupal 10.1 and drupal/file_mdm (^3) first.

This is in my opinion a major update because I have to install other things first before I can do an update of this module.
Therefor, it should logically better to make the new version a "major" version - like 4.0 in stead of 3.5. Then I should not have the reaction that this module could be updated with the update command.

Any way, it works of course on Drupal 10 and it doesn't do nothing wrong on Drupal 9 except not updating.

Therefor this issue may be closed by an admin.

🇧🇪Belgium ericvl

I think the problem has also something to do with this issue Update to file_mdm version 3 dependency Active .
I'm still using 2.6 if drupal/file_mdm and not 3.0. This 2.6 version is also compatible with D9.

🇧🇪Belgium ericvl

@yuvania
This is the same patch as in #14.
See also remarks in #10 and #23.

🇧🇪Belgium ericvl

Hello,

I think, we should release a new version of this theme with only the modifications needed to make this theme Drupal 10 compatible because most of the modifications that are done in css on the dev branch are not fully tested and some do not even work properly.
Therefor it is probably better to make a new branch away from the 8.1_dev branch to make this possible if we do not want to wait for all the tests of the css modifications.
Just IMHO
Greetings

🇧🇪Belgium ericvl

@jcnventura
To be very clear and having no misunderstandings: the patch in #40 should still be applied to the code before this issue should have the state "Fixed".
Thank you

🇧🇪Belgium ericvl

@jcnventura
I'm using this modification you sugested in #40 for months and it works.
The Project Bot in #2 is right.

🇧🇪Belgium ericvl

By the way:
This modification was allready done in the last push before the release of 1.8.
It should just be cherry-picked to the 2.0 branch.
My 2 cents

🇧🇪Belgium ericvl

@chetan 11
I know this module is not D10 compatible but adding a composer.json file should be part of making this module compatible with D10.
Therfore I've first added this requiest to this 📌 Automated Drupal 10 compatibility fixes Fixed issue but according to @jcnventura this was not the correct issue to ask for a composer.json.
Therfore i have made a new one - this one here.
So, could somebody add this composer.json file together with the solution to make this module D10 compatible, please.
Thank you

🇧🇪Belgium ericvl

What a pitty the composer.json only specifies a required drupal/core of 8.* or 9.* and not version 10.*.
Is it possible to adapt this?
Thanks

🇧🇪Belgium ericvl

@densh0
Thank you for the clear explanation. My confusion was due to the above issue that all versions of captcha could be a dependency of recaptcha v3 See the requirements in the "composer show" command. This is of course wrong. Thank you.
But what I'm seeing now is that you have released the new 2.0.1 version on the same git version of 2.0.0. See the repository graph.
A compare between 2.0.1 and 2.0.0 gives nothing at all.
The fix is done in a later git version but the tag is on the same version as 2.0.0 is.
Sorry to bother you again but can you fix this?
Thank you for your patience.

🇧🇪Belgium ericvl

@dench0
Thank you for the quick fix but I think many people has still have the version 1.* of captcha running because they had no reason to change to the 2.x version. Narrowing the version capabilities to only 2.x will need to update captcha too and maybe they don't want to because of other reasons (e.g. a module that needs 1.* of captcha).
Is there a reason that this module should NOT work with 1.* of captcha?
Greetings

🇧🇪Belgium ericvl

@saranyamariappan
May be you did a "composer require drupal/captcha:2.0" and forgot the "^" before the version spec.
Indeed version 2.0.0 only works with Drupal 10 and higher.
If you did rather a "composer require drupal/captcha:^2.0" then composer should select a later version than 2.0.0 (.1, .2, .3 or .4) and these versions are Drupal >=9.4 <11 compatible.

🇧🇪Belgium ericvl

In your problem description, you stated that the version 1.10 is working perfectly.
Why do you assign the version 1.10 then to this issue? Should it rather not be 1.13?
Just a question.

🇧🇪Belgium ericvl

Hello,

I have the same issue as corE.
I am updating through composer and get the same error when I try to open the site before an updatecycle has occured because I have no drush and do the update from within the user interface.
I then was trying to run an update.php but couldn't because I wasn't logged in as an administrator. I had to edit the settings.php file and set $settings['update_free_access'] to TRUE before I could do an update.php.
After the update of the module, I've restored the setiing in settings.php and then I could login as an administrator and everything went fine.
Maybe this is a tip for corE to get things running again.
Greetings

🇧🇪Belgium ericvl

@jcnventura

Sorry if I wronly have put it here but I thought it was a requirement of D10.
I've tried to install the theme without the composer.json file and it gave me an error. I don't know anymore what the error was but by adding the file, it was OK.
A new issue is made now.
Sorry again

🇧🇪Belgium ericvl

A question before this patch is merged:

Shouldn't we need a composer.json in this project?
I know, it isn't strictly needed because this theme doesn't need any other "requirements" but it should be convenient for composer to work more smoothly. Especially to find out if this is a module or a theme. It can find this info under the "type" tag.
I have made sample that could be used:

{
  "name": "drupal/danland",
  "type": "drupal-theme",
  "description": "Provides Danland theme",
  "keywords": ["Drupal"],
  "license": "GPL-2.0+",
  "homepage": "https://www.drupal.org/project/danland",
  "minimum-stability": "dev",
  "support": {
    "issues": "https://www.drupal.org/project/issues/danland",
    "source": "https://git.drupalcode.org/project/danland"
  },
  "require": { }
}

As said, it is not stricly needed but convenient.
Greetings and thanks for the great work.

🇧🇪Belgium ericvl

@jcnventura : any idea when this can be released? no beta I mean.
thanks

🇧🇪Belgium ericvl

@Anybody - Yes, it works now with this beta3 release.
Great job - Thank you.
Have a nice day

🇧🇪Belgium ericvl

@Grevil
Thank you very much for the clear explanation why the 1.10 doesn't support D10 anymore.
This was a logical move to do but I understand the issue from @komlenic too.
@Anybody
I know this is open source and everybody is glad to use it.
I spend allready a lot of time to help people and make things easier for everyone.
My comment was not ment to blame someone. I do apologize if you thought so.
Greetings

🇧🇪Belgium ericvl

@komienic

You are right. Therefor, I never updated to version 1.10 and stayed at 1.09 because this version was drupal 9 and 10 compatible. I then moved to te 2.0 version with "composer require drupal/captha..." and not "composer update...".
My opion then was that the 1.10 version was rather a downgrade than an upgrade because they removed the D10 compatibility. This was IMHO not a good solution for another bug. The bug should have been resolved and not by removing the compatibility.
So you should do the jump from 1.09 to 2.x.

🇧🇪Belgium ericvl

Remark: The example in the settings page of image_captcha is OK.
Only the thumbnails of Tuffy, Tuffy Bold and Tesox are not shown.

🇧🇪Belgium ericvl

@Matroskeen,

First of all, thanks for the patch in #9 but I've checked the patch and find that the function "denormalize" in the file "src/Normalizer/FileEntityNormalizer.php" should also have a returnvalue of "mixed" in stead of "array|string|int|float|bool|\ArrayObject|NULL".
Just like in all other denormalize functions in the other files.
Can you confirm this and eventually create a new patch, please?
Thanks

🇧🇪Belgium ericvl

Hallo,

There is a new version of the google/recaptcha package since Feb. 18th. It's version 1.3.0.
This is the version that should be compatible with PHP 8.
Should it not ne advisable to make a new version of this package here that is dependent on ^1.3 in stead of ^1.2?
We need this to be compatible with Drupal 10.
Greetings.

🇧🇪Belgium ericvl

EricVL made their first commit to this issue’s fork.

🇧🇪Belgium ericvl

@Prashant.c
Yes, it extends from EntityReferenceFieldItemNormalizer but not from the one in core. It should extend from the EntityReferenceFieldItemNormalizer in the same folder (src/Normalizer) of the module. And if you delete the "use" line in the file, it will extends the one in the same folder.
I think, this was copied from another module, created a new EntityReferenceFieldItemNormalizer in the module and forgotten to delete the original line.
If you use the patch, it will work.

🇧🇪Belgium ericvl

Hello,

The issue has not been seen until now because most people didn't change the (default) settings of the filefield_paths module. These settings were somewhere hidden inside the settings of the /admin/modules and then choose this module. These default settings were always public://. And this selection worked out.
Changing the settings to temporary:// on previous versions didn't work neither.

Now, from beta6 on, these settings are changed to temporary:// by default and this doesn't work like before. Also a new settings page is created in admin/config/media/file-system/filefield-paths next to the admin/config/media/file-system settings page, so that users can more easily change the settings and most imported: it is more visible.

So, if you used the settings public:// before in beta5 and earlier versions and you don't want to use the temporary path for your temporary files when you create or edit a node then first go to admin/config/media/file-system/filefield-paths and change it back to public:// like it was before in beta5. This way, you wil see your thumbnails again.

Greetings

🇧🇪Belgium ericvl

A few tests I made.

My original setup had no private path set in settings.php so I've set it to a specific folder outsite the web directory, on the same level of the temporary folder. I had to confirm the settings in /admin/config/media/file-system and clear the caches.
Then, I updated the module from beta 5 to beta 6 and run update.php.

My settings in admin/config/media/file-system/filefield-paths are set to temporary://filefield_paths.
When I create a new node with an image then the thumbnail is not visible and when I inspect the location of the file it reads <img data-drupal-selector="edit-field-image-0-preview" src="/site10/web/system/temporary?file=styles/thumbnail/temporary/filefield_paths/kippen2023.jpg&amp;itok=6VN5sNjz" width="100" height="75" alt="" loading="lazy" class="image-style-thumbnail">.
I can not find any thumbnail file in the temporary folder that correspond to the file uploaded and that is the reason why the thumbnail is not seen.

Second test:
I change the settings in admin/config/media/file-system/filefield-paths to private://filefield_paths.
I create again a new node and add the same image. The image is now visible and when I inpect the location of the thumbnail file again it reads <img data-drupal-selector="edit-field-image-0-preview" src="/site10/web/system/files/styles/thumbnail/private/filefield_paths/kippen2023.jpg?itok=j7MjYfJJ" width="100" height="75" alt="" loading="lazy" class="image-style-thumbnail">.
Now I can find a file that correspond the file uploaded in the private folder and everything is fine now.

So the beta 6 version only works:
1. if you specify a private folder in settings.php AND
2. use the private://filefield_paths settings and NOT the temporary://filefield_paths settings.

Since using a private path is not the default settings in a new installation nor for those that have never the need to use it, this update does NOT work for the most of us.

Please a look to my findings. Maybe some light is coming in the darkness now.

🇧🇪Belgium ericvl

This is normal. Even for all modules.
Composer only adds or removes files from the specified installation but does nothing in the database to enable or disable the added or removed module.
Before you remove the module, you should first disable the module and then let composer remove it. This will adapt core.extensios first. It is not good practice to let module be in the enabled state and then remove the entire module.
my 2 cents

🇧🇪Belgium ericvl

I have this problem too.
The main question is now: is this theme compatible with Drupal 10 or not because it refers to modules that are removed in 10???

Production build 0.71.5 2024