dadish

Hi @markus_blue_tomato. Do you see your fields in PW admin? At Setup -> GraphQL page?

New Release v1.3.0 Adds support for Page interface. Updates webonyx/graphql-php to the latest version. Adds hook that enables to modify the GraphQL schema. (#26 @sebastiandittrich) Fixes error when creating/updating a page with DateTime field. (#28 @sebastiandittrich) @sodesign Not sure if you still need this but this release brings support for interfaces that I previously talked about. Hope you'll find it helpful.

You can add support for Repeater Matrix Fieldtypes via custom third-party modules. Refer to documentation on how you can create one. https://github.com/dadish/ProcessGraphQL#third-party-fieldtypes-support

You need to use the language field. In your graphql endpoint there is a language field. So it will look like { language(name:"<language_name_here>") test { list { testtext } } }

For some reason this is an issue only with this module. You're not the first one to stumble on it. I updated the Readme to add Troubleshooting section that explains this issue in details.

@Miguel Scaramozzino Also, just wanted to confirm with you that you're making request to the correct url. In default PW settings "/graphql" and "/graphql/" are different. If you happen to make a request to "/graphql" (without forward slash at the end) it will be redirected to "/graphql/" and the content of your POST request gets lost in the middle.

In your graphql template file. Try manually extracting the query and variables and passing them to ProcessGraphQL. Should looks something like this. <?php namespace ProcessWire; header('Content-Type: application/json'); $query = $input->post->query; $variables = $input->post->variables || []; echo json_encode($modules->get('ProcessGraphQL')->executeGraphQL($query, $variables), true); It might be slightly different how you extract the query but the bottom line is make sure you're getting it in your graphql template file and passing it to ProcessGraphQL.

Can you post the code in your graphql.php template file. My only guess is that something happening in that file.

I understand why you are asking for this feature. You're not the first one. But it's not as obvious as it seems. The 'title' field is not the same as all other built-in fields. You can't modify the behavior of the built-in fields per template basis. Which means they all behave the same no matter what template the page has. That's why we have a generic type 'Page' that has all the built-in fields. No matter what template the page we can confidently serve those fields for every page. The 'title' field's behavior could change depending on the template. I understand that it is almost never the case, but semantically it is. For example, you can set different access settings for 'title' field depending on the template. You make it that user can view the 'title' on one template and not on the other. You can change the description of the field for each template and it will appear in the GraphQL documentation. You can also make 'title' field 'not required' for one template and 'required' for others. So, including 'title' field into the Page type will break the semantics. I understand that 'title' field is almost always treated as a built-in field but I just can't overcome this feeling that it is the 'wrong' way to do it. I would like do it only the 'right' way. And the right way brings us to your second question. If we implement it properly and add the ability to get the values of the template fields for generic Page types, then 'title' field should also be solved. For this we will be adding interfaces. It will allow you to get template fields for Page types by providing a template. It will look something like this. { city{ list{ children{ # <== let's say children are the pages with template skyscraper and architect list{ id name ... on SkyscraperPage { # <== you basically say: "for skyscraper pages give me these fields" title images{ url width height } } ... on ArchitectPage { # <== "and for architect pages give me these fields" born email resume{ url filesize } } } } } } } this way you can fetch values for all template fields on Page types. This will work with everything that returns a Page type. Including 'child', 'children', 'parent', 'parents' and Page Reference fields too. And the best part is, it will be semantically correct! ?

@sodesign Ok, I think I found the problem. I was able to get the same error as yours and patched the module to fix it, just now. Try the latest version and let me know if the issue is resolved for you. New Release 1.1.4 - Fix FieldtypePage bug when FieldtypePage:derefAsPageOrNullPage option is enabled.

@sodesign First, I want to clarify some stuff. You are saying that you want to create a page and using a mutation field "createConfiguratorQuote" but supplying it with "ConfiguratorQuoteUpdateInput" which is an incorrect input type. You should supply "ConfiguratorQuoteCreateInput" for creating and "ConfiguratorQuoteUpdateInput" for updating a page. The "add" and "remove" for page references always expects an array of ids. So your latest format for variables is correct for creating a page. Just change UpdateInput type to CreateInput type. But, if you're trying to update a page then "page" input variable should include "id" field. It should look like this... variables: { "page": { "id" : 11111, // <=== you should tell which page you're trying to update. "name": "test-quote", "title": "Test Quote", "parent": "22905", "colour": { "add": [10392] } } } Let me know if I'm missing something.

Hello @Brett. Thank you for your feedback! I was able to reproduce your issue and hopefully tracked down the bug. Please, install the latest version and give it a try. Let me know if the issue is resolved for you. New Release 1.1.3 - Fixed bug with FieldtypePage returning only single value.

The children results only have with built-in page fields. They don't have template fields. You have to make sure the field title exists in GraphiQL before querying it. When you go to Setup -> GraphQL and enter the above query it will tell you that there is no "title" field for children list. If the field is not in your GraphQL schema you cannot query it. If you want to query your task pages with template fields like title, you can set them as a Page field like you do with your job_client field. That way your tasks will have all the template fields you enabled.

Nowhere. This is embarrassing. I forgot about language field when I rewrote the module for alternative graphql library. My bad, sorry. New Version 1.1.0 I updated the module to support languages now. Please upgrade and it should work fine. Sorry for inconvenience and thanks a lot for the feedback.

@charger I have no other ideas how to solve your case. Could you describe the steps to reproduce the error? You can take a starting point of any site profile and outline the steps to reproduce the issue. That would make it much easier for me to help you.

@charger Hmm. Did you try enabling view access to your repeater_product_groups template?

@charger So the bug you're facing is due to the fact that repeaters are pages under the hood and the module checks permission those pages as well and since you do not have view access enabled for your repeater template the values return empty. So in version 1.0.5 you just need to enable view access for your repeater template repeater_product_groups and the values should show up. But since you are already enabling view for your repeater field I think it's safe to assume that you want to enable view for template that used by that repeater field too. So for latest version 1.0.6 that I just released you don't have to enable access to your repeater templates. Just enabling access to your repeater field is enough. New Version 1.0.6 Just upgrade the module to the version above and let me know if it solves your problem.

@charger I was able to reproduce your bug. Will get back to you soon when I fix it.

Yes, it is probably a permission problem. For the page fields. You need to make sure the user has view permission for the pages in the page field. So in your case, you need to make sure that user has a view permission for product template. Not sure why the title and body are not showing up. But, If you are setting permissions in the template context, then you need to set them for the fields in your repeater too. Either via the repeater field settings or via the template that your repeater is using. That would be repeater_product_groups template, if I guessed the name correctly.

New Version 1.0.5 - Fixes empty value bug for FieldtypePage and FieldtypePage::derefAsPageOrFalse setting. @dragan I was trying to reproduce your bug but encountered different one which is also related to FieldtypePage. This probably not related to your bug but try it anyway when you have time.

That's fine. You should set it under legalFields config. The legalPageFields is for built-in fields like name, id, path, url, created and etc. I'm still not sure how this could be happening. You're the second person with this problem but I can't reproduce it. Page reference fields have title and I can query them on my installations. Is there any chance that you can reproduce this in any of the Site Profiles? Then you can export it with Site Profile Exporter and share with me. I will continue trying to reproduce it but it'll go faster if you help me with it.

No, it's not. The title field can be removed from the page. so it's not included by default. In your graphql documentation, does your page reference fields has a title field in them?

When you create a FieldtypePage field it can store a reference to any page. Which means the module cannot know which template those pages have upfront, which in turn means we cannot know which fields those pages will have when we generate the schema (except built in fields like id, name, url and etc). But if you set a particular template for selectable pages for that field, then it will detect it and additional template fields for your page references will be available. So my guess would be that your page reference field does not have a template assigned to it. Is that your case?

New Version 1.0.4 - Fixes empty value bug for FieldtypeInteger. @dragan I was able to reproduce error for FieldtypeInteger. Turns out ProcessWire returns an empty string instead of null when FieldtypeInteger is empty. That's why GraphQL schema was complaining about getting empty string instead of Int. Let me know if the latest patch works for you.

It could be. When some field is empty it should return null or empty array. Somewhere in the code it might be trying to return a value instead. I'm looking into FieldtypeInteger and can't quite figure out yet what I missed.