Soma

Remember that you can use more than just one Process module and admin pages hierarchically in the admin. Don't limit yourself to one module or admin page. Also each admin page (nested maybe) can have the same process module attached. Not sure if that would be helpful at all but it's very well possible. I see what you mean with the routes and how they can be used in a REST-like structure. I think if you try to rebuild those you're left with trying urlSegments, but maybe not. I would suggest to try and experiment some time before you deciding on something. Up to you. I mean adding or editing a page can be something like using the ProcessPageEdit and ProcessPageAdd in your module. As you said it's just pages and templates and fields, you already have the - and can extend the crud, and you can use what is there or build completely your own things. Everything fits nicely together with admin modules, Pages, Templates, Fieldtypes and Inputfields. It took some time to get into, but I'm maybe not the best person to advocate all this. Lister and Lister Pro is something that may be of interest for you also, cause it can build Admin pages simply by entering a Name in the module settings and click "add". It will generate a new Lister admin page, that can list pages/entries with the InputfieldSelector field type Ryan built, that let's you build filters/selectors for what to list, you then can edit or add pages etc, run actions (also add your own action modules you can build and extend on) on the results. It's what is new in PW 2.5 and the light version is now in Users and Admin page search. The pro version might also be available soon. It seems all to go very far and is complex, but also shows what's possible. I would try to study some process modules in core and what Ryan have built. But feel free to try implement your way of working, just keep in mind that maybe with a more PW way you also can ensure it will be more "compatible", if that's really an issue. Ryan said once Process modules are just mini apps inside PW, and they can be verstaile and modular. I'm not sure Ryan was ever into REST-like routing, as it's also not something that is an absolute best way.

So if you remove all that code, it is gone? You can also use $runtimer = Debug::timer(); ... code $runtimer = Debug::timer($runtimer); echo "Time: $runtimer"; Edit: corrected syntax...

I'm not sure you'll need to go as far as set a "path", as I see it you have multiple admin pages using the executeSomething, that's the path. Or not?

I don't think it matters really in an admin context I don't think it's old school and that PW is a not-modern framework. It's a kind of its own. It may feel different when coming from other frameworks (I see that, as PW is not my first CMS or Framework), but then I embrace what PW is giving us. Never will everybody 100% agree with design decision made by Ryan, but then it's with everything and after all it's here to discuss and may be extend on a solid base. It's living software and forum. See it as Ryan is listening and giving his view on things, it's what he likes. And if there's something that makes a lot of sense he doesn't restrain from adding it. Need a method to be hookable that isn't? Don't be afraid to question it and ask to add it, after all it's just three underscores to add.

So let's start again. 2. is wrong and is what got me partly confused (apart from not knowing the multiple url segment after a executeSomething()) You can't add url segments to execute() base url of your module /admin/mymodule/ it would give you a unrecognized path. What also got me confused and can't agree, is I'm not sure I understand your statement that the current admin Process modules need a more roboust routing? Or maybe I don't understand. I find them very robust and flexible. I don't think it's ever meant to be used extensively with urlSegments rather than url params if many params are needed. I think you can assume that at least 1 urlSegment is given as you can't set it to 0, or processwire admin won't work cause the executeSomething() methods are internally using urlSegments (as I see now). I'm not sure what you mean with url segment level? I think you mean the maxUrlSegments in config? You could either check for the max setting in the init() and throw an exception or $this->error(message) to the admin that they need to up their setting. Default is 4 and if you really need more (unlikely) you could set that config value using an simple autoload module. I think Ryan isn't using urlSegments in admin extensively other than checking in the init(), if you're on executeSave() "save" and maybe load conditional modules that need to be loaded in the init() because of required load order and it would be too late in the executeSomething(). I'm not sure what Ryan thinks about using urlSegments in admin at all. He still thinks Process modules are a minority, yet I see dozens of them popping up all over the place and there's no real documentation. So basically, you use execute() for the default output of the admin page when you go to it, or maybe use it as ajax handler for something on JS side of your module. That part doesn't allow urlSegments. Segment one added your admin url, must be defined by a executeYoursegment() as we already know by now So those most likely build the "subpages" of your admin page, if really needed. And you could expand using urlSegments or url params.

Then why does admin template not have url segments enabled? And you get a unrecognized path when adding a segment to any admin url that is not defned route using executeNamex? I've built dozens of modules and admin pages over the years, and if this would be something completely new You can get the execute segment also using input url segment. But that's all... there's no more like 2 or 3 ( ahh bulls. .. read next post) Edited: Ah I know now what you mean. It's with after a executeSomething you can add segments to something/segment1/ etc. But not without. So you need at least one executeSomething defined. Sorry for my confusion and so... Edited: Yeah they're virtual and defined by the execute methods. I find them very easy to work with. Just look at some of the admin process modules as you surely did. There's no real best practice regarding those just use them as you need them. I would use those executes for different outputs of 1 admin page. They can also serve as ajax URLs in admin etc. Nothing really special and really simple system. There's no either that or those. Use executes and if really needed for sublogic use segments or simply url params.

Either the pim function for the image Or what are you searching with? $selector = "product_cats.title=" . $type; $products = $pages->find("$selector, limit=12"); Is that a repeater? How many repeaters are there?

Is this module still maintained cause there's some requests and issues. Kinda sad to not get a response.

Hello , anybody out there? I get that this module isn't maintained which is kinda sad Lots of issues with this module https://github.com/FlipZoomMedia/ProcessWire-AIOM-All-In-One-Minify/issues

Ah I think that $this->users isn't working here, you have to use pages $this->pages->addHookBefore("delete", $this, "hookDeleteUsers"); And then check in the hook if you're dealing with a user page.

