Sorry Matt. Now I can see the reference to the 7.1 build.
I was too quick to respond.
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.
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
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.
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.
This is the related issue.
Related issue: is here. 📌 Uncaught TypeError: $(...).datetimepicker is not a function Needs review
@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
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...
@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.
@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
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
@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???
@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
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.
Duplicate of this issue 📌 Automated Drupal 10 compatibility fixes Fixed
@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.
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?
@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.
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.
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.
EricVL → created an issue.
@yuvania
This is the same patch as in #14.
See also remarks in #10 and #23.
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
@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
@jcnventura
I'm using this modification you sugested in #40 for months and it works.
The Project Bot in #2 is right.
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
@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
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
@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.
@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
@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.
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.
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
@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
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.
@jcnventura : any idea when this can be released? no beta I mean.
thanks
@Anybody - Yes, it works now with this beta3 release.
Great job - Thank you.
Have a nice day
@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
@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.
Remark: The example in the settings page of image_captcha is OK.
Only the thumbnails of Tuffy, Tuffy Bold and Tesox are not shown.
EricVL → created an issue.
@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
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.
@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.
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
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&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.
You're welcome
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
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???