johannschopplich / kirby-nuxt-starterkit

šŸ’š Kirby's sample site ā€“ ported to Nuxt and Kirby Query Language
https://kirby-nuxt-starter.pages.dev
MIT License
52 stars 2 forks source link

[KQL Setup] 500 Couldn't execute KQL query #1

Closed Maybach91 closed 2 years ago

Maybach91 commented 2 years ago

Hej,

thanks for your awesome starterkit! I was trying to follow the readme, but i got stucked at the part with the Bearer Token.

I installed my kirby installation just in a subfolder of my project and use valet to run kirby. Everything works on the kirby site. Also installed the kql plugin.

But when i run pnpm run dev i get the following error in the console:

(node:65589) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
Error loading site data: 500 Couldn't execute KQL query (/api/__kql__)

That also means that my localhost:3000 is empty, since nuxt cannot access to my kirby installation. is there a way to test, if KQL is correctly running in the kirby?

I tried to deactivate the auth and access kirby.test/api/__kql__ but i get a 404 ("No route found for path: \"query\" and request method: \"GET\"",)

Thanks in advance!

johannschopplich commented 2 years ago

Seems like you are using a bare bones Kirby instance with the KQL plugin, right? I highly recommend using the Kirby headless starter.

Have you followed the Getting Started instructions of nuxt-kql? Please take a look into the documentation. Some of your questions will work themselves out! The internal api/__kql__ route is intended as a proxy to fetch data from Kirby while protecting your credentials.

For testing locally, you can use the Kirby headless starter and the Nuxt instance will work out of the box, as it depends on this Kirby setup by default. In this regard, just follow the instructions of this repo, and you are ready to go.

Maybach91 commented 2 years ago

Yes, thank you. I just figured this out. I was already on the headless starter repo, but were wondering why the folders are different to kirby default installation, so i thought it was kinda a own starter or something. But after a short break and some more evening thoughts i got the idea that this could be the preconfigured kirby installation. :)

Also i was looking into the nuxt-kql Getting Started section and came to the conclusion that my bare kirby installation was not the right one. :)

So maybe just add to the README the hint, that you recommend the kirby headless starter. :) It wasnā€™t clear for me, that i need your explicit headless starter to make this repo work.

Maybach91 commented 2 years ago

I just tried everything, but somehow i still get the same error, even with the headless starter. I think i donā€™t need username + password as ENV-variables, since iā€™m using bearer token, right? How can i debug this? Is something wrong using valet for this? like KIRBY_BASE_URL=https://kirby.test as variable? šŸ¤”

It looks like it doesnā€™t get the ENV vars:

image

johannschopplich commented 2 years ago

Do you have Valet configured to use HTTPS? Isn't it just HTTP? You have to make sure Kirby is accessible.

You just need the authentication token. For a quick start, you can duplicate each .env.example files pf each repo (and adapt their values) to get an idea what you need for your local setup.

Maybach91 commented 2 years ago

Yes, i secured my local valet installation and its working (i can access it etc. and see the starterkit content).

I used the example ENV files. Just changed the KIRBY_BASE_URL to the valet one. :/

Even using https://kirby-headless-starter.jhnn.dev as KIRBY_BASE_URL is not working (i suppose it should work). It always tries to access localhost:3000/api/__kql__

johannschopplich commented 2 years ago

localhost:3000/api/__kql__ is correct. That's a Nuxt server API route to hide the Kirby auth credentials from the client (please take a look into the documentation), which then will fetch the actual data from the Kirby instance.

The contents from .env.example should just work... I can't reproduce the issue. Working fine locally as well as deployed. Maybe requests are somehow blocked on your machine?

Maybach91 commented 2 years ago

Okay, the .env.example is working. I will try to look into it tomorrow, maybe its too late to solve this now.

Maybach91 commented 2 years ago

Iā€™ve tried running kirby with php -S localhost:5000 (which works) and used http://localhost:5000 as KIRBY_BASE_URL, but this doesnā€™t work neither.

