MarkE

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?

I've been using this module successfully for a long time, but have just come across one issue. On older versions of IOS, the modal box can extend beyond the screen and not all be viewable. In particular, the "Save" button is not accessible. Is there any way I can put a save button at the top of the modal?

Just found this small print on the selectors help page: Please note: OR-groups work with database-driven find operations, but not with in-memory filtering (where they are less useful).

I am attempting to use an expiry for a cache item that is triggered by page updates matching the selected pages. Doing $cache->getInfo() shows that the cache item has been created correctly: [311] => Array ( [name] => dueNoticeBkg459 [type] => array (2 items) [expires] => when selector matches modified page [selector] => (template=Settings|BusinessProcess|BookingStatus), (template=Booking, title=Bkg459), include=hidden [size] => 271 ) I've tested the selector in the "selector test" module and it lists the correct pages. However, if I change and save one of those pages, the cache item has not expired. It works with a simpler selector such as "template=Settings, include=hidden" but not with the "or group". Are "or groups" not allowed in this context, or am I doing something wrong?

Not very old. v4.20.17

Realised I wasn't on the latest version - now updated and all OK.

It's just on one site. I have two sites as a multi install but only one of them has the problem. It also seems like $page is not being passed.

Any idea why, in the console, I get this message "Invalid argument supplied for foreach()" in lines 172, 180 and 184 of CodeProcessor.php? It seems to be there whatever the code is, but the code still seems to execute OK.

Any idea how I can use an image which is inside a pagetable to populate the og:image property?

OK - I've debugged the issue, although I never understood the exact sequence. FWIW, without going into details, I learned two things about ProcessWire while debugging this: If you are signed into mysite.com, this does not mean that you are signed into www.mysite.com although they are the same PW site. If a template has caching turned on, it does not detect if the the request method changes from GET to POST (with variables supplied) or if new/changed GET parameters are supplied. I don't know if these behaviours are intentional but they both caught me out. In particular, I'm surprised that PW doesn't serve up a new page with a POST.

I'm trying to debug a weird issue with POST variables disappearing. For some reason this only happens when the url of the page with the form is www.... as opposed to the canonical form. I have placed a trap in various places (the trap is just to test for $_SERVER['REQUEST_METHOD'] == 'POST' and, if true, var_dump($_POST) and exit) with the following results: in ready.php the dump executes and the POST vars are there in _init.php the POST vars are no longer there if I hook Page::loaded, the POST vars are not there So the vars are getting lost between ready.php and Page::loaded. I'm afraid I don't know PW well enough in terms of what happens in between these, so I don't know where to place my trap next. Any suggestions? EDIT: if I hook after PageRender::renderPage, the POST vars are there. So what happens between PageRender::renderPage and Page::loaded?

All my hanna codes return $hanna->field as: id => 0 name => "" label => "" flags => "" type => null Any ideas why? The other properties ($hanna->name and $hanna->value) are fine (contents shown are from Tracy - bd($hanna)) Solved - just being a bit dim and not realising that I need to pass the field explicitly in the API - it doesn't infer it from the context.

I'll take a look. Meanwhile, I'm doing a work-round to try and avoid needing each(). Thanks.

It appears that RockLESS uses LESS version 2.5.3. I am wanting 3.7 so that I can use the each() function. Is it possible to upgrade? Thanks.

Problem solved (sort of): The problem is caused by the HannaCodeDialog iframe effectively removing the <div id="dm-editor-content"> from the current DOM. This causes an error in Desigme as ACE can't find #dm-editor-content. Ideally, Designme should detect that #dm-editor-content is missing and not call ACE. My temporary inelegant fix/hack is to add <div id="dm-editor-content"></div> to the HannaCodeDialog iframe_form.php. Maybe someone cleverer than me can suggest the best way of fixing Designme (in designme.editor.js - the problem is line 58) ? EDIT: In the absence of better ideas, I have modified design.me.editor.js as follows (line 419 et seq) $(document).ready(function(){ if ($('#dm-editor-content').length) { designme.editor.init(); } }); @elabx - Is this on Github or some such for PR (I have 2 mods now) or do users just keep their own branches?