dadish

On 1/2/2022 at 12:55 AM, ngrmm said:

UPDATE: seems it has something to do with my site-settings
I tried it in JS and it works

Glad to see you progressed on this.

On 1/2/2022 at 12:55 AM, ngrmm said:

However when I use /graphql/ as URL i see an object in the console. When I use /processwire/setup/graphql/ I see a json in the console

The /processwire/setup/graphql/ is for internal/admin use only. You should focus on the /graphql/ endpoint.

Hello @Matoseb,

I haven't used any of the pro fields, myself. So I don't know much about them. But conceptually they should be very similar to list of pages.

4 hours ago, Matoseb said:

The way RepeaterMatrix works is it is differentiating the types based on the repeater_matrix_type. It doesn't seem to work with templates. I tried to use the constructor `new Template()` to create some based on this property but I don't know where to add this line.

You should take a closer look what I do in PageType. I create the fields of the page by inspecting it's template. I don't know what kind of API the repeater_matrix_type has, but I suspect similar. But even then, I have a separate type generator for each supported field. If RepeaterMatrix does not use those as underlying FieldType classes, then you'll have to recreate for each of them on your own.

5 hours ago, Matoseb said:

Also should I create a new RepeaterMatrixPageArrayType based on your PageArrayType?

Yes, but the bulk of the work would be implementing the equivalent of PageType that would be responsible for creating types for each repeater_matrix_type. The PageArrayType simply wraps the PageType into an array and adds things like pagination, first item, last item, total count, etc.

5 hours ago, Matoseb said:

Any chance you would take a look? I know it's a ProField, but if you got some time I would be very grateful

Sorry bud. The ProFields are out of the scope of this plugin.

Hi @ngrmm. I suggest you to start debugging the request from your template. Depending on how you are sending the request, first try to simply echo it. In your template, simply echo back the graphql request. Could look something like this.

<?php

echo $input->post('query');

// Or:
// echo $_POST['query']

// Or:
// $rawBody     = file_get_contents('php://input');
// $requestData = json_decode($rawBody ?: '', true);
// echo $requestData['query']

And see if your PW installation correctly receives the graphql request. You can look at how GraphQL module makes different attempts to capture the request itself here. https://github.com/dadish/ProcessGraphQL/blob/530a72e349d7a262d26af9452f5681fa36ee5d33/ProcessGraphQL.module#L161-L183

When you find out a proper way to capture a request in your template file, you can manually pass the request to the Graphql module. Something like below

<?php
     
$query = $input->post('query');
$variables = $input->post('variables');

echo json_encode($modules->get('ProcessGraphQL')->executeGraphQL($query, $variables), true);

Let me know if this helps.

5 hours ago, Tom. said:

It's just a default text field with the HTML Entity Encoder enabled. 

Whatever it is, I suspect it's causing problems. Try changing the field type for job_title to another field that ProcessGraphQL module supports and see if the error is gone. Then, if it is possible you can share your custom field in github and I can take a look at it.

Hi @Tom.. I am trying to figure out what is EntryCreateInput type. Looks like you're extending graphql module somehow. If you can tell me more about that input type, I might be able to figure out the problem.

2 minutes ago, Tom. said:

That would suit most peoples needs. It would make it more feature rich out of the box.

Or in other words, it would force people to use a predefined method of authentication, instead of allowing them to use their own preferred version. Some people may prefer JWT tokens, others might want cookie based auth or maybe people need to use third party authentication like AWS Incognito..., the list goes on.

4 minutes ago, Tom. said:

Seems really simple to implement. I'm unsure whether it's worth shipping with that functionality or have people build it in? What do you think @dadish?

I would prefer people implement their own authenticaton/session flow. The thing you describe above should be simple to implement with the ProcessGraphQL::getMutationFields hook. I think I will remove the login(name: "name", pass: "pass") query field in the future and add a clear documentation/example on how you could implement your own authentication flow.

Thanks a lot for the idea @Tom.. I think it would be more flexible this way.

On 7/25/2021 at 11:30 PM, zynth said:

Is there a way to transform the data like that before it is returned to my frontend, like make the list operation return the object instead of an array when the list operation result only yields one item?

You can do it manually on the ProcessWire side. Before returning the result to the client, simply do the JS trick that you posted in PHP and return the result to the client.

5 hours ago, Tom. said:

May I ask if you are using Node JS server? I believe this may be the reason it's not working as mine is apache with vanilla JavaScript.

Hey Tom. What do you mean "using Node JS server?" Do you mean where the JavaScript files coming from? If that's your question, then it should not matter. It does not matter where the javascript files are coming from.

I did a little research and found out that it works in Firefox but not in Chrome. I don't use Chrome, that's why I couldn't reproduce your issue. Have you tried the above JS code in Firefox? If not please try it out and tell me the results. If that works then we will work on fixing it for the Chrome browser.

11 hours ago, Neue Rituale said:

Hi Guys,

i want to get a hooked page property into my graphql schema. Does anybody know how i can configure/implement this?

Haven't tried it, but something like this should work. https://webonyx.github.io/graphql-php/getting-started/ Scroll down to the first example and see how fields are defined in GraphQL.

In your case it should look similar to this.

<?php

$fields[] = [
  'name' => 'intro',
  'type' => Type::string(),
  'resolve' => function ($page) {
    return $page->intro;
  }
];

Play around with it and you'll get there.

42 minutes ago, Tom. said:

Shameless Bump ?

