Macrura

ok cool -thanks for testing out my version! i will be submitting a PR soon so once that happens and if it is accepted you could switch back to the official branch; but if it works for you and satisfies your current requirements, it should be 'stable', there are just a few simple changes to the code and those added inputfields. if you do run into any issues, you can post an issue on the forked github issues page..

you can't get past events, but you can try the forked version which has a few extra options... (date since, date until, reverse sort)... https://github.com/outflux3/processwire-facebookevents planned to do a PR but haven't gotten round to it yet..

the scenario i encountered was this: - ProcessGeneralSettings original version did not permit non-superusers to access the settings page; in order to achieve that i added the permission and permissions properties to the module config 'permission' => 'general-settings', "permissions" => ["general-settings" => "Access general settings page"], ); then i gave my 'manager' role that permission. However once i did that, the settings were no longer available on the front end, (using the global variable that the module sets in wire), i assume i would have had to give the guest role that permission; so instead i just split the module into 2 and then could enforce access control on the process without preventing the settings from being accessed on the site. But if there is/was a better way that would be interesting to know about... the getDefaultData() as adrian posted...

ran into this problem with the General Settings module and my fork of the module consists of 2 separate modules, one process module for editing settings and one for storing the settings; because you can't access control the process module without preventing its data from being accessible to the front end. Settings Factory should work in this case, but i haven't tried required fields yet, and see that you have those implemented; (i should probably improve that part). I also haven't tried tabs yet... You could also just split your module into 2 separate modules...

I'm working on the github wiki which will include those instructions, but here it is in a nutshell: Once you have created the process page for the settings, those settings are available using the process name, so if you made a page with the name theme-settings, you would do this: $factory = $modules->get("SettingsFactory"); $themeSettings = $factory->getSettings('theme-settings'); the settings are delivered as a WireArray (or can be delivered as a plain array getSettingsArray('name-of-process); Here is the bar dump of those settings, using default wireArray; In some scenarios i'm getting the raw array and merging it with some other hardcoded array, like for outputting JSON-LD schema: Person.schema.php: <?php namespace ProcessWire; if(empty($item)) $item = $page; if(!isset($tag)) $tag = true; $jsonld = array( "@context" => $tag ? "http://schema.org/" : '', '@type' => 'Person', 'mainEntityOfPage' => array( '@type' => "WebPage", '@id' => $pages->get(1)->httpUrl, ) ); $factory = $modules->get('SettingsFactory'); $personSchema = $factory->getSettingsArray('schema-person'); $jsonld = array_merge($jsonld, $personSchema); // add image here... $profileMedia = wire('pages')->get("template=media, media_roles.name=schema-profile, images.count>0"); if($profileMedia->id) { $image = $profileMedia->images->first()->width(696); $jsonld['image'] = array( "@type" => "ImageObject", 'url' => $image->httpUrl, 'height'=> $image->height, 'width' => $image->width ); } $jsonld = array_filter($jsonld); if(!$tag) { return $jsonld; } else { if($user->isLoggedin()) { $jsonld = json_encode($jsonld, JSON_PRETTY_PRINT); } else { $jsonld = json_encode($jsonld); } echo '<script type="application/ld+json">' . $jsonld . '</script>'; }

Just a quick update, so this module works fine and if you purchased FontAwesome 5 Pro and need/want to use those icons in the PW admin, this module allows that do be done, and works with default and Reno themes; it doesn't work on UiKit theme yet, see here for the reason https://github.com/processwire/processwire-requests/issues/120

I ended up turning this into a module, ProcessDatabaseRepair, though it also can also check and/or optimize the tables. So far works well, but since it interacts with database, i'd be worried about distributing the module. If anyone in particular needs such a module, let me know. It's quicker for me to use this to optimize the tables than to login to client's PhpMyAdmin and run it there; also if in the rare event described above, any table crashes, the hope is that this will fix it (yet to encounter a situation where it can be tested in that scenario, unless there is a way to force crash a table)...

Thanks @Mike Rockett! currently as far as i know/can see in Sublime, the module follows the PW coding guide, so only uses tabs I fixed all the other items according to your recommendations, commit after testing..

This is the new topic for the Settings Factory module (formerly known as Settings Train). Repo: https://github.com/outflux3/SettingsFactory I'm not sure what versions this is compatible with, it has only been tested on 3.x branch; it is not namespaced, and i'm not sure if namespacing is necessary or a benefit for this module; if any namespace or module gurus can weigh in on this, let me know. I'm also not sure if there needs to be a minimum php version; I have one live site using this now and it's working great; But before submitting to mods directory, would be better if there was some additional testing by other users.

