Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


d'Hinnisdaël last won the day on February 3

d'Hinnisdaël had the most liked content!

Community Reputation

201 Excellent

1 Follower

About d'Hinnisdaël

  • Rank
    Sr. Member

Profile Information

  • Location
    Vienna, Austria

Recent Profile Visitors

1,663 profile views
  1. Right, thanks, I left a session message in there. I pushed a patch at version 0.7.1. While it propagates to the module directory, removing line 119 of DashboardPanelCollection.module should work as well.
  2. I would second MoritzLost's viewpoint here. Most template engines auto-escape output — so as soon as you use Twig or Latte for your views, it's best to disable the entity formatter for all fields and let the template engine handle it.
  3. Release 0.7.0 adds a few features and fixes an issue reported by @MoritzLost. Collection panel: Field names as column headers The collections panel now uses the field label as column header. No need to pass them in explicitly anymore. See the docs on column headers for details. Shortcuts panel: Add option to hide shortcut summaries Disable the summaries altogether by setting the summaries option to false. Shortcuts panel: Fix undefined-index error when destructuring shortcuts
  4. You don't need to fiddle with the ports really. Pass ngrok your local origin (localhost:8888) and then it returns an https domain without a port, i.e. on port 80. Paste that portless domain into Snipcart. That should do it. If it doesn't, it might be a problem with how you declare your product data.
  5. localtunnel and ngrok work great in this type of scenario. They expose a public URL that proxies requests to your local dev server so external services like Snipcart get access to it.
  6. There's really two reasons this isn't implemented: 1 — I don't think it's all that necessary. For actual browsing of data that requires state and pagination, there's much better tools available: PageList and PageLister, among others. The pagination info, as implemented currently, is merely meant to communicate that there's more results than currently shown and avoid any confusion there. 2 — It's probably not that trivial to build. The native pagination breaks down once you do any sorting or render multiple paginated panels on a dashboard. To make it work well, it would have to be a custom-built solution that fetches results via AJAX and does the sorting server-side. I'm not currently doing any substantial work on the module, however I'm planning to implement some missing features when I find the time later this summer. In the meantime, I'll happily accept pull requests for a working pagination feature.
  7. You're right, thanks for letting me know. Links should be fixed now. I just switched to a different GitHub username and hadn't come around to updating the links yet. The docs can be found here now: daun.github.io/processwire-dashboard/
  8. @Markus (Blue Tomato) I had a chance to use this on a production site and it's working great! Looks fantastic. Quite a bit faster than expected as well — I measured 10ms per image on a low-end Digital Ocean box, so no need for atomic caching so far. Thanks again for releasing, really appreciate this one 👽
  9. Very interesting! This is definitely the cleanest and most straight-forward option for generating low-quality image placeholders. Thanks for releasing 🌝 Two questions @Markus (Blue Tomato): 1. How is performance for generating the data URIs? Do you generate them on the fly for every request or do you store the final LQIP data URI somewhere as well? My current implementation puts the tiny 200byte LQIP file alongside the source image; I wonder what's better here: generating in memory or reading from disk. 2. I remember you releasing a similar tool for generating SVG shapes — did you stop using that in favor of the blurhash or are you using both in parallel?
  10. This looks great, thanks for open-sourcing! Am I right in assuming that the callbacks will only get invoked if the matching placeholder is found in the server response?
  11. @Sevarf2 How do you manage state in your template — get variables? The template panel works best for displaying static data. For creating pages and importing data I'd suggest creating a custom panel type. That'd make it much easier to manage the required multi-step processes. Or better yet, a Process module for importing data and a separate dashboard panel that only kicks off the import and hands off the actual workload to the main module.
  12. Not sure what you're running into here. If you have a repo or gist with the code that's blowing up, I'm happy to take a look. Best bet is to make sure your templates are properly namespaced (ProcessWire).
  13. All of these are good points, actually. I'm surprised I missed the default field label thing, since it's kind of the standard behavior in most core modules and especially useful in multi-language environments. I'm currently short on time, but will tackle these as soon as things settle down.
  14. Chart.js expects an array at datasets, even if you just use a single one. It'll work once you wrap that in brackets again.
  15. The collection panel does allow for an ›Add New‹ button. It's just not documented at the moment. You can either specify the child page's template or the parent page and it'll figure it out. For the template option to work, the child template must have a default parent defined. This should work: $panels->add([ 'panel' => 'collection', 'title' => 'Widgets', 'data' => [ 'collection' => 'template=widget, limit=6', // Option A: Add to child template's defined parent page 'template' => 'widget', // Option B: Add to specific parent page (page, ID or selector) 'parent' => 'template=widget-list', ] ]);
  • Create New...