Macrura

for my application i don't think showing the process page edit on the help page would work, b/c how would the textformatter apply the styles and how would the tabs get rendered? Maybe i'm misunderstanding though - does setting the visibility to locked render the page content somehow - sorry just got confused from your image. yes, i agree about the nested shortcodes and the bad-old-joomla days that i never want to remember.. The point of building that shortcode based dashboard was basically a proof-of-concept to show that the module itself is flexible enough to handle display of anything you put into your CK editor, including some complex shortcodes, and specifying your own custom CSS files etc.. so more of a test case than something i would ever recommend. i think this module should really be optimized for showing beautifully styled documentation, so the focus is on body field/ck editor presentation and the CSS needed to get there, along with the additional ability to show tabs for navigating and simplifying the UI for related documentation content. I think your ideas would be great for a separate module, but i think i still need to understand more what you mean about it; apropos building a dashboard as fast/easily as possible, i am interested; my dashboard redux module works well and each widget can be shown based on user role, permission or the actual user; so it is optimized for sites where you want different widgets to show for different users/roles/perms; but for super simple builds where you just need to get a dashboard up fast, i think what you are suggesting sounds promising..

I was able to build a decent widget based dashboard using only this module and some hanna codes; And using @Robin S's hanna code dialog, i was able to build a widget based dashboard in a few minutes, with text and buttons. these are all based off the dashboard redux module markup and styling; the outer container hanna code loads the styles needed, so no need to actually add those to the module css files. 1) the CK editor view of the dashboard (page that is rendered): 2) the resulting page: also, i added the ability to disable the default CSS file from loading, allowing users to make their own styling for the dashboard pages; this way you can load whatever font you want, and style it to match your goal design for the doc pages. Here is what the unstyled page would look like, (and using the built-in, native jQuery UI tabs): Here is the styled version, loading default CSS (currently optimized for Reno Theme): Here is the latest module config screen:

Yes, it can totally serve as a makeshift dashboard; if you are able to make the markup how you need it within CK editor, then it would work but wouldn't be able to replace the page tree as the landing because usually like in the dashboard module there is code in place to handle that; but as a sub-page dashboard it would work. (alternately maybe you could use a hook in ready.php to set the page as the admin landing page, instead of page tree.. If you need custom PHP, you can just use Hanna Code Textformatter and your options are pretty unlimited; for example you could build a super simple dashboard with some buttons or information using those hanna codes to output the required markup for your dashboard; for simple sites this could be preferable to trying to build a custom dashboard from scratch; the dashboard redux module i use has around 13 fields, a few templates and a lot of page references, as well as requires icon picker, color picker; you could achieve almost the same type of dashboard layout by using some nested hanna codes...

Released: https://modules.processwire.com/modules/process-documentation/ https://github.com/outflux3/ProcessDocumentation This is a new module that will be released soon - the purpose is to allow you to create help pages in the admin. This differs from the Admin Help module in the approach, and will be kept totally separate. The Admin Help modules provides the ability to make a help tab on any page edit screen (and optionally make that pop up in a lightbox), as well as a single process page showing all of the help pages in a single accordion. This module's workflow is different - first you can create your help pages any way you want using any template and any field for the body text. You can create unlimited admin help pages, using ProcessDocumentation, select the page to display, and then users can click on that in your menu to access the help page. You can create a folder structure by creating a top level menu item using ProcessList, and then various help pages under that parent using ProcessDocumentation. The module comes with 2 internally used textformatters, one of them adds classes needed to the markup for some elements to allow styling within the content and not conflict with admin theme rules (e.g. ol, ul, blockquote, table etc.). The other textformatter allows you to implement jQueryUI tabs within your help page, using a simple shortcode/token format. The styling for the jQueryTabs widget matches that of the standard processwire admin theme tabs, so that users will feel familiar with the interface. Instructions: 1) Install the ProcessDocumentation module. It will also install the 2 textformatters. You don't need to apply those textformatters to any field, they are just used internally by the module and called in the correct order to make them work. 2) Select the field to use for the content display (e.g. body). 3) Create your content. If you want to use tabs, this is the syntax: {tab=My First Tab} Some content {tab=My 2nd Tab} Some more content {/tabs} Make sure to close the tabs or the page will break... you need 2 or more tabs for it to work. You can only currently have 1 set of tabs per page. You should be able to safely use lists and tables. 4) Create the process page under the admin. Select ProcessDocumentation as the process and then select the page to show from the tree. 5) Now you should have the menu item in your menu if you are using Reno it will be on the left, and under a parent if you setup a parent in the tree. Clicking on that will render the help page. This example uses 7 tabs. If you are superuser, you will see the edit process settings. Other users will see the edit content only, which allows them to edit the content of the help doc, make corrections or additions. If you need to prevent access to any documentation pages by any role, you just add the name of the process page to the permissions and then don't check it for that role. The module has a defined permissionMethod that checks to see if that permission is defined, and then if the user has it. Not defining individual help page permissions means they are visible to anyone with the documentation permission. There is more work to be done on CSS, and other small details.

yeah i wish that GreekMachine was still around, maybe we can ask for the php file

at least in terms of usage in the api, checkboxes always have the value of 1, so you don't need to manipulate the value, just the checked status of the input.

Do you think FA version 5 is an improvement? I have noticed that i like the V5 icons a lot better (using them in the admin via the FontAwesomePro module) a lot more icons also

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...