Jump to content

dadish

Members
  • Posts

    113
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by dadish

  1. Hello @Brett. Thank you for your feedback! I was able to reproduce your issue and hopefully tracked down the bug. Please, install the latest version and give it a try. Let me know if the issue is resolved for you. New Release 1.1.3 - Fixed bug with FieldtypePage returning only single value.
  2. 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.
  3. 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.
  4. @charger I have no other ideas how to solve your case. Could you describe the steps to reproduce the error? You can take a starting point of any site profile and outline the steps to reproduce the issue. That would make it much easier for me to help you.
  5. @charger Hmm. Did you try enabling view access to your repeater_product_groups template?
  6. @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.
  7. @charger I was able to reproduce your bug. Will get back to you soon when I fix it.
  8. 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.
  9. New Version 1.0.5 - Fixes empty value bug for FieldtypePage and FieldtypePage::derefAsPageOrFalse setting. @dragan I was trying to reproduce your bug but encountered different one which is also related to FieldtypePage. This probably not related to your bug but try it anyway when you have time.
  10. 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.
  11. No, it's not. The title field can be removed from the page. so it's not included by default. In your graphql documentation, does your page reference fields has a title field in them?
  12. 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?
  13. New Version 1.0.4 - Fixes empty value bug for FieldtypeInteger. @dragan I was able to reproduce error for FieldtypeInteger. Turns out ProcessWire returns an empty string instead of null when FieldtypeInteger is empty. That's why GraphQL schema was complaining about getting empty string instead of Int. Let me know if the latest patch works for you.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. @charger I don't think that hashing graphql queries would cause performance problems. They are not that big. You should be fine.
  19. 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?
  20. 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.
  21. 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.
  22. Yes it does. The more fields and templates are enabled the bigger the schema, the bigger the response time.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...