I’m trying to build a new topbar page.
I decided to model the page after the Users page. So I copied all the user pages in the panel into files called accounts - so that’s the files in controllers under directories views and api, the files under views/users into a directory called accounts. I also added routing inside the routing files (both views and apis). I also added a link in the top bar to accounts. I of course made sure to change all the copied files to do the new thing (UsersController is no AccountsController, etc.) but whenever I try to go to the accounts link I get a page not found.
Is there something I’m missing? or even better is there a guide on how to do this?
You mean you want to extend the Panel with a new view? That’s currently not officially supported as you currently need to change files in the
panel directory, which will be overwritten on updates.
Maybe you can implement what you need using a dashboard widget though.
Yes, I do mean that. and while this is not “officially supported”. It doesn’t mean I can’t do that. and even update if I keep track off the changes I’ve done (which I’m doing).
I haven’t seen anything in the dashboard widget docs that helps me.
Anyway - did anyone do this before? are there any suggestions? For me right now it seems like the main problem is the routing - so if I could get some tips on that…
Regarding your issue, it sounds like your routes aren’t being loaded, or maybe they’re being loaded too early.
It’s usually best to avoid modifying core files, since upgrading Kirby versions (and panel, and toolkit) will overwrite your changes. You’d have to rebuild/reimplement your changes each time you upgrade, and Kirby is now doing more regular minor releases.
Most of us tend to build custom administration pages via the front-end using Kirby’s routes, authentication, and our own custom handlers/controllers.
At first, I thought that I’d be limited by not being able to extend the panel with my own custom pages. But there are ways to add custom routes to the panel. However I’ve found that using custom front-end routes/views for administration of other things has actually kept a good separation of concerns.
For example on one of my sites, the admin/editors can access the panel and manage content and users. But there is also a “Store Manager” role, and these users can’t access the panel, but they can use a front-end “Manager’s Dashboard” that I built.
This keeps the panel unmodified, so I’m safe to upgrade. And it actually helps maintain a good separation between content administration and “other management tasks.” I’m much more comfortable keeping these users outside of the panel.
Jevets. this might make snese - I’ill think about it.
But it somehow feels comfortable if the admin can do everything from the same place with the same log-in. and don’t need different places for the same person.
Agreed, and that’s how I initially felt, too. It took me a while to accept this, but after implementing and training my client (editor) and her staff (store managers), it actually worked out wonderfully.
There are one or two managers that we trust enough, so we gave them Editor role. And they were happy with separate areas, too. Most days, they login and use the Manager’s Dashboard for day-to-day operations. They don’t manage content frequently every day, so they’re totally fine with having a separate place.
And they get a nice URL to remember: “go to /manage” to do your work.
And the front-end authentication uses the same users as the panel, so if you’re logged into the site, you don’t have to log in again on the panel (assuming your role allows panel access).
So I’m with you here, but I was very surprised at how well it actually did work out. It really took me a while to come around to this approach instead of providing a one-stop admin section. And I’m very glad I did.