Leaderboard

Hi, even if i would not recommend what you are looking for being a great fan of structure in the url and the use of page reference when it comes to products/posts and so on categories, i think you would need two hooks the first one to create the wanted url on the fly, the now well known @WillyC's one let'assume your products have a template named... product 😀 $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; if($page->template == 'product') $e->return = "/car/internal/$page->name/"; } this will automatically generate the url but, big bvut, clicking on the link would lead to a 404, thus now comes the hook in the page @da² is speaking about $wire->addHook('/car/internal/(.*)', function($event) { $name = $event->arguments(1); $product = $event->pages->get("template=product, name=$name"); if($product->viewable()) return $event->pages->get($product->id); }); and this tells pw what is the real page behind this fale url (both hooks, in that order, in your ready.php file) written on the fly so you may have to adapt to your templates and situation (and, maybe also use a more restrictive regex...) something more, this will only work if each product is under one category when the use of page reference would allow a product to belong to more than one have a nice day

And even more. This is how the page names and titles show up in the database. Looks like it is using some non-standard punycode to encode the names and this is also where everything seems to break:

There you go running on the same test install from above: You are on to something here.. that looks very inconsistent! Note how the page name in the log message is always correct but shows wrong in the "Settings" tab.

It's always a tricky decision whether to include packages or have the user run composer. If license terms allow it, I've so far included the full source to make sure users don't end up with incompatibilities introduced by future versions. This, of course, sometimes means to react quickly if a vulnerability is discovered in a package my module relies upon, but I still prefer that to dysfunctional installations. About using parser libraries at all - PHPs native capabilities are a PITA, and there are reasons why almost everybody uses a third party parser package (I had to rely on native stuff for a bunch of email parsing scripts that extracted contents of non standard conformant emails, and that was no fun at all). Which to choose? A hard decision. Both are mature projects. One thing that comes to mind would be the dependency on PECL mailparse, which also has a known memory leak that can hit hard if one tries to process a larger number of mails in a loop. This and more intuitive handling of addresses could be a point towards Mail-Mime-Parser. On the other hand, a few content part handling methods feel more intuitive for PHP-Mime-Mail-Parser. No clear winner there, but I'd personally go for the simpler option from the user's perspective (i.e. Mail-Mime-Parser). You might consider working with a queue directory as an option instead of using a direct pipe, which would improve resilience and performance. In cases like the database going away, all emails could still be written to the directory and processed later in a (lazy) cron job. Interfacing software is my main job description, and one philosophy I've acquired is to always finish pipe jobs as fast as possible.

My planned approach to this was to allow multiple templates as 'parents' for child mails. The mail will be saved under whichever parent has the matching 'to' address. It is then up to the user to use a LazyCron to process the mail pages as they wish (with different processing possible for different parent templates). So, for example, 'blog@mydomain.com' can be used to process to a blog whereas 'maillist@mydomain.com' can forward the mail to a list.

That's what I feared and that suppression might not fully work. Good idea. I'll look into that. Definitely. I am trying to build it to be as general-purpose as possible, although my immediate need is to replace a hacked version of ProcessEmailToPage in a specific application. Hence the provision of hooks. Once I have the components in place, I will put it on GitHub. My view is that open source benefits everyone, including the original developer.

I get the same error, but I can install just fine. I don't think the dev environment plays a role there, it's the browser running the JS. Why is the error preventing you from continuing? The installation page should still be there. However, you should be able to comment out line 843 in wire/modules/AdminTheme/AdminThemeUikit/scripts/main.js with no ill effects if Safari for some weird reasons prevents the page from working because of the error.

