thei

#2106 solved

OK - i opened an issue

Hi, thank you for your response and your "tricky" smart ideas 🙂 With halting the process / dying i was in doubt if this would lead to some side effects. But injecting an fake HTTP header would be more save - i guess.

Hi Brodie, Do you know their problems in more detail? Have you some knowledge how they want to maintain their sites? i would prefer to implement sufficient different roles to enable people to maintain their own scope of interest/responsibility. So that everybody who has a natural interest to keep it up to date can do it by himself. Which features and media will you support for a rotary? May be It would be good to create a typical "rotary basic structure" for the content? Will they accept your product? 🙂

The problem could be solved by modifying ProcessController->isAjax() i.e. in wire/core/ProcessController.php In case of Htmx as well in case of ajax this method should return true. More flexible: when ProcessController would delegate this to its Process object (and the parent Process class would provide such a method by default) than a module could override the default implementation isAjax(). And ... since this is no longer related to ajax only but decides between a direct output of content or embedding the output in a admin page the method should be named to needsDirectOutpput() or similar. context: $config ->ajax is set in the ProcessWire instance by evaluating the http header HTTP_X_REQUESTED_WITH. It is used by admin.php to control an output buffer (ob_...) inbetween $ajax is overwritten by ProcessController->isAjax(). If true the output returned by the processes execute() is not embbedded in an admin page but output directly. In the current implementation ProcessController->isAjax() checks the http header in the same way like the ProcessWire instance. So this has no added value in the moment. It seems this is some sort of preparation for future plans. e.g. this works: in ProcessController.php (delegation to Process) public function isAjax() { return $this->process->isAjax(); } in Process.php (default implementation) public function isAjax() { return isset($_SERVER['HTTP_X_REQUESTED_WITH']) && ($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest'); } now this can be overridden by the modules class to enable htmx output Discussion: this is a "quick" solution. May be there is some kind of architectural snag: the decision whether something is to be embedded in an outer frame / page would belong to the view part e.g. in a "viewFile" instead of the modules main object - which acts as a controller in this context. If - alternatively - we want to handle the mode of output controlled purely on a protocol basis we should have something like $input->asynchProtocolType() which should return true in case of ajax, htmx and so on and should be hookable. So this is a question to the ProcessWire Masters here... 🙂

Hi, thanks for your response! But: meanwhile i found out... it's not possible ajax handling is processed in admin.php and only there the ProcessController instance is created. This controller has its own method isAjax() and gets the result directly from the http header. But there's no way to hook in here. so one has to modify the admin.php - which i want to avoid. i simply manipulated the $ajax with the debugger and it works except that tracy debugger pollutes the response with its own stuff.

When writing a process module the execute<name> methods output ... either is handled as the part of content embedded in a admin page ... or as output for an appropriate ajax-request (if ajax is detected while processing the incoming request by ProcessWire). When integrating HTMX this leads to an architectural problem: output of HTMX cannot be handled inside the modules process object (which can be seen as "controller") because it is handled as content and will be embedded in an admin page layout. One has to introduce a second route and a has to create a second Controller-Object to handle especially HTMX-responses. put on the wishlist: Processing the execute<name> methods should have something like an option to control processing the output (direct output and appropriate HTTP-headers) - not only ajax.

very nice. Thanx a lot!

HOW can i set this topic to "solved" ? ... there is no "solved" button. Hm, may be inserting in the topic title .... 😄

Thanks you very much for your help! i did some tests and found out: the only bad guy is 'template_id' (or 'template_ids'). Now i eliminated only this parameter and ran the whole bunch (including the "unnecessary parameters"). AND it works fine. I copied the code from the RockMirations Code field. i expected this generated code from RockMigration would be the correct code for setting up the fields. The generated code includes template_id => 0 and sometimes template_id => '' both cause a corrupted database.

The SQL error mentioned above is not related to RM. but here some testing that show the strange behavior when updating / creating repeater fields - may be this helps A) Situation: repeater field 'contact' exists, all caches cleared MariaDB [PW]> select id,name,data from templates where id = 51; | id | name | data | 51 | repeater_contact | {"noChildren":1, ... ,"modified":1727544508} | 1) running Config Migrations v6.7 with a ...fields/contact.php: | id | name | data | | 51 | repeater_contact | {"noChildren":1, ... ,"modified":1737381992,"_lazy":1,"_rockmigrations_log":"--- 2025-01-20 15:06:31 ---\n"} | | 68 | repeater_contact1 | {"noChildren":1, ... ,"modified":1737382002} | 2) remove contact.php and refresh: no changes 3) delete from templates where id=68; and then refresh: a new contact repeater field without Config Migrations having a contact.php | 51 | repeater_contact | {"noChildren":1, ... ,"modified":1737381992,"_lazy":1,"_rockmigrations_log":"--- 2025-01-20 15:06:31 ---\n"} | | 69 | repeater_contact2 | {"noChildren":1, ... ,"modified":1737382565} | 4) delete from templates where id=69; disable Config Migrations in Module Settings and then refresh: a new contact repeater field without Config Migrations active: | 51 | repeater_contact | {"noChildren":1, ... ,"modified":1737381992,"_lazy":1,"_rockmigrations_log":"--- 2025-01-20 15:06:31 ---\n"} | | 70 | repeater_contact3 | {"noChildren":1, ... ,"modified":1737382877} | ================================================================ B) Situation: repeater field 'contact' DOES NOT exists, all caches cleared 1) running Config Migrations v6.7 with a ...fields/contact.php: | 68 | repeater_contact | {"noChildren":1, ... ,"modified":1737383770,"_rockmigrations_log":"--- 2025-01-20 15:36:10 ---\n"} | | 69 | repeater_contact1 | {"noChildren":1, ... ,"modified":1737383771,"_rockmigrations_log":"--- 2025-01-20 15:36:11 ---\n"} | | 70 | repeater_contact2 | {"noChildren":1, ... ,"modified":1737383771} | Rock-Migrations Log entries: Trigger RockMigrations::migrationsDone --- config migration hook: afterData (0 files) --- /site/RockMigrations/fields/contact.php --- second run: migrate data --- --- config migration hook: beforeData (0 files) --- --- config migration hook: afterAssets (0 files) --- Tag: Name: contact --- first run: create assets --- --- config migration hook: beforeAssets (0 files) --- --- create PHP constant traits --- ### Running Config Migrations ### ### Migrate items with priority #1000 ### Running migrations from watchfiles ... Detected change in /site/RockMigrations/fields/contact.php -------------------------------------

