Add Drupal 8.7 JSON:API support

[chrfritsch]

When currently requesting jsonapi with a GET on https://thunder.test/jsonapi/node/article, I get the following error.

{
    "jsonapi": {
        "version": "1.0",
        "meta": {
            "links": {
                "self": {
                    "href": "http://jsonapi.org/format/1.0/"
                }
            }
        }
    },
    "errors": [
        {
            "title": "Bad Request",
            "status": "400",
            "detail": "The following query parameters violate the JSON:API spec: 'q'.",
            "links": {
                "via": {
                    "href": "https://thunder.test/jsonapi/node/article"
                },
                "info": {
                    "href": "http://jsonapi.org/format/#query-parameters"
                }
            }
        }
    ]
}

I tried to apply the fix from weprovide/valet-plus#268, but that didn't work for me.

[drogers98]

So, not optimum, but changing line 60-62 of DrupalValetDriver.php from:
if (!isset($_GET['q']) && !empty($uri) && $uri !== '/') { $_GET['q'] = $uri; }
to:
if (!isset($_GET['Q']) && !empty($uri) && $uri !== '/') { $_GET['Q'] = $uri; }

Fixed this for me. Think it is to do with jsonapi expecting camel/upper case. Not 100% sure what else this would affect, if any, so not submitting a patch, but this did the trick for me locally for now.

remember to run "valet restart" and clear drupal cache, if you go this route.

[wimleers]

It sounds like Laravel Valet is rewriting example.com/foobar to example.com/index.php?q=foobar — i.e. it sounds like it's causing routing to not use clean URLs anymore internally?

[dustinleblanc]

I've temporarily made my local driver look like this:

<?php

class LocalValetDriver extends DrupalValetDriver
{
    /**
     * Get the fully resolved path to the application's front controller.
     *
     * @param  string  $sitePath
     * @param  string  $siteName
     * @param  string  $uri
     * @return string
     */
    public function frontControllerPath($sitePath, $siteName, $uri)
    {
        $sitePath = $this->addSubdirectory($sitePath);
        $matches = [];
        if (preg_match('/^\/(.*?)\.php/', $uri, $matches)) {
            $filename = $matches[0];
            if (file_exists($sitePath.$filename) && ! is_dir($sitePath.$filename)) {
                $_SERVER['SCRIPT_FILENAME'] = $sitePath.$filename;
                $_SERVER['SCRIPT_NAME'] = $filename;
                return $sitePath.$filename;
            }
        }
        // Fallback
        $_SERVER['SCRIPT_FILENAME'] = $sitePath.'/index.php';
        $_SERVER['SCRIPT_NAME'] = '/index.php';
        return $sitePath.'/index.php';
    }
}

[fabianderijk]

For me this is still an issue.

For some reason or another the workaround from @dustinleblanc doesn't work for me. Placed the file in the root of the site and theres an error: Call to undefined method LocalValetDriver::addSubdirectory() which is correct, because it exists in DrupalValetDriver what somehow doesn't get found.

Is there a solution? Because this needs to be fixed in valet IMHO

[fabianderijk]

Wow, after some fiddling around, I found out that I'm using the url http://example.test/jsonapi, this returns the error, the url http://example.test/jsonapi/ (see the final slash) works.

[dustinleblanc]

@fabianderijk did you make sure to extend the Drupal driver? I think the function it calls is in that class. Might be an issue with your locally installed version of valet since the driver has changed a few times

[MichaelBrauner]

@dustinleblanc your solution worked for me. But is this a "secure" solution for my projects or will it affect the behavior of drupal in the future?

[dustinleblanc]

@Slowwie, no idea, its been a long time since I did this and I don't even use Valet for most of my localdev anymore since moving my primary dev over to Windows and WSL2. The only projects I am really doing on my mac these days use good ol php artisan serve and drush rs to get things done. In regards to "secure" in the context of localdev, when I write stuff like this I have less than zero idea if there were some kind of security issue, but I don't see how modification of a valet driver like this would cause any kind of security issue.

[MichaelBrauner]

Ok, thank you!

[BurningDog]

This issue is still a problem. #771 (comment) fixed it for me. I'm not sure why this issue is closed? Can I put a PR together?

[mattstauffer]

@BurningDog Please feel free to PR If it's a needed fix :)

[BurningDog]

Thanks! PR added! It's needed for me and my team, so that we don't have to manually patch DrupalValetDriver.php.