Jump to content

dadish

Members
  • Posts

    112
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by dadish

  1. 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.
  2. So it is obviously a permission problem. Can you show me the query you're making to your api please.
  3. @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.
  4. @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
  5. 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.
  6. 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 } } } } } }
  7. 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.
  8. 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.
  9. 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.
  10. @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); } });
  11. 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.
  12. 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.
  13. 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.
  14. More updates! Here is what was added since my last post: FieldtypeDatetime now supports format argument. Which allows you to pass PHP date format string and retrieve your datetime values formatted the way you want. Besides FieldtypeDatetime fields, the built-in fields created and modified are also support new format argument. FieldtypeOptions is now supported. first and last fields on PageArray types are now supported. As per @eelkenet's request. See above post for details on those. Finally, now there is a way to add support for any fieldtype you want via third-party module. What you need to do is create a module with the name exactly as the fieldtype you want to add support for with "GraphQL" prefix. So for FieldtypeMapMarker it would be GraphQLFieldtypeMapMarker. Then you need to add three required methods and install it. This will automatically add GraphQL support for your desired fieldtype and it will be available in your GraphQL api. Checkout the documentation and an example module for reference.
  15. Hey @eelkenet! That seems reasonable to me. I was planning to add those fields. Didn't have time till now. I'll let you know as soon as I implement them. You won't be able to add those fields via getQuery hook btw. The getQuery hook is there for very trivial custom fields to be honest. Like your api version number, or your contact data or anything you want to send via GraphQL api without creating templates, fields and pages for it.
  16. Hey everyone! It's been a while since I last had a time to work on this module. But now I finally managed to focus on this module. So here are the latest updates. The codebase of the module grew very big and the more features I added the more time I had to spend to make sure the changes I made does not break anything. Because I had to manually verify if everything works as expected. After long night hours of trial and error I managed to setup tests for this module. Tests will help us quickly add/remove features as needed, because now there is no need for manually verifying all edge cases. Also I setup the Travis-CI so people can contribute more confidently and I can merge pull requests without worrying! There are already bunch of tests, but there is still some I'll be adding. 🎉 🎉 I will add some documentation on how to run tests locally in github wiki pages soon and let you know here. Another thing to note is that the master branch of our module no longer tracks the vendor code. This means that if you download the master branch and put it into your /site/modules directory it will not work. Instead you should use release builds that are a cleaned version of the module. It includes required vendor codes and does not have extra files that are not relevant to ProcessWire. Like presentation gif images, test files and so on. This makes the module size smaller!
  17. PageTable is not supported yet. To be honest I am very busy right now and don't have much time to update this module. So I can't say when additional features will be added. Until then, you'll have to figure out your own way. Sorry
  18. Hey, Rudy! I couldn't fully understand your use case. I guess you want to restrict access to certain entities, like your other site. It is very easy to restrict access to certain ip address. Just before serving GraphQL API you could check for the requested entities ip address and behave accordingly. For example: <?php if ($_SERVER['REMOTE_ADDR'] == 123.234.34.1 ) { echo $modules->get('ProcessGraphQL')->executeGraphQL(); } else { echo 'Access Denied'; } I can't say for sure if that's what you are asking though. If not, please give more details on what you are trying to achieve.
  19. @abdus First of all you don't need to import ProcesGraphQL's vendor.php file. It is done automatically when you do $processGraphQL = modules()->get('ProcessGraphQL'); Second is, I don't see where you include your /site/templates/api/SubscriptionField.php file into graphql.php. So replace the require_once '../modules/ProcessGraphQL/vendor/autoload.php'; with require_once "./api/SubscriptionType.php"; in your graphql.php and it should work. Also, your SubscriptionField class requires the public function getName().
  20. Done! The latest version now allows you to hook into getQuery & getMutation methods of the ProcessGraphQL class. Those hooks are solely there so you could modify the query and mutation operations. Here how it might look like in your template file. <?php namespace ProcessWire; use Youshido\GraphQL\Type\Scalar\StringType; $processGraphQL = $modules->get('ProcessGraphQL'); wire()->addHookAfter('ProcessGraphQL::getQuery', function ($event) { $query = $event->return; $query->addField('hello', [ 'type' => new StringType(), 'resolve' => function () { return 'world!'; } ]); }); echo $processGraphQL->executeGraphQL(); The above code will add a hello field into your GraphQL query that responds with the string "world!". You'll have to use the Youshido\GraphQL library that ProcessGraphQL module uses internally. The same thing could be done with the mutation operation via getMutation hook method.
  21. Well now I am embarrassed. So sorry. It turns out upgrading to the latest graphql library broke some stuff. For some reason I did not check the queries without the selectors. I made some fixes. This should solve your problem. Please get the latest version and try again.
  22. Hi @abdus. You are good to go actually. The argument is required only when there is an exclamation mark after it. It does not have to be = false. Sorry for the confusion, the way I explain it in screencast is a bit misleading. To sum it up, if there is an exclamation mark "!" at the end, it means it is required, of not then it is optional. The = false part means, the default value is false. I know, it sounds stupid. It was a bug in the library I used for this module. I updated it to the latest version since the screencast and now it shows correctly. The = false part is actually is a bug in older version of the module. You probably installed the latest version which shows correctly. So, your version is actually is the way it supposed to be. The version in the screencast is a bit misleading, but still correct.
  23. Unfortunately not yet. I am planning to implement them. But I am a bit busy now and it would definitely take some time to implement it. For now, you will have to do it some other way. Sorry
  24. Yes. It was my bad. I did not make sure the FieldtypeCheckbox always returned a boolean. I think it returns 0/1 in ProcessWire. Anyways, just patched it. Update to the latest version and it should work. Edit: As always, thanks for the feedback.
  25. Yeah, I had my nightmares with this situation too. There are lots of scenarios when ProcessWire could redirect your ajax requests and the graphql will not receive the query. The ones that I had encountered were: If the url ends without slash: ...website.com/graphql ==> ...website.com/graphql/ If there is now www prefix: website.com/graphql/ ==> www.website.com/graphq/ And now I guess when languages are enabled you also gotta make sure ProcessWire is not redirecting you to the respective language url of the graphql api. I haven't tested the module with the languages enabled yet, but I am sure there would be some additional caveats. Yes, that's the expected behavior. Unfortunately to support permission inheritance would be too expensive. Because it means to check template permissions of each ancestor of each returned page. I think the module is already slow and supporting permission inheritance would make it even slower. I guess I have to mention about not supporting permission inheritance somewhere in the documentation of the module. That's right, it turns out there was a bug. I pushed an update regarding the datetime field. Grab the latest version of the module and it should work properly. Yep. That's the way. I know, it's ugly. But I can't think of a less verbose way to return a single page from the api. We could, of course introduce an additional field for each template like basic_page_single or something. But I don't think it's worth it, plus it will make the schema bigger for very little gain. I totally agree. We can't allow everyone to create images. The size field of the image type creates images only if the user has an edit permission on that image field. It is still available to the users who do not have edit permission, but only for getting existing variations, and it should return null if there isn't an image variation with the requested size. Edit: By the way, thanks a lot for the feedback.
×
×
  • Create New...