The module evolved from a couple of separate ideas/needs and other modules; First there was the General Settings module, which I used on a few sites and worked well. But that has some problems/caveats/gotchas: 1) by default it uses a $settings global variable that overwrites the Lister Pro settings global $settings; 2) it has limited support for inputfield types (thus why my forked version added support for more field types, collapsed status etc.); 3) you could only have 1 settings page with that module 4) you had to use the module's interface for setting up the fields. So the overall the idea of defining settings fields with json and storing the data inside the module config was inspired by PGS (process general settings). The settings values are stored in the database, in the module config of the main (non process) module. No, no data is stored in the template folder; only the field definitions; this is a feature, not a caveat/limitation. Settings Factory itself is part Warehouse, part Factory, and part Delivery Service.. Factory in that it takes raw materials (the json and php files you have created) and turns those into process pages where you use those inputfields... Warehouse in that it stores those settings values for you, each in it's own array named after your process page. Delivery Service in that is facilitates the retrieval of those settings as a WIreArray or Plain Array (depending on your needs) to the templates; One recent use case of this module is for defining Schema.org values for various Schema types; In this use case, all of the fields are defined in the json field definition file, and then the process module displays the input fields; the Schema rendering function/file reads the SettingsFactory data array straight into the schema (json-ld) since the keys are matching the Schema.org properties; So if you are doing a company site, you can give them a few pages of schema fields to fill out and then create your json-ld from those various arrays.. I think the use case for this module is pretty clear, and really comes down to 1 field, 1 value config settings, or definitions of things like Schema properties; as opposed to real fields that can contain values for that field on multiple pages.

sorry my phone kb doesn't have straight quotes?

wire(‘settings’) in func/module

So now there are 2 modes that the process pages can be rendered in, Field Render Mode and Template Render Mode; in field render mode, you just select the field to render and that's it; if you use the built in CSS, shortcodes and such you can output those simple tabbed help pages or just plain wikis. if you need more options you can disable the default css and use your own css file, or multiple css files; a.k.a Field Render Mode, advanced settings. Here is a simple wiki page, using a custom CSS file (to make it a bit more wiki-looking): In Template Render Mode, you activate that by just putting the name of the directory where you will store the template files, within your templates directory. This mode is not mutually exclusive of Field Render Mode; they both work depending on the factors; Once you are in Template Render Mode, you have to load all of your own dependencies; in other words, the module just lets that file take over, and renders it; The only thing the module does in this mode is sets output formatting to true on the page being rendered, before sending into the wireRenderFile method. Here is an example of a page being rendered in Template Render Mode; for this to work it requires a matching php file to the name of the page, so this is being rendered by news-help.php inside the folder: Here is the code in the news-help.php file. $jqt = $modules->get("TextformatterJqueryUITabs"); $mcs = $modules->get("TextformatterMarkupCSS"); $body = $page->body; $mcs->format($body); $jqt->format($body); $config->styles->add("/processwire_test1/site/modules/ProcessDocumentation/ProcessDocumentationDefault.css"); echo '<div class="help-doc">'; echo $body; echo '</div>'; The only exception to the use of both modes is if you create a default.php file in the folder; if you do that, then the module will always render the pages using that file; So this way you can have all of your document pages being output by that one file and not have to create new php files for every new doc page; Since you can do anything you want in those php files, you could show some content from another site. Here is an example where the php file loads a github readme file: $markdown = file_get_contents("https://raw.githubusercontent.com/outflux3/InputfieldSelectize/master/README.md"); $tfmd = $modules->get("TextformatterMarkdownExtra"); $tfmd->format($markdown); $config->styles->add("/processwire_test1/site/templates/docu-templates/test-wiki.css"); echo '<div class="help-doc">'; echo $markdown; echo '</div>'; ... and the page:

manual testing basically, also unsure of minimum pw and php requirements also need to install/uninstall a few times, make sure it all works right;

thanks - i also responded on github - i think the selector does need to change to optimize this, but somehow i think we need to limit to siblings - what about adding to the selector like parent=$this->editedPage->parent

This module is on Github, https://github.com/outflux3/ProcessDocumentation in case any one wants to test it; will wait till i have time to run test cases before releasing..

I ended up going with Settings Factory, since it may just make more sense in the long run. The module is really more of a facilitator to the display of inputfields related to settings, and their subsequent storage and retrieval, so not sure there is any good metaphor that could be used...

1) the purpose of using the process module is so that you can have single pages for the documentation articles, that are navigable from the primary admin nav and bookmarkable so you can send users a link to the article; There isn't any plan for template contextual help because that is already covered by Admin Help module. Also using the jquery tabs is completely optional; In its simplest use case, you'd just render some text there on that page for your users to read and refer to; maybe some global instructions for things they get confused about, an embedded video, or links to some tutorials on ck editor, or even some instructions about how modules work, or SEO consideration... 2) In the scenario where let's say you do want to render some very complex help page, say with tabs, accordions, or some complex charts that need custom javascript, and you don't want to use the built in tabs shortcodes, and you don't want to use hanna codes; you'd like to be able to display the output of a template file field that generates the markup for your help page, because you are doing your tabs in a repeater, and you also have a table that you are generating with a table field etc.; I believe that you would not need RuntimeMarkup for this; the module would simply need a switch between rendering a single field (default behavior), vs. using the template class to render the page using that custom template; so in that case you'd only need to have a field to input the path to the custom template file for rendering the help page, if i understand correctly; Said template file would be able to self-control its own dependencies for styles and script so you'd also disable the default style from loading; As far as i can predict, this should be a fairly simple addition to the module and shouldn't have any negative effect on the typical/simple use case;

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