Merge request ready for review!
I also noticed that "client_id" was misspelled in config/install/farm_farmlab.settings.ym so I fixed that in a second commit in the same MR.
m.stenta → created an issue.
Rebased onto new 2.x branch.
m.stenta → created an issue.
I created a farmOS Integrations module: https://www.drupal.org/project/farm_integration →
And opened a merge request that adds FarmLab to the Integration menu (with a dependency on the module).
This is a breaking change (new dependency), so it will require a 2.0.0 release.
m.stenta → created an issue.
Thanks @pcambra!!
PR is ready for review: https://github.com/farmOS/farmOS/pull/960
Merged into 2.x.
@dmitry.korhov It isn't the getSupportedTypes() method that's at issue, it is the normalize() method.
See this commit in the MR: https://git.drupalcode.org/issue/jsonapi_schema-3431487/-/commit/7f424f1...
(Originally cherry-picked from 🐛 PHP8.3 compatibility issues Active )
This is the fatal error that it fixes:
Fatal error: Declaration of Drupal\jsonapi_schema\Normalizer\DataDefinitionNormalizer::normalize($entity, $format = null, array $context = []) must be compatible with Symfony\Component\Serializer\Normalizer\NormalizerInterface::normalize(mixed $data, ?string $format = null, array $context = [])
Is there a way to support that in Drupal 10 and 11? I would be happy to adjust the MR if there is, but if not then I think this is the best we can do.
The 4.x branch is officially open! I created a 4.x-dev release, so now we can categorize issues accordingly.
This seems to be a bug with MySQL: LIMIT clause results in duplicate data across pages
We run Drupal on PostgreSQL and it is also an issue in that context.
We have been consistently hearing about it from API users of
farmOS →
, and we just tell everyone to add a ?sort=drupal_internal__id to their queries. We do this automatically in our farmOS.js and farmOS.py API libraries to save our users the headache and head scratching when they can't find records in the API endpoints or find duplicate records.
But this really should be fixed in core IMO. This is a major bug with the jsonapi module in my opinion, and it is not documented anywhere.
@dmitry.korhov See my comment #10 above.
Drupal 11 upgrades Symfony from version 7, which changes the method signatures in Symfony's NormalizerInterface. I think this means we need to drop support for Drupal 10.
Thanks @nununo! We have an existing feature request open for this: [#]
I've copied your description into this comment for reference: https://www.drupal.org/project/farm/issues/2786107#comment-16073247 ✨ Option to filter assets by area AND include child areas Active
Closing this as a duplicate.
A similar request was made for this, so I'm going to close it as a duplicate of this, but copy over the description for reference:
Problem/Motivation
I would like to be able to list which Plants are in a particular bed, but also which Plants are in a particular Field, since my Beds are hierarchically grouped under Fields.
I guess this functionality could probably be available in all kinds of Assets, even though I need it specifically in Plant assets.
Steps to reproduce
When I go to page Records > Assets > Plant, I can filter by a lot of different fields like Name, Season, Crop/Variety, etc. But I cannot filter by Location.
Proposed resolution
Implement the functionality to allow the filter to also take Location into consideration and make the field available in the filters form. Also, bear in mind that, ideally, this filtering should be done recursively: report all Assets that are at a given Location but also all Assets that are at locations that are children of that given Location.
@paul121's context PR: https://github.com/farmOS/farmOS/pull/904
I opened a PR that changes how we maintain CHANGELOG.md moving forward: https://github.com/farmOS/farmOS/pull/948
I also started a draft PR for starting an official 4.x branch: https://github.com/farmOS/farmOS/pull/949
Once we merge that, then we can push it to https://git.drupalcode.org/project/farm and create a 4.x-dev snapshot, which will allow us to start referencing that version in this issue queue.
Discussed this on the farmOS dev call today. We will probably just make the changes to the farmOS (and Log module) plugins in the 4.x-attributes branch, rather than trying to get it into 3.x.
There is a draft PR for a Rector rule that automates this conversion here: https://github.com/palantirnet/drupal-rector/pull/308
I'll reverse that commit and see if it makes any difference. First look is that it's only the category name that has changed. Hard pressed to think that would make a difference.
That was my thought too, but maybe the category gets used somewhere along the way. Just a guess...
@elc What version of Drupal core and Fraction are you using?
I wonder if this change has anything to do with it?
https://git.drupalcode.org/project/fraction/-/commit/f34523b9fe859f80745...
That is the only substantive change to the 2.x branch since January.
Key to it is that
$field->field_alias == 'unknown'for all of the Fraction fields in a view. That was causing the complete failure of what this patch was doing.
Otherwise, I wonder if something changed in Drupal core / Views that could explain the new behavior you're seeing. 🤔
I have tested and updated the merge requests for both of the contrib module's we're waiting for:
entity_reference_validators: 📌 Automated Drupal 11 compatibility fixes for entity_reference_validators Needs reviewjsonapi_schema: 📌 Automated Drupal 11 compatibility fixes for jsonapi_schema Needs review
With both of these in place, I was able to successfully install farmOS 4.x on Drupal 11 in my local dev environment! 🎉
There were a bunch of new PHPStan errors, so I fixed those as well. PHP CodeSniffer and Rector are both clean. I have not run automated tests yet (it will be easiest to do that via GitHub Actions).
I will rebase and push all my 4.x-* branches to my GitHub fork once we release 3.4.4. Then we can consider if we're ready to start an official 4.x branch and start opening PRs against it.
Pushed a commit that fixes the /api/[entity-type]/[bundle]/resource/schema routes.
This Drupal core change record describes the change that was necessary: https://www.drupal.org/node/3359695 →
Back to Needs Review!
The root /api/schema endpoint and collection endpoints (/api/[entity-type]/[bundle]/collection/schema) seem to be working.
Not working yet...
I tried to view a schema endpoint (/api/[entity-type]/[bundle]/resource/schema) in my browser and the following error occurs:
Uncaught PHP Exception Symfony\\Component\\Serializer\\Exception\\NotNormalizableValueException: "Could not normalize object of type "Drupal\\Core\\Field\\BaseFieldDefinition", no supporting normalizer found." at /opt/drupal/vendor/symfony/serializer/Serializer.php line 181
Opened a merge request with @volha_si's commit from 🐛 PHP8.3 compatibility issues Active (I updated the commit message to be more descriptive of its purpose, but kept the author credit).
I also added a commit that drops support for Drupal 8, 9, and 10. So this will need to be a new major release (not on the 8.x-1.x branch) - pending @bradjones1's response to my question above (#10).
I will do more testing locally and report back if I find any other issues.
Thanks @volha_si!
Quoting myself from 📌 Automated Drupal 11 compatibility fixes for jsonapi_schema Needs review :
This error is actually a result of changes in the upstream Symfony class that we extend from. So I don't think it's specific to PHP 8.3.
We can probably close 🐛 PHP8.3 compatibility issues Active as a duplicate of this issue, and incorporate the MR changes into here. I'll start a new MR and cherry-pick them over.
I'm going to close this as a duplicate and see if I can incorporate your changes into 📌 Automated Drupal 11 compatibility fixes for jsonapi_schema Needs review .
@m.stena Probably related to this: https://www.drupal.org/project/jsonapi_schema/issues/3504440 🐛 PHP8.3 compatibility issues Active
Thanks @alexander-tallqvist!
This error is actually a result of changes in the upstream Symfony class that we extend from. So I don't think it's specific to PHP 8.3.
We can probably close 🐛 PHP8.3 compatibility issues Active as a duplicate of this issue, and incorporate the MR changes into here. I'll start a new MR and cherry-pick them over.
Fatal error: Declaration of Drupal\jsonapi_schema\Normalizer\DataDefinitionNormalizer::normalize($entity, $format = null, array $context = []) must be compatible with Symfony\Component\Serializer\Normalizer\NormalizerInterface::normalize(mixed $data, ?string $format = null, array $context = [])
I think fixing this is going to necessitate dropping support for Drupal 10.
@bradjones1: I see that you have started a 2.x (and 2.0.x) branch that makes some of these changes already. Should I base a MR off of one of those? I can't find any mention of them in the issue queue, and there are a number of other changes. Any guidance you can provide on your intentions would be appreciated! I want to help push this forward, but don't want to step on toes or duplicate efforts.
I tested installing on Drupal 11.1.5 and it failed with the following error:
$ drush en jsonapi_schema
Fatal error: Declaration of Drupal\jsonapi_schema\Normalizer\DataDefinitionNormalizer::normalize($entity, $format = null, array $context = []) must be compatible with Symfony\Component\Serializer\Normalizer\NormalizerInterface::normalize(mixed $data, ?string $format = null, array $context = []): ArrayObject|array|string|int|float|bool|null in /opt/repos/jsonapi_schema/src/Normalizer/DataDefinitionNormalizer.php on line 53
[warning] Drush command terminated abnormally.
I had to fix this in farmOS as well, so I'm familiar with the solution. I'll work on this...
Thanks for testing @onfire84 and @alexander-tallqvist.
Let's get confirmation that this works on Drupal 11. Setting back to Needs Review.
Rebased onto 11.x.
The biggest change was to move the node and taxonomy hook implementation changes to Hook classes, since 📌 [ignore] Convert everything everywhere all at once Active was merged.
Also attached (and hidden) is a patch that works with 11.1.x, since that has some slight differences, and is useful for applying to the current stable release (11.1.5) via cweagans/composer-patches.
I wonder if we should consider deprecating the Asset/Log/Plan/etc events, and just recommend using the core hooks as intended.
I opened this related issue, which IMO we should tackle first: 📌 Convert all procedural hook implementations to Hook classes Active
Postponing this issue, but let's review it in more detail to see if there's anything we can work on or plan for in the meantime.