adrian

I am thinking that this might actually be an easy fix in the PW core. I just did a quick edit, replacing this line: https://github.com/processwire/processwire/blob/cc43f8e67600fc3ad73ea3ac095d67f166c5ca96/wire/templates-admin/scripts/inputfields.js#L1483 with: var field = match[1]; if(field.indexOf('forpage.') == 0) { field = field.replace('forpage.', '').replace(/\_repeater\d+/g, ''); } This lets me use: forpage.fieldname=value as described by @999design in the OP. @ryan - can you see any problems with this approach? Maybe I've overlooked something? Note that this approach currently won't work with AJAX loaded repeater items.

@999design - I just found myself wanting this exact functionality. The easiest way for now seems to be Robin's https://processwire.com/modules/custom-inputfield-dependencies/. The custom PHP option does the trick with something like this: $p = $page->getForPage(); if($p->field_name == 'value') return true; return false; The caveat is that the conditions provided by this module are only applied on page load, not instantly via JS like the PW core feature. But definitely better than nothing for now.

Hi @szabesz - sorry for such a late reply, but this should show what needs to change: https://github.com/adrianbj/FieldtypePhone/commit/b3376e13615a702bf5075f94c08e790ab9778c53 I added a new data_country field and moved the contents of the data field to data_country and then populated data with the raw number (concatenate data_country and data_number). Hope that helps still.

Hi @sebr - when I test your module, it saves the the data truncated to 65535 characters. I don't get any error. I also tested the module saveModuleConfigData() method with a long string, and again it just truncates it. All I can think is that there was a DB error during the save which removed the data. Maybe saveModuleConfigData (or actually saveConfig) needs a try catch to make sure an error can't delete data?

@Mike Rockett - The issue is that it's an exclusion rather than an inclusion, so the children are already added before it gets back to the canBeIncluded check.

Hi @MarkE - looking at the pages DB table, it seems that in reality I should just be setting the sort values starting at 0 and not 1. Not sure why I set it up this way - seems like generally it doesn't matter, but setting the first child page to 0 should work for you I believe. I have made that change for the latest version - can you let me know how it goes for you please?

@elabx - I found the same as you that the only way was to do a direct SQL update. Just looking and this problem seems to be around forever based on this really old code: https://github.com/adrianbj/ProcessMigrator/blob/master/ProcessMigrator.module#L1707-L1714

@teppo - new hook, eval replaced, and composer support added in the latest version. Thanks for the feedback!

If you ever find that it's just my modules that are holding up this transition for you, let me know and I'll make the change.

You know what, I don't think there is actually a need for it. I was sure there was at the time so I am wondering if PW supported periods in $page->get many years ago (keeping in mind that I actually started using this module in 2015 even though it wasn't public until much later). Or maybe I just wasn't aware back then of the ability to do $page->get('field') vs $page->field in general. Anyway, it's pretty clear that we can now do $page->get('parent.id') so it does look like your solution now works well, so I'll replace it in the next commit. Mind you, I don't really have a problem with eval() in cases like this but I understand the issue of automated scanners picking up on it.

@teppo - I think that's a very desirable use case. I use locked fields quite a lot. I guess I just haven't ever needed them together with this module's functionality before. My quick testing also shows that it is working as expected with Inputfield::renderReadyHook. I am not sure I can think of any issues with it at the moment, so I'll probably commit soon. At the moment, all my modules still rely on the file compiler. I guess I just haven't seen the need to break any 2.x installs because it seems to work just fine and once it's compiled the first time, I don't think there is any significant (if any) overhead. Are you aware of any? As for composer - yeah, I probably should - for whatever reason, Composer still doesn't really gel with me so I tend to avoid it when possible :)

Thanks for the report @LAPS - it should be fixed in the latest version. Please let me know.