imported production database, installed RM 6.5 and copied RockMigrations folder with fields and repeater fields files. So this is the first effect: PDO Error 1050

above i wrote "Even when i removed the Config Migrations files for these repeater fields these repeater fields have "doubles" in the template fields" i.e. i couldn't reproduce this effect (new repeater-field rows when repeater-field Config-Migrations file is moved away. But: a repeater field Config - Migrations file produces to an improper database when refreshing modules is clicked

at the moment i cannot reproduce the effect, when moving away 'contact.php' and the problem does not disappear.... Cache? i deleted the cache

<?php /* repeater field contact */ return [ 'accordionMode' => 0, 'allowContexts' => [ 0 => 'repeaterTitle', ], 'collapsed' => 0, 'columnWidth' => 100, 'familyFriendly' => 0, 'fields' => [ 'desc' => [ 'rows' => 1, ], 'role' => [ 'columnWidth' => 25, ], 'email' => [ 'columnWidth' => 25, ], 'phone' => [ 'columnWidth' => 25,], 'mobile' => ['columnWidth' => 25, ], ], 'flags' => 0, 'icon' => 'user-md', 'label' => 'Contact', 'lazyParents' => '', 'loudControls' => 0, 'parent_id' => 0, 'rememberOpen' => 0, 'repeaterAddLabel' => '', 'repeaterCollapse' => 3, 'repeaterDepth' => '', 'repeaterLoading' => 1, 'repeaterMaxItems' => '', 'repeaterMinItems' => '', 'repeaterTitle' => '', 'required' => '', 'requiredIf' => '', 'showIf' => '', 'tags' => 'address organisation', 'template_id' => 0, 'themeBorder' => '', 'themeColor' => '', 'themeOffset' => '', 'type' => 'FieldtypeRepeater', ]; <?php /* field 'desc' */ return [ 'collapsed' => 0, 'columnWidth' => 100, 'contentType' => 0, 'flags' => 0, 'htmlOptions' => '', 'icon' => 'sticky-note-o', 'inputfieldClass' => 'InputfieldTextarea', 'label' => 'Description', 'maxlength' => 0,'minlength' => 0, 'placeholder' => '', 'required' => '', 'requiredAttr' => '', 'requiredIf' => '', 'rows' => 5, 'showCount' => 0, 'showIf' => '', 'stripTags' => '', 'tags' => 'text', 'textformatters' => [ 0 => 'TextformatterEntities', ], 'themeBlank' => '', 'themeBorder' => '', 'themeColor' => '', 'themeInputSize' => '', 'themeOffset' => '', 'type' => 'FieldtypeTextarea', ]; <?php /* field 'role' */ return [ 'collapsed' => 0, 'columnWidth' => 100, 'flags' => 0, 'icon' => 'black-tie','inputfieldClass' => '','label' => 'Role', 'maxlength' => 2048, 'minlength' => 0, 'pattern' => '', 'placeholder' => '', 'required' => '', 'requiredAttr' => '', 'requiredIf' => '', 'showCount' => 0, 'showIf' => '', 'size' => 0, 'stripTags' => '', 'tags' => 'organisation', 'textformatters' => [ 0 => 'TextformatterEntities', ], 'themeBlank' => '', 'themeBorder' => '', 'themeColor' => '', 'themeInputSize' => '', 'themeInputWidth' => '','themeOffset' => '', 'type' => 'FieldtypeText', ]; <?php /* email */ return [ 'collapsed' => 0, 'columnWidth' => 100, 'flags' => 9, 'icon' => 'at', 'inputfieldClass' => '', 'label' => 'E-Mail Address', 'maxlength' => 255, 'minlength' => 0, 'pattern' => '', 'placeholder' => '', 'required' => '', 'requiredAttr' => '', 'requiredIf' => '', 'showCount' => 0, 'showIf' => '', 'size' => 0, 'stripTags' => 1, 'tags' => 'communication', 'textformatters' => [ 0 => 'TextformatterEntities', ], 'themeBlank' => '', 'themeBorder' => '', 'themeColor' => '', 'themeInputSize' => '', 'themeInputWidth' => '', 'themeOffset' => '', 'type' => 'FieldtypeText', ]; ~ <?php /* phone */ return [ 'collapsed' => 0, 'columnWidth' => 100, 'flags' => 0, 'icon' => 'phone', 'inputfieldClass' => '', 'label' => 'Phone', 'maxlength' => 2048, 'minlength' => 0, 'pattern' => '', 'placeholder' => '', 'required' => '', 'requiredAttr' => '', 'requiredIf' => '', 'showCount' => 0, 'showIf' => '', 'size' => 0, 'stripTags' => '', 'tags' => 'communication', 'textformatters' => [ 0 => 'TextformatterEntities', ], 'themeBlank' => '', 'themeBorder' => '', 'themeColor' => '', 'themeInputSize' => '', 'themeInputWidth' => '', 'themeOffset' => '', 'type' => 'FieldtypeText', ]; <?php /* mobile */ return [ 'collapsed' => 0, 'columnWidth' => 100, 'flags' => 0, 'icon' => 'mobile', 'inputfieldClass' => '', 'label' => 'Mobile', 'maxlength' => 2048, 'minlength' => 0, 'pattern' => '', 'placeholder' => '', 'required' => '', 'requiredAttr' => '', 'requiredIf' => '', 'showCount' => 0, 'showIf' => '', 'size' => 0, 'stripTags' => '', 'tags' => 'communication', 'textformatters' => [ 0 => 'TextformatterEntities', ], 'themeBlank' => '', 'themeBorder' => '', 'themeColor' => '', 'themeInputSize' => '', 'themeInputWidth' => '', 'themeOffset' => '', 'type' => 'FieldtypeText', ]; ~ when i put the files shown above in RockMigrations/fields and click module refresh... | 51 | repeater_contact | {"noChildren":1,"noParents":1,"slashUrls":1,"pageClass":"RepeaterPage","noGlobal":1,"compile":3,"modified":1736510539,"_lazy":1,"_rockmigrations_log":"--- 2025-01-10 13:02:19 ---\n"} | | 77 | repeater_contact7 | {"noChildren":1,"noParents":1,"slashUrls":1,"pageClass":"RepeaterPage","noGlobal":1,"compile":3,"modified":1736933902,"_lazy":1,"_rockmigrations_log":"--- 2025-01-15 10:38:22 ---\n"} | | 79 | repeater_contact8 | {"noChildren":1,"noParents":1,"slashUrls":1,"noGlobal":1,"compile":3,"modified":1736933910,"_rockmigrations_log":"--- 2025-01-15 10:38:30 ---\n"} | | 80 | repeater_contact9 | {"noChildren":1,"noParents":1,"slashUrls":1,"pageClass":"RepeaterPage","noGlobal":1,"compile":3,"modified":1736933916} |

