Robin S

Sounds good. In the meantime it's easy to do with a little custom CSS and JS. .InputfieldFileData { display:none; } .data-open + .InputfieldFileData { display:block; } $(document).on('click', '.InputfieldFileInfo', function() { $(this).toggleClass('data-open'); });

Hi @adrian, I updated an older site running PHP 7.1 to the latest Tracy Debugger and got this error: Maybe that line needs a check of which Tracy version is in use?

@ryan, the main branch is at 3.0.244 but the dev branch is still at 3.0.243. Does the dev version number need an update?

No, everything is good. A really useful set of features, thanks!

@adrian, thanks, the history is working for me now. I think this is caused by a combination of the button height being in fractional pixels and the scaleX(-1) transform on the right arrow. This causes Chrome to round the two arrow buttons to different numbers of whole pixels. There would be a several different ways to solve this, but perhaps the easiest thing would be to use the FontAwesome right arrow character for second arrow button rather than flipping a left arrow character. You'd also then tweak the margin and border on that button seeing as it would no longer be flipped. Leaving the coloured border on all sides and adjusting to margin-left: -12px looks good to me.

This is awesome, thanks! A few things I noticed when testing: 1. After updating from a previous TracyDebugger version, the console window is only 1 line high and there's an error in the browser console. Probably a browser cache issue because if I do a hard reload the issues are gone. 2. Is it expected that clicking on a snippet that's already open in the console will open another copy of the snippet? Perhaps instead it should focus the already open tab? 3. The "Go Back" arrow never seems to become activated after executions or changes to the code. It's always greyed out for me. 4. Very minor and I think it's not a new thing, but for some reason the right arrow button is 1 pixel higher than the left arrow button.

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; });

@ryan, is there an update on this? It would be good to have PW use the current version of TinyMCE because v6 is now past the official End Of Life.

@adrian, wonderful, thanks!

Hi @adrian, Is it possible for an action to return markup apart from the successMessage and failureMessage? I'd like to use MarkupAdminDataTable to show a table of results of the action. Putting the markup in successMessage sort of works, except it has the green background so I figure it's intended for a simple sentence rather than longer markup like this. If the module doesn't already have a solution for this that I've missed, what do you think about adding a new method similar to successMessage(), or maybe if the return value of executeAction() is a string rather than boolean the module could render that under the success/failure message? Thanks for considering.

To do this I think you'll have to hook the rendering of the repeater item, which is a fieldset: $wire->addHookBefore('InputfieldFieldset(name^=repeater_item)::render', function(HookEvent $event) { $inputfield = $event->object; $inputfield->label = $event->wire()->sanitizer->unentities($inputfield->label); });

@mel47, I didn't follow everything in your post, but Dynamic Options doesn't rename your images or create any variations. Looking at your code, you want to avoid doing this: Because $par is a Pageimages object and every Pageimages object is bound to a particular page (Page A), so when you add images to it from a different page (Page B) then the image files will be copied from from Page B's folder in /site/assets/files/ to Page A's folder, and I doubt that's what you intend. I suggest you rewrite your code so that you only add the image information to the $options array. Something like: $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { $page = $event->arguments(0); $field = $event->arguments(1); $pages = $event->wire()->pages; if($field->name === 'image_selection') { $options = []; foreach($pages(1065)->images as $image) { $options[$image->url] = "{$image->basename}<br>{$image->filesizeStr}"; } foreach($pages(1042)->content_blocks->find("repeater_matrix_type=2") as $p) { $image = $p->images->last(); if(!$image) continue; $options[$image->url] = "{$image->basename}<br>{$image->filesizeStr}"; } $event->return = $options; } });

@Macrura, yeah, that's not wanted so in v0.3.6 I've excluded the inputfield mods when the process is ProcessPageListerPro.

TinyMCE itself supports this via the style_formats setting, where you would define a "class" value rather than a "classes" value, e.g. style_formats: [ { title: 'Table row 1', selector: 'tr', class: 'tablerow1' } ] But PW's implementation of TinyMCE doesn't provide a way to directly control this setting and instead parses the contents of the "Custom style formats CSS" config textarea into the style_formats setting. Situations like this are why I think PW should provide a hookable method allowing the array of data that becomes the TinyMCE settings to be modified at runtime, as mentioned in this issue: https://github.com/processwire/processwire-issues/issues/1981

You might be experiencing this issue: https://github.com/processwire/processwire-issues/issues/1952 https://github.com/processwire/processwire-issues/issues/1974 To fix you can update to the latest PW dev version so as to get this commit, or change this line of .htaccess to: RewriteRule ^(.*)$ index.php?it=$1 [L,QSA,UnsafeAllow3F]