dadish

Yes. In debug mode it will return very verbose error messages. But ideally it should not return any errors. All my success tests check if the response has data in it and does not assert that there are no errors. So it might be that I have those errors as well, just didn't catch them. I'll try to reproduce your case and fix it. What type of field your budget field is? I assume integer, but want to be certain.

New Version Release: 1.0.3 - Improves performance for FieldtypeFile & FieldtypeImage fields. @dragan Looking forward to your feedback. I'm still very curious how you managed to get 6s response time from GraphQL. Let me know how the latest version works for you. @nbcommunication That's great to hear! Any involvement is absolutely welcome. If you have your module available on github or some other place I would love to look at your approach and maybe steal some ideas ?. Also, if your implementation is different than mine I would encourage you to finish it. We will only benefit from different approaches.

New version release! 1.0.2 I am very happy to inform you guys that the new major version of the module is out. ⚠️ WARNING: Breaking Changes! ⚠️ The module was rewritten to use webonyx/graphql-php instead of youshido/graphql. This was a big issue because the latter was not properly maintained anymore and the webonyx/graphql-php gone very further in development and supports more features that we need. There are some more breaking changes that are listed on the latest release page. What's new trash(id: ID!): Page! field allows to move pages to trash via GraphQL api. Solves N+1 problem for FieldtypePage field. Significantly improves response speed! Support for even more ProcessWire permissions. Now the full list is: page-add page-create page-delete page-edit page-move page-view page-edit-created page-edit-trash-created It is already available in ProcessWire's modules directory. So you can install it via class name.

@charger I don't think that hashing graphql queries would cause performance problems. They are not that big. You should be fine.

The link you're referring to talks about the caching on the client side, not server. And we already have unique id for all the objects. They are page ids and are enabled by default. But that wont help you with caching on the server side. I think using a hash of your queries as a cache name is perfectly reasonable solution. Why do you feel uncomfortable with it?

https://vitalydidenko.com https://skyscrapers.nurgulyashyrov.com/ We use Nginx for all PW websites, but these are the ones I have on my own servers. Please DM me if you find any security issues.

I'm not sure if I can blame the PHP library alone. It definitely could be one of the things that contribute to poor performance. But there are many more things going on. For example permissions is a big one. The schema needs to check the permissions for each field and subfields. So if you have lots of page-refs and fetching their subfields, it will check if the user has permission to view those fields. When you make a query inside your templates, the script already got access and don't do permission checks manually. It needs to be improved. Performance is very important. But right now I'm dealing with PHP library deprecation, because it's not maintained anymore.

Yes it does. The more fields and templates are enabled the bigger the schema, the bigger the response time.

Unfortunately the getMotationHook requires you to use the Youshido/GraphQL library that this module depends on. The issue with it, is that the youshido/graphql is not maintained anymore. Which means that I'll be rewriting GraphQL module to get red of it and use some other library. So I can't give you the correct solution because it's being deprecated at the moment, and I can't tell when I'll finish the migration to another php graphql library because I'm limited with my spare time. Sorry for replying this late, I hope you found a solution.

GraphQL requests are slow for sure, but 6 seconds is a bit too much. In my cases it usually took around 200-300ms. Not sure what's causing it to be so slow on your end.

AFAIK the only way to ask PW to get you conferences that has particular speakers in it, is to pass which speakers exactly you want. The selector looks like "template=conferences, speaker=1234|1235|1236..." So, you need get the speakers before you can query the conferences. My only solution is to query all your speakers first. Then make another query of all conferences that has those speakers in it. Query them all at once. And then, in the client when you are listing conferences for each speaker, just filter through them. I know, it's not a great solution, but I can't think of another way. I haven't used ProccessWire in a while, so there might be some better way.

Please test your query in a Graphiql. Insert your query in the Graphiql and confirm that the "product_single.list" is an array of nulls. Now remove every field inside the list and leave "id" and confirm that the list now contains objects with single "id" property in it. If that was successful then keep adding your "product_single" fields one by one. Whenever you see that the list is an array of "null"s, it means that exact field is causing this issue.

I was able to reproduce the similar response from your api. Seems like your guest user might not have access to one of the fields of the "product_single" page. You'll have to go to each of the "product_single" page fields that you are querying and make sure Access is enabled and the guest user has a view access to it.

So it is obviously a permission problem. Can you show me the query you're making to your api please.

