MarkE

I am getting this error on my live site Fatal Error: Uncaught Error: Class 'ProcessModuleInstall' not found in wire/modules/Process/ProcessModule/ProcessModule.module:1075 when trying to download (any) module. I cleared the FileCompiler, but the error persists. I copied the database across to my dev site and everything works fine. So I can install on the dev site and then copy back, but this is obviously unsatisfactory. Any ideas? NB I can also install on the live site OK by uploading the php and then installing. It's just the "download" function that is failing.

Hi @Macrura - you can see my changes here: https://github.com/outflux3/AdminHelp/compare/master...MetaTunes:master I also think it would be a good idea to allow more than superusers to edit - say via a permission.

Thanks. That’s useful, in that it has no database component, but I really need a drop-down/dialog capability so I think I’ll have to stick with the “hybrid” route, where only standard code is in the back-end.

Thanks - that looks neat. I guess I could then just have another function for the common elements.

I use Hanna Code quite a lot, and especially with @Robin S's excellent dialog module. However, one thing I find a bit irritating is when you have lots of codes with php; the number of clicks to edit the php plus then needing to update the database (assuming you do this on a test version before implementing live) is quite time consuming, often for quite trivial changes. So: I am looking at re-engineering my codes along the following lines. Each code which needs php will just have the same code - something like <?php $result = hannaCode($input, $attr, $page, $hanna->name, $hanna->field, $hanna->value); if (in_array('text', $result)) $hanna->value = $result['text']; echo $result['out']; Then, in a separate php file (probably "include"d in init.php) I have a function hannaCode($input, $attr, $page, $hannaName, $hannaField, $hannaText) with a switch on $hannaName to execute the code for that name. This has 2 benefits: Any common code can go at the top, before the switch. E.g. I have if ($page->template == 'admin') { $pId = $input->get('id'); $page = wire('pages')->get($pId); } $helpArray = [ 'Property' => '[[Property]]: The name/title of the property (choose system name or title). Only works on a Booking page and its Mailing children', ..etc... ]; if ($page->template == 'help-doc') { return ['out' => $helpArray[$hannaName]]; } switch ... I can do simple edits in the IDE, test and upload without having to touch the database. Has anyone else tried this. Any thoughts? Is it even worth a tut?

OK - there's an easy answer to this - use InputfieldPage with InputFieldSelect, rather than InputFieldPageListSelect. Perhaps - when I get the related js working! - Works.

I have built a property booking status screen (see partial pic at end) that works very nicely on my dev machine. However, when on the remote server, it is very slow to load as there are about 70 InputfieldPageListSelect fields, each of which appears to do a request to processwire/page/list/?id=... Over the internet, 70 such requests takes an appreciable time. I've been scratching my head and getting only splinters in my fingers ... does anyone have any ideas for strategies to speed this up? Although there are 60-70 lines, each with a "tariff" field, there are only about 6 tariffs, so each page is fetched about 10 or more times. I need each field to have a unique id, though, so that I can update it via Ajax if the user changes it (see code below). // Select tariff $inputFieldTariffSelect = $this->modules->get('InputfieldPageListSelect'); $inputFieldTariffSelect->parent_id = $week->yearPage->id; $inputFieldTariffSelect->attr('name + id', 'tariffId'); $inputFieldTariffSelect->label = ''; $inputFieldTariffSelect->value = $week->tariffPage->id; $inputFieldTariffSelect->attr('data-action', 'form-update'); // selector for jquery on change $inputFieldTariffSelect->attr('data-update-target', '#innerWrap' . $week->id); // need week id to make unique $inputFieldTariffSelect->attr('data-update-reply', '#tariffAmount' . $week->id); $inputFieldTariffSelect->wrapAttr('style', 'width: 50%;'); $formTariff->append($inputFieldTariffSelect); I'd be very grateful for any thoughts or pointers.