I ended up modifying the module (FieldtypeSecureFile) of Wanze to my needs. Wanze's module doesn't delete the files nor the sub-directories where the files are in. Also, the module didn't work in the latest version of PW. Now it does, but I don't know about the old versions (and I don't care). I left out the download part and the roles, because I don't need that. I'm sure there are some things that could be approved in the code, but it works for me. I can now safely upload and delete files in a directory outside the webroot. Example: /home/username/securedir The link to the module: FieldtypeSecureFile (GitHub)

Some more peculiarities which might help us:

Unfortunately I don't think this module can be easily adapted to support multi-language menus, because to get the repeater-like interface for variable numbers of child items working I needed to come up with a custom way to store that data in JSON format rather than use the core way of storing individual inputfield data. So multi-language support would mean creating a new way of storing multi-language data that's separate from PW's way and I don't want to try to reinvent that wheel. But you could hook some of the same methods that the module does to add your own custom menus to the admin. Example: $wire->addHookBefore('ProcessController::execute', function(HookEvent $event) { // Prevent admin menus from being cached $this->wire()->session->removeFor('AdminThemeUikit', 'prnav'); $this->wire()->session->removeFor('AdminThemeUikit', 'sidenav'); }); $wire->addHookAfter('AdminThemeFramework::getPrimaryNavArray', function(HookEvent $event) { $items = $event->return; $user = $event->wire()->user; $data = [ [ 'label' => [ 'default' => 'Shirts', 'french' => 'Chemises', ], 'url' => [ 'default' => '/shirts/', 'french' => '/chemises/', ], 'children' => [ [ 'label' => [ 'default' => 'Small', 'french' => 'Petit', ], 'url' => [ 'default' => '/shirts/small/', 'french' => '/chemises/petit/', ], 'icon' => 'smile-o', ], [ 'label' => [ 'default' => 'Medium', 'french' => 'Moyen', ], 'url' => [ 'default' => '/shirts/medium/', 'french' => '/chemises/moyen/', ], 'icon' => 'thumbs-o-up', ], ], ], ]; foreach($data as $item) { $menu = [ 'id' => 0, 'parent_id' => 0, 'name' => '', 'title' => $item['label'][$user->language->name], 'url' => $item['url'][$user->language->name], 'icon' => '', 'children' => [], 'navJSON' => '', ]; foreach($item['children'] as $child) { $menu['children'][] = [ 'id' => 0, 'parent_id' => 0, 'name' => '', 'title' => $child['label'][$user->language->name], 'url' => $child['url'][$user->language->name], 'icon' => $child['icon'], 'children' => [], 'navJSON' => '', ]; } $items[] = $menu; } $event->return = $items; });

This week I got wrapped up in unexpected client work, but it did lead to development of a new Inputfield module, which I think I’ll be using a lot, and hoping some others might find it useful too. It’s called Small Select Multiple, and the purpose of it is to provide a multi-selection input that is as simple as a single-selection input, and that didn't introduce new UI elements, sticking just to native browser controls. It came about because a client has a large front-end form that has a lot of multi-selection inputs, which we handled with checkboxes. It started to become too much for users, so we tried changing to AsmSelect. That helped a lot, but it still became overwhelming once a lot of options were selected. We needed something that looked simple from the start, and stayed simple even after a lot of selections had been made. The Small Select Multiple input seems to do the trick. You can use this input type with Options fields or Page fields, or anywhere else you might us ProcessWire’s SelectMultiple, Checkboxes, or AsmSelect input types. Like the other Inputfield types, it’s not always going to be the right fit, and has it’s own unique set of benefits and drawbacks, but for the times where it suits the need, I hope you find it useful. Rather than writing more about it, I’ll link you to the module page for it. There’s more details and screenshots there. While you are in the modules directory, see the 3 other new modules posted this week too, they look great. Core updates coming next week. Thanks for reading and have a great weekend.

We’re moving along with trying to cover as many small issue fixes as possible for the next main/master version. So that’s what all the commits this week are for. There’s not much more to report than that, making good progress! If you spot any new issues on the dev branch be sure to report them in the processwire-issues repository. Thanks and have a great weekend!

Prepros (https://prepros.io/) works well for me for most things. It's (much) less customizable than gulp and similar tools, but makes life simple, and in practice I've rarely wanted it to do something it couldn't - though obviously YMMV. It can slow up when watching large numbers of files, and the FTP could be developed, but although it may not be quite as cool as gulp etc, it saves me a good amount of time!

https://processwire.com/blog/posts/upgrades-optimizations-pw-3.0.22/#major-enhancements-to-our-password-field