Jump to content

dadish

Members
  • Posts

    124
  • Joined

  • Last visited

  • Days Won

    8

dadish last won the day on November 19 2019

dadish had the most liked content!

About dadish

  • Birthday 03/15/1987

Contact Methods

  • Website URL
    https://nurgulyashyrov.com

Profile Information

  • Gender
    Male
  • Location
    Waterloo, ON

Recent Profile Visitors

3,387 profile views

dadish's Achievements

Sr. Member

Sr. Member (5/6)

457

Reputation

  1. I updated the requirement in the code but forgot to update the requirements listed in the docs. My bad, I'll try to update it this weekend or so. Unfortunately we don't have bandwidth to test and support all the ProcessWire versions. So, just to be safe, we default to the later versions. Generally speaking though, ProcessWire is very stable and rarely break anything with patch updates. As long as it works without problems you should be good to go. One thing to keep an eye though, is PHP version. The underlying library (webonyx/graphql-php) requires PHP version `^7.4 || ^8`. So make sure you meet that requirement.
  2. Not sure what to tell. You can use hooks and create an alias field that would work with GraphQL and add hooks that would sync with your current dropdown field. But that is a bit hacky and will need to be kept up to date with every new logic that involves your dropdown field. You might as well rename your dropdown option names throughout your code if it is just renaming it. As for the future, my personal advice for ProcessWire users, do not use FieldtypeOptions. Just use FieldtypePage for dropdowns, radio buttons or any type of options field. FieldtypePage takes a bit more time to set up properly as an options field, but in the long run it is always a better approach and much easier to deal with. Sorry, but you'll have to figure that out for yourself. Ask ChatGPT or Google about how to make PHP server to allow requests from any origin.
  3. Most likely the react app is not including the cookie headers in it's requests. Like I mentioned before, sometimes you need to explicitly include them. Like for the fetch api you need to set credentials option to "include".
  4. Prevent what exactly? I'm still trying to understand what you're trying to achieve. You want all those requests to log under a single session id? Because it's the same person? What kind of problems? The logged out user gets access to restricted content which you want to prevent? Or the logged in user can't get the content that it should have access to?
  5. Not entirely sure if I understood you correctly. Once you login, subsequent requests will include the session cookies that were set by ProcessWire. If you want to omit cookies for certain requests, then you probably can explicitly exclude cookies in your ajax calls? For example if you're using fetch api, you can omit the credentials when executing a request.
  6. No, we don't have that ability. We had it as an experimental feature in initial version of the module. But we dropped it because of the security concerns. Could you describe a hypothetical, real world example where you would need it? If I am convinced that it is a popular use case I might consider adding it back.
  7. Hey @sodesign I tested the module against the latest ProcessWire(3.0.229) and it works. It performs mutations. See the screenshot below. My best guess is that there is something doesn't work with your custom mutation. But it's hard to find out what it is, because I don't know what it does. The error message points to the graphiql client script. But I am not sure why it's failing for you and not for me. One thing I can suggest is to debug this without the graphiql. Make the request from your script and log the response/error and see if that gives some more insight. Meanwhile I'll try to upgrade the graphiql to the latest version. Maybe that will solve your problem.
  8. Not sure tbh. I would create an alias field. Create the a similar field. If your field is called `options` call the alias field `options_graphql`. Set the same set of options to your alias field, but make sure to have their title be prefixed with some word. So if your options are `1, 2, 3` then have your alias options `gql_1, gql_2, gql_3` or similar. Add the `options_graphql` field into graphql. Then use hooks to synchronize the two fields when page is saved and loaded with `Pages:saveReady` and `Page:loaded` hooks.
  9. Hey @martind, So I looked into this and it looks like it's not possible. The values for the FieldtypeOptions are described in Enums. The values for the Enums in GraphQL spec should conform to the GraphQL Name. Which must start with a letter and followed by zero or more letters and/or numbers. So an option in the FieldtypeOptions that starts with or only have digits will not compile properly.
  10. Glad to see you progressed on this. The /processwire/setup/graphql/ is for internal/admin use only. You should focus on the /graphql/ endpoint.
  11. 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. 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. 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. Sorry bud. The ProFields are out of the scope of this plugin.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...