Jump to content

d'Hinnisdaël

Members
  • Posts

    160
  • Joined

  • Last visited

  • Days Won

    5

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

d'Hinnisdaël had the most liked content!

1 Follower

Profile Information

  • Location
    Vienna, Austria

Recent Profile Visitors

1,987 profile views

d'Hinnisdaël's Achievements

Sr. Member

Sr. Member (5/6)

257

Reputation

  1. Thanks @Robin S, I managed to narrow it down to a specific module. Will file an issue on the repo.
  2. 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)
  3. Accepting arbitrary pages sounds like a nightmare to support. There's really no upside to it that I can see. Linking existing pages via page reference fields sounds much more doable and logical. You'll avoid all those problems you already recognized.
  4. I think your reasoning is sound. Especially for blocks that are re-used across pages (which I didn't have in mind).
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. @MarkE There's currently no direct way to do this — the chart data is passed as a JSON blob, so no functions. I've been looking at setting up charts via JS files or JSON endpoints, but nothing concrete yet. I'll probably end up moving the chart panel to a chartkick.js implementation which would allow all of that.
  10. @MarkE Callback function in what context? What's the goal?
  11. There's currently no way of grouping panels in tabs. What'd be your use case?
  12. @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.
  13. +1 for a solid database migration mechanism. Deploying field/template updates to production involves a lot of manual copy/pasting. Having a built-in way of describing changes in database structure would make automated deployments and rollbacks possible.
  14. The module seems stable enough to bump to version 1.0. Notable changes Declare a private namespace, solving install issues Require the latest ProcessWire master version 3.0.165 Add a new panel type Add New Page which recreates the core add-page shortcut menu
  15. 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.
×
×
  • Create New...