Jump to content

sodesign

Members
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

19 Good

About sodesign

  • Rank
    Jr. Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for your reply @flydev 👊🏻 I have looked through our nginx config, and I can see the lines fastcgi_ignore_headers Cache-Control Set-Cookie Expires; fastcgi_pass_header Set-Cookie; fastcgi_pass_header Cookie; fastcgi_cache OPS-FASTCGI; fastcgi_cache_valid 240m; fastcgi_cache_bypass $no_cache; fastcgi_no_cache $no_cache; The $no_cache param is set based on the request uri, and I did notice one 'private' url had been missed from the exclusions at the time of the issue. This really isn't my area of expertise, and we set up the config some time ago, inspired by Trellis (in wordpress land). I noticed someone questioned them about the inclusion of the fastcgi_pass_header Set-Cookie property (https://discourse.roots.io/t/nginx-caching-configuration-in-trellis/7056) Would removing fastcgi_pass_header Set-Cookie be a good idea? Is there any reason this would need to be passed?
  2. That's great news, and thanks for letting me know. I've recently been working on a nuxt.js project with Craft CMS which uses interfaces, and I'm very excited to now have this capability in PW as well.
  3. Hello, I manage a client website which use PW and Padloper for ecommerce. We recently had an issue where customers were seeing other customers' baskets and prefilled form data on the checkout form. From what I saw, the data was not users who had accounts, just data which was held in their sessions. I think I have narrowed this down to being caused by nginx fast-cgi caching, but I do not know enough about how this works to be certain. I have a couple of questions: • Can fast-cgi cached cause session data to be shared, leaked or incorrectly assigned? • Can fast-cgi cache provide authentication to unauthorised users? I'm reasonably confident that the whole shop cart and checkout bypassed the cache, so is it possible that somebody could 'swap' sessions on a diffetent part of the site which shouldn't have been cached? I don't have a great deal of knowlegde of how sessions, caching and cookies work and fit together, so if it's likely that the fastcgi-cache isn't the problem, can anyone point me in the direction of what might be?
  4. Thank you for explaning these details and your plans. If you'd like any help testing, I'd be happy to do what I can; this module is a great asset for PW develoment.
  5. I have one more question - do you plan to include child template fields? If not, what is your recommendation for querying child pages? Thanks
  6. 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 Thanks, Tom
  7. Just updated and the issue is fixed, thank you for such a speedy patch!
  8. Sorry - copy and paste error*. I am using a ConfiguratorQuoteCreateInput field when I get the error. *(I tried using update as well in case the page reference needed a parent page to exist first)
  9. Hi @dadish, I'm upgrading a site to use the latest version of this module. I'm having trouble with a page reference field when creating a new page with a mutation. Before, I was using a mutation with variables like this: mutation ($page: ConfiguratorQuoteUpdateInput!) { createConfiguratorQuote(page: $page) { id } } variables: { "page": { "name": "test-quote", "title": "Tets Quote", "parent": "22905", "colour": [10392] // this is the page reference field } } I noticed the field now uses the type InputfieldPage rather than [ID] and there are add and remove fields inside this InputfieldPage field. I have tried formatting the variables in a couple of ways and I see this error in graphqil: // "debugMessage": "Method NullPage::add does not exist or is not callable in this context", // When using either of these variables: { "page": { "name": "test-quote", "title": "Test Quote", "parent": "22905", "colour": { "add": 10392 } } } variables: { "page": { "name": "test-quote", "title": "Test Quote", "parent": "22905", "colour": { "add": [10392] } } } Can you advise how I should be adding page reference fields? I have checked the page template and fields are legal, they return without issue in queries for existing pages. Many thanks, Tom
  10. This is great news! I love using the module, makes integrating Vue with processwire powerful. The only difficulty I had was with the N+1 with FieldtypePage, thrilled this is solved 👏 Thank you for all your work @dadish
  11. Hello, My ProDrafts license expired just shy of a year ago and I'm trying to find out if it's worth renewing. One of my clients has always been frustrated witrh the way images are handled - which I found mentioned here - effectively they 'get lost' and I have to do a weird dance of publishing, saving a draft, saving again, reuploading an image, saving a draft and then publishing, before unpublishign to remain as a draft etc etc... I am currently on version 0.0.6 - is anyone able to tell me if the issues mentioned in this thread have been resolved? Many thanks
  12. No problem, thanks for the clarification. In the end I solved this by saving the base64 image as a text field, and I'm planning to use an on page-created hook to convert this to an image in a more PW way. I look forward to seeing where this plugin goes; even in its early form it's been very helpful.
  13. Hello, Thanks for all your work on this module, it's a joy to use! I have a question around modifying a mutation, and am not sure how the ___getMutation Hook works. I normally use TracyDebugger but using Tracy with this module seems to break (all graphql responses throw a json error) How do I modify the value of a field in a mutation using the getMutation hook? Thanks, Tom Edit - to clarify - I'm generating a base64 image in vuejs on the front end, and need to save this to an image field. I'm planning to do this by sending the base64 string as part of the request (I'm using vue apollo) - and then intercepting this with a hook, creating and saving as a png file in a temporary directory, and then setting this as the PageImage url in the query.
  14. Just to follow up on this - I bought the Profiler Pro module and have been discussing this in the module forum there. As part of this I created a test template which just outputs a string, with init.php and main.php prepending disabled - the Profiler Pro time for this is down to under 300ms, while the load time I see in my dev tools is still between 900ms and 3000ms. My next steps are trying to find out why this discrepancy exists - very strange!
  15. Thanks for your reply - I've been making changes quite frequently - it's a fairly big site to which we're adding a shop. There's no one change which stands out as a huge change. Debug mode is off on the live site, other than when temporarily testing, and all of the modules are pretty much up to date. The load times aren't much better when in the admin which is why I haven't spent too much time trying to optimize templates - does template logic affect load time in the admin? I don't think Procache supports nginx. I was using fastcgi_cache but it gets a little messy with the way we're handling locale redirects - we need to refine our config. I'd rather find out the reason for the long load times before resorting to a flat cache. Do these timings for loading /pw/page look reasonable to you?
×
×
  • Create New...