MarkE

I'm obviously being a bit dim, but I'm not sure how this is supposed to be implemented. I already have a hook on getSelectablePages, using this code. Are you suggesting something different, or if not, how does this play with your module?

Just came across this thread - very useful: Not sure why it is not documented, unless there are risks using it. It really should be documented IMHO. @OLSA's solution for repeaters was particularly helpful and was (almost) what I needed for my use case. My case was complicated by the successive pages not being children of the previous selection - the last page reference was a repeater matrix item, not a child. In my case, however, the 'blendFrom' page reference is a repeater stage in the Cider/Juice page, not a child of it, so parent=page.cider{suffix} does not work. My solution was to add (via a before save hook) a field 'parent_page_id' to the repeater matrix item, which is the id of its getForPage, and use the selector "template=repeater_stage, parent_page_id=page.cider" where 'cider' is the field in the previous page selector. Ideally, I would have liked to have used 'parent.name$=page.cider', as that would avoid the use of an extra field, but although that seems to work fine normally (in Tracy console, for example), it does not seem to work in this context.

@Pete - the module has been working trouble-free for the last 2 years. I’ve pretty much forgotten the details, but will look into it when I have a mo. Funnily enough, I may have another app when I might want to use it - but I’ll look at @adrian’s solution as well. Mailgun would be good for the first app also, but not the second, so that’s a useful lead too, thanks.

