Leaderboard

Is there any smart way to get image variants (and create them if necessary) when using findRaw? We were thinking of using it to get array of several thousand products instead of using page array for performance reasons, but of course getting images becomes a problem. Is using a regular page array a better idea after all? We will need to turn it into an JSON format after so the page array isn't needed except to get the information out.

I am also wanting a solution for this, or at least get the path to to the image url. I want to use this data in a data grid to render the image. Normal pages->find operator is slow with many pages, so it is no fit for me. I also tried findJoin, but it also seem it does not work for images? We should open a request at processwire/processwire-requests: ProcessWire feature requests. (github.com). Are you doing it, @MSP01?

What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.

Hey @MarkE there is no RockFrontend.js file any more in the new version. Maybe just remove it from the scripts() array?

@Robin S this still makes an appearance on every install I have. Is there any way to extend the module so that it adds options for pages at top?

Preventing a page from being moved is not necessarily a straightforward matter of trapping the change in a save hook in the same way as a page edit. A problem occurs if the page is only to be 'blocked' conditionally - when the page path is in some given array, for example. In hooking before page save, the page path is the new page path after the move, rather than before it, so you need to do something like this: // .... In the before page:saveReady hook // $page is the page :) The code below operates when (isset($page->parentPrevious) && $object->parentPrevious != $object->parent) $name = $page->parentPrevious->path . $page->name . '/'; // need the path before it was moved if(in_array($name, $blockedNames)) { // $blockedNames are the ones where we don't want moves // Because this hook operates after the move, we need to reverse the move $page->parent = $page->parentPrevious; // Alternatively, to completely stop the save //$event->replace = true; //$event->return = false; } //... rest of hook This prevents the page being moved, both in the page hierarchy (by dragging) or in the page editor by changing the parent in the settings tab. It is also possible to hook before Page:moveable with something like this /** @var Page $page */ $page = $event->object; $moveable = $event->return; // ... code to set $moveable to false if conditions met $event->return = $moveable; Interestingly, the (not documented?) moveable method is created as a hook by PagePermissions and so is hookable. However, this method appears to catch only the situation where the move is effected by dragging the page in the tree, not when the parent is changed in the settings.

Just a quick update this week, as yesterday was a holiday here and it becomes kind of a holiday week with kids out of school. On the core dev branch, the built-in PageFrontEdit module has been updated to support the new InputfieldTinyMCE rich text editor module. In addition. The $sanitizer->email() method has been updated with several new options. These include support for emails with Internationalized Domain Names (IDNs), UTF-8 local parts and an option to validate the DNS of the email domain. Currently all of these options are off by default but can be enabled with a new $options argument. These options will likely be translated to configure options for email fields (FieldtypeEmail) in the next week or so. In addition, a new version of the ProFields Combo has been released and this version also adds support for the new InputfieldTinyMCE module. I'm also working on updates for ProFields Table and Textareas for support of InputfieldTinyMCE as well, but those updates aren't quite ready to post just yet. If you opt to use TinyMCE with PageFrontEdit or Combo, make sure you grab the latest version of InputfieldTinyMCE, as it also received related updates this week. Thanks for reading and have a great weekend!

You can use the User::changed hook to do what you want (see https://processwire.com/api/ref/wire/changed/). Put this in site/ready.php: $wire->addHookAfter('User::changed', function ($event) { if($event->arguments(0) === 'pass') { $user = $event->object; $this->wire->log->save('password-changes', "User $user->name has changed their password"); } }); Now everytime a user changes their password, it will be logged to Setup->logs->password-changes. You can do similar thing with roles if($event->arguments(0) === 'roles') { $user = $event->object; $oldRoles = $event->arguments(1); $newRoles = $event->arguments(2); // code to compare $oldRoles/$newRoles // write to log } If you want to have that information in the session log, just do $this->wire->log->save('session',...)

Wow nice work @BitPoet!

I'm really happy with InputfieldTinyMCE so far. And as threatened to in reply to an earlier core updates post, I took a stab at migrating my autocomplete module over from InputfieldCKEditor. All in all, it was quite a pleasant experience and the JS side was really straight forward. The change also involved a lot of refactoring, and in the aftermath of that there's still a good bit of house cleaning to do, but for anybody willing to toy around with it, there's an alpha release of InlineCompleteTinyMCE on GitHub. A snapshot of InlineCompleteTinyMCEActionUsers in action: And the corresponding configuration in the field's "Input" tab (added to the TinyMCE config section): I haven't tested it with lazy loading or the inline editor yet.

Quick heads-up: As of version 0.35.0 SearchEngine supports indexing file/image custom fields. In order to avoid surprises, I ended up adding these as separately selectable indexed fields. For an example: in order to have custom field "author_email" for image field "photo" indexed, you'll have to select "photo.author_email" from the "indexed fields" list in module config. There's a "file_field.*" setting available as well, in case you want to index all existing custom fields for a specific file field. Note that description and tags also need to be specifically selected. In earlier versions description text was always indexed, but now if you select the file field name and nothing more, only file name(s) (and content, if you have a suitable file indexing module installed and enabled) are indexed. -- In order to index file/image custom fields I had to refactor parts of the Indexer class. I hope I didn't break too many hooks, but there's a possibility that something goes wrong. Please test carefully, and let me know if you run into any issues!

To support my team I'm looking forward to find German support for Processwire projects. I would be happy to get in touch! Please DM me. Best regards Mats

Just as an addition to my post above. Maybe someone benefits from it... In a multilanguage environment the HTML5 validation prevents controll over the output on search input errors (example: when the search string is too short). It skips translated strings and always gets populated depending on the browser language settings. To disable the HTML5 validation, you must enhance the template render args for the form with the attribute novalidate. $config->SearchEngine = [ 'render_args' => [ 'templates' => [ 'form' => '<form id="{form_id}" class="{classes.form}" action="{form_action}" role="search" novalidate>%s</form>', ], ], ] With that, errors are displayed within the regular HTML Elements (which respects translated strings). I don't see any drawbacks so far. See also the comment from @teppo below!

Please ignore the awful zurb foundation markup - this was an ASAP conversion of a site from an unusable Drupal setup so I rebuilt using the old site's markup / css. At some point this will be redone as well, but at least it all works now ? You can see though that each button adds the type and then I use that like this: $findOptions['selector_extra'] = 'template=' . $type; You can ignore the hook on Renderer::renderResult at the top - it's just for adding the thumbnails to the results.