Macrura

right, sorry, my example was pulling from a 'media' template where you have these different media types, like image, video, audio. So you wouldn't need that in your application.

i'm not a fan of the fa-industry icon, any other ideas for icons? wrench is kind of over used... might just keep the train icon, even if the name changes to Settings Factory, but still Settings Train is more catchy...

OK, php defined settings are working: 1) process page config: 2) contents of example.php <?php namespace ProcessWire; $fieldOptions = array(); foreach(wire('fields') as $field) { if ($field->flags & Field::flagSystem || $field->flags & Field::flagPermanent) continue; if(count($field->getFieldgroups()) === 0) $fieldOptions[$field->id] = $field->label ? $field->label . ' (' . $field->name . ')' : $field->name; } return [ 'colors' => [ 'name' => 'radiostest2', 'type' => 'radios', 'label' => $this->_('Color Set'), 'options' => [ 'classic' => $this->_('Classic'), 'warm' => $this->_('Warm'), 'modern' => $this->_('Modern'), 'futura' => $this->_('Futura') ], 'value' => 'classic', 'optionColumns' => 1 ], [ 'name' => 'fields', 'label' => 'Fields', 'description' => 'Select the fields you want to delete', 'notes' => 'Note that all fields listed are not used by any templates and should therefore be safe to delete', 'type' => 'checkboxes', 'options' => $fieldOptions, 'required' => true ] ]; 3) result:

should be really easy, you'd just need create a php file that returns an array of inputfields; DO you think i should try and integrate that array-config, or just allow the php file to return an array, like in Adrian's example? right now i just feed the array converted from json right into the form; the values are almost all automatically read from the module config except for checkbox that takes some special handling.. // ------------------------------------------------------------------------ // USER DEFINED FIELDS // ------------------------------------------------------------------------ if(wire('page')->st_filepath) { $path = wire('config')->paths->templates . wire('page')->st_filepath; $settingsKey = $this->wire('page')->name; $modData = $this->modules->getConfig('SettingsTrain'); $thisData = isset($modData[$settingsKey]) ? $modData[$settingsKey] : null; if(file_exists($path)) { $json = file_get_contents($path); $fArray = json_decode($json, true); // update values foreach($fArray as $key => $cField) { $name = $cField['name']; $cField['value'] = $thisData ? $thisData[$name] : ''; // or get default value in json file? if($cField['type'] == 'InputfieldCheckbox' && $cField['value'] == 1) { $cField['checked'] = 'checked'; } $fArray[$key] = $cField; } $form->add($fArray); } } i started building it on Thursday night, and have probably like 7 hrs on it, mostly figuring out the logic of the process pages each saving their unique data to the main module that extends wiredata... this also might need someone else to have a look at; i do have it working fine, but there could most likely be some places where the code could be tightened up. yeah, i was wondering how that was going to work with this; for some people they may want to use the json system, but it should also support php; So in your example if the file ending is php, then the process module would do this: $fArray = wireRenderFile($path); instead of this: $json = file_get_contents($path); $fArray = json_decode($json, true); ok possibly, yeah i couldn't come up with anything and needed to start building it with some name... the FA train icon does look cool though! How about a vote on what to call it?... Settings Factory could be a good option... I do understand that this is a downside of using a process module for this; so usually i setup a media type page with 1 image and then i let the users upload the images to their media library; then i let them choose the page (image) from this module, somethings using Selectize, or just a plain page select.. not ideal; once i have the code on github, anyone is certainly welcome to insert some code into the logic somewhere to allow images to work, would be cool..

