JSON API integration

Yes, that sound good !! I try to found time to purpose a prototype to test it fasT.

Hello, I also need the image-crop relationship!!

I come back to this subject today, I'll try to purpose a relationship fast.

hii @berdyshev

The permission "administer crop" is required to get the crop entity (/jsonapi/crop/focal_point/{uuid?})

This seem's not be an Crop API issue because this storage entity isn't not designed to only work with "focal_point" concept but more Crop zone in space. I see more anything like (/jsonapi/crop/{uuid?}) or (/jsonapi/crop/{crop_type}) for final endpoint ?

I need to test more but normally all entities 'standard' does work with jsonapi discover no ? I come back fast with information about that ...

Another thing the possibility to create crops for given uri sound great IMHO with jsonapi / graphQL integration ? We need to see what you need to achieve that wonderfull feature for API-first app building by Drupal.

I test Crop api basic integration. Actually Crops are available with "api/crop/{crop_type}" and "api/crop/{crop_type}/{uuid}"

Here you have a small representation of what that endpoint can display :

{
    "data": [
        {
            "type": "crop--crop_16_9",
            "id": "4345d944-c5e8-4611-a596-7fc1f1f530ac",
            "attributes": {
                "cid": 1,
                "uuid": "4345d944-c5e8-4611-a596-7fc1f1f530ac",
                "vid": 1,
                "langcode": "en",
                "entity_id": 230,
                "entity_type": "file",
                "uri": "public://2017-10/Bibury-England.jpg",
                "height": 544,
                "width": 973,
                "x": 1831,
                "y": 1008,
                "revision_timestamp": 1509093093,
                "revision_log": null,
                "default_langcode": true
            },
            "relationships": {
                "type": {
                    "data": {
                        "type": "crop_type--crop_type",
                        "id": "fe390f76-5b54-451d-968b-d139b626020f"
                    },
                    "links": {
                        "self": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac/relationships/type",
                        "related": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac/type"
                    }
                },
                "revision_uid": {
                    "data": {
                        "type": "users",
                        "id": "11f483d2-a1fb-47f0-9e11-ffb21f014f62"
                    },
                    "links": {
                        "self": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac/relationships/revision_uid",
                        "related": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac/revision_uid"
                    }
                }
            },
            "links": {
                "self": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac"
            }
        }
    ],
    "links": {
        "self": "http://contenta.local/api/crop/crop_16_9"
    }
}

I admit in this state this is not really pretty and easy to use in contenta context or simple jsonApi context.

We need to have more reflexion about where we need to access Crop ressources ? IMHO the best place is a relationship onto File representation ? or directly at basis of field_xxxx data ? Like

                "image_cropped": {
                    "data": {
                        "type": "files",
                        "id": "bb03b3b7-b27e-41a4-bdba-401d714af8b5",
                        "meta": {
                            "alt": "",
                            "title": "",
                            "width": "2560",
                            "height": "1600"
                            >>>>"crop": "my_crop_type" or uuid or true / false to be sure that ressource contain a link with crop<<<<
                        }
                    },
                    "links": {
                        "self": "http://contenta.local/api/pages/64bed44b-8cc1-40c8-9d22-03cb5e91b100/relationships/image_cropped",
                        "related": "http://contenta.local/api/pages/64bed44b-8cc1-40c8-9d22-03cb5e91b100/image_cropped"
                    }
                }
            },

I'm really open to all suggestions about how crops can be integrated ?

As you can see, there are no relationship or attributes related to the Crop data. That's why I need to make another request to /jsonapi/crop/focal_point?filter[entityId][condition][path]=entity_id&filter[entityId][condition][value]=651 and get these details:

The main problem of that, is this work only in Focal Point approach and here we need more robust and common implementation.

In #decoupled slack room we have started to found solutions because Crop are a hard problem to be managed with JsonAPI (@see this excellent article ==> https://www.lullabot.com/articles/decoupled-drupal-hard-problems-image-s... ).

Here you are the discuss from Slack on that subject :

First thing with @dawehner

dawehner [17 h 31]
@woprrr Have you seen how the
```consumer_image_styles```
module exposes image style urls? I'm wonderin whether you could do something similar

Second part on #decoupled room :

gabesullice [15 h 33]
@woprrr I'm happy to talk it through with you. We had some discussions about handling image styles in the JSON API module and decided against including anything like a relationship to a styled version of the link. Including putting something in the "meta" section.

[15:36]
The general conclusion was that image styles/crops are a presentational decision and therefore should not be included in the data returned in the response.

woprrr
[17 h 03]
@gabesullice In this case that should be great to add relationship onto Files ?

[17:03]
That seem’s hard to make a link with crop and files at this current state

gabesullice [17 h 06]
I think the only way to add a relationship onto an entity is to add a computed entity reference field

[17:06]
there's really no way to hook in and add one @woprrr

Another suggestion is why not expose ALL crop types effects and filter crops by specific rights ? (Only a suggestion to found better solution...).

@gabesullice Have you an example or whatever usefull to illustrate your idea ?

