Soma

Yeah there's pros an cons. But it seems you never had done bigger complex sites where there's a lot of demand for modularity and flexibility. I simply wouldn't be able to do what I do currently (project) with that old default approach. And I used many different approaches on PW projects. That's why one have to come up with other approaches. You can for sure, but sorry, if that's your main concern, I have to tell that's just not true. It's not required at all. It's just an (bad?) example by Ryan. You don't have to do that and there's a lot of ways you can avoid that. I use delayed output with using templates only as a controller that defines a layout template, load, or delegates and renders widgets/partials/content using view templates etc, where there's mainly the plain html tags with some php used as "template engine", it's only basic presentational logic. Maybe also have a look at the Spex template helper module.

@everfreecreative The thing is if you have like a lot of templates you'll have to do this for every template, once you want to change something on that part you'll have to edit all templates, so it doesn't scale well and isn't as flexible. If you wanted to conditionally not include header and footer, you'll have to edit all templates again. Once you want to be able to be more flexible with different layout types you're left with editing all templates to implement some logic. Once you decide you need to have different main container template for certain templates ... it doesn't scale as well. Of course to some extend you can incorporate things before the header include, but what if you have some after you wanted to add a css or js or something else? Maybe you want to be able to render a widget (page) inside content generation, that has a module or partial, that then wants to load conditional things like assets, you can't with your approach as the header is already "rendered".

Ah nice! I think I kinda ignored or forgot the little appended note there in the timers tab. This is relatively new. I wasn't aware of the context when writing thinking about templates!

Or just use $log ? $timer = Debug::timer(); ... $log->save("mylog", "phase 1: " . Debug::timer($timer)); $timer = Debug::timer(); ... $log->save("mylog", "phase 2: " . Debug::timer($timer)); Will create a log in site/assets/logs/ as mylog.txt

After all I think it depends a lot on what context and how it's used. If in templates, a call to the main module (which is not autoload), you can't use the autoload condition, unless you also trigger something from the template which is not that nice. In the end I think a conditional autoload also requires some "resources" so loading a simple module that only has hooks anyway, might not be as bad you think. As far as I know modules that hook into something need to be "autoload" anyway, if using a condition or not doesn't really matter and is a ok tradeoff? Not sure if I'm overlooking something obvious. Of course it's a good thinking in the first place to not waste resources, would be good to maybe have some sort of data to show what impact autoload really has when there's 100's of additonal modules? I'm also curious how Ryan would see this, I can't remember there was ever something in more depth about this. Anybody care to test?

I'm not sure I really understand it enough, is it just to format values? But isn't that what TextFormatter modules are in PW. There can be multiple and sorted, attached to a per field basis. If there's any it will run the value through the Textformatters. Fieldtype::formatValue is used to sent through a value of a field after wakeup, but only when outputformatting is on ($page->of(true), you can also disable it or get the unformatted value). Some fields use that to format a value like Datetime or Page. It can also be hooked via modules or in templates. To get a unformatted value you can use $page->getUnformatted("fieldname"); A hook in a module example $this->addHookAfter("Fieldtype::formatValue", $this, function(HookEvent $event){ $value = $event->return; $value = $event->arguments("value"); $page = $event->arguments("page"); $field = $event->arguments("field"); $event->return = "new value"; }); About your module, I still don't understand the real world use case for this or and if it's really best way to go for it. Anyway I think it's a little problematic (?) to have the helper functions outside the module in the global namespace (no namespace yet in PW) and if it's good to name a module just "Filter" ? Edit: I'm maybe also confused by the word "filter" in context to PW, cause there's a $wirearray->filter(selector); but it's not about the same thing?

Sorry wasn't reading carefully. Maybe if you can provide more what you want to archive, maybe there's better alternative ways. It's also good to know that if you change the autoload setting in code you have to refresh module cache or reinstall module.

Maybe worth reading https://processwire.com/talk/topic/5477-check-if-a-module-is-loaded/

You have to set the default page name cause it's required.

If you go the urlSegment REST like routing you could still ensure and set the maxUrlSegment for your module. This for example would work out: <?php class MyHelper extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'MyHelper', 'version' => 1, 'summary' => '', 'singular' => true, 'autoload' => "Process=ProcessHello", // only load on your module ProcessHello ); } public function init() { $this->config->maxUrlSegments = 7; // more ? } } It's not possible from an non autoload Process module to overwrite it but a little helper module would do fine.

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.