@patricktsg As far as I understand, it's not the httpUrl you are having the problem with. It's the "item" in "item.httpUrl". The error "null is not an object" in JS means you're trying to access a property of a null, in this case "item". So whatever the "item" is in your query, you're getting "null" for it from your api. Then in your JS you're trying to access "httpUrl" of the "null" when you do "item.httpUrl". Hence the "null is not an object" error. So make sure your "item" is not null when returned from the api. If the "item" is a page, make sure the user (in this case guest) has access privileges for that page.

@patricktsg Make sure the template of the colour pages are enabled in the ProcessGraphQL module's config page and make sure user has explicit access to them in template permissions page. More on that here https://github.com/dadish/processgraphql#access-control

Unfortunately I haven't had much time in optimization for this module. I'm very busy so can't promise any timelines when this will happen. The only thing you can do now is to keep your graphql schema as small as possible by unchecking all the unwanted fields and templates in the module config page. There is supposed to be a way to cache the schema (https://github.com/youshido-php/GraphQL/pull/37) I was planning to look into it. But never had a time for it and thus is not implemented in this module yet.

It should be like this { product_single (s: "parent=X") { list { title product_code colors { getTotal getLimit getStart list { // list of colors name // name for each color } } } } } }

Hi @Karl_T. The module has no ability to modify the session data. It only can modify PW pages. AFAIK session data is not stored as pages. What you can do is add a custom GraphQL mutation field for modifying your session. But that would require you to learn GraphQL and the PHP library that we use. Here is how it might look like <?php namespace ProcessWire; use Youshido\GraphQL\Type\Scalar\BooleanType; use Youshido\GraphQL\Type\Scalar\StringType; use Youshido\GraphQL\Type\Scalar\IntType; use Youshido\GraphQL\Execution\ResolveInfo; $processGraphQL = $modules->get('ProcessGraphQL'); wire()->addHookAfter('ProcessGraphQL::getMutation', function ($event) { $mutation = $event->return; $mutation->addField('modifySessionData', [ 'type' => new BooleanType(), 'args' => [ 'foo' => new StringType(), 'bar' => new IntType(), ], 'resolve' => function ($value, array $args, ResolveInfo $info) { $success = false; // modify session data here... if ($something) { $success = true; } return $success; } ]); }); echo $processGraphQL->executeGraphQL(); And then the query for this could look like this mutation { modifySessionData("foo": "boblibob", "bar": 12234) } Haven't tried it. So there might be something I'm missing. But I hope this gives you the idea of how you can achieve what you want.

Hi @Zeka. You should not install the main repository of the module. The main repository of the module is intended only for development of the module. You can install the module in two ways: By module classname. Go to Modules -> Site -> Add New in your PW admin and write `ProcessGraphQL` in Module Class Name field and press Download and Install button. By a zip file. You need to download the module for installation from the releases page of the module. There you can download a .zip file and place it's contents to the site/modules/ directory of the module.

You shouldn't use it to obtain output in your template file. ProcessWire already comes with the best API to access your content. The purpose of the GraphQL module is to let you access content via AJAX, using JavaScript from client side.

@louisstephens Your query should be assigned to query variable. Try to change above code like this $.ajax({ type: "POST", url: 'localhost/pw/graphql/', data: { query: "{ modals(s: \"title=Test-Page\") { list { id title body } } }" // <-- change here }, success: function(data) { console.log(data); } });

This one is weird. I just installed the module on Classic profile and Skyscrapers profile with latest ProccessWire. Works fine for me. The "Loading..." is a placeholder till JavaScript kicks in. So this means the GraphiQL js assets are not loading or firing. Could you please try to see if GraphiQL works out of ProcessWire admin. You can either do that manually, using API that exposes GraphiQL in your template file. Or use GraphQL Pages generator. It's in the modules setting page. Looks like this. Just press it and go to `/graphiql/` on your website and show us what you got there.

I'm very happy you like it @alan. You definitely can use this for any single page application. That's exactly why I built this module for. Please don't hesitate to share the issues that might come up when using this module. I would love hear some feedback and maybe fix bugs if there are any.

So I made a mistake by not taking into account the ProcessWire's module naming convention. I totally forgot the fact that if module name starts with Fieldtype it becomes a fieldtype and PW will treat it like any other fieldtype. Like it would try to let you add a new field with that fieldtype. Which we do not want for our GraphQL extension modules. I already faced bugs because of this on admin side. So naming rule for GraphQL extension modules will be changed from suffixing the name with GraphQL to prefixing the name with GraphQL. So it is GraphQLFieldtypeMapMarker instead of FieldtypeMapMarkerGraphQL. Other than that, everything is the same as before. I'll also update the previous post to reflect this change. Sorry if this causes inconvenience to anyone. The updated version of ProcessGraphQL that works with new rules is available for use in latest release.