Yes. See pic. But I actually did the mod for any number of levels. Each heading is <h{$level>

Just a little more re this. The recursion is in two places: In the help tab. There it seemed to have no effect as help-docs could not be children of help-docs. Changing the template family fixed that. In the Help processmodule. There only one level of expansion was catered for. I have put the expansion into a separate function with recursion, increasing the heading level each time.

That's probably better than what I did which was to render the hanna explicitly. So that the user can see the help at the same time, I added a button after the edit pencil in AdminHelpTab.module line 150: $body .= " <span><a href='{$docLink}{$doc->id}' target='_blank' title='Edit'><i class='fa fa-pencil'></i></a></span>"; $body .= " <span><a class='popout-help' href='{$doc->url}' title='Pop-out'><i class='fa fa-external-link'></i></a></span></h1>"; and then the following in AdminHelpTab.js: $(document).on('click', 'a.popout-help', popOut); function popOut(event) { var link = $(this).attr('href'); window.open(link, 'popup', 'resizable= 1, height = 600, width=800, scrollbars=1'); return false; } That would be good. However, what I would also like to be able to do is to have 2 fields - one with the developer-supplied help and the other which the client can edit to add their own aides-memoire - so I was going to just hack the code for that ? Correct, but since neither the help-index or help-doc templates allow children, it has no effect. Easy enough to edit the templates though. With the css, my main issue was with .cbp-ntaccordion h3.cbp-nttrigger {} where I changed the font size to 1.2em (from 2.2em). Especially with these changes, I think this is actually quite a powerful help system - if all you want is help - without needing the full ProcessDocumentation (which, in any case does not have the accordion) - though I may want to add a few more things (e.g to produce a complete pdf).

Thanks. I've hacked my copy as follows: To allow use of Hanna codes in the body To add a pop-out button next to the edit button in the tab Let me know if you are interested in incorporating these very simple changes. Also, as I said earlier, I changed the help-index template to allow recursion. P.S. I might look at re-styling the accordion, which occupies a lot of screen real-estate.

Hi @Macrura. I just found this module and it looks very much like what I was going to do from scratch for my current development - i.e. have a help file for each template but also as part of a general help page. I installed it and made a minor mod - to allow help-index pages to have help-index children (plus a body field). This works nicely in the accordion as a hierarchical drop-down. However, it seems like the module is no longer supported and you are suggesting ProcessDocumentation instead. I also note that there seems to be another module - ContextHelpTemplate - that is more up-to-date than AdminHelpTab in allowing more options for display. So I am a bit confused. What do you recommend for my help pages (it would be nice to use pw-panel)?

It's actually a bit more complicated than that at the moment, because a urlencode(serialize($array)) is the get parameter with all the data for the lister session bookmark, as the latter is general-purpose (there is more than one 2-dim table and they have different features). I don't see that tabulator replaces the 2-dim display I showed in the image, but it might make for a better drill-down display instead of the lister. I'll take a look into that while the client is user-testing the current version.

Thanks @bernhard. Tabulator certainly looks interesting. My use case is slightly different from the standard table, however. It is a 2-dimensional tabulation of summary data (each cell based on the sum of values meeting the criteria of both column and row). Each cell than has a link to a process module which takes the criteria and turns them into a Lister session bookmark, to which it redirects, thus providing a drill down for the components of each cell. I'm not sure that tabulator handles this, but it does look like a potential enhancement of the standard MarkupAdminDataTable. See image:

I guess the alternative is to put the call in Process module so that the Listers are created on the fly. However, the load time for a table of 300+ cells is currently 1.5 sec, of which I suspect only a fraction is for creating the Listers. I may give it a try to see which is best. Update: using the module cuts the time to 1.4 sec on my dev m/c (there's a lot of processing to produce the table anyway) and makes no appreciable difference to the time to open the drill-down lister (if anything, it's a bit faster). So I can ditch my mod to ProcessPageLister, but I'm still curious about the limit.

Done that, thanks. Any views on whether this should be raised as a fix, or if the hard-coded max is there for a good reason? The fix is very simple - just add an argument $max=30 to the method and set $maxBookmarks = $max;

I have been making use of the ProcessPageLister::addSessionBookmark() method to create drill-downs of financial data in a table - so that the user can see the pages comprising the amount in the table cell. This works really well and has been well-received by the client. However, I soon ran into a problem in that the method sets $maxBookmarks = 30; hard-coded just like that. I changed the code to $maxBookmarks = 400; and haven't noticed any ill-effects so far, so some questions arise: Why is it hard-coded rather than modifiable? If the answer to (1) is because too many bookmarks cause a problem, what is the problem? If there is no particular problem with more than 30 bookmarks, is there any other practical limit? Clearly changing the code in my copy of PW is not a good idea as it will get over-written at the next update. Is there a way of dealing with this until (if ever) the variable can be modified through the API?

Here's what I did: $wire->addHookAfter('HannaCodeDialog::buildForm', function(HookEvent $event) { // The Hanna tag that is being opened in the dialog $tag_name = $event->arguments(0); // The form rendered in the dialog /* @var InputfieldForm $form */ $form = $event->return; if($tag_name === 'BusinessProcess') { $modules = $event->wire('modules'); // Generate page list $f = $modules->InputfieldPageListSelect; $f->set('parent_id', 6199); $f->name = 'businessProcess'; $f->id = 'businessProcess'; $f->label = 'businessProcess'; $form->add($f); } });

Regarding attributes of type pagelistselect, it would be really useful to be able to specify the parent page to restrict the selection. I assume it may be possible to do this in a hook somehow, but might it also be a useful enhancement - something like attribute__parent=id?

Many thanks - didn't spot that!

This is a nice module and I've added a number of panels successfully. However, I have a problem with the chart panel. My code is below (the data is just a test and will be replaced by integer variables): $reports->add([ 'panel' => 'chart', 'title' => 'Contact bookings for ' . $property->title, 'data' => [ 'chart' => [ 'type' => 'bar', 'data' => [ 'labels' => [4, 6], 'datasets' => [ 'label' => 'count', 'data' => [1, 1], ], ], ], ] ]); I get a js error: DashboardPanelChart.js?v=0.6.14:121 Uncaught TypeError: e.data.datasets.forEach is not a function at Object.beforeUpdate (DashboardPanelChart.js?v=0.6.14:121) at Object.notify (chart.js@2.9.3:7) at Qe.update (chart.js@2.9.3:7) at Qe.construct (chart.js@2.9.3:7) at new Qe (chart.js@2.9.3:7) at n (DashboardPanelChart.js?v=0.6.14:123) at HTMLCanvasElement.<anonymous> (DashboardPanelChart.js?v=0.6.14:123) at Function.each (JqueryCore.js?v=1585265024:2) at init.each (JqueryCore.js?v=1585265024:2) at c (DashboardPanelChart.js?v=0.6.14:123)

That's the idea. However, I have decided to use ProcessPageLister::addSessionBookmark() now I've got it working, as it doesn't suffer from the problem of altering the default filters. All works fine now and I have a lovely drill-down effect ? EDIT - actually the default lister settings are still affected ?

Some progress: looks like you can use the properties listed in the ProcessPageLister module as the keys in the bookmark array - certainly initSelector works.

Context: I have a (html) table of financial data in a back-end dashboard. Each element of the table is the sum of values from certain pages (for which a selector has been constructed). What I want to do is add a link for each element to a lister page showing the pages that go to make up the element. i.e. a link to a lister page which uses the constructed selector. This sounds like it ought to be easy, but I've been chasing around for a while now and can't seem to crack it. What I've tried: supply a GET var with a csv of the required page ids - /?open=1,2,3 - this seems to have no effect; use ProcessPageLister::addSessionBookmark() - I can't find much documentation about this, particularly regarding the format of the $bookmark array to be supplied. I tried the array structure I inferred from the code, viz: ['id' => , 'title' => , 'desc' => , 'selector' => , 'columns' => , 'sort' => , 'share' => ] but the selector seems not to be recognised (all pages are selected); use a session var to communicate the selector to a hook before ProcessPageLister::renderResults - at least with this, the selector gets recognised, but it will be messy to operate because multiple selectors would be required to handle all the table elements (or some js would need to be added to see which one was clicked) I really feel it ought to be easier than this and that I'm missing something obvious. Can anyone shed some light please?

Thanks for the ideas. I decided to use a class for the template (MailConditional) and put the method in there. This simplifies things a bit for me - just need to call $mailPage->evaluate_condition(). <?php namespace ProcessWire; class MailConditionalPage extends DefaultPage { /** * Create a new MailConditional page in memory. * * @param Template $tpl Template object this page should use. */ public function __construct(Template $tpl = null) { if(is_null($tpl)) $tpl = $this->templates->get('MailConditionalPage'); parent::__construct($tpl); } /** * @param $codes * @return bool * @throws WireException */ public function evaluate_condition($codes=[]) { ... }