API Platform 3.2

[soyuka]

Please report 3.2 issues here:

composer config minimum-stability beta
composer update api-platform/core
composer recipes:update 

[divine]

Hello!

I'm currently migrating one of the 2.6 projects.

JFYI the migration process is from scratch (install the new 3.2 version and migrate the files one by one I know it might take a longer time but would like to make sure that I'm using the latest features).

1. Serializer error:
   Blank APP install visiting https://localhost throws an error in profiler:

Uncaught PHP Exception Symfony\Component\Serializer\Exception\UnsupportedFormatException: "Serialization for the format "html" is not supported." at /app/vendor/symfony/serializer/Serializer.php line 134

Visiting https://localhost/docs/ doesn't throw anything.

This is the line problematic line (source):

    docs_formats:
        jsonld: ['application/ld+json']
        jsonopenapi: ['application/vnd.openapi+json']
        html: ['text/html']

EDIT:
Sometimes it throws an 404 error Format "html" is not supported:

core/src/Symfony/EventListener/AddFormatListener.php

Lines 76 to 79 in 7ebff27

	} elseif (!isset($formats[$routeFormat])) {
	if (!$request->attributes->get('data') instanceof \Exception) {
	throw new NotFoundHttpException(sprintf('Format "%s" is not supported', $routeFormat));
	}

EDIT:

Created a PR api-platform/api-platform#2523

2. Docker vendor folder isn't copied to container:

Looking at docker-compose.override.yml file and commenting out the line:

      # If you develop on Mac or Windows you can remove the vendor/ directory
      #  from the bind-mount for better performance by enabling the next line:
      - /app/vendor

Doesn't start the container, throwing frankenphp error:

 Fatal error: Uncaught LogicException: Symfony Runtime is missing. Try running "composer require symfony/runtime". in /app/bin/console:8
| Stack trace:
| #0 {main}
|   thrown in /app/bin/console on line 8

That's all for now, continuing the migration and I'll let you any issues I'm having.

Thanks!

[vincentchalamon]

@divine I can't reproduce your bug.

Starting from a fresh install of api-platform/api-platform, then starting the project thanks to docker compose up --build --wait, going to https://localhost, I don't see any error...

Can you try to clean your local environment just in case you're using an old version of containers?

[paullallier]

I'm going to need it to allow #[ApiProperty(schema: ['type' => 'string'])] to override the assumed type on an entity variable when generating the schema, like it does with 3.1.x please. I had a look it how it works in 3.1 and I think it's far beyond my skill level to PR it myself, unfortunately.

I guess there might be some other overrides from ApiProperty which we want too - but schema is the only one I'm using.

An example would be:

    #[ORM\ManyToOne(targetEntity: User::class)]
    #[ORM\JoinColumn(name: 'inserted_by', referencedColumnName: 'id', nullable: false)]
    #[ApiProperty(schema: ['type' => 'string'])]
    private string $insertedBy;

[paullallier]

Thanks guys - I'll try it over the weekend and make sure my issue is fixed (I suspect it is).

[divine]

@divine I can't reproduce your bug.

Starting from a fresh install of api-platform/api-platform, then starting the project thanks to docker compose up --build --wait, going to https://localhost, I don't see any error...

Can you try to clean your local environment just in case you're using an old version of containers?

Ok, I'll try again and let you know.

Another behavior changes:

Order of the data has changed (previously):

{
  "@context": "/contexts/Book",
  "@id": "/books",
  "@type": "hydra:Collection",
  "hydra:member": [
    {
      "@id": "/books/1",
      "@type": "Book",
      "id": "1",
      "name": "test"
    }
  ],
  "hydra:totalItems": 1
}

Now 3.2 (see '"hydra:totalItems": 1' moved above "hydra:member")

{
  "@context": "/contexts/Book",
  "@id": "/books",
  "@type": "hydra:Collection",
  "hydra:totalItems": 1,
  "hydra:member": [
    {
      "@id": "/books/1",
      "@type": "Book",
      "id": "1",
      "name": "test"
    }
  ]
}

This might break some tests.

Ok, another "bug" or "behavior change that I've found:

This is the code with custom controller to return currently authenticated user:

#[ApiResource(
    operations: [
        new Get(
            uriTemplate: '/myself',
            controller: GetUserController::class,
            security: 'is_granted("IS_AUTHENTICATED_FULLY")',
            read: false,
        ),
    ]
)

This is the controller:

<?php

namespace App\Controller;

use App\Entity\User;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Security\Core\User\UserInterface;

class GetUserController extends AbstractController
{
    public function __invoke(): UserInterface
    {
        /* @var User $user */
        return $this->getUser();
    }
}

Previous version:

{
    "@context": "\/contexts\/User",
    "@id": "\/users\/1",
    "@type": "User",
    "id": "1",
    "username": "test",
    "createdAt": "2023-10-01T22:16:56+00:00",
    "updatedAt": "2023-10-01T22:16:56+00:00"
}

Now:

{
    "@context": "\/contexts\/User",
    "@id": "\/myself",
    "@type": "User",
    "id": "1",
    "username": "test",
    "createdAt": "2023-10-01T22:16:56+00:00",
    "updatedAt": "2023-10-01T22:16:56+00:00"
}

@id field should be "@id": "\/users\/1" instead of "@id": "\/myself".

Otherwise new version looks neat even though I'm still having an issues with custom DTO which I gave up as it generates weird open api documentation, I might add more details if you're interested to take a look.

Thanks!

[vincentchalamon]

@divine do you have other operations on your User resource? Can you copy/paste the complete resource code please? The order of the operations matters!

[dannyvw]

We have added a custom serialized name on a property like this <attribute name="endDate" serialized-name="publishedUntil"> and with API Platform 3.2 the properties don't return the serialized name in the violation response.

Before/after

      -    "hydra:description": "publishedUntil: This value should be after the start date.",
      +    "hydra:description": "endDate: This value should be after the start date.",
           "hydra:title": "An error occurred",
           "violations": [
               {
                   "code": "778b7ae0-84d3-481a-9dec-35fdb64b1d78",
                   "message": "This value should be after the start date.",
      -            "propertyPath": "publishedUntil"
      +            "propertyPath": "endDate"
               }
           ]

[vincentchalamon]

Hi @dannyvw, can you provide a reproducer please, with the same environment you used to reproduce this issue (Doctrine ORM vs ODM or any other data provider, XML/YAML/Attribute format, etc.)? You can use https://github.com/api-platform/api-platform to create this reproducer

[divine]

@divine I can't reproduce your bug.

Starting from a fresh install of api-platform/api-platform, then starting the project thanks to docker compose up --build --wait, going to https://localhost, I don't see any error...

Can you try to clean your local environment just in case you're using an old version of containers?

Hello,

Here is a reproduction repository https://github.com/divine/apipbug.

I've removed only PWA as I don't use Next.js frontend.

Run the following commands from documentation:

docker compose build --no-cache
docker compose up --pull --wait 

Thanks!

@divine do you have other operations on your User resource? Can you copy/paste the complete resource code please? The order of the operations matters!

Even if keep only one operation it's still the same, @id field shouldn't be /myself. I'll try to check when this behavior was changed. Probably version 3.0?

Thanks!

[vincentchalamon]

@divine I've recreated a use-case for your User /myself bug using the demo, but still can't reproduce your bug:

Reproducer is available here: https://github.com/api-platform/demo/tree/test/user-myself

docker compose build
docker compose up -d

Then, go to https://localhost/docs, log in using authorize button, and use /myself sandbox endpoint.