MarkE

Yes. To explain further: Site 1 is a web app which handles the bookings. Site 2 is the public website for the property. I need to publish the availability from 1 to 2. The result is the availability table you see at https://www.bawdhall.co.uk/prices. The admin app will handle multiple properties, each with their own availability page. The availability page in the admin app hosts the RM field. It is intended that the publishing of availability could take place in one of 3 ways: iframe in the public site (which could be anywhere). The availability template in the admin app provides the rendering for this (using the RM field). access the admin app PW API from a non-PW site on the same server (this is the method used for the link given above and works very well using the RM field on the admin site). access the admin app PW API from another PW instance (what I am now trying to do). The code for the RM field is really rather big and accesses a lot of data from across the admin site (site 1), not just the (non RM) fields on the availability page. As well as the table you see, it also hosts a booking form. You will realise from the above that this code needs to sit within the admin site to handle cases 1 and 2 - I really don’t want to replicate it in a slightly different form for case 3 to access all the underlying data directly and re-build the table. Besides, it seems nonsensical that case 2 should work “out of the box” but not case 3. I don’t know if I have made things harder by putting both sites in a multi-site setting. Maybe it would help if they were completely separate sites, whilst still on the same server. However, I read Ryan’s comment that it would be good to use the same PW version so I though that multi-site was a sure way to achieve that. I’ll answer the last point on code in a later post.

OK. Results as follows: Undefined function Filename does not exist (it is looking on site 2, not site 1 - where the page and field are) render() on null call to undefined function wire() I tried them all with and without RM module in site 2. The results are exactly the same (if the site 2 module is present it will run that, otherwise it will run the site 1 module). If I put the file in site-2/templates then alternative (2) works (with and without the module in site 2). (But it makes no sense to have the file in a different site from the page and field).

Additional info. I have the RM module in both sites. It seems like the site 2 module is attempting to run the site 1 field. (EDIT - Background - I thought I'd try a work-round by putting a function call to the php in the paste PHP box. The page and RM field are in site 1 so that's where the PHP file and function are. However, the work-round fails because of "undefined function" being called from the RM module in site 2. I'm not sure how modules are supposed to operate in a multi-instance set-up, but it seems that any modules necessary to process site 1 fields need to be in site 2 as well and somehow be "multi-instance aware"). FURTHER EDIT! - The above is not entirely correct. If I remove the site 2 module, the site 1 module will run (in Paste PHP mode only).

That works fine! EDIT But if it's in a php file then it doesn't work

Used Tracy. The field is just shown as empty. Other fields from the same page are all OK. As a separate php file. plus I can see that it all renders OK on site 1.

I've now implemented a multi-site and multi-instance setup and it mostly works. For some reason, the 2nd site cannot access select options fields on pages on the 1st site - I changed these to page reference fields and that works. The only major problem so far is with runtime markup fields, which are pretty crucial to my app (great module btw @kongondo ? ). These don't seem to be accessible by the 2nd site at all - either directly or via $page->render(). Curiously, I had no problem accessing them from a non-PW site (on the same server).

? Whoops! Many thanks - I wasn't aware of that - I'll read up on it.

Am I right in thinking that dragging of selected items to sort them is not possible on an iPad (or other touch screen?). Or, if it is possible, how?

Thanks @kongondo, the standard API only works on the same server anyway - that works now with the non-pw site. I’ve used multi-site before, but I don’t see how I could access the API of the other site without namespace confusion.

Uploaded script to github at https://github.com/MetaTunes/Form-update This includes a force refresh of the target field in order to make it work in more instances (e.g. a nice new application for providing previews of multi-select page-per-image)

I'm building a holiday cottage management system and website. It's coming along very nicely. Originally the plan was for it to be fully integrated - i.e. public website in the same PW site as the booking admin app. As a temporary integration of the availability calendar from the admin site into the existing public site, I used the PW API as documented here. It works very well - see the calendar embedded here. That got me thinking that perhaps it would be better to keep the two sites separate in any case, even after re-engineering the public site into PW (for its better CMS capability). Having the sites separate would make maintenance easier as well as not confusing the two environments (one on Bootstrap, the other on UIKit, for example). Two questions arise: Has anyone else done something similar (i.e. split website and web app in PW) or otherwise have any views on the pros and cons? More specifically: How do I address the namespace issues when I have one PW site accessing the API of another? It isn't a problem at the moment because the public website is not in PW.

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: