MarkE

Hi @bernhard. Prompted by your comments here , I decided to give this module a go as it looks very useful. One thing I find rather confusing is that you seem to have changed the suggested methodology and it's not entirely clear to me what is now the suggested best practice for using the module. From what I can see, you are suggesting that users construct their own module (along the lines of your example). Installing this will then run the migration and uninstalling it will do a downgrade. For further migrations, it seems that you are suggesting just adding to this module, not creating a new module. Your previous approach seems to have been more version-based. I am trying to understand how that works in practice. I currently have 2 migrations that I want to carry out. The dev system reflects the end state of both. I want to do it in 2 stages so that I can throroughly test the first migration before applying the second (although I think there is no dependency, it is better to do them in the same order as on the dev system). My plan is therefore to create the first migration module, back up the dev database, load the live database to the dev system, install the migration module to this, then test. If that is OK, then, if I understand correctly, I should amend the migration module to include the second migration and refresh the modules to run it. I would then test again. Now, what if there is a problem with this second migration and I want to reverse it? Uninstalling the module would presumably undo both migrations (unless I change the uninstall method to be only partial, which seems inconsistent). Sure, in the dev system, I could just revert to a backup, but that would not be a solution if the problems happened in the live environment as (unknown) data will also have been updated - in that case I would need to just be able to reverse the last migration. So should I put the second migration in a separate module? In which case, this starts to look more like your initial approach (except that the use of the migrate() method allows for a more declarative style). Am I clear in explaining my confusion? If so, can you de-confuse me? By way of background, here is my first migration plan (as a set of human instructions), to give you an idea about what I am trying to do: 1. Add new fields to templates: a. Property -> operator b. Property -> website2 (new field req’d) c. BookingForm -> propertyPage d. home -> taxYear, dayMonth, month & website2 (with descriptions) 2. Amend home template for a. description of operator (& webmaster?) & website (now allowed) b. re-use of summary field as restricted access field with description/instructions (and resize) c. re-order fields as per dev system 3. Change title of home to “System” 4. Add/amend hanna codes for a. ManagementMember b. Operator 5. Edit cheque payment method to = that on the dev system 6. Add images and files pages to home 7. Change title of home 8. Re-purpose comparison field as “mailHeaders” and add to StandardMails template 9. Remove bodyTop field from StandardMails template – change body to 10 rows, summary to 3, footer to 2, update descriptions & notes in the template and update instructions in the page I think I can see that there are methods for most of that in your module, but I'm not sure about the hanna codes. The php in all my hanna codes is identical (as it just passes data to a separate script), but obviously attributes etc. are different. I don't think RockMigrations handles these, but they have convenient export/import features so that's not too much of an issue. The second migration is 1. Use findPages to detect all pages with BookingStatus in a body field (i.e bodyTop etc. as well as body – any field that can take a hanna code) – approx. 15 pages. Make appropriate changes. 2. Change the refNumber for cancelled statuses (2 pages). I can probably turn these human instructions into php (although it may be quicker just to do it in the admin, but then I definitely do not have a quick 'downgrade option!).

Hmm. Thanks, but that just seems to just resize the unformatted column. Also, if you drag it under the Tracy bar at the bottom, then there doesn't seem to be a way of getting it back ?

Simple question: Is it possible to resize the field settings column when using Request Info on page? If you expand the array you get a very long thin column and I can't see how to resize. Thanks.

? I was going to mention the 2 migrations modules, but they are not part of the core. I have taken a look at RockMigrations and will do again - it's just that my last migration was too messy to use as an initial attempt. I will try using it for a simple migration first, to get the hang of it.

I chose to use PW precisely because of its back-end capabilities - it facilitates quick and effective building of back-end applications. I've used it for a few sites now - one (a holiday cottage booking system) is an almost completely submerged "iceberg" which has hardly any front-end pages and even those are access-controlled - e.g. for use by other front-end apps. In that one, I have a similar issue to yours with customer pages. Of course, all the pages and names are unique, but that is not the real issue, which is to say precisely when a combination of fields should determine that a new page is added rather than an existing one updated . My solution is to have a hidden field (uniqueId) which is a concatenation of first name, last name, email address and postcode. So I have this in the before Pages::save hook: case 'Person' : if ($p->id) { $p->of(false); $postCode = ($p->address) ? $p->address->postal_code : ''; $p->uniqueId = wire()->sanitizer->selectorValue($p->firstName . '_' . $p->lastName . ' ' . $p->email . ' ' . $postCode); // Prevent duplicate records if ($p->parents("name=contacts")->count()) { $uniqueMatches = wire()->pages->find("has_parent=/contacts/, template=Person, uniqueId=$p->uniqueId, id!=$p->id, include=unpublished"); if ($uniqueMatches->count() > 0) { $this->warning("Change to contact record not saved - Unique id: " . $p->uniqueId . " already exists. (Use search box to find it). If you just created this record, please delete it if it is a duplicate."); $event->replace = true; $event->return; } else { $event->arguments(0, $p); // Save the unique value, overwriting any previous value } } } break; One might argue that the uniqueID is superfluous and that the key should be assigned to name instead, but my preference was for a hidden field. Another site is less of an iceberg (about 30% above the water) and is a membership system whereby members can access their records only through the front end via an email challenge protocol (like a password reset every time - a lot of the members are quite old and struggle with passwords). There are various admin access permissions for different roles within the club (membership secretary, treasurer, event organiser etc.). This one just uses the email address as the unique id - an approach not possible for the first site as not all customers book on line. I think PW is admirably suited for this type of application - I researched a whole bunch of other CMS/CMFs and nothing came close. The balance of features vs flexibility is spot on. The only issue that irks me slightly is the database vs. code issue - i.e. the database effectively contains business logic as well as data which does create maintenance issues (some careful thought is required as to what logic should be capable of being amended in the admin and what is best to put in the code if possible - for example I moved all Hanna code logic into a separate php script). I suspect the recent debate about front-end enhancements is precisely because PW is seen as a bit more lacking in that department.

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