Leaderboard

A bit offtop... Maybe such epic modules like Tracy Debugger (and AOS, and some else, probably) could get their own sub-forums under Modules/Plugins? Kind of like Padloper got its own under Vip Support? I am sure, it can be done and (arguably) would make it easier for people to find stuff. But would it make it easier for maintainers? What do you think, @adrian?

Custom panels shipped with my own modules would be great ? Maybe Tracy could scan for /site/modules/***/TracyPanel***/ folders? So I could ship my module with two custom panels: /site/modules/MyModule/TracyPanelFoo/Foo.php /site/modules/MyModule/TracyPanelFoo/Foo.css /site/modules/MyModule/TracyPanelFoo/Foo.js /site/modules/MyModule/TracyPanelBar/Bar.php /site/modules/MyModule/TracyPanelBar/Bar.css // or like this? /site/modules/MyModule/TracyPanels/Foo/Foo.php /site/modules/MyModule/TracyPanels/Foo/Foo.css /site/modules/MyModule/TracyPanels/Bar/Bar.php thx again for this brilliant module!

Hi @teppo - I'd love to make it easier to support custom panels. It's interesting about the $allPanels array - it really wouldn't be necessary except for the title vs the name, eg "phpInfo" to "PHP Info". In most cases it would be easy to programmatically convert the case, except for those with acronyms (PHP, API, etc). I think you are probably correct that hooks might be problematic because Tracy is always loaded before all other modules. Perhaps module authors who want to add new Tracy panels could simply provide me with the path and panel class name and I can have Tracy check the location if the module is installed. Perhaps as simple as adding a new $externalPanels array that is added to as needed? This array could be merged into the $allPanels array which would probably need to be made multidimensional to support separate title and path properties so that https://github.com/adrianbj/TracyDebugger/blob/cc1c17e50487580f5c1e3485411d7c9a766b0a4f/TracyDebugger.module.php#L1526 would know what path to use to load these external panels. Anyway, I'll have a play around and see what I think will work best and send you a test version to work with.

A new module that hasn't had a lot of testing yet. Please do your own testing before deploying on any production website. Custom Paths Allows any page to have a custom path/URL. Note: Custom Paths is incompatible with the core LanguageSupportPageNames module. I have no experience working with LanguageSupportPageNames or multi-language sites in general so I'm not in a position to work out if a fix is possible. If anyone with multi-language experience can contribute a fix it would be much appreciated! Screenshot Usage The module creates a field named custom_path on install. Add the custom_path field to the template of any page you want to set a custom path for. Whatever path is entered into this field determines the path and URL of the page ($page->path and $page->url). Page numbers and URL segments are supported if these are enabled for the template, and previous custom paths are managed by PagePathHistory if that module is installed. The custom_path field appears on the Settings tab in Page Edit by default but there is an option in the module configuration to disable this if you want to position the field among the other template fields. If the custom_path field is populated for a page it should be a path that is relative to the site root and that starts with a forward slash. The module prevents the same custom path being set for more than one page. The custom_path value takes precedence over any ProcessWire path. You can even override the Home page by setting a custom path of "/" for a page. It is highly recommended to set access controls on the custom_path field so that only privileged roles can edit it: superuser-only is recommended. It is up to the user to set and maintain suitable custom paths for any pages where the module is in use. Make sure your custom paths are compatible with ProcessWire's $config and .htaccess settings, and if you are basing the custom path on the names of parent pages you will probably want to have a strategy for updating custom paths if parent pages are renamed or moved. Example hooks to Pages::saveReady You might want to use a Pages::saveReady hook to automatically set the custom path for some pages. Below are a couple of examples. 1. In this example the start of the custom path is fixed but the end of the path will update dynamically according to the name of the page: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'my_template') { $page->custom_path = "/some-custom/path-segments/$page->name/"; } }); 2. The Custom Paths module adds a new Page::realPath method/property that can be used to get the "real" ProcessWire path to a page that might have a custom path set. In this example the custom path for news items is derived from the real ProcessWire path but a parent named "news-items" is removed: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'news_item') { $page->custom_path = str_replace('/news-items/', '/', $page->realPath); } }); Caveats The custom paths will be used automatically for links created in CKEditor fields, but if you have the "link abstraction" option enabled for CKEditor fields (Details > Markup/HTML (Content Type) > HTML Options) then you will see notices from MarkupQA warning you that it is unable to resolve the links. Installation Install the Custom Paths module. Uninstallation The custom_path field is not automatically deleted when the module is uninstalled. You can delete it manually if the field is no longer needed. https://github.com/Toutouwai/CustomPaths https://modules.processwire.com/modules/custom-paths/