MODULE PREVIEW This is a new module I'm working on, Settings Train. Ever needed to setup one or more pages for site settings, need a lot of fields/settings and an easy way to access them in the front end. This module may be of use to you. You can of course either make an editor page using standard fields for settings, but the goal of this module is to allow files within the template folder to define their own 'dependencies' for settings. Description: this module allows you to create an unlimited number of admin/process pages, and on any process page you can enter the path to a json file that defines the fields to use for the process page. 1.) Contents of kitchen-sink.json [ { "name":"text1", "label":"Text Field 1", "type":"InputfieldText", "width":"100", "description":"", "collapsed":0, "placeholder":"", "value":"", "columnWidth":50 }, { "name":"text2", "label":"Text Field 2", "type":"InputfieldText", "width":"100", "description":"", "collapsed":2, "placeholder":"", "value":"", "columnWidth":50 }, { "name":"select1", "label":"Select Test", "type":"InputfieldSelect", "width":"100", "description":"Description of select 1", "options": { "default":"Default", "blue":"Blue", "red":"Red", "yellow":"Yellow", "dark":"Dark" }, "collapsed":0, "placeholder":"", "value":"", "columnWidth":33 }, { "name":"checkbox1", "label":"Checkbox Test", "type":"InputfieldCheckbox", "width":"50", "description":"Checkbox 1 description", "collapsed":0, "placeholder":"", "value":1, "columnWidth":34 }, { "name":"radios1", "label":"Radios Test", "type":"InputfieldRadios", "width":"50", "description":"", "options":{ "black":"Black", "white":"White" }, "collapsed":0, "placeholder":"", "value":"black", "columnWidth":33 }, { "name":"checkboxes1", "label":"Checkboxes Test 1", "type":"InputfieldCheckboxes", "width":"50", "description":"Checkboxes 1 Description", "options":{ "address":"Address", "phone":"Phone", "social":"Social Icons", "top_menu":"Top Menu" }, "collapsed":0, "placeholder":"", "value":"", "columnWidth":50 }, { "name":"checboxes2", "label":"Checkboxes Test 1", "type":"InputfieldCheckboxes", "width":"50", "description":"Checkboxes 2 Description", "options":{ "address":"Address", "phone":"Phone", "social":"Social Icons", "top_menu":"Top Menu" }, "collapsed":0, "placeholder":"", "value":"", "columnWidth":50 }, { "name":"textarea1", "label":"Textarea Test", "type":"InputfieldTextarea", "width":"100", "description":"Textarea 1 Description", "collapsed":2, "value":"" }, { "name":"pagelistselect1", "label":"Page List Select Test", "type":"InputfieldPageListSelect", "width":"100", "description":"Page List Select Test Description", "collapsed":0, "value":"0", "columnWidth":50 }, { "name":"asm_select1", "label":"ASM Select Test", "type":"InputfieldAsmSelect", "width":"100", "description":"ASM Select (templates) - select a template.", "options":{ "43":"Image", "59":"Options", "61":"Post (post)", "62":"Post Index (post-index)" }, "collapsed":0, "value":"", "columnWidth":50 }, { "name":"url_test", "label":"URL Test", "type":"InputfieldURL", "width":"100", "description":"Enter a URL", "noRelative":1, "collapsed":0, "value":"", "columnWidth":33 }, { "name":"integer_test", "label":"Integer Test", "type":"InputfieldInteger", "width":"100", "description":"Enter an Integer", "collapsed":0, "value":"", "columnWidth":34 }, { "name":"email_test", "label":"Email Test", "type":"InputfieldEmail", "width":"100", "description":"Enter an Email Address", "collapsed":0, "value":"", "columnWidth":33 }, { "name":"ckeditor_test", "label":"CK Editor Test", "type":"InputfieldCKEditor", "width":"100", "description":"Some Formatted Text", "collapsed":0, "value":"" } ] The json file can be anywhere (currently limited to the templates folder). For example, if you have a theme folder and that theme requires specific preferences to be set for that theme, you can have the settings page load the fields needed by that theme. Process Page in Menu: Process Page (editing the settings): Then you can access those settings in your front end like this: $train = $modules->get("SettingsTrain"); $themeSettings = $train->getSettings('news-settings'); the settings are delivered as a WireArray: so you can now do this: echo $newSettings->url_test; which outputs http://processwire.com For rapid site development, this can save you from having to manually setup fields for new projects settings, especially if you use those same settings a lot.

modules > core ... install

you’ll have to use the language api to get the value you want to show there; You may also be able to try $page->region->getFormatted('title') but the language api should give you what you need to get that value/data if formatted doesn't work..., e.g. $dutch = $languages->get('dutch'); // get the language we want $body = $page->title->getLanguageValue($dutch);

maybe try $page->of(false); at the top of the code

