Robin S

I've never seen a file at that path before. My sites don't even have a "/wire/config/" directory.

I was just trying to think if there was a way to achieve what I wanted without changes to the module. I saw that the module was adding the import/export features according to a permission so thought I might be able to grant that permission selectively at runtime. But I later realised that the permission is checked at the ready state rather than before the InputfieldTable render so even if my idea was possible I'd have to set the permission at every page load which would be a bit over the top. I think that a couple of extra checkboxes on each Table field config would be ideal - something like "Allow CSV export" and "Allow CSV import", although it would still depend on the user having the relevant permissions so there should probably be a note about that. Existing users of the module would expect to have these options checked on all existing fields and I guess you could deal with that in the module upgrade() method. Thanks!

Hi @adrian, My first time using this module - looks amazing, thanks! (silly me, I've used the awesome import features before) In my site I have a number of Table fields that are used for various purposes, but just one Table field that I want to allow users to export to CSV from. I couldn't see a way to show the export interface just on this one field. Any tips on how I could achieve this? Or would you consider adding a hookable method that would determine if the import/export interface gets added to each Table field? (the relevant permissions would still apply) Thanks. Edit: very minor thing... in AdminThemeUikit there is an outline around the inputfield that has the export iframe and this looks a bit weird. Not sure if there is a better way but I hid it with some custom CSS: .Inputfield_tableExportIframe { outline:none; }

Do these inputfields have a column width set so that they all appear in the same row? If so then I think it is recent core behaviour that collapsing one inputfield in a row collapses all the fields in the row. This didn't use to happen but it did make for some weird gaps and outline anomalies when a single inputfield in a row was collapsed, so the new behaviour is probably better. So if you have an inputfield that will usually be collapsed I think the best thing is to put it on a separate row within the fieldset.

@PascalKonings, the suggestion from @Zeka is probably the way to go, but in case you do want to stick with image tags you can set them dynamically in a hook in /site/ready.php: // Dynamically set the selectable tags for an images field $wire->addHookAfter('InputfieldImage::renderReadyHook', function(HookEvent $event) { /** @var InputfieldImage $inputfield */ $inputfield = $event->object; // The images field $field = $inputfield->hasField; // The page that the field is on $page = $inputfield->hasPage; // Only for a specific images field if(!$field || $field->name !== 'your_image_field') return; $config = $event->wire()->config; $js_name = "InputfieldFileTags_$field->name"; $data = $config->js($js_name); // Set the tags however you like, using $page if needed $data['tags'] = [ 'carrot', 'pumpkin', 'cauliflower', ]; $config->js($js_name, $data); });

I believe so, but the simplest thing would be to try it and see.

The Limit Table module (previously not in the modules directory but I just added it) adds this feature to Profields Table.

Thanks for the suggestion. I'll keep it in mind but for now will leave the interface as it is for a couple of reasons: The intention with this module is just to create a temporary mode to activate when doing a drag sort, and leaving the repeater interface as per the core default at other times. At this point I don't want to get into making broader changes to the repeater interface: hacking controls into the inputfield header (the core doesn't make this easy to do), setting a default view mode, storing the view mode in a cookie, etc, like what is done with image fields. I'm predicting that users will first identify the item they want to drag with the repeater field in its normal mode. When easy-sort mode is activated the repeater items move quite a bit from their original position, and it's a feature of this module that the item you want to drag gets identified with a black background so it's easier to locate. This requires a button per repeater item rather than a single button per repeater field. Fixed in v0.1.1. Although personally speaking I gotta say... I wish @ryan would drop those ancient legacy themes from the core because it's a real hassle for module developers to support multiple themes. The Uikit theme has been the default standard for several years at this point and it's the only theme that's likely to get attention and further development going forward, so PW users should get on board with it. I only test my modules in AdminThemeUikit but will consider compatibility fixes for legacy themes on a case-by-case basis.

Repeater Easy Sort Adds a compact "easy-sort" mode to Repeater and Repeater Matrix, making those fields easier to sort when there are a large number of items. The module also enhances Repeater Matrix by allowing a colour to be set for each matrix type. This colour is used in the item headers and in the "add new" links, to help visually distinguish different matrix types in the inputfield. Screencasts A Repeater field A Repeater Matrix field with custom header colours Easy-sort mode There are two ways to enter easy-sort mode. 1. Click the double-arrow in a Repeater item header. This activates easy-sort mode and also highlights the item with a black background so it's easier to find it in easy-sort mode. 2. Click the horizontal ellipsis icon in the Repeater field header to activate easy-sort mode. To return to normal mode click the vertical ellipsis icon. While in easy-sort mode: The items will reduce in width so that more items can be shown on the screen at once. The minimum width is configurable in the field settings. Any items that were in an open state are collapsed, but when you exit easy-sort mode the previously open items will be reopened. You can drag an item left/right/up/down to sort it within the items. You can click an item header to open the item. An "Exit easy-sort mode" button appears at the bottom of the inputfield. Configuration In the field settings for Repeater and Repeater Matrix fields you can define a minimum width in pixels for items in easy-sort mode. While in easy-sort mode the items will be sized to neatly fill the available width on any screen size but will never be narrower than the width you set here. If desired you can enable easy-sort mode for a field by default. Since easy-sort is then the default mode for the field no "Exit easy-sort mode" button is shown. Use the mode buttons in the field header to change between easy-sort and normal mode when needed. In the field settings for Repeater Matrix you can define a custom header colour for each matrix type using an HTML "color" type input. The default colour for this type of input is black, so when black is selected in the input it means that no custom colour will be applied to the header. Exclusions The easy-sort mode is only possible on Repeater/Matrix fields that do not use the "item depth" option. https://github.com/Toutouwai/RepeaterEasySort https://processwire.com/modules/repeater-easy-sort/

Adapting a post Ryan made in the Repeater Matrix support forum: In /site/templates/admin.php, before the line... require($config->paths->core . "admin.php"); ...add the following... if($page->process == 'ProcessPageEditImageSelect') { // The page ID that is open in Page Edit $edited_page_id = (int) $input->get->edit_page_id; // The page ID that contains the CKEditor field // This is where PW will look for images by default $cke_page_id = (int) $input->get->id; // If the edited page is not the same as the CKEditor page if($edited_page_id && $cke_page_id && $edited_page_id != $cke_page_id) { // Get the CKEditor page $cke_page = $pages->get($cke_page_id); // If the CKEditor page is a particular Repeater field page // Substitute the name of your Repeater template if($cke_page->template == 'repeater_your_repeater_template') { // Set the page ID where you want PW to look for images $input->get->id = $edited_page_id; } } }

@Morphosis, welcome to the PW forums! ? It's unlikely that this is related to browser differences. What's more likely is that you are logged in to the PW backend in Chrome (probably as superuser) but in Safari you are not logged in, or logged in as a less privileged user. So the area to focus on is fields or templates that have access restrictions. If I understand right you have created a Page Reference select field (selectfromrepeater) and set the selectable pages to be items in a repeater field. The template used by a repeater field (named in the format "repeater_[field_name]") is not accessible by non-superusers. The idea is that users should not have direct access to repeater pages but instead must access them via the repeater field value. So if you are defining selectable pages for the selectfromrepeater field using a selector string like this... template=repeater_yourfieldname ...then this will cause problems when a non-superuser works with the field. The "official" way to get repeater pages is via the repeater field value, so you would use the "Custom PHP code" option for defining selectable pages: $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'selectfromrepeater') { // Get the page that contains the repeater field however suits $page_with_repeater_field = $event->pages->get(1234); // The event return is the repeater field value $event->return = $page_with_repeater_field->repeater_field_name; } }); Technically you could stick with the selector string option and explicitly disable the access control when getting the repeater pages... template=repeater_yourfieldname, check_access=0 ...but in doing that you would be going against the way the core wants you to work with repeater pages, so perhaps better not to do that unless you're 100% clear on all details of how repeater fields work. When debugging issues like this, the Tracy Debugger module is a huge help. The bd() method is all you need to learn to start with.

I think this relates to a problem at the video/Vimeo end rather than a problem with the textformatter module. The post below suggests that the stripes thumbnail is what appears when Vimeo fails to successfully generate a thumbnail for a video: http://support.syngency.com/en/articles/3048197-set-a-new-thumbnail-for-your-video

If you are adding inputfields to a InputfieldForm object (as it looks like you are according the code you posted) then it will work. Yeah, my suggestion is that you don't do that and you instead take advantage of all the useful stuff PW provides for you in the InputfieldForm::processInput() method. This method calls the various processInput() methods of all the inputfields that you have in your form. That does a lot of the input validation work for you and has useful features like inputfield-specific error messages, required fields, required-if logic, etc.

Have you studied this thread? You can use the PW API to process your form submission and then you won't need to do any hacks like that for checkbox fields. The "truthiness" of the checkbox field value once the form has been processed will tell you if it was checked or not. Example: /** @var InputfieldForm $form */ $form = $modules->get('InputfieldForm'); /** @var InputfieldText $f */ $f = $modules->get('InputfieldText'); $f->name = 'greeting'; $f->label = 'Greeting'; $form->add($f); /** @var InputfieldCheckbox $f */ $f = $modules->get('InputfieldCheckbox'); $f->name = 'new_zealander'; $f->label = 'I am a New Zealander'; $f->skipLabel = Inputfield::skipLabelMarkup; $form->add($f); /** @var InputfieldSubmit $f */ $f = $modules->get('InputfieldSubmit'); $form->add($f); if($input->post('submit')) { $form->processInput($input->post); $greeting = $form->getChildByName('greeting')->value; $new_zealander = $form->getChildByName('new_zealander')->value ? 'checked' : 'not checked'; bd("The greeting was '$greeting' and the 'I am a New Zealander' checkbox was $new_zealander"); } echo $form->render();

$field = $modules->get("InputfieldHidden"); $field->attr('name','Name'); $field->skipLabel = Inputfield::skipLabelMarkup; $form->append($field); https://processwire.com/api/ref/inputfield/#pwapi-methods-skipLabel-constants

Well it's not intended for use with Combo but rather with FieldtypeDynamicOptions. But I tested and if you enter paths/URLs to already uploaded Pageimage files as the values of the selectable options then it does work. But I can't see why that would be a better thing to do than using a FieldtypeDynamicOptions field where you can define the selectable options dynamically.

No, but there needed to be some limit set and I can't personally imagine needing more than three custom menus. If anyone using the module finds they need more then I'd consider increasing the limit. Not actual navJSON ajax-loaded menus because those require a Process module. But in the latest version I've allowed for the possibility to define multiple levels of submenus using a hook. See the updated readme. In the hook you can check if the user has or lacks a role and return different child item data accordingly. And in the latest version if you return false from the hook then the menu is not shown at all. See the updated readme. Should be fixed in the latest version.

Here's the module:

This module lets you add some custom menu items to the main admin menu, and you can set the dropdown links dynamically in a hook if needed. Sidenote: the module config uses some repeatable/sortable rows for the child link settings, similar to the ProFields Table interface. The data gets saved as JSON in a hidden textarea field. Might be interesting to other module developers? Custom Admin Menus Adds up to three custom menu items with optional dropdowns to the main admin menu. The menu items can link to admin pages, front-end pages, or pages on external websites. The links can be set to open in a new browser tab, and child links in the dropdown can be given an icon. Requires ProcessWire v3.0.178 or newer and AdminThemeUikit. Screenshots Example of menu items Module config for the menus Link list shown when parent menu item is not given a URL Advanced Setting child menu items dynamically If needed you can set the child menu items dynamically using a hook. Example: $wire->addHookAfter('CustomAdminMenus::getMenuChildren', function(HookEvent $event) { // The menu number is the first argument $menu_number = $event->arguments(0); if($menu_number === 1) { $colours = $event->wire()->pages->findRaw('template=colour', ['title', 'url', 'page_icon']); $children = []; foreach($colours as $colour) { // Each child item should be an array with the following keys $children[] = [ 'icon' => $colour['page_icon'], 'label' => $colour['title'], 'url' => $colour['url'], 'newtab' => false, ]; } $event->return = $children; } }); Create multiple levels of flyout menus It's also possible to create multiple levels of flyout submenus using a hook. For each level a submenu can be defined in a "children" item. Example: $wire->addHookAfter('CustomAdminMenus::getMenuChildren', function(HookEvent $event) { // The menu number is the first argument $menu_number = $event->arguments(0); if($menu_number === 1) { $children = [ [ 'icon' => 'adjust', 'label' => 'One', 'url' => '/one/', 'newtab' => false, ], [ 'icon' => 'anchor', 'label' => 'Two', 'url' => '/two/', 'newtab' => false, 'children' => [ [ 'icon' => 'child', 'label' => 'Red', 'url' => '/red/', 'newtab' => false, ], [ 'icon' => 'bullhorn', 'label' => 'Green', 'url' => '/green/', 'newtab' => false, 'children' => [ [ 'icon' => 'wifi', 'label' => 'Small', 'url' => '/small/', 'newtab' => true, ], [ 'icon' => 'codepen', 'label' => 'Medium', 'url' => '/medium/', 'newtab' => false, ], [ 'icon' => 'cogs', 'label' => 'Large', 'url' => '/large/', 'newtab' => false, ], ] ], [ 'icon' => 'futbol-o', 'label' => 'Blue', 'url' => '/blue/', 'newtab' => true, ], ] ], [ 'icon' => 'hand-o-left', 'label' => 'Three', 'url' => '/three/', 'newtab' => false, ], ]; $event->return = $children; } }); Showing/hiding menus according to user role You can determine which menu items can be seen by a role by checking the user's role in the hook. For example, if a user has or lacks a role you could include different child menu items in the hook return value. Or if you want to conditionally hide a custom menu altogether you can set the return value to false. Example: $wire->addHookAfter('CustomAdminMenus::getMenuChildren', function(HookEvent $event) { // The menu number is the first argument $menu_number = $event->arguments(0); $user = $event->wire()->user; // For custom menu number 1... if($menu_number === 1) { // ...if user does not have some particular role... if(!$user->hasRole('foo')) { // ...do not show the menu $event->return = false; } } }); https://github.com/Toutouwai/CustomAdminMenus https://processwire.com/modules/custom-admin-menus/

I've found something similar in a few cases. Doing a Modules > Refresh is supposed to both clear the module info cache and the admin menu cache (AdminThemeUikit hooks Modules::refresh) but sometimes it doesn't work and you have to either logout/login or (easier) use the Tracy Debugger "Clear Session & Cookies" link in the "ProcessWire Info" panel. The whole cached admin menu thing seems a bit pointless to me, so if you want to effectively disable that you can put the following in /site/ready.php // Prevent admin menu from being cached $wire->addHookBefore('ProcessController::execute', function(HookEvent $event) { $event->wire()->session->removeFor('AdminThemeUikit', 'prnav'); }); But you'll still need to do a Modules > Refresh if you make changes to the "nav" item in a Process module's getModuleInfo method. Have a look at ProcessModule and I think you'll be able to work it out. Within getModuleInfo see "useNavJSON" and the "navJSON" items within the "nav" array, and the executeNavJSON method. You probably can't. Probably best to make a corresponding executeSomething() method in your Process module that simply lists the child links. Yeah, unfortunately you can't because AdminThemeFramework forces the Process page URL before the link for items in the "nav" array. It seems this array is really only intended to be used for executeSomething() methods within the Process module and not for general purpose links. Recently I've been playing around with an alternative approach to custom admin menus which involves hooking AdminThemeFramework::getPrimaryNavArray (only possible in PW 3.0.178 or newer). If you use Tracy to dump the event return you can work out how the menus can be manipulated. And I've put together a module that lets you add custom admin menus without writing code - will release soon.

Yes, the original module which is a completely separate thing to LoginRegisterPro. There is no support thread so people create lots of separate forum threads for questions. And also there are quite a lot of GitHub issues and it's not clear what support or future there is for LoginRegister, and people need to know that before they start using it.

Wow, a triple-whammy of modules, thanks @ryan! I noticed that two of these new modules don't have support threads in the forum and the Support button in the modules directory listing isn't functional. That situation also applies to your Login Register module which I believe used to have an entry in the modules directory but no longer does. (Edit: after doing a quick scan through your modules in the directory it looks like the majority don't have support threads in the Modules/Plugins subforum) It's inevitable that users of these modules will have questions/issues that they will want to raise here in the forums, so it would be good if every module that's shared with the community has a dedicated thread in the forums. Otherwise people open multiple new topics so it's harder for users to look through the history of discussion about a module. If the reason some of your modules don't have support threads is that you're not able to spend time responding to support requests (which is totally legitimate IMO) then the opening post could explain the support status of the module, maybe something along the lines of "this module has been shared with the community but the author is generally not available to provide ongoing support". Then people can still post questions or issues with the understanding that they are not guaranteed to get support from the module author but that other members of the PW community may offer advice.

Thanks. I assume you mean if you accidentally add a description because the point of this module is that it hides the fieldset that surrounds the fields so you wouldn't expect to be able to see any description. In v0.1.7 the module explicitly hides any description and notes for the fieldset so if these are accidentally present they won't disrupt the intended layout.

Pages will only appear in the dropdown menu if those pages have a Process assigned. See here. In effect this usually means "pages that use the admin template". You could possibly create a custom Process module that you use to redirect to other pages in the module's execute() method. Then create new pages using the admin template and select your Process. See here for an easy way to set the menu icon of admin pages. But also consider using the "nav" item in the getModuleInfo() method of a custom Process module. This lets you define some dropdown menu items for the Process when the page is in the top menu. ProcessModule is an example. Unfortunately you cannot set the first level of dropdown items dynamically. https://github.com/processwire/processwire-requests/issues/189 The top menu is cached (unnecessary in my opinion) so if you are making changes and not seeing them reflected in the menu then do a Modules > Refresh (and Tracy has a handy shortcut). Add "#ProcessPageEditChildren" to the URL. /your-admin-page/page/edit/?id=1234#ProcessPageEditChildren

What is the showif condition you are using for the Page Reference field? If the visibility depends on the value of the Roles field make sure you are matching by role ID, e.g. roles=1234|1235