No problem. Sorry for not answering sooner.

On 7/16/2021 at 6:39 PM, Tom. said:

Didn't work for me, maybe it's an issue with Fetch API. What do you use to make your HTTP requests? 

I used fetch api. Just like you.

On 7/16/2021 at 6:39 PM, Tom. said:

Better still, could you provide me with example code where you have CORs working through JavaScript requests?

Sure. I created a sample app with create-react-app. Then I start the app with `npm start`. And here is my App.js file.

const query = async (query) => {
  const res = await fetch("https://skyscrapers.nurgulyashyrov.com/graphql/", {
    method: "POST",
    credentials: "include",
    headers: {
      "Content-Type": "application/json",
      Accept: "application/json",
    },
    body: JSON.stringify({ query }),
  });
  const json = await res.json();

  console.log("json", json);
};

const execute = async () => {
  await query(`{ logout { statusCode }}`);
  await query(`{ me { name }}`);
  await query(`{ login(name: "name", pass: "pass") { statusCode } }`);
  await query(`{ me { name }}`);
};

execute();

function App() {
  return null;
}

export default App;

Note that the app starts a server that runs on http://localhost:3000. If you are testing by simply opening a file in the browser then it will probably not work. So you need your browser address bar to start with http(s):// and not with file:///

EDIT: You will have to substitute the url with your own, of course. The graphql api is setup exactly as in my previous post. I assume you noticed that the CORS headers are inside the cors() function and that you have to call that function before final response.

On 7/8/2021 at 1:24 PM, Tom. said:

I have corrected my cors headers so it doesn't return an error, but it's still not working. Have you had any success having the login work cross-origin? I imagine so as this is a pretty common use case for use an API cross-origin. 

Here is the CORS setup that works for me.

<?php

// https://github.com/dadish/ProcessGraphQL/blob/622c9db61cb7cf3ef998edb31e4e0e47b3c96669/test/server.php#L20-L43

function cors() {
  // Allow from any origin
  if (isset($_SERVER['HTTP_ORIGIN'])) {
      // Decide if the origin in $_SERVER['HTTP_ORIGIN'] is one
      // you want to allow, and if so:
      header("Access-Control-Allow-Origin: {$_SERVER['HTTP_ORIGIN']}");
      header('Access-Control-Allow-Credentials: true');
      header('Access-Control-Max-Age: 86400');    // cache for 1 day
  }

  // Access-Control headers are received during OPTIONS requests
  if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {
      if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD']))
          // may also be using PUT, PATCH, HEAD etc
          header("Access-Control-Allow-Methods: GET, POST, OPTIONS");         
      if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']))
          header("Access-Control-Allow-Headers: {$_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}");
      exit(0);
    }
}

Could you try it and let me know if it solves your problem with different domains?

1 hour ago, Tom. said:

Also, I'm logged in as Admin (superuser) and I can't seem to use the mutation to "create" only "update" and I can't seem to find the reason why. How do I add the ability to create pages?

Probably because there are some conditions that are required. One of those things is that in order for user to be able to create a page they require a `page-create` permission for the template that is going to be created, but also `page-add` permission for the template that will be a parent of the created page.

2 hours ago, Tom. said:

Also is there an option to create pages but not edit them. It isn't possible with the permissions on ProcessWire, but I wouldn't want people exploiting the API and editing content, but I would like user submitted content. e.g. storing form submission data.

You could probably achieve this by just removing some mutation fields with hooks. Should look something like below.

<?php

$wire->addHookAfter("ProcessGraphQL::getMutationFields", function (HookEvent $event) {
  $fields = $event->return;
  $newFields = [];
  foreach ($fields as $field) {
    if (!in_array($field['name'], ['updatePost', 'updateComment'] )) { // list the name of mutation fields you want to disable
      $newFields[] = $field;
    }
  }
  $event->return = $newFields;
});

Make sure this code is run before the module has responded to the query. Before $modules->get('ProcessGraphQL')->executeGraphQL()

4 hours ago, Tom. said:

"Adds me query field. Allows user to query her credentials."

Should be "Allows user to query their credentials." 

Thanks. Will update. ?

11 hours ago, Tom. said:

Figured it out, I needed to give Guest permissions to access. I was wondering how do you do the login flow through JavaScript so I can make requests that only certain users could view, I like the fact that this uses ProcessWires permission system! Very clever. 

Login should work as regular processwire login flow. Just do a first request as

{
	login(name: "username", pass: "password") {
    	statusCode
    }
}

Then all subsequent requests from the browser will automatically include the processwire cookies.

@markus_blue_tomato I assume job_group is a page field. Page fields in GraphQL return Page interface that has only built-in fields (id. name, url...). If you want to get custom fields like (title, job_group_id...) you need to use fragments.

{
  jobDetail {
    list {
      id
      job_name
      job_group {
        list {
          id
          name
          ... on JobGroupPage { // <== you need to use the actual type name here
            title
            job_group_id
          }
        }
      }
    }
  }
}

3 minutes ago, markus_blue_tomato said:

but still not in Insomnia Client...

Make sure you have rights to see it in insomnia. You probably not authenticated in insomnia, which means you're a guest user and those fields are not configured to be accessible by the guest user. Can you check if my assumptions are correct?

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

On 6/23/2020 at 8:20 PM, pmichaelis said:

I don't know if there have been any requests, but is ist possible to make the module work with "Repeater Matrix Fieldtypes"?

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

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

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.

@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.

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.

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.

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