Jump to content

d'Hinnisdaël

Members
  • Content Count

    133
  • Joined

  • Last visited

  • Days Won

    5

d'Hinnisdaël last won the day on October 20

d'Hinnisdaël had the most liked content!

Community Reputation

215 Excellent

1 Follower

About d'Hinnisdaël

  • Rank
    Sr. Member

Profile Information

  • Location
    Vienna, Austria

Recent Profile Visitors

1,723 profile views
  1. 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 🤗
  2. 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?
  3. 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.
  4. I'm pretty sure those anchor hashes never reach the server and are evaluated by the browser only.
  5. 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.
  6. 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"
  7. 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 👽
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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/
  15. @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 👽
×
×
  • Create New...