MarkE

Resolved by adding the following to admin.js $('.pw-sidebar-nav').on('click', '#topPropertySelectForm', function(event) { // // as of Uikit beta 34, clicking items closes the offcanvas unless the following line is here event.stopPropagation(); }); where #topPropertySelectForm is the page select form.

Thanks - I had come to the same conclusion. The following appears to achieve the same result as .load() but works when the div is outside pw-content-body var id = '#wrap_topPropertySelect'; $.ajax(window.location.href, { headers: {'X-Requested-With': 'justgivemethedanghtml'}, //:) dataType: "html", type: 'GET', cache: false, success: function (result) { var val = $(result).find(id).html(); $(id).html(val); } } )

Thanks for the simple solution @Jan Romero Now I have the same problem with .load() - you are right that it is ProcessController.php that is causing it. I want to use .load(document.URL + ' #' + 'wrap_topPropertySelect' + '> *'); but it is outside pw-content-body so doesn't work.

Adding the following in the ajax request seems to fool PW into responding with the full HTML. xhr: function() { // Get new xhr object using default factory var xhr = jQuery.ajaxSettings.xhr(); // Copy the browser's native setRequestHeader method var setRequestHeader = xhr.setRequestHeader; // Replace with a wrapper xhr.setRequestHeader = function(name, value) { // Ignore the X-Requested-With header if (name == 'X-Requested-With') return; // Otherwise call the native setRequestHeader method // Note: setRequestHeader requires its 'this' to be the xhr object, // which is what 'this' is here when executed. setRequestHeader.call(this, name, value); } // pass it on to jQuery return xhr; }, Still not worked out where PW is fixing the response. I thought it might be the line in ProcessWire.php: $config->ajax = (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest'); but commenting that out seems to have no effect.

Maybe I'm being a bit dim (not unusual ?) but I don't understand the ajax response I get from an admin template. A very simple example is function formTest(event) { $.ajax(window.location.href, { success: function (result) { console.log(result); } }) } If this is activated in the admin then the result seems to be not the entire html of the current page, but just the DOM under <div id=pw-content-body>. Why is this and how can I get the full HTML? Or am I being really dim....?

Maybe this isn't a great idea, but I wanted to place a pageselect inputfield in the admin masthead. There are several ways of doing this, but at the moment I am using a Page::render hook. That works well - see pic I'm then using js to clone that into the off-canvas menu. However, in the off-canvas menu, it is not usable - clicking on it just closes the menu. I'm assuming that there is some js in play here that I'm not aware of - any ideas? Thanks. PS I should have mentioned that this is in AdminUiKit

Sure. In fact, I was wrong to say that it works fine - I needed to make a small adjustment, which also enables more checking. The page object in the hook has the admin template - so we need to get the actual page being edited in order to get the override field. $this->addHookAfter('Page::render', function(HookEvent $event) { $p = $event->object; if ($p->template == 'admin') { $pId = wire()->input->get->int('id'); $page = wire('pages')->get($pId); if ($page and $page->template == 'BookingForm') { $event->return = str_replace("</body>", '<input type="hidden" id="Inputfield_override" name="override" value="' . $page->override . '"></body>', $event->return); } } });

No worries - thanks for the help This one works fine ? I suspect I need to mod this a bit to get it working. Ta muchly!

I've been using this for a while with no problems, but have just run into a slight issue. I have a checkbox field 'override' which is in a tab 'system'. The 'system' tab is only allowed for superuser. However, another field in an unrestricted tab uses a visibility condition "override!=1". It seems that, when a non-superuser is logged in, the visibility condition returns false when it should be true, presumably because override cannot be accessed. There are no restrictions on the override field itself. Any ideas @adrian? I tried a work-round with a hook, assuming that the API would work even if the tab was hidden. The one below is after renderReadyHook, but I also tried a before hook. In each case, the value is applied, but it seems like the form is unchanged. $this->addHookAfter('Inputfield::renderReadyHook', function(HookEvent $event) { $input = $event->arguments(0); if ($input and $input->id == 'Inputfield_fieldset_minimal') { bd($input, 'input'); $input->showIf = (wire()->page->overide!=1); } $event->arguments(0, $input); $event->return; });

Following the above discussion, I decided that it made more sense to display the title rather than the path (since it is only for display purposes). I also wanted a solution for attribute types pagelistselectmultiple, not just pagelistselect. In case it is useful to anyone else, my suggested js is: $(document).ready(function() { /* Author: Mark Evens, based on an original script by Robin Sallis */ /* This version displays the title text rather than the path name */ /* It also works for pagelistselectmultiple as well as pagelistselect */ /* Hide the text field */ /* id_title is the name of a text attribute in the hanna code*/ /* change id_title throughout the code below to match your attribute name */ $('#wrap_id_title').addClass('hide-field'); // Must use mousedown instead of click event due to frustrating event propagation issues across PW core // https://github.com/processwire/processwire-issues/issues/1028 // .PageListActionSelect is the button 'Select' with appears when a page is clicked (no normally visible - loaded by js) $(document).on('mousedown', '.PageListActionSelect a', function (event) { var id_title; // Adapt unselect label to suit your language if ($(this).text() === 'Unselect') { id_title = ''; } else { id_title = ($(this).closest('.PageListItem').children('.PageListPage').text()); // replace .text() by .attr('title') for path name } $('#id_title').val(id_title); }); // For pagelistselectmultiple, get all the selected pages when the selection is updated // This returns the contents of the label displayed in the pagelist item. This can be set in your HannaCodeDialog::buildForm hook // The default is the page title. For the path name, set $f->labelFieldName = 'path'; in your hook $(document).on('change', '.InputfieldPageListSelectMultiple', function(event) { var id_title = []; $(this).find('.InputfieldContent ol li:not(.itemTemplate)').each(function(){ id_title.push($(this).children('span.itemLabel').text()) }) $('#id_title').val(id_title); }); }); To hide the id_title attribute in the dialog, you need to add the following css: #hanna-form .hide-field { display: none !important; }

Just to report that this works well. I also added some css to hide the path attribute in the dialog box, so as not to confuse the user or risk inadvertant amendment. Super module , super support!

Brilliant - thanks. I was thinking along those lines, but obviously not hacky enough ?

This is one of my favourite modules and I use it a lot to provide user-customisation of, for example, email contents. In particular, I have managed to reduce the number of hanna codes used by introducing dialogs with page-select attributes (limited to certain children, specified by a hook described earlier in this thread). This works really well and avoids the need for head-scratching over tag names, but has one slight disadvantage in that the selected page is shown as an id in the text area - e.g. [[RentalPayment payment_type="5363" net_gross="Net" due="" format="£0.00" absolute=""]]. Unless the user can remember what page id 5363 is, they have to click the code to display it in the dialog. That's no great hardship, but in a text area filled with several such codes, it would be nice to display the name rather than the id. I'm wondering if there is a way to achieve a more meaningful display in the text area. I guess I could introduce a text or select attribute (unused in the code) which the user could use to document the selection. That seems a bit unreliable, however. It would be nice to fill the dummy attribute automatically, so my next idea was to use a hook - which is where I started running out of ideas: the hook would need to be on the page selection and somehow rebuild the form, whch all start to feel a bit messy. Any better ideas?

I have a chart that has a logarithmic y axis and I want normal numeric notation, not scientific, on the tick marks. In Chart.js v2 it seems the only way you can do this is with a callback - see https://github.com/chartjs/Chart.js/issues/3121

Maybe I'm trying to push this module too far. I decided to separate the other info into a separate (tabbed presentation) module. Now I have a different need - to use a callback function in chart options. I can't see how to do that in the syntax, but maybe it's just not possible?

Just that one of my dashboards is getting a bit large. I'd like to have maybe 3 tabs - one a pure dashboard of information, one with various settings and one webmaster-only board with system information and housekeeping etc. I could do it with a custom module, but I like your dashboard for the information view ?

Nice module which I use on a couple of sites. Just wondering if it is possible to specify a group to be shown in a tab?

Re issue 2 - Found it - classic missing = sign in condition led to inadvertant assignment. Doh! Issue 1 is still of interest though ( as is the more general question re $config vs. setting()).

Yeah - I was able to fix issue 1 because it is set in init. I guess I could try doing the environment test in init and setting a setting() there, but I thought it would be best to set $config->BH_ENV as early as possible and, besides, I would like to understand better what is happening with $config. Other assignments which are environment-dependent are set in the same config.php script - e.g. $config->httpHosts - and I am concerned that these may be affected also (willl do some investigations). More generally, are there any thoughts on when best to use $config and when to use setting()?

I've recently upgraded to v3.0.165 from 3.0.153 and it seem that the $config API is not working in the same way. Has anything changed. Two examples: 1. Use of $config to pass settings across a multi-site, multi-instance environment stopped working. I fixed this by changing to use setting() - see 2. Use of $config to determine environment. I set $config->BH_ENV = 'LIVE'; in config.php and overwrite it later in that file with $config->BH_ENV = 'DEV'; as follows: if(strpos($config->paths->root, 'M:/laragon/') === 0) { $config->BH_ENV = 'DEV'; //...... } However, in some circumstances $config->BH_ENV seems to take the value 'DEV' in the live environment. As far as I am aware, the relevant code has not changed - just the PW version. I have triple checked and there is nowhere other than the two assignaments decribed above where $config->BH_ENV is set. At the moment I am having to do a work-round by using different code in the two environments, but that's not a good solution. (BTW setting() doesn't seem to be available in config.php).

Hi @kongondo. Back to this issue of last year. Everything had been working fine until yesterday I upgraded PW from 3.0.153 to 3.0.165. Superficially everything seemed to be working, but then it became apparent that the cross-site operation of RM as described above was no longer working - basically the $config was not making it across the sites. In case it helps anyone else, I stopped using $config to hold the admin site instance and used setting() instead (see https://processwire.com/api/ref/functions/setting/). That seems to have fixed it ?

I was starting to guess that .... but nevertheless, it is a great module and actually a lot more useful than the module description implies as it does cover more than just templates if you use custom page classes (which I do for practically every template other than basic pages). Many thanks for the module and your thoughtful help. EDIT: Now I understand, I could just turn off the notification in the Settings->Editor->Inspections->PHP->Undefined->Undefined property, but I think I'll live with it.

Not in a template file - that's in a custom page class . Other documented page variables in this context will recognise fields. That's what I meant - except in my case it is better for documented page variables other than $this. The autocomplete works in all cases, but the $this-> fields are shown as accessed by the magic method. As you can see in the pic, $this->paymentAmount is accessed via magic method, but not for $payment->paymentAmount. A minor point since it is a bonus to get all the field help everywhere and not just in template files. Originally I didn't install the module because I thought it would only work in template files, but with custom page classes it seems to work everywhere (including in ready.php etc.) which is great! So the module description rather undersells it, I think.

I think it does if you are using custom page classes and include a documentor statement for any page variables that have classes. Try it and see. PhpStorm understands any methods for $this but not any fields.

As a PhpStorm user, I must say that this is a really helpful module. It works in ready.php, init.php etc. as well as template files (I use custom page classes a lot and always use /* @var ...*/ as it picks up the methods - now it picks up field names too!). Just one query - the only place it doesn't seem to work (ironically) is on $this within classes, even using the documentor /* @var $this ClassnamePage */ Any suggestions on this?