correct, when you get the array of data to supply to each option, that is being used when the module iterates through the selectable pages and is then used to generate the json attribute that gets added to the select option itself, in the data-data attribute. Selectize.js natively reads that data-data attribute to get the object that it can then parse into the item and option markup that it renders... item always refers to the actual option

here are the settings for the image above: 1) Array of Data $image = ''; if(count($page->images)) $image = $page->images->first(); $thumb = ''; $dims = ''; if($image !='') { $thumb = $image->size(100,100)->url; $dims = $image->width . 'x' . $image->height; } $data = array( 'title' => $page->title, 'type' => $page->media_type->title, 'thumb' => $thumb, 'img_dims' => $dims, 'edit_src' => $page->editUrl ); return $data; 2) Render Item Markup '<div class="item" style="width:100%;">' + (item.thumb ? '<div class="image-wrapper" style="float:left;"><img src="' + escape(item.thumb) + '" alt=""></div>' : '') + '<div class="info-wrapper" style="float:left; padding:5px;">' + '<span style="font-size:14px;font-weight:bold">' + escape(item.title) + '</span><br>' + '<span>Type: ' + escape(item.type) + '</span><br>' + (item.img_dims ? '<span>Dims: ' + escape(item.img_dims) + 'px</span><br>' : '') + '<a class="pw-modal pw-modal-medium" href="' + escape(item.edit_src) + '">Edit <span class="ui-icon ui-icon-extlink"></span></a></div>' + '</div>' 3) Render Option markup '<div class="item" style="width:100%;">' + (item.thumb ? '<div class="image-wrapper" style="float:left;"><img src="' + escape(item.thumb) + '" alt=""></div>' : '') + '<div class="info-wrapper" style="float:left; padding:5px;">' + '<span style="font-size:14px;font-weight:bold">' + escape(item.title) + '</span><br>' + '<span>Type: ' + escape(item.type) + '</span><br></div>' + '</div>'

yup, doing it all the time.. one of the main use cases for this... lotta examples earlier in this thread of images being used, here is a slider section where you select the slides to be shown:

i haven't looked at the functional fields yet... Here is my version of PGS: https://github.com/outflux3/ProcessGeneralSettings

it might really need to be released as a whole new module as it is massively changed; for example, my version has 2 modules, one process module for setting up the fields and one that actually handles the object for providing the settings to the front end; has to be done like this if you want to give access to that settings panel to any other role besides superuser; Also, i think i tried to ask some questions to the original module author but they seem to be no longer around (mostly in reference to the major conflict the original module has with the $settings global variable which is also used by ListerPro).. The way i handle images is to have a page tree select where you select the page holding the image; this works well for me because most sites i'm building have some type of media library, so this allows users to select media pages containing stuff like logos, open graph fallback images, schema profile images etc;

I'm using a highly modded version of ProcessGeneralSettings; got it working with most fieldtypes, so i can setup settings dashboard now and have fields for most things i need on the frontend, social media urls, metas, company info as well as visual settings; it all stores as module config, so i can have a lot of fields (50-60) without having to add those fields to PW...

maybe leave as is? Me and my superusers only need edit...no bookmark

right - cool, so for superusers leave the left = bookmark, right edit icon = edit, but for non-super users, clicking it just goes to edit?

I'd like to make some suggestions about this module, after having used it/installed it and setup on a lot of sites recently: 1) I believe that the module should default to everything off. Many of the changes that this module makes to the admin are potentially breaking, or may totally confuse non tech-savvy clients. I would rather be able to install this, and enable 1 feature at a time and then test each enabled feature. 2) In terms of defaults, i believe the CK editor skin should default to 'default' not to lightwire; because since default is the default, why not let users decide if they want to change to lightwire, instead of assuming they want it. Also, i wouldn't include any plugins by default, especially not justify - one a site i just installed AOS on, it was showing 3 entire sets of text alignment icons in the editor; by removing that plugin, this has reverted to normal behavior. 3) with nav items, that is certainly an awesome feature, and allows you to make a lot of cool shortcuts in the sidebar, also having the option to group some into their own submenu is cool - would be even better if the submenu could be above pages so that you could put your custom shortcuts into it's own top level menu, like "Site" or "Company"; I'm not fully understanding why the menu items have 2 areas, one that links to a bookmark and one that links to the editor; it is very clever that by selecting a page, it knows you mean edit the page (not view); my clients are so technically handicapped that even having 2 areas of a menu item will probably cause a meltdown. Ideally clicking on the item would just take them to the edit page, or maybe there can be some setting for this in case other users like that dual menu item functionality... thanks for considering!

