RyanJ

This is an old thread, but I have searched hours for an answer to the same question. I am really surprised I could not find something about this, so I will post how I achieved this. I want to update a specific row in for my pro table field. So in my case, I have added the row id as a hidden input foreach ( $page->getUnformatted('my_table_field') as $item ) { $item->id; //get the id of the row to use in hidden input; } //update part $page->of(false); $update_row = $page->my_table_field->get("id=$id"); $update_row->title = $title; $update_row->description = $description; $page->save('my_table_field'); $page->of(true); I am curious if anyone sees any issues with this approach for if there is a better way doing so.

@Entil`zhaand @wbmnfktr Thanks, confirmed that was the missing piece. Thanks for the details and much appreciated.

@flydevThanks, but still getting the same: Verified its installed: wirecli/wire-cli 1.4.11 An extendable ProcessWire command line interface Command: wirecli -help Output: wirecli: command not found

Looking forward to using this, but I am running into issues. What am I missing? After installing globally, I get Using version ^1.4 for wirecli/wire-cli Then when I try an run it. wire-cli: command not found

Same issue creeped up yesterday. There is an open ticket for it here. Details are in the ticket.

@FlorianA I know your question is a bit old, but I just recently had to do this and below is how you get the form data. In my case, I put it all in a custom module. Gets called after an update is made at /admin/profile/ public function init() { $this->pages->addHookAfter('ProcessProfile::execute', $this, 'sendOutProfileNotification'); } public function sendOutProfileNotification(HookEvent $event) { $event = $event->object; //form data is found in $data = $event->return; //do something with data here is data is not null. } Hope that helps.

Just in case anyone else runs across this topic. I finally found the culprit. It was the Seo Maestro module which was trying to generate a sitemap. Reading the docs (which I apparently overlooked) states that this could be an issue on large sites. I ended up bootstrapping the module to render the sitemap, so it has no affect on the cms side of things. Great module by the @Wanze

Hi @kongondo In reference to this feature here. Is there a way to indicate to the user which image they are replacing or if they are even replacing an image on upload?

An update to this. As @adrian suggested, I tried out one of the db clusters at DO. I updated the storage engine from MyISAM (I could not import the MyISAM version anyway) to innoDB and did a fresh import. From the image above you can compare. Box 2 - Frontend PHP 7.4, MySQL 8 Box 2 - Admin This I can work with. Cheers!

I am also seeing serious performance issues when migrating to MySQL 8. I am not sure if this is particularly related to Digital Ocean. I think @Lutz has solid concerns. Just some stats on my testing. Two servers, both running on nignx. Box 1 is on a shared hosting environment and Box 2 is on DO. Using TRACY, you can see the difference below in execution time on same pages. The sites are replicas of each other. The execution time is from a front-end page that is using the matrix repeater to render layout items. Even a page with one matrix repeater has as significant difference Box 1 (440.8ms) - Box 2 (1039.4ms). Interestingly enough, pages not using the matrix are faster on both frontend and backend on Box 2 (125.6ms) - Box 1 (249.5ms). Admin pages with matrix items are also significantly slower on load. Box 1 - Frontend PHP 7.3, MySQL 5.7 Box 2 - Frontend PHP 7.4, MySQL 8 Box 1 - Admin Box 2 - Admin

Hi @szabesz Thanks for checking back in. No, I have not. I want to determine that is the cause before reaching out to Ryan. I would agree with you and would be surprised that the number of pages is the issue. I can't rule anything out at this time. There is no blaming the system, I am just trying to determine the issue. I am curious if the admin pages are cached at any point.

@szabesz Thanks for the suggestion. Bumping up the execution time is only a short term solution. I need to figure out why its crashing the entire admin. I am having a hard time believing PW can't handle this data load. Not to mention the site is only going to grow in pages, so I need to ensure it will scale. My fear is that it maybe related to the Repeater Matrix or repeaters overall, but I just don't know yet. Does anyone know if the admin pages are cached? It is strange to me that sometimes I can get it to work, then others it just times out. My next steps are to blow away all the data and try to piece my import in and see where the bottle neck occurs.

I have quite the pickle. The admin no matter where I am at in it, times out constantly. I either get a 504 gateway or and execution timeout. I am banging my head why its across the board. The frontend of the site works great. The site does have a lot of pages, 164,889 to be exact. Most of that is due to image pages created by media manager and having repeater matrix installed which is used on most of the pages. For some reason, if I can manage click the "Clear file compiler" without it timing out, the site perks back up and I can access the admin again and it is quite speedy. However if I walk away leaving the browser sitting for about an hour and come back, I have to start the process all over again. The site has 52 various fields. Not every field is assigned to every template. a lot of the fields are used by the matrix to create a page builder. I can't accept that PW can't handle such. I have other sites that run triple the amount of pages, but don't rely on the matrix to build the layout. I have disabled any custom module that I thought could possibly cause an issue. I have overwrote every module and the wire core thinking something may have got corrupted. I guess my next step is starting with a fresh install, but I thought I would reach out to see if I am missing something. Some background on pages: All the pages are imported using the command line which bootstraps PW and uses the api. This is a dev site, so I blow away the pages if I need to reimport them, until I get it correct. PW Version 3.0.172, PHP 7.3, Innodb 5.7.27-30. I appreciate any suggestions or thoughts.

Hi @kongondo Thanks for getting me in the correct thread. I am not sure how I managed to get lost. I think role based would be useful, but I url segments would work for sure. The restriction would be based off the "Parent Page", so Location A and any child pages of Location A being edited, would only get Location A images. Maybe disabling filtering could be an option to not allow the client to filter on different images other then what is in the url segment. The same concept would need to occur if they added a new image as well. It would automatically get tagged or whatever is used for filtering the images. So and uploaded image would be tagged "Location A" if they are on the Location A page or any child pages. Thanks for the prompt response and taking the time to have a look at what I am trying to achieve. Much obliged and Cheers!

Hi @kongondo Wow, I am all discombobulated. This was meant to go under the media manager. My apologies.