Macrura

@mike62 1) no need to remove ProCache 2) you should be logged into your admin when you are developing or trying to see uncached pages 3) make sure to add body class to cached pages so you can tell what is going on 4) install and use Tracy Debugger 5) make sure you have both wire_challenge and wires_challenge cookies in PC settings 6) if you for some reason do need to see the site when not logged in, add a get var, like ?nocache to the end of the url by the way, what happened to your admin - it looks like the admin from a much earlier version of PW. You should check to see if your user has an admin theme selected... By the way, i have never had to do any of the things you list, and work on live sites around 20 hrs a week.

@adrianromega - thanks for taking it for a test drive, and identifying that problem! I ended up rewriting the method that extracts the inputfields and now it should work a lot better thanks to your testing of that scenario.

ok i think i have fixed this, and improved the extraction process for the inputfields. Can you try the latest version?

you achieve that using the simple html dom parser, just have it scan for the anchors; the Process Documentation module has an example that will do exactly what you need; you can download a copy of the simple html dom parser and put it somewhere you can include it, and then process the body field as is shown in the example... https://github.com/outflux3/ProcessDocumentation/blob/master/examples/uikit-example.php

yes.

Since i typically maintain separate pages for those types of media (in a media library for every site), it is just a matter of setting up page select field. I use selectize so that the user can see what they are selecting. Also if i use a page for logo, then they can update the logo from the media library without having to change the setting; or they can add several logos to the media library and then select which one to use on the settings page. I don't yet know how to support image/file fields natively in this module, although since the settings pages themselves are pages of template admin, it might be possible. I was actually able to use both image and file fields and upload an image, however there are still errors with the value of the inputfield not yet working... In other news, here are some new screenshots of settings panels using UiKit theme, including a working example of using WireTabs:

there is no dashboard for PW. If you login though, you would see the page tree, that's the admin landing page. I would never permit a client access to changing the site's global base font. As mentioned in posts above this could have not only detrimental effects to the layout of all content elements, but would also be virtually impossible considering that many parts of the base css file (global style for example) may have rules that refer to that loaded web font. If this ability for base font to be selectable in admin was a requirement of the project, then i would neutralize all of the font rules in the css, and place 1 style tag in the header, which would be selected using some settings page (settings factory or custom helper module), this selection would also have the effect of loading the correct webfont (i use webfonts.js for font loading)... so to sum up, yes it is definitely possible to grant control of the global base font for a site to a settings page with the right modules, and code in the header, but whether it would really work is questionable; You also might need to account for 2 fonts, since most sites use 2-3 complementary webfonts each optimized for either headings or body text..

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;