Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


d'Hinnisdaël last won the day on September 22 2021

d'Hinnisdaël had the most liked content!

1 Follower

Profile Information

  • Location
    Vienna, Austria

Recent Profile Visitors

2,206 profile views

d'Hinnisdaël's Achievements

Sr. Member

Sr. Member (5/6)



  1. I'd love to hear how you accomplished the filtering part — I'm assuming you've built a panel emitting custom events that trigger panel reloads. Or is it plain old get params?
  2. If you create a panel group and add the tabs to that, it should work.
  3. Yeah, the migration guide looks pretty daunting. In that case I prefer leaving it as-is for now. If you find a simple fix, let me know and I'll happily review/merge any input.
  4. Realistically speaking, I won't get to refactoring the chart panel until later this year. Updating the chart.js library in the meantime sounds good, though. Do you happen to know if the update contains any breaking changes that would apply to its use in the context of this dashboard? I haven't been actively following along and I'd like to avoid breaking people's existing dashboards if possible.
  5. Yes, I have it working in production on a few up-to-date sites. If you find it doesn't work for some reason, feel free to raise the issue here or on GitHub.
  6. Sounds good, happy to integrate that if you submit a pull request on the GitHub repo.
  7. Good catch. Now that I think about it, returning all repeaters makes sense in the admin context — otherwise you wouldn't be able to edit all repeater items on page edit screens. But as you said, you'll have to remember to properly mark/mask unpublished repeaters yourself.
  8. @wbmnfktr I just created a quick test case and you're right, ProcessWire seems to have access checks disabled for repeaters in this context. Output formatting seems to be turned on, however. Is this usually the case in the admin?
  9. Another good option for partial HTML updates is morphdom which transforms the existing dom nodes to match the new incoming HTML without discarding any elements. That way, any dom events, scroll positions or css transition states will be kept on the existing elements. No specific markup required, nor changes to how you set up dom events. It's used in Phoenix LiveView which is pretty close to our use case (live updates from server-rendered templates).
  10. Untested code, but along those lines: wire()->addHookAfter('ProcessPageEdit::buildForm', null, function (HookEvent $event) { $form = $event->return; $statusField = $form->find("name=status")->first(); if ($statusField) { $statusField->collapsed = Inputfield::collapsedHidden; } });
  11. I think the correct way of doing it is a bit different with newer ProcessWire versions. Try this one: require $config->paths->core . 'admin.php';
  12. @adrian I went ahead and added very basic tab support. Thanks for the nudge. If you want to give it a try, feel free to check out the tabs branch of the repo. Theoretically it supports nesting tabs inside groups and vice versa, however it's largely untested so let me know if you run into trouble. I'd like to do some more testing before releasing a new version. wire()->addHookAfter('Dashboard::getPanels', function ($event) { $panels = $event->return; $tab1 = $panels->createTab(['title' => 'Lorem ipsum']); $tab1->add(/* add panels here */); $tab2 = $panels->createTab(['title' => 'Dolor sit amet']); $tab2->add(/* add panels here */); $panels->add($tab1); $panels->add($tab2); });
  13. Good point about making charts styleable via CSS. My experience has been that most clients and most dashboards don't need charts at all, so frankly I don't think I'll be investing too much time here, but if or when I decide to revamp the chart panel I'll keep that in mind. Adding tabs is definitely on my list. Groups are already supported, so adding tabs should be somewhat trivial. There's possible performance issues to keep in mind when rendering too many panels at once but that shouldn't be a blocker.
  14. @markus_blue_tomato I've noticed that blurhashes aren't regenerated when images are replaced via drag-and-drop in the admin. Have you run into this or is this a known limitation of the module? Best way to reproduce is: clone a page with a populated single-image field, drag a new image into the image field of the cloned page and save. The blurhash still looks like the old image from the page it was cloned from.
  15. Thanks @Robin S, I managed to narrow it down to a specific module. Will file an issue on the repo.
  • Create New...