I think it's probably good idea, but this is a request for @Pete and @ryan

Yeah, I know it's coming, but it's still often not that great of an improvement in size, whereas AVIF looks like it will be significant.

Hey @adrian! Just wondering: what's your take on extending current panel collection with custom tools on a case-by-case basis? Sorry if this has been discussed already, there's so much stuff in this thread that I can't keep up anymore ? I just had a quick look and it seems that adding new panels is currently not possible without directly modifying the module file(s) and dropping the class file to the panels directory. I was wondering if you'd be open to adding some way of "injecting" custom panels from outside the module? My initial idea was something along the lines of allowing custom options to be pushed into the allPanels array by passing it to hookable methods at certain points and adding support for array values so that custom panel options could contain both name and path. (I didn't actually try this. It's possible that hooks won't work due to load order and all that, so another option would be the Tracy module reading them from config settings; not quite as elegant or robust, but pretty much guaranteed to work.) Anyway, just throwing in ideas. I'm working on some Wireframe related dev tools, and was thinking that it'd be neat to have them available in the admin — and what better way to do that than to introduce them to Tracy... ?

I hope we are getting closer - code keeps lockdown hands busy. ?

@kongondo, still no announcement? ? I was sending ecommerce quotes all summer thanks to government grants and still hoping to at least beta test the new Padloper.

Hi @michelangelo, could you please post bug reports on GitHub: https://github.com/gadgetto/SnipWire/issues?q=is%3Aopen+is%3Aissue And please include the complete configuration of your currency (screenshot?) from within Snipcart. Questions and suggestions regarding SnipWire are OK here, but it's very hard to follow bug reports in this forum...

My approach from today: $wire->addHookProperty("Page::myFooLabel", function($event) { $page = $event->object; if($page->template != 'foo-page') return; $event->return = $page->title . " (foo label)"; } Then just set the label field to "myFooLabel" and enjoy. This also has the benefit of having the dynamic label always available easily via $page->myFooLabel

Nearly ten months later, FormBuilder is happily at work here and I am testing a home-brewed module that implements repeating fieldsets for FB forms [TM]. I have named it FormBuilderMultiplier and put it on GitHub in case anybody is interested.

Thanks Robin, this worked well and avoids the approach of having to hack PW and make InputfieldPage::getPageLabel hookable. Note: In order for it to work, you must edit the field's "Label field" under the "Input" tab. It must be changed from "title (default)" to "Custom format (multiple fields) ..." and a value must be put in the "Custom page label format" field, even if it's just a temp value (I put "x").

I haven't tested it much but it looks like you can hook Page::getMarkup() $wire->addHookAfter('Page::getMarkup', function(HookEvent $event) { $page = $event->object; if($page->template->name !== 'TEMPLATE(S)_USED_IN_YOUR_PAGE_FIELD') return; $out = $page->title; // add more stuff to $out using $page $event->return = $out; });

Simple answer is that @Valan had a need and commissioned me to develop this . Seriously though, mr-fan already covered it brilliantly. When I get some time, I'll post some other examples.

// assuming your images field is named "images": $pagesWithImages = $pages->find("images.count>0"); // now that you have all pages with images, you can put them all in 1 array if you want $allImages = array(); foreach($pagesWithImages as $p) { foreach($p->images as $image) $allImages[] = $image; }