I often just add an exit("hallo"); inside the hook to test if it gets called at all. If return it won't really be visible most of the times. Also then $pages would be wire("pages") or $this->pages ... and get(selector) will return 1 page not multiple, if need mutliple you need a find(selector) $userPage = wire("pages")->get("created_users_id={$userpage->id}"); wire("pages")->trash($userPage); then pages->trash($page) is only for single pages so you would need a loop if multiple pages.

Process modules (admin pages) can't use urlSegments. It would be conflict with the execute routing methods, which is not a full MVC, and was never meant to be, but quite convenient and still enough flexible for what is needed. Whole PW is built on that, so it must be good enough.

I was in the assumption from your description that users = "editor" create new fields on the fly for every page. While this may possible it won't scale as it would end in too much custom fields when you have a site with hundreds or thousands pages each built that way. If for only used for a couple pages this could work fine, but don't see anything new that wouldn't be possible already with repeater or pagetable fields. I'm using repeater since almost 3 years now, so I think I know what it does . But it doesn't scale well and Ryan is and was originally very sceptic about this sort of thing in PW. Currently there's a new field PageTable that works in a similar was (pages) but is slightly more efficient and flexible built. But still, as forseen, those fields often get misused in some way. The PageTable currently is the most close mini system for building blocks and it works great. It may be of interest for you that MadeMyDay expanded the field a little with his: http://modules.processwire.com/modules/fieldtype-page-table-extended/

Usually for days.

Hard times Well at least I tried out lightning.pw ! It's awesome.

Just looks like the menu code isn't generating the menu properly and that if you look at the code source you can tell that there are the profile pages, but they're not showing in the boostrap menu cause no title or just an <ul class="drop-down"> so not valid code? So after all it looks like the menu code has problems (or not), but could easily spot with a glance at the console or html source... Just looking at the "/profile/" page it has no title field? So sorry but check your code and don't worry about PW setup or something.

I just tried on your site and I'm not sure I see what is exactly not working, it's all working fine. I can login and see profile page (actually am on profile page). So what exactly is not showing that you think it should, and post your (all) code related to that, not just the menu function because that works fine.

Let's keep conv. in thread and not in PM. How would that matter? I just changed the /profiles/profile1/ page to use profiles template too and there's no change in behaviour. Permission are inherited in PW so child pages inherit permission from parents. Not that it really matters here but it's good to keep in mind. Maybe it's me or you're not communicating clearly and with all details, but there's nothing really obvious that I see but then I maybe don't see/know all.

Yeah but that's just an option and nothing to do with your problem. Unless your custom login, doesn't log user in.

Took 10 min (ok 20min) to setup a site with this setup showing that it works just fine. http://lithium-r3t.lightningpw.com/ If you go to site http://lithium-r3t.lightningpw.com/profiles/ You'll get to login (not 404 as default), member member123 is a member user Once logged in you'll see the profiles page and the profile page under it in navigations. I added the menu code you posted in the profiles page, but you can also confirm it by the top default navigation or the sitemap. I sent you a admin login PW so you could see the setup (as you posted).

I think your op is confusing cause you now say userprofile template has view access removed for guests. Yet your screen shot indicates clearly the profiles page is restricted by the lock icon. Not sure if that helps. So your profiles page wouldn't be visible when not logged in but visible when logged in. An all user profile pages are then also viewable. Just judging from the screen shot.

Maybe we should make bug and issue reports have PW version mandatory or we just ignore them.

Your first post shows only profiles template. Not sure what profile. However I set up the same thing and used your function to create a list and it works fine as it should. Maybe we need to see all settings and whole code. Or you just need to try harder cause it isn't magic and just works.

Just a small detail but for "behind" the scenes hooks and such thing you don't need a Process module. Those are for admin pages that have a process added (the module). The ___execute is for returning markup that should show on the admin page with this process. You would create a simple WireData module like the HelloWorld.module. And you don't need that ProcessPageTrash module, that is also an admin page to delete trashed pages. So you need a WireData module that autoloads, Process module shouldn't ever be autoload. autoload on a selector "process=ProcessPageList" doesn't work, and if at all I think it's not suitable cause that's a module working mostly with ajax. Not 100% sure without trying. autoload=>true should be sufficient. You check anyway what you want to delete and already add the hook to users. $this->users->addHookAfter('delete', $this, '___execute()'); // is this correct This is a hook for when a page was deleted, but afterwards, so you never know what page was deleted. May it would be better to use addHookBefore("delete", $this, "hookDeleteUsers"); Then not "___execute()" but a custom function, and you use the $event to catch the page being deleted public function hookDeleteUsers($event){ $userpage = $event->arguments("page"); if($userpage->id){ // do some stuff example $userPage = $pages->get("created_users_id={$userpage->id}"); $this->pages->trash($userPage); } } http://cheatsheet.processwire.com/?filter=trash

Just to make clear my approach is just the way I prefer for members to a site only having their profile and maybe see things when logged in. The view permission is great for that and I keep things flexible on a per page or situation where not possbile with template permissions. Page edit permission isn't necessary really as they don't edit pages in "admin", if then I create forms tailored to the needs. Page editing isn't needed cause I edit them via API and not the page edit screen from the admin. Note that the new Dynamic Roles module may open up a lot more possibilities to fine tune permissions, but then I still wouldn't use that for simple frontend only users. Not saying it's not possible. About navigation, I'm not sure I can follow you. If a template (page) has guest view access removed, it doesn't show in navigations for guest user. One logged in with a role that has view access on that template it shows up. As explained in my post above. There's some settings on the behaviour one you untick the guest view access on a template below, like show 404 or redirect to a url etc and if pages with that template show in lists or not.