The difference with Admin Actions is that it's always going to be PHP code and also it's not being used to edit code, just view it. I did look at Monaco when I was initially developing the Console panel and came across some issues I couldn't resolve (although I don't remember what they were now). I could probably get away with only packaging one theme and remove the config options, but because I think so many of use the Console panel so much, I think giving users the ability to match the styling to their preferences is a pretty nice bonus. As for language syntax highlighting / linting etc - there are certainly options that could be removed like elixir, csharp, and lots of others, but I wouldn't want to limit to just PHP, HTML, CSS, JS. What if someone is working in latte or twig or coding JS in CoffeeScript or they are connecting to a separate Postgres DB and could make use of (mode-pgsql), or editing some SVG code (I sometimes use the Console panel for this). Keep in mind that the entire Tracy module zip file is only 3.5MB (https://github.com/adrianbj/TracyDebugger/archive/refs/heads/master.zip) so even if I removed all the extra Ace files, it might get down to ~1MB. I am just not certain I want to remove functionality that someone might use for the sake of a couple of MB. Note that I used to do exactly what you are asking for: https://github.com/adrianbj/TracyDebugger/tree/3181668f6841ae9f75a9fe49e6e8331ab0c69fc4/scripts/ace-editor but as I mentioned, each time I update it, I have to manually copy across the new files rather than the entire set.

Hey @bernhard - any particular reason you want it disabled? That said, you can do what you want very easily by adding this in your URL hook. \Tracy\Debugger::$showBar = false;

Hi @szabesz - probably not, but I didn't want to limit users to specific themes and I also didn't want to remove syntax highlighting and linting for languages just because I don't think they will be needed. I guess my main reason though is that it's much easier for me to just update the entire set without needing to limit updates each time and in the scheme of things, I don't see 11MB as an issue given that one high resolution image upload might easily equal this. Keep in mind that none of these are loaded except those that are needed. Do you have a specific need to reduce it?

It's essential to my PW work as well so would definitely love to see it maintained, or at least some of its key features incorporated into the PW core which is probably the better approach. Maybe we should start a list of the features we all need and put together PRs for Ryan to get them into the core?

I use this to allow the use of include=all in the default selector in the config $this->wire()->addHookBefore('ProcessPageLister::getSelector', function($event) { $event->object->allowIncludeAll = true; });

Thanks @Robin S - very timely - I am making use of this in a custom frontend form today!

Absolutely - I was just thinking that the code for this feature that is in AOS might be useful in preparing the PR for the core.

Have you looked at how it's done in AOS? https://github.com/rolandtoth/AdminOnSteroids/blob/2e8f9c56dbc0d05edcb203d7dcf9af31eb862b02/AdminOnSteroids.module#L1159

Really rough, but gets the job done. You could easily put this into a function. This builds up the name of variation (assuming you want 330x330), checks to see if it exists and if it doesn't then we need to go old school and get the page object and image and generate the variation. Then next time the page is loaded, the variation will exist and we can display it with $imageUrl as the image src directly from the data returned by findRaw. if(count($p->image) > 0) { $imageOrigUrl = $config->urls->files. $p->id . '/' . $p->image[0]['data']; $path_parts = pathinfo($imageOrigUrl); $imageVarFilename = $path_parts['filename'] . '.330x330.' . $path_parts['extension']; $imageUrl = $config->urls->files . $p->id . '/' . $imageVarFilename; if(!file_exists($config->paths->files. $p->id . '/' . $imageVarFilename)) { $image = $pages->get($p->id)->image->size(330, 330); $imageUrl = $image->url; } }

I ended up doing a file_exists() on the image variation I am wanting to call (built from the returned filename) and if it doesn't exist, then get the full page and call the size on the image. This should only happen once until the reduced size is created and then we're back to being able to load directly from the raw data.

For further clarification, compare: to: Surely that indicates a bug?

Hi all, Is anyone else having issues with findJoin? If I try to join a checkbox it doesn't work at all and if I try to join a page reference field foreach($pages->findJoin('template=date', 'relationships') as $date) { d($date); } I end up with this which appears to be unusable: But if I do the old school auto-join (the checkbox in the field settings), then I get the expected: Can anyone confirm this behavior in the latest dev version? Or do you know what I am doing wrong? Thanks for any input!

Hi @Martinus - I am not sure what scenario would result in that but it might help if you can provide a screenshot to show this so I can see what options for Child Template are available. The error suggest that there are none, but not really sure how that would happen unless you have the page locked down so that there are no allowed child templates. Actually, you should check the family settings for the template of the parent page to confirm that as well.