adrian

Thanks @Robin S for the report and fix. It's in the latest version.

Sorry @LAPS I am not sure what to suggest - maybe there is a Netbeans forum or maybe StackOverflow where you could ask about it?

Maybe something useful in one of these? They aren't Netbeans specific but seem to explain how to configure custom ones. https://superuser.com/questions/548119/how-do-i-configure-custom-url-handlers-on-os-x https://stackoverflow.com/questions/471581/how-to-map-a-custom-protocol-to-an-application-on-the-mac or maybe you could use this as a starting point to write one for Netbeans? https://github.com/inopinatus/sublime_url

@LAPS - it looks like it should be: netbeans://open?file=%file&line=%line I am basing that on this project for Linux: https://tracy.nette.org/en/open-files-in-ide

Hi @virtualgadjo - it's only one language at a time IIRC. The problem with multiple is how to arrange the data in the export. Different users will need different layouts so it's best to generate these sorts of exports yourself. I tend to use AdminActions to create these sorts of custom imports.

You might find this a better approach: https://processwire.com/blog/posts/pw-3.0.173/

Maybe - I was using fpm with 8.1

Interesting. I am pretty sure I was testing this feature on my local dev which was running 8.1 at the time, but great to hear it's now working for you regardless. I no longer have access to the dev tools support board so I can't test the latest version of the module - maybe there were multiple issues?

findOne()

Nah sorry, I gave up :)

PR for the above change submitted: https://github.com/processwire/processwire/pull/255 although I expect Ryan might have a more complete solution, but at least that will hopefully get this issue on his radar.

Yep of course - sorry about that. Done now.

@LAPS - I can't reproduce here, but it looks like it's related to a pages find selector in your Hanna PHP code - can you share that?

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.