Thanx for your quick reaction. Hm, "steps" i installed 6.5.0 (previously a had an old version (5.2..?) installed) i copied the code from the RockMigrations code field to set up the files using fieldname as filename in RockMigrations/fields. e.g. 'label.php' below <?php return [ 'collapsed' => 0, 'columnWidth' => 100, 'flags' => 0, 'icon' => 'bookmark-o', 'inputfieldClass' => '', 'label' => 'Label', 'maxlength' => 2048, 'minlength' => 0, 'pattern' => '', 'placeholder' => '', 'required' => '', 'requiredAttr' => '', 'requiredIf' => '', 'showCount' => 0, 'showIf' => '', 'size' => 0, 'stripTags' => '', 'tags' => 'text', 'textformatters' => [ 0 => 'TextformatterEntities', ], 'themeBlank' => '', 'themeBorder' => '', 'themeColor' => '', 'themeInputSize' => '', 'themeInputWidth' => '', 'themeOffset' => '', 'type' => 'FieldtypeText', ]; i remember i did some changes via GUI and did not update the appropriate field file. At the moment i have no idea how/where to start with debugging RockMigrations

i started to use Config Migrations in an existing processwire application. In directory site/RockMigrations/fields i created all the files defining the fields. Up to now i created only two templates (i.e. 2 of 15 but this shouldn't matter) in the appropriate templates folder - so far. yesterday my database crashed after clicking the admin modules page - a PDO Error 1062 / duplicates... so i did some research in the database. i found the templates table contains something like duplicated repeater field rows - the field 'contact' has some duplicates with same name followed by numbers 'contact8' 'contact9' etc. I could repair the database by deleting these strange rows. When i click on module refresh, some new repeater field rows will be created. The crash seems to be a rare case. Such rows can exist and the application still works in some way but some content of repeater fields is missing on pages. The problem occurs with repeater fields only. Even when i removed the Config Migrations files for these repeater fields these repeater fields have "doubles" in the template fields. When i switch of RockMigrations this behavior disappears. RockMigrations 6.5.0 / PW 3.0.227

Hi, i'am new with FrontendForms. I use v2.2.16. When i set custom classes it is ignored. When i define a framework as described i can select it in the settings and save the config. But nothing happens. The class names i see in the generated html are always the same generic names e.g. fieldwrapper etc. So, i can write by my own a class "fieldwrapper" and it works - sure. But this is - as far as i understood the documentation - not the intention of framework files: to be without effect. Where do i get it wrong? Or is there a bug? Thank you for your help

Ah! i see. It's the keyword 'options'. In my example i used 'text'. I just tested it and it works using when 'createField()' - great! Thank you!!

Thank you! This way - using 'migrate' instead of 'createField' - it works.

i'm using Rockmigrations the first time. I copied field settings (Rockmigration Code) from an Processwire site in the migration.php of a new Processwire environment. It works fine except for one options field: it throws Fatal error: Uncaught Error: Class "ProcessWire\SelectableOptionManager" not found in /var/www/html/app/site/modules/RockMigrations/RockMigrations.module.php on line 4144 here is the code $rm->createField('country', 'text', [ 'collapsed' => 0, 'columnWidth' => 100, 'defaultValue' => '', 'flags' => 0, 'icon' => 'flag-o', 'initValue' => '', 'inputfieldClass' => 'InputfieldSelect', 'label' => 'Country', 'options' => [ 65 => 'Germany', 120 => 'Namibia', 1 => 'Afghanistan', 2 => 'Albania', 3 => 'Algeria', 4 => 'Andorra', 5 => 'Angola', 6 => 'Antigua and Barbuda', 7 => 'Argentina', 8 => 'Armenia', 9 => 'Australia', 10 => 'Austria', ...etc... ], 'required' => '', 'requiredIf' => '', 'showIf' => '', 'tags' => 'address', 'themeBorder' => '', 'themeColor' => '', 'themeInputSize' => '', 'themeInputWidth' => '', 'themeOffset' => '', 'type' => 'FieldtypeOptions', ]); I do not understand what the problem is with the options field Thanx for ideas and help 🐵

Hi BitPoet, YES indeed it works. Thank you very much!! Nevertheless this case should be handled inside PW rather than checking for $page in the user defined hook. HM... what is the further procedure here. Should i report a bug? Where? Otherwise: the guideline here in this forum says, i should mark this as 'soved' by clicking the 'mark-as-solved' button. BUT there is no 'solved-button' displayed here ?

what is the procedure now? should i write a bug report? i guess here https://github.com/processwire/processwire-issues/issues ? Thank you for your help ?

hm. if i download the latest stable i get a 3.0.227 (cannot find a 228) with 3.0.227 still the same behavior. OK found 229. same problem.

but for a repeater field the page object is of class RepeaterPage. Using ->template returns 'repeater_....' which is not the name of the embedding page. The documentation of RepeaterPage describes a getForPage