Jump to content

dadish

Members
  • Posts

    124
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by dadish

  1. 7 hours ago, SlackMcKracken said:

    I could use some help. I'm trying to run the module on a multilanguage installation.

    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
        }
      }
    }

     

    • Like 1
  2. 18 hours ago, Miguel Scaramozzino said:

    I've been using PW for years and I've never encountered that quirk.

    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.

    • Like 1
  3. @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.

    • Like 1
    • Thanks 1
  4. 12 hours ago, Miguel Scaramozzino said:

    So there must be something wrong with the way that the graphql template is being processed. Maybe ProcessWire is taking control of the post body before it reaches the module and this doesn't happen when you bootstrap PW from an external file?

    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.

  5. On 3/7/2020 at 7:19 AM, Miguel Scaramozzino said:

    When I try with GraphiQL (which posts to /processwire/setup/graphql instead of /graphql), everything works perfectly. Of course the templates are installed, field and templates access are configured, etc.

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

    • Like 1
  6. On 1/17/2020 at 9:36 PM, sodesign said:

    One other small thing - can you add support for the built in 'title' field in the Page type? 

    I tried this locally editing the getBuiltInFields() function at line 41 in src/Type/PageType.php

    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.

    22 hours ago, sodesign said:

    I have one more question - do you plan to include child template fields?

    If not, what is your recommendation for querying child pages?

    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! ?

    • Like 6
  7. @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.

    • Like 2
  8. 1 hour ago, DavidBerlin said:

    Children results work with "name" instead of "title"...

    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.

    • Like 2
  9. 9 hours ago, Ilyas said:

    Where did I make a mistake?

    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.

    • Like 2
  10. @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.

    • Like 2
  11. 6 hours ago, charger said:

    Could this be a permission problem? I correctly set the access permissions to view for all the fields mentioned in the query.

    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.

  12. 2 minutes ago, dragan said:

    However, I can't choose it from legalPageFields, i.e. the dropdown doesn't list it.

    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.

    • Like 2
  13. 27 minutes ago, dragan said:

    I only ever just use the system-field title. Is that not included?

    No, it's not. The title field can be removed from the page. so it's not included by default.

    28 minutes ago, dragan said:

    Strange thing is that if I replace title with name in the query, it works. But (again, just for some PR fields) if use title, I get errors.

    In your graphql documentation, does your page reference fields has a title field in them?

    • Like 1
  14. 3 minutes ago, dragan said:

    "message": "Cannot query field \"title\" on type \"Page\".",

     

    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?

    • Like 1
  15. 25 minutes ago, dragan said:

    Granted, I didn't do extensive testing so far, but I guess it throws errors each time when there is no value in a field. (hence, the selector "only show if images.count > 0" was working fine). Could that be? Earlier it just outputted empty nodes or null instead (which I would expect and is totally fine).

    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.

    • Like 1
×
×
  • Create New...