Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by d'Hinnisdaël

  1. @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 👽
  2. 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?
  3. 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?
  4. @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.
  5. 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).
  6. 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.
  7. 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.
  8. 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', ] ]);
  9. Looks great! Let me know how it's faring and I'm happy to use that instead of the page's process setting. You're doing a good job convincing me here. It does make sense conceptually and thinking about the module ecosystem as a whole. That said, the module is currently at a point where I'm not missing much in terms of functionality and am not that keen on re-writing the whole output layer with no new features to show for it. And it's not like I have the time, with everybody currently wanting to expand their online stores... If anything, I'd put that on the list for version 1.0 as a summer/fall project since it'd be a breaking change either way. If you definitely need this and need it soon, I'm happy to accept a pull request. But why would you want to re-use a dashboard panel in another module? That doesn't make sense to me. The way I see a dashboard working is the other way around: it displays a condensed form of information found elsewhere, e.g. shortcuts from all possible admin views, a single chart from a whole host of data, the most recent news pages from a whole archive of them, and so on. If anything, you'd re-use a fieldset from one of your modules in the dashboard. Using markup from an existing module in a dashboard panel is working just fine — with the exception of granular access control and conditional visibility. Which to me seem minor but might be a deal-breaker for more corporate-y types of applications.
  10. Hi @bernhard, thanks for your feedback, really appreciated. There's a few things to unpack here: Module dependencies The panel modules need to inherit from an actual class from a separate PHP file which made things more difficult than I'd like to admit. So right now I'm happy it's working properly at all. I wouldn't dwell on this issue too long since all modules are within a single folder and the naming is quite obvious. Might revisit this in the future. Exit on save I'd always expect »Exit & Save« on a page edit form to get me back to the page tree, since that's the level above. I'm happy to make that configurable, though. Admin home process Can you think of a way to permanently and consistently re-route everything to the admin homepage instead of the page tree? And then still have the page tree clickable as a stand-alone view? That would be a better solution that the current one for sure. I've had a previous version that changes the admin parent's process manually and changes it back on uninstall, but that was buggy as hell and really scared me. Asset CDN Good point about the intranet. I'm really uncomfortable bundling dependencies in projects. There's something quite icky about it and using a CDN feels like sort of a happy middle ground, but your point is valid. Panels as Inputfield I get what you're saying about not re-inventing the wheel. I'm afraid I have to disagree here, though. Input fields primarily serve the need to create complex forms, to arrange components for user input. In ProcessWire, it's become common to use them for everything under the sun since they're as close to a universal layout component as it gets. Might be a misnomer in hindsight, but I don't feel like every layout panel in the admin needs to be an input panel. It's useful for sure, but I don't see the need to have every container in the backend inherit from the base Inputfield class. They come with a lot of additional logic that doesn't apply to simple output panels, like the collapsing stuff and the conditional display logic. For context, the initial version of the module was created the way you suggested, using ProcessWire's input fields and fieldsets. There was just no way to make them look nice and behave the way the module required. Laying them out in a grid with proper spacing and responsive sizing was plain horrible. You're not only fighting a hundred separate existing CSS rules for margins and outlines but ProcessWire's internal JS for collapsing/uncollapsing/calculating of field widths on top. One of the requirements for me was to have 'renderless' panels without border, background or margin to achieve floating panels for charts. Undoing all the internal inputfield styling just wasn't something I was comfortable spending my time on. Out of curiosity: what's a possible scenario for re-using a dashboard panel in some other part of the admin?
  11. Release 0.6.14 fixes the overflow issue in Firefox.
  12. Sure. Happy to merge your fix. The other one seems to be an issue with the Textareas module. I hope 👽 The dashboard module uses PW's internal $page->getText() method to resolve the dot syntax field name: $page->getText($markup, false, true) (where $markup would be 'c_campaign_parameters.utm_source') Haven't worked with the textarea module so far, but it either doesn't cast strings by default or it overwrites the getText method. Suggested fix in your case: create a custom hook property that casts the textarea field into a string manually, and then use that property for display in the dashboard panel.
  13. Actual pagination buttons aren't implemented at the moment. That footer is meant to provide clarity for editors that there's more records than the ones currently displayed. I'd consider the dashboard more a jumping-off point for editors than a replacement for other admin views better suited to browsing pages (like the page tree or listers). Ideally, they'd spend as little time as necessary on the dashboard and then go off to do whatever needs to get done in other parts of the admin. While I'm pondering whether adding this is a good idea (it is a useful feature!), there's two options: 1. Create a copy of the included collection panel and give it a stab yourself. It shouldn't be too difficult — the module supports reloading panels via AJAX and provides the necessary JS events. Have a look at the documentation section on creating custom panels or crack open the chart panel to see an example. Let me know how it goes or if the module is missing anything to get this working. 2. There is a (currently) undocumented parameter you can supply to display a ›View All‹ button next to the pagination info. The parameter name is list and it takes a page, page ID or selector. If it's an admin page (ProcessLister), it will link to that page. If it's a content page (e.g. your Clients parent page), it will open the page tree at that page. $panels->add([ 'panel' => 'collection', 'title' => 'Clients', 'data' => [ 'collection' => 'template=client, limit=10', 'sortable' => true, 'pagination' => true, 'columns' => [ 'title' => 'Title', 'url' => 'URL', 'modified' => 'Modified', // Display "View All" button in footer 'list' => 1184, // ID of lister page ] ] ]);
  14. @Macrura My two cents on this: I feel like it's the other way around — $config as a data store is (for the most part) internal to ProcessWire's backend. The $config->scripts and $config->styles arrays are wired up in a way that makes sense for the admin panel to work properly. Using them for the frontend is surely convenient (I've done that myself on a lot of sites) but probably not meant to be used that way and prone to breaking. I've personally stopped using the internal file arrays for that reason and created namespaced versions for the frontend.
  15. I pushed release v0.6.13 which fixes the page list action buttons (unpublish, hide, etc.)
  16. Just had a look. Your syntax for the dataset options is off: you need the remove the outer array around backgroundColor. Then it works as expected. 'data' => [ 'datasets' => [ [ 'data' => [ floor($normalTotal), floor($recurringTotal) ], 'backgroundColor' => [ 'rgba(193, 66, 66, 1)', 'rgba(193, 66, 66, 1)' ] ] ] ] You're right though about the default colors not being applied to pie charts. I pushed release v0.6.12 that fixes that.
  17. What happens if you leave out the backgroundColor key? If that restores the default color theme, it's most likely a Chart.js configuration issue — the panel only passes the options through to the library. If it's still all grey then, let me know.
  18. In that case, I'm afraid we're out of luck. The PageList component in ProcessWire doesn't seem to work well with multiple instances on the same page. Do the page actions work if there's only one instance? Just to make sure I haven't broken the whole panel with the latest release.
  19. Try again. I re-built the minified JS for production and pushed a new release. Should work now.
  20. How is RockDatetime different from wrapping date fields in Carbon instances? Not trying to be dismissive here, just curious how this would help to establish a sane default for dealing with datetimes (which ProcessWire is currently lacking, unfortunately).
  21. You're right, it was duplicating page lists. I pushed a fix as version 0.6.10. Try and pull that and let me know if it works.
  22. Are you accessing it through $page->page_icon? That should give you the icon code.
  23. As long as your classes are named this generically, you'll sooner or later have people showing up in the forum complaining about broken sites 🌝 What IDE are you using? A lot of them can refactor classes and move them into different namespaces, e.g. PHPStorm has a Move Namespace dialog. However, if you go the route suggested by teppo above, you only need to move all your helper classes into a subdirectory/namespace, setup the autoloader for that namespace, and call it a day. In reality, it will mostly simplify your code and get rid of all the require()s. I'll quote his suggestion here again:
  24. That's kind of my intuition as well. Wait a little longer and see if this becomes a problem for more people, and in case rename it.
  25. Am I right that in the case of Wireframe if somebody has an existing class of Wireframe in their codebase (for whatever reason), it would still clash with your module? So without waiting for 3.0.150, the class name of the module itself must be unique anyway? Not sure how I should handle this one. Rename the module and post a notice here in the forum? Hope people will figure it out and move their own Dashboard classes into a different namespace until I can require 3.0.150? My intuition is to go with the latter, but maybe somebody has an opinion on that. When I used to cobble together custom dashboards for clients in the past, I have used ProcessDashboard or CustomDashboard. Maybe it's not that big a deal 🏓
  • Create New...