Iā€™m also using LTS Version of node and pnpm 7.11.0. Do you have any idea how to debug this further @johannschopplich? I did not customize anything.

Request blocking should be visible somewhere, but normally it works and i donā€™t block anything.

johannschopplich commented 2 years ago

The headless starter uses the public folder setup. Make sure to use composer start to use the Kirby router. php -S without the router won't be sufficient.

composer start calls php -S localhost:8000 -t public vendor/getkirby/cms/router.php under the hood.

But using Valet is easier, Kirby will run out of the box with the public folder setup.

Does Kirby itself work? Can you fetch queries in your browser by accessing <your-kirby.test>/about while having no bearer token set? Your Kirby instance doesn't seem to work. Have you followed the headless starter instructions?

Node dependencies should work fine. Even without pnpm.

Maybach91 commented 2 years ago

Hej @johannschopplich ,

thanks for your patience helping me. Unfortunately i cannot accesing kirby via localhost:8000 with no bearer Token. Even if i deactivate kql auth.

{
  "code": 401,
  "status": "Unauthorized"
}
 'api' => [
        'basicAuth' => false
    ],

    // Default to token-based authentication
    'kql' => [
        'auth' => false
    ]

But it shouldnā€™t work like this, right?

http://localhost:8000/api/query gets me Unauthenticated and with kql auth set to false i get the information about the site.

The bearer token still is test in both .env files, that should work, right?

nuxt-startkiter `.env` ``` NUXT_PUBLIC_SITE_URL= #KIRBY_BASE_URL=https://kirby-headless-starter.jhnn.dev KIRBY_BASE_URL=http://localhost:8000 KIRBY_API_TOKEN=test ```
headless kirby `.env` ``` KIRBY_DEBUG=true KIRBY_PANEL_INSTALL=true KIRBY_CACHE=false KIRBY_HEADLESS_API_TOKEN=test KIRBY_HEADLESS_ALLOW_ORIGIN=* KIRBY_HEADLESS_FRONTEND_URL= ```
johannschopplich commented 2 years ago

Both .env files are looking great. Basically, you'll only have to set the token for the backend and frontend, as well as the Kirby URL for the Nuxt frontend only. You don't have to touch the config.php for the starter kit at all.

If you can't open Kirby on your machine, it seems like an issue outside the scope of this project. Can you use Valet instead? What's the cli error when spinning up the Nuxt dev server? Unfortunately, I can't help you further on your machine-specific issuesā€¦

But it shouldnā€™t work like this, right?

The result looks fine. But we don't use the /api/query route, but the /api/kql route instead.

Maybach91 commented 2 years ago

I understand, i will look into this in more detail. Can you explain me what you mean with this:

Basically, you'll only have to set the token for the backend and frontend, as well as the Kirby URL for the Nuxt frontend only.

ā†³ as far as i understood it only needs to be the same "word" within the .env files, right? or is there something else?

To do so, set the environment variable KIRBY_HEADLESS_API_TOKEN with a token string of your choice.

johannschopplich commented 2 years ago

as far as i understood it only needs to be the same "word" within the .env files, right? or is there something else?

Yes, the token (environment variable value) itself has to be identical. The environment variable key differs tho.

It shouldn't be that hard. The setup should be done easily and quick; it's also working fine for other devs, that I know of. I have no clue what's the case for you.

Maybach91 commented 2 years ago

Okay, iā€™ve tried everything (reinstalling brew services, pnpm, upgrading etc.) on my M1 (i think this is one issue here). And the only solution to make it work was using http://[::1]:8000 instead of http://localhost:8000 in the env var. I still have some brew services issues, i cannot solve, but this fixed using this repo, finally.

Thank you so much @johannschopplich for your work and your help!

johannschopplich commented 2 years ago

Dang, never thought IPv6 would be the issue hereā€¦ Great learning! Thanks for sharing.

Have fun with the starter kit, at last. šŸ˜