d'Hinnisdaël

I've gone ahead and created a separate repo for third-party and Pro modules. Looking forward to having forum users test these and contribute with their own translations. daun/pw-lang-de-modules While the list of modules to include is obviously subjective, I've started with the ones my non-technical clients tend to use on their own (in alphabetical order): Dashboard Jumplinks PageListerPro PageLister Actions Delete Email Set field Set status ProcessWire Upgrade ProFields Table

Hi @Mike Rockett, first of all thanks for this wonderful module! Been using this for a while but never stopped by to say thanks. I just sent two pull requests your way I'd love to get your take on. The first one makes the module work well with multi-language sites by adding a hook for modifying the Typographer Settings instance. The second one just updates the underlying php-typography package, while we're at it.

Just a quick note that the above example will need an adjustment if the site uses a non-default asset folder or url. To make this work when serving assets from, say, /data/* or assets.domain.com/v1/*, we can use the path and url settings for the files folder instead of root. if ('url' === $event->method) { $file = $config->paths->files . substr($file, strlen($config->urls->files)); }

How does everybody feel about creating a separate language pack for official and/or popular modules which would usually be in the site folder? I just noticed the Norwegian language pack making that switch. Especially for the Pro modules (Lister, FormBuilder) it would be nice to have a drop-in solution. And if you don't need them, just install the core language pack and everything stays the same. As far as I can tell, the current de-DE language pack doesn't include module translations, right? I'd be willing to create a repo and get things rolling.

Just reading through the thread now, that looks very promising! Working with event dates from the API/selector side is quite messy but it seems like it doesn't have to be ?

Format Datetime fields as Carbon instances. You can find the latest release and the complete readme on Github. Installation composer require daun/datetime-carbon-format Usage All Datetime fields will now be formatted as Carbon instances instead of strings. Some examples: // $page->date is a Datetime field // Output format: j/n/Y echo $page->date; // 20/10/2020 echo $page->date->add('7 days'); // 27/10/2020 echo $page->date->format('l, F j'); // Monday, October 20 echo $page->date->year; // 2020 echo $page->date->diffForHumans(); // 28 minutes ago Frontend only The ProcessWire admin seems to expect datetime fields to be strings. This module will only return Carbon instances on frontend page views. Date output format When casting a Carbon instance to a string (usually when outputting the field in a template), the field's date output format will be respected. Links GitHub • Readme • Carbon docs PS. I remember reading about a Carbon module in a recent newsletter, but couldn't find it anywhere. Was that you, @bernhard?

I think what I meant to say was that the hash (#prodDescription) is never sent to the server. ProcessWore doesn't know about it. Any redirects that are dependent on the presence or absence of a hash need to be done in JavaScript on the client.

I'm pretty sure those anchor hashes never reach the server and are evaluated by the browser only.

What are you using ProcessWire for in this scenario? Will you have other internal content managed in ProcessWire or will you just be using it to render the external content on the frontend? I've done the latter before (using PW only to import and display data) und wouldn't recommend doing it. Importing the data is just a lot of added complexity. A static site generator might be a better solution here.

There's two ways I've tried in the past that worked: 1. Use a regex for your allowed url segments so it won't match "sitemap.xml" 2. Trigger a 404 manually from your homepage template file if the first input segment is "sitemap.xml"

The code looks right to me. The fact that you're seeing a chart at all means there's probably something off in the way your options are structured. The panel itself only sets the defaults so overriding them like you're doing it should work. I'm afraid I won't be of much help here since debugging Chart.js config is a bit out of scope of this module ?

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.

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.

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

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.

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.

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.

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/

@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 ?

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?

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?

@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.

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).

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.

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.