Jump to content

charger

Members
  • Content Count

    93
  • Joined

Everything posted by charger

  1. I could track down the problem to Apollo fragments (specifically using the same fragment more than once in the same query). Not sure why this only popped up inside Repeater fields though. Thanks for the support!
  2. Yes, it is still the same response: no values.
  3. @dadish I’m afraid the problem persists. I get the exact same response. I cleared compiled files and browser cache.
  4. The template permissions are set correctly then. The guest role has view permission on the product template. I’m setting the field permissions not in template context, but per field. So they all have the view permission, also in template context. Just double-checked that. What’s weird is that title and body generally work outside a repeater field. It’s only within the repeater field, that they return no values. Any other ideas?
  5. When trying to fetch Repeater fields with module version 1.0.5, I get responses like this one: [ { "title": "", "body": "", "products": { "list": [], "__typename": "ProductPageArray" }, "__typename": "RepeaterProductGroupsPage" }, { "title": "", "body": "", "products": { "list": [], "__typename": "ProductPageArray" }, "__typename": "RepeaterProductGroupsPage" } ] So I get an answer with the expected data structure (and no errors whatsoever), but the values of the fields are always empty. Also the amount of repeater items in the response matches with the backend. This is when I send the request from the frontend (via Apollo). Looking at the same query within GraphiQL returns the data with the correct values. Could this be a permission problem? I correctly set the access permissions to view for all the fields mentioned in the query.
  6. My idea was to move the logic to get a unique cache name from the server to the client (by setting an ID for a query just like in the linked example) and then use that ID on the server for caching purposes. I was mainly worried that there might be a performance problem with creating hashes from complex queries, but I have no data to back that up.
  7. I implemented a very basic caching strategy for GraphQL queries with the help of PW’s native $cache methods. Here’s how my graphql.php template looks like: <?php namespace ProcessWire; $namespace = 'graphql'; $serializedQuery = file_get_contents('php://input'); $cacheName = hash('md5', $serializedQuery); $cacheData = $cache->getFor($namespace, $cacheName); if (!$cacheData) { $cacheData = $modules->get('ProcessGraphQL')->executeGraphQL(); $cacheSaved = $cache->saveFor($namespace, $cacheName, $cacheData, $expire = 604800); $log->save('graphql', "cache saved $cacheSaved with name $cacheName"); } echo json_encode($cacheData, true); When saving a page in the backend, for now I just clear the whole cache associated with this namespace (inside ready.php ) <?php namespace ProcessWire; $pages->addHookAfter('saveReady', function($event) { $deleted = wire('cache')->deleteFor('graphql'); if ($deleted) wire('log')->save('graphql', 'cache deleted'); }); Serializing the whole query just to get a unique cache name obviously isn’t optimal. How about if the module supported globally unique IDs that could then be used as cache name instead?
  8. @schwarzdesign I’m sorry, but I think I wasn’t specific enough. How does your router.js look like? 🙂 As you say the routing is handled by Vue. However, I wonder how Vue knows about the routes that exist. Do you manually add the routes to router.js? Or do you grab existing routes via API and then include them in the Vue router config?
  9. Thanks for the detailed write-up! Would you mind sharing how exactly you sync the PW routes with Vue router?
  10. I can do that, but you don’t have to set up a new environment. You just grab the PW files and put them in a newly created folder in your webserver’s root.
  11. I was able to solve the problem meanwhile. It was related to my template file structure. I’m using the delayed output strategy together with some nested wireRenderFile() calls which lead to the problem.
  12. The following line in RockPdf.module.php returns a wrong URL if the PW installation lives in a subdirectory (subdirectory is applied twice): 'httpUrl' => rtrim($this->pages->get(1)->httpUrl, '/') . $url,
  13. Thanks for the hint, wasn’t aware of that. But if the default age for a temp folder is 120 seconds, then that should be plenty of time already. The PDF generation maybe takes around 3 seconds.
  14. This will not work for me as I generate the PDF if there’s a "pdf" GET parameter found (this is e.g. how https://github.com/wanze/Pages2Pdf handles it as well). That’s why I was pursuing another way meanwhile: the wireSendFile() function (https://github.com/processwire/processwire/blob/master/wire/core/Functions.php#L257, https://github.com/wanze/Pages2Pdf/blob/master/Pages2Pdf.module#L312). Here’s the relevant code from my template file: $inputPdf = $input->get('pdf'); $inputPdfSan = $sanitizer->int($inputPdf); if ($inputPdfSan == 1) { $pdf = $modules->get('RockPdf'); $pdf->settings([ 'tempDir' => $this->config->paths->root . 'site/assets/cache/WireTempDir/.RockPdf/test/', ], 'mode' => 's', 'mirrorMargins' => 1, ]); $mpdf = $pdf->mpdf; $mpdf->WriteHTML('Hello World ' . date('H:i:s')); $filename = $page->name . '-pdf-' . $page->id . '.pdf'; $response = $pdf->save($filename); wireSendFile($response->path, array('forceDownload' => true)); } However, the problem remains: the PDFs do get saved correctly, but when trying to download them (either via wireSendFile() or RockPDF’s download()), they are blank or corrupted.
  15. Hmm, that didn’t help on my side. I still see the "Unable to remove" errors in the wire-temp-dir logfile, now they’re just referring to the newly set directory. And yes, these are more complex PDFs, but not overly complex (~3MB).
  16. What kind of mime-type errors? And how could that be related to PW only but not the webserver or PHP in general? I also just checked it on the webserver (was on localhost before): same problem there. It’s weird that one option would work while the other two wouldn’t. I can’t make sense of it atm.
  17. @bernhard download() and show() both work outside of PW.
  18. Latest Chrome/Safari/Firefox on macOS 10.14 show all the same problem. The weird thing is it creates the correct amount of pages in the PDF, they’re just blank. Calling `$mpdf->Output($filename, \Mpdf\Output\Destination::DOWNLOAD);` directly results in the same error.
  19. Did anyone else encounter problems with `show()` and `download()`? If I use them, all I get is blank pages resulting in an invalid PDF. The `save()` function works as expected though. I’m running PW 3.0.98 with PHP 7.1.12 and RockPdf 1.0.1
  20. You’re right. Bad example. But it also doesn’t work with width and height values like this: @page { size: 100mm 150mm; }
  21. Did anyone successfully use @page in the stylesheet to e.g. set page size or margins? I don’t see anything happen if I add the following code block to templates/pages2pdf/styles.css: @page { size: A5; margin: 10mm; } I’m using the dev branch of Pages2Pdf (mPDF v6.1).
  22. Found the solution myself: https://github.com/wanze/Pages2Pdf/pull/13
  23. Did anyone get odd/even header/footers and margins working? I’m using the dev branch of Pages2Pdf and can’t seem to find a way to do it.
  24. Is there a particular reason why $page->localUrl() returns "" even if the backend says it’s not empty (as the value is inherited from the default language)?
  25. Sorry, my bad! I was looking for the wrong module. What I wanted was to get rid of multilang page names, which of course is the Languages Support - Page Names module. This one I could uninstall without problems.
×
×
  • Create New...