Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by d'Hinnisdaël

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

    • Like 2
  2. 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;


  3. @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 */);


  4. 3 hours ago, adrian said:

    @d'Hinnisdaël - if you're contemplating moving away from chartjs, can I recommend a library that outputs SVG, rather than canvas - perhaps c3js? The reason being that it makes styling the charts with CSS really easy and also modifying them with D3JS is easy.

    On a different note, I wonder if you'd consider setting up support for multiple tabs using WireTab? One of my dashboards is getting very long and it would be great to be able to split it up into different views and I think a tabbed interface would be effective.

    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.

    • Like 2
  5. @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.

  6. The admin page list seems to be hiding the content of page labels inside square brackets.

    For a page titled Some Title [old], it will display as Some Title, removing the content inside the brackets.

    Oddly enough, a page titled Some Title [old content] displays correctly as Some Title [old content].

    My guess is that ProcessWire is trying to interpret the part in square brackets as dot-field notation and trying to access a field value. Since there's no field named 'old', it will drop the brackets and everything inside entirely. Is this documented behavior? Can this be turned off?

    (Tested on latest dev branch, 3.0.171 and 3.0.181)

  7. I see. In that case creating a custom field would probably be best and have little overhead if it's autoloaded.

    What's the reasoning behind storing the data on the parent and not on the children? Performance? Storing it on the children, you could use the `$page->meta()` api and avoid the need for hooks since that should be cloned alongside the page. It currently only allows associative arrays and might have a performance penalty as well.

    • Like 1
  8. Shouldn't it be enough to associate the styles with the block page's id and make sure cloning a page also clones its associated styles? If you assign a unique id (pgrid_id) to each block but keep that around after cloning, you won't be able to edit the cloned page's styles without it affecting the original page's styles. Or maybe I'm missing a part of the picture here.

    • Like 1
  9. 1 hour ago, StanLindsey said:

    How have you found ploi? Im well up for making use of their additional server types. 

    Specifically it doesn't look like they give an Apache option, are you running Processwire on Nginx? 

    It's working great, we're not missing much in terms of features. I think ploi did at some point offer Apache + Nginx but scrapped the option. We're running ProcessWire on Nginx now. It requires some extra work here and there but is running smoothly overall.

  10. Having a sanctioned way for creating "dynamic" routes would definitely be a worthwhile addition to the core.

    I've settled on creating JSON endpoints as separate templates and implementing the routing inside the template file. Sometimes a switch statement is enough, sometimes FastRoute makes more sense. It tends to be a lot of boilerplate even for simple tasks.

    I agree with Ryan that piggybacking on 404s is technically correct even though somewhat of a misnomer. It ensures that regular pages always have priority when routing a request. In the case of conflicts with a module, the site has a way of overwriting and customising the routes.

  11. @schwarzdesign Thanks for reporting. I'm afraid there's no easy solution without changing how the core handles user edit permissions. Currently, the editable() check fails for all processes other than the default page-edit or page-lister ones. That's why it doesn't work in the context of the Dashboard process. See the corresponding source code of PagePermissions.module.

    I'm not sure why it's done this way and if there's a chance to get this opened up. I'd suggest you open an issue in the official ProcessWire repo to get a discussion started.

    Checking for user-admin permissions as a special case sounds good but won't solve the problem: the user permissions are a lot more complex when you're handling superusers vs. non-superusers and multi-layer permission systems. There's user-admin-all and any combination of user-admin-[role] permissions we'd have to check manually. It's definitely better than the current state, though. I might implement this in the near future.

    • Thanks 1
  12. We've switched most of our servers to a setup of Hetzner VPS managed via Ploi. I haven't found many differences between Cloudways, ServerPilot, Moss, Ploi, etc. if all you're doing is hosting simple Laravel or ProcessWire sites.

    The main advantage seems to be speed here — compared to shared hosting, the sites are between 4 to 10 times faster even when hosted on the cheapest Hetzner instance at 3$/month and with security and updates taken care by Ploi. We liked Ploi because it's great at regular backups, has lots of notification channels for automatic deploys and the admin panel is very polished.

    • Like 3
  13. Does anybody else feel like the login screen could use a revamp? While it might not be the most important thing in the world, first impressions count.

    On large(r) screens the login form seems to get lost in the upper third. The rest of the admin looks a lot cleaner and more deliberate.


    A few tweaks would go a long way in making the login screen work on all device sizes. Those are two custom styles I've been adding to my sites lately, one PW-branded and one not. No markup changes needed, just CSS.


    This second one borrows heavily from Twill's login screen.


    The floating environment label has turned out to be really useful to see at a glance if one is editing on staging or live. Not sure if there's a way to make this 100% core compatible.

    • Like 6
  14. 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.


    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
    • Like 2
  15. 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.

    • Like 1
  • Create New...