I'm definitely meaning to 'weigh in'. I think this is a really important topic - possibly the most important one for the future development of PW, maybe alongside the pagebuilder. However I'm really buried in a complex app at the moment and don't have time to fully consider all the issues. First off, regardless of the merits of my particular module, I do think that the help file explains some of the functionality that I think is important. In particular, the approach is completely declarative and UI-based - it neither requires coding nor a clean start (it can be installed in an existing system). I encountered a number of issues in building the module this way that others should be aware of - for example that ids can vary between the development and target environments - but I think any other approach reduces the scope of application. As regards the status of ProcessDbMigrate, I have been using it quite successfully in a moderately complex live app (there are some bug fixes and improvements pending for the released version) but really wanted to try it out in the app referred to earlier, which has complex fieldtypes (e.g. my FieldtypeMeasurement) and many pro fields. I hit a snag with nested repeaters which needs attention once I have finished the app. I don't see ProcessDbMigrate as the solution however, but I do think it demonstrates a lot of the required functionality (it creates json not yaml files, but that's not a big difference). I see it as a partial prototype. Aside for any snags like that mentioned, I do not like the profusion of templates and fields which clutter up the admin. As to a way forward, I think a collaborative development of requirements and spec would help and then some agreement on who and how to build it. I also really think that a contribution to this discussion from @ryan before proceeding would be most helpful. I'll try and return with some more detailed thoughts once I get this app done!

Just came across this - @evan's solution works, but I can't believe there is no 'label' method or property.

Further info (in what seems to be a monologue so far ? ) What is actually happening is that PW is opening TWO modals when I double click the item. The HTML looks perfectly OK - e.g. (from developer tools after PW has applied its classes etc.) <div id="pw-edit-modal-1017-100-104-107-113" class="pw-modal pw-modal-dblclick pw-edit-modal" data-href="/processwire/page/edit/?id=1017&amp;fields=weight,volume,gravity,acidity&amp;modal=1" data-fields="weight,volume,gravity,acidity" data-buttons="button.ui-button[type=submit]" data-autoclose=""> <p><span style="font-weight: bold">Default units: </span> Weight: pound , Volume: litre , Gravity: SG , Acidity: ppt malic</p> </div> The work-round is just to close one modal and then work in the other one, but why is it happening ....? SOLVED (sort of) Something was wrong in my front-end template - possibly mis-matching div tags. Code double checked and all ok now

A bit more info. In fact the first save is OK, but returns to the modal with the original value. If I just close the modal (i.e do not change and re-save) then the change has been made. I have no idea why it returns to the (unchanged) modal rather than the FE page - poking around in FEE but no light yet. I also notice that if I click the close x immeditelay after loading the modal, the background lightens and then any changes (followed by clicking 'save') are taken and the modal closes. Seems like something to do the the js, but still in the dark

I suggest you try the simple thing first: Replace <a><?php echo __("Ver detalle"); ?></a> by <a><?php echo \ProcessWire\__("Ver detalle"); ?></a> Let me know if that works - then I know we have the same namesapce issue as I have already reported

The namespace issue still seems to be unresolved. I think that is also related to this. I would be grateful for any comments on the GitHub issue I raised and whether I should just raise a PR to get @ryan’s attention?

The hack in the quoted post is quite simple @Krlos - you may wish to try it and see if it fixes your problem. If not, you can revert. Or you could just try \ProcessWire\_(“….”)

Github issue opened at https://github.com/processwire/processwire-issues/issues/1502 Suggested fix is to amend the regexes in $sanitizer->float() to not remove 'E-', 'E+', 'e-' or 'e+', but I have (yet?) to devise a suitable regex. If anyone is a regex whizz then please save me some head-scratching ? EDIT: I have also suggested, in the GIthub, a simple fix to deal with the internally-generated scientific notation that causes the InputfieldFloat problem. That's what I'm using for now, otherwise I consider InputfieldFloat is unsafe for live use! (I appreciate that may sound a bit dramatic, but I cannot risk major calculation errors).

Will do @Jan Romero. I'm pretty sure that the problem is with $sanitizer->float() since hacking that to just return (float)$value fixes the problem with float fields.

This might possibly be connected with an issue that I raised here https://github.com/ryancramerdesign/ProcessHannaCode/issues/26 and here but I haven’t received any response

If I have a float or double field in the Admin with a value such as -0.00001253 then saving initially shows this as -1.253E-5, which is fine, but saving again changes it to -1.2535 (v3.0.184 and 3.0.190) In my FieldtypeMeasurement module I have fixed this (in a not yet released version) by using a text field and using (float)$value in the wakeupValue rather than $sanitizer because $sanitizer->float($value) returns -1.2535 from -1.253E-5. Is this a bug or is there something subtle that I don't understand here? It seems to me that InputfieldFloat may be using $sanitizer->float() which does not convert the scientific notation.

For some reason, in the new site I am building, every time I use the front-end editor on a field, I have to save the changes twice - the first time just reloads the module with the previous value. I've not come across this before. I disabled hooks and auto-save but it still happens. Any ideas?

https://processwire.com/modules/inputfield-runtime-only/ ?

Is this what you want?

Added the inputfield renderValue() method, wich may be required if the rendered output when the field is locked. (Otherwise, for example in my FieldtypeMeasurement module, a locked field just displays the class name).

Page (Autocomplete Single) works very nicely. Thanks @Robin S. Just one thought - is it possible to add 'selectOnce' to the existing hints under the settings box - no worries if not, just "a nice to have".

Just what I need for a current project. Brill!

Import/Export has a number of problems and fails to deal with some field types properly. Not wishing to detract from RockMigrations, which is excellent, but there is also my module ProcessDbMigrate. It is different in concept in that it is UI-based rather than code-based. It does handle 'uninstallation' of migrations and also database comparisons, but there are some features of RockMigrations that it does not have. In it I used some code from Import/Export but ditched or fixed quite a bit.

Sorry @Robin S- it was late at night and the error only happened after I installed ConnectPageFields. On closer inspection this morning, it seems that the error might have been caused by something else. Will report back. EDIT: The problem seems to be with Repeaters, not ConnectPageFields. Not pursued this further as my solution was to use hidden visibility (which does not cause errors) together with another excellent little module: FieldtypeRuntimeOnly to display the hidden field in a non-editable way, with the link back ?

This is a real go-to module - I have used on almost every site! Today maybe I was trying to be a bit too clever and have one of the fields locked (visibility: Open when populated + Closed when blank + Locked (not editable)). I just want the back-link to be viewable, not editable. However, this threw up a fatal error: Too few arguments to function ProcessWire\RepeaterPageArray::__construct(), 0 passed in M:\laragon\www\Cider\wire\core\WireData.php on line 438 and exactly 2 expected search► Is there any way of doing this? I guess I can restrict access for certain user types - is that the only way?

Thanks muchly @BitPoet! The first was rather obvious - should have spotted that! The second was more subtle. Inspecting the php.ini from the laragon panel, it looked ok. Opened it directly in an editor and the extensions clearly weren't enabled. Odd, but all working now, thanks.

Since it looked like others have successfully upgraded to PHP 8, I decided to give it a try. I use Laragon on the dev machine so started with that. Succesfully added PHP 8.0 and got Apache running OK. Tried two sites which noth returned similar fatal error messages: Site 1 Fatal error: Uncaught Error: Undefined constant "ProcessWire\HTTP_HOST" in M:\laragon\www\processwire\site-ncog\config.php:191 Stack trace: #0 M:\laragon\www\processwire\wire\core\ProcessWire.php(1246): require() #1 M:\laragon\www\processwire\index.php(33): ProcessWire\ProcessWire::buildConfig('M:/laragon/www/...') #2 {main} thrown in M:\laragon\www\processwire\site-ncog\config.php on line 191 Site 2 Breaking news… Fatal Error: Uncaught Error: Undefined constant PDO::MYSQL_ATTR_INIT_COMMAND in M:\laragon\www\BawdHall\wire\core\WireDatabasePDO.php:240 #0 M:\laragon\www\BawdHall\wire\core\ProcessWire.php(514): WireDatabasePDO::getInstance(Object(Config)) #1 M:\laragon\www\BawdHall\wire\core\ProcessWire.php(313): ProcessWire->load(Object(Config)) #2 M:\laragon\www\BawdHall\index.php(52): ProcessWire->__construct(Object(Config)) #3 {main} thrown (line 240 of M:\laragon\www\BawdHall\wire\core\WireDatabasePDO.php) Reverted to PHP 7.2 and all is fine. Both sites are on PW 3.0.184 and are in (separate) multi-site installations. Any suggestions? Thanks.