Leaderboard

@horst is right. Here's a demo:

maybe this can help you out: https://processwire.com/api/ref/wire-array/sort-flags/ (but haven't tested anything myself)

Not sure if I got this right, but when you say that the images are "in a custom folder directly from ERP", do you mean that this custom folder is at the local disk, not some external server/service/whatever? If that's the case, you can resize them with ImageSizer, but it requires going through some extra hoops. You may find this thread useful — it's about generating resized versions of Pagefiles, but the concept here is similar, with the difference that the path to file is not in a Pagefile object but rather your text field. That being said, it would be much easier if you would just store those images in an image field on one of your pages. The process would be more straightforward, you wouldn't need to worry about cleaning up old variations, and so on. I guess the TL;DR here is that if you have a good reason for not handling those images as regular ProcessWire images, then yes, technically it's possible to do what you've asked here with ImageSizer, but a) this is rarely the best approach, and b) even then you may find working with Imagick or something similar directly a tad easier ?

The last 5 projects all needed some kind of API endpoint. Over time, I've settled for a custom "api" page under home. In two projects, this is a very simple piece of code with a switch statement, in others it looks for individual templates under templates/api. I'm not completely happy with any of them, though, and I've often wished for something akin to hooks with enough boilerplate to avoid repetitive code. I do concur that Laravel has some very nice and expressive features. I could picture a WireApi singleton class with which modules could register, and a fixed "api" page that is by default not much more than <?php namespace ProcessWire; wire('api')->handleRequest(); WireApi may or may not route to matching PHP files under templates/api by default. Autload modules could register their routes in their init() method. Just a rough example with one or two Laravel niceties stirred into the usual PW awesomeness to get a nice declarative approach to api route definitions: <?php namespace ProcessWire; class ApiExampleHandler extends ApiRoute { public static function getModuleInfo() { return [...]; } public function init() { parent::init(); # hand GET requests to /api/users/USERID/profiledata off to our getUsrProfileData method # and pass the value in place of USERID as the first parameter $user to the method. # Use $sanitizer->intUnsigned on $user to make sure it is a valid page id. $this->api->get('/users/{user}/profiledata', $this, 'getUserProfileData')->whereSanitized('user', 'intUnsigned'); } public function getUserProfileData($user) { $u = $this->users->get($user) ?: $this->api->notFound(); $p = $u->profilepage ?: $this->api->notFound(); # Set Content-Type header, set json_encode return value and output it $this->api->jsonResponse([ 'nickname' => $p->nick, 'hobbies' => $p->hobbies, 'membersince' => $p->joindate ]); } } Something along those lines could go a long way to making endpoint implementation easier. I don't know how often I've checked for isAjax et al, called json_decode and json_encode, checked the request method, sanitized and compared urlSegement1 and urlSegment2 and urlSegment3 (and sometimes even urlSegement4) in nested conditionals... For quick and dirty solutions, api route registration could go into api.php before handleRequest() is called, or even into site/ready.php. With a bit of creative magic, a nice PWish equivalent to Laravel's model binding should also be in the realm of possible things.

No changes here. There's only so much that can be joined in one query per field, so autojoin is not always possible, especially on multi-value (FieldtypeMulti) fields with lots of values. It should be possible on most Page reference and options fields though, so long as they don't have huge amounts of selections. If there's need for it though, I may be able to have fields (where applicable) store a cache of data (like FieldtypeCombo does) that can be autojoined. I recall that in the past auto joining multi-value page fields would fail quietly and simply result in bad data being returned (like a single page instead of all pages). Can this be changed so that it throws an exception (or at least skips trying to auto join it) if you try to auto join a field that can't be auto joined? That would help avoid nasty issues for programmers who aren't familiar with the internal workings here.

Moderator note: this is not a module support thread, so I'm moving it to the General Support area of the forum instead. Please keep in mind that the Modules/Plugins area is only intended for module-specific support threads. Thanks!

Really no problem at all. I've released a newer version since then that addresses an issue that I didn't see come up in testing previously. Just a courtesy tag in case the bugfixes end up helping someone. I haven't heard of Lingvanex before so I didn't know to look into them. Initially when I found DeepL I was really impressed by the service but needed someone else to really verify what was going on because I only speak English. I had a coworker who speaks Spanish look at the results and he was very impressed. I kind of stopped there and didn't think to look further. Overall if someone was able to verify the quality of translation of any translation then that's all that matters. I don't have any personal allegiance to DeepL, it's just what I found and what I heard about on the PW forums which also nudged me towards them. It would be interesting in the future to update Fluency to allow the dev to select a translation engine, and the way the module is built I think it could be done well. I wish I could work on that now but I just had 3 clients contact me for work and that's in addition to my day job...

Thanks Elabx, I tried this but still having the same issue. " SQLSTATE[HY000]: General error: 1364 Field 'tag' doesn't have a default value"

This just happened to me a few days ago when I disabled the tags on the image field (I think there is a Use Tags? checkbox). Adding it back fixed although I haven't had time to figure out what's going on.

Here is a new created version to track changes which works without any problems and you dont have to take care about the deletion of input values if the page was not saved successfully (like in the version before) Put this little piece of code inside your ready.php. //Compare before and after values and output a warning message $pages->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments('page'); $page->of(false); //configuration: change it to your needs $templates = ['event_businessvacations', 'event_dates', 'event_events', 'event_specialbusinesshours']; //array of templates where this hook should run $fields = ['summary', 'body']; //array of fields which should be checked //configuration end if(in_array($page->template->name, $templates)){ $changedfields = []; foreach($fields as $fieldname){ if ($page->isChanged($fieldname)) { // Page as it is in the DB $oldPage = wire('pages')->getById($page->id, array( 'cache' => false, // don't let it write to cache 'getFromCache' => false, // don't let it read from cache 'getOne' => true, // return a Page instead of a PageArray )); $changedfields[] = $oldPage->fields->$fieldname->label; } } $changedfields = implode(", ", $changedfields); if(!empty($changedfields)){ $this->warning(__("The following fields have been changed: {$changedfields}")); } } }); Change the configuration block to your needs (template names, field names). This little code snippet outputs only a warning message which fields have been changed - not more or less, but you can also run some other logics - its up to you. Note: Works also with repeaterfields, but you can only check the repeaterfields for changes in general. It is not possible to check for specific fields inside the repeater.