ok, maybe not - i actually just realized that i need admins to be able to browse and delete the caches so may have spoke too soon.. yes, i do routinely output the cache vars as you demonstrate...

i vote for the clear cache admin to be in TD; I do find it necessary to sometimes look at and/or clear caches in wirecache ($cache)..

you can double click the Pages item to page tree, or you can re-enable the Tree submenu item (i always do that).

Font Awesome 5 Pro for ProcessWire At Github: https://github.com/outflux3/FontAwesomePro I whipped up a font awesome pro module so that i could use those icons in the admin; it will be one of those "BYO vendor files", so you'd load your own Font Awesome 5 Pro assets once you buy it (about 1 day left to get the discounted pro license!)... Just posting this here in case anyone else ...is working on something similar ...already built something like this ...wants to collaborate on it} The webfont version basically works well in current admin theme but requires a custom css with fontface redefinition to refer to legacy 'fontAwesome' which is used in the admin css. The svg framework seems to work well, and leaving in the legacy font-awesome means that any icons that can't be replaced by JS are still visible (like :after psuedo classes); SVG framework only works with solid, probably because the new prefixing (fal for light, far for regular..) This is also going to be interesting for future admin themes, and the new 'regular' style is cute... Solid (default): dashboard example showing more icons: SVG framework:

this does work: $FieldtypeColor = wire('modules')->get('FieldtypeColor'); $field = $fields->get('dw_color'); $field->outputFormat = 0; $widgetColor = $FieldtypeColor->formatValue($widget,$field,$widget->dw_color); i just wonder if it is simpler/more efficient to do it this way: $widgetColor = '#' . ltrim($widget->dw_color, 'ff');

medkit - ok thanks, wasn't sure which one! Yes, the module does do some of the field and template installation, however so many things have to be assumed, because around 5 of the fields are page reference, so there needs to be populated items in the tree to even setup those fields correctly; i know it can be done, but would take some interaction or module config settings; right now the module config does need you to specify the root of the widgets themselves; but the other fields, like the shortcut select needs a branch holding all of the shortcut definitions; also each widget has view access settings for user, role and permissions, and for some reason those fields are not being fully setup correctly through the api; i will try and get the current version up on github soon and see if anyone else can work on it; i was also considering how to not use any PW fields or templates and make the whole thing be configurable from the module settings.

The dashboard module definitely works well and saves a lot of headaches for me as far as interacting with clients. For some reason most of my clients have an incredibly hard time using computers. I have to make everything as simple as possible; The dashboard was the only way to accomplish this, e.g. allow users to interact with a complex website, with a lot of data, moving parts, etc, and make it where they can log in and within 1 click either be editing a new content item, viewing a list of content items, recent formbuilder entries etc. The module is dependent on several types of fields, like FieldtypeColor (for the color of the widget header bar), FontIconPicker, for the icon to use for shortcuts, and Selector field for setting up the custom mini-listers. The module requires about 13 fields and 2 templates, as well as 3 page tree branches to hold the widget types, shortcuts, and widgets themselves; it hasn't been easy to port the dashboard from site to site, but i have gradually been able to automate some of the process of creating fields and templates (using some methods in the module that read the json export of fields and templates), or have used the built in export/import of fields and templates, as well as the new pages import/export. This screenshot is a simple example from a testing instance of PW.

possibly, read on... If you are comparing 'the' UI side by side, the problem is that there is no 'the' ui, because the page tree is the default UI, however when i build a site, my clients log into an admin that shows a dashboard (like wordpress), with lots of shortcuts to common areas, as well as content creation (like 'New Blog Post'). Some of these clients have never seen the page tree. ListerPro is a little bit like the wordpress listing of pages (albeit without hierarchical indents), but 'on steroids' – instantly filter to any page by title, use the filters or lister actions, edit inline, and ... bob's your uncle.