@woprrr, unfortunately, I don't have an example for creating a computed field that I can share. To do so, you will need to implement hook_entity_type_build_alter and add a new field definitions to all the entities which have image fields. To be clear, I think this is a bit of a hack, but it would "get the job done".

If you read @e0ipso's blog, you might be able to take some inspiration from his module, https://www.drupal.org/project/consumer_image_styles.

This overrides the image field normalizer to add "meta" information about image styles. This is most like your proposal for the JSON output. Unfortunately, this method only works when one module overrides the normalizer. I.e., multiple modules trying to add different information under the "meta" key will conflict with one another.

> This overrides the image field normalizer to add "meta" information about image styles. This is most like your proposal for the JSON output. Unfortunately, this method only works when one module overrides the normalizer. I.e., multiple modules trying to add different information under the "meta" key will conflict with one another.

That is the sad truth. However we can use service decorators to play nicely. I'd love to review a patch in that direction if that's not the case (I can't remember now).

Hi,

For information, there is a related issue in Entity Share #3220320: Support Crop API.

Created MR to add computed field which contains crop data for image. Now it should be available in jsonapi relationships under "crop"

Thank you @sickness29!

We're running Crop 8.x-2.4 and Drupal 10.3.2. We applied MR !9 and tested @grimreaper's #3220320: Support Crop API. Our setup is now bringing over the crops and displaying images as our users desire. We did have a locked policy that needed updating in order for the shares to bring over the content.

Bumping for inclusion - we have tested in our instance for over 8 months now. Additionally, two other members of the community have confirmed that this is working for our use in conjunction with Entity Share - https://www.drupal.org/project/entity_share/issues/3220320

Note: the administer crop permission is required to fetch information about crops through JSON:API. Ideally, there would be a separate permission to view crops.

There's still an issue here: if a file has multiple crops of the same type, all these crops are returned. In CropStorageInterface::getCrop() a database query fetches all crops keyed by type, making sure that only the last crop of each type is returned. The Crop API module currently has no way to expose old crops, so I think we should keep that consistent here.

This merge request introduces several improvements and fixes related to Crop API and its integration with other systems like Entity Share:

• Adds a “view only” permission for crops.
• Introduces an access controller to handle the new permission.
• Exposes selected fields in Entity/Crop.php to JSON:API when the new permission is granted.
• Updates the parent entity timestamp when a crop changes. This ensures that tools like Entity Share can detect when the parent entity (file/media) has changed due to crop modifications. Without this, remote sites would not re-import updated crop data.

Notes and caveats

This is my first major patch, so I expect some tests to break and anticipate that new functional tests will be required. I’m very open to feedback and eager to make this release-ready — I’m happy to adjust the implementation based on reviewer guidance.

Regarding the parent entity timestamp logic: this was the only reliable way I found to get crops to re-import through Entity Share after updates (initial imports worked, but subsequent updates did not). I explored adding a dedicated changed field, but the current timestamp update was the most effective solution. That said, it still feels like a workaround that might be better addressed more directly in this or a related update.

For more background, see:

• Entity Share issue: Entity Share needs to support Crop API
• Related investigation: Crop API - Crop Updates and Entity Share

Also note that I applied the following patch for compatibility in my environment:

“Crop API is not appending a hash when the image styles are converted to WEBP” — Merge Request #20

This work has been submitted as a separate merge request to avoid disrupting any existing workflows depending on the previous patch.

Ran into issues after implementing my initial patch. Entity Share still needed admin access to view the crops.

Problem: Exposing crop data via JSON:API for use with Entity Share required granting anonymous users administer crop types and administer crop — full admin permissions — because no read-only access path existed.

Changes made in the most recent patch

Access control (CropAccessControlHandler, CropTypeAccessControlHandler, CropType.php): Added a new view crop permission that grants read-only view/view label access to both crop content entities and crop_type config entities. CropType previously had no custom access handler at all, so all operations fell through to the admin permission. A new CropTypeAccessControlHandler was added and registered on the entity. CropAccessControlHandler was also corrected — its view fallback was pointing to administer crop types instead of the crop entity's own administer crop permission, and checkCreateAccess was added to prevent JSON:API schema introspection from requiring admin access.

Entity ID reconciliation (Crop::preSave): When Entity Share imports a crop from a remote site, the crop's entity_id (an integer FK) holds the source site's ID, which differs from the local entity ID for the same file/media. This caused the crop to be invisible to the local media entity's computed field, and image_widget_crop would create a new default full-size crop on top of it — producing the wrong (full-size) crop on the client. preSave now detects when entity_id does not resolve to a real local entity and reconciles it to the correct local ID by looking up the file by URI.

URI fallback in CropFieldItemList: The computed crop field queried only by entity_id + entity_type. Added a URI-based fallback query (the same key used by CropStorage::getCrop() and CropEffect) so imported crops are always surfaced even if entity_id hasn't been reconciled yet.
Display visibility (crop.module): Removed setDisplayOptions('view', ...) and set setDisplayConfigurable('view', FALSE) so the computed field is never rendered in entity view displays and never written into display config exports.

I also added tests for the functionality that was added.