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.

Hi Kongondo, Hope your well. After looking through this thread, I am not seeing anything specific to my question. So I am dropping it here. To better explain what I am trying to do, I will give a brief structure of my site. I have a directory which contains multiple locations as parent pages. Each location can have multiple child pages. Location and child pages contain a media manager field which currently pulls in all images allowing the user to select from those. What I am looking for is restricting images based off the location page and or child pages of that location that is being edited. Example: I am editing Location A or any child page of Location A and when I click "Add media", the run time hook would restrict/filter the list of available images that have been tagged as Location A. If a tag wont work, maybe a custom field. Is there some sort of hook to achieve this functionally? Thanks for your time.

Hi kongondo, Thanks for the quick replay. Your solution seems to work. I do have a follow up regarding tags. I am unable to successfully return images with the getTag() or findTag() methods that are available. Am I misunderstanding something? Media Manager Field. Returns empty string $test = $theme_options->media_manager->getTag("MainNavLogo"); Default Image Field Returns ProcessWire\Pageimage $test = $theme_options->images->getTag("MainNavLogo"); Thanks for your time.

Hello, Good to be back developing in ProcessWire, but I must admit I am a little rusty. Just installed version 012 on a fresh install of PW version 3.0.165 and getting the following errors when trying to edit the uploaded image page under Admin -> Media -> Manager. Whats also odd is when trying to upload at Media Manager -> Upload, the file appears to upload, but does not show up in the Images/All tab nor does the preview show up. On some occasions the file name is present, but others it is not. I ran the check field data with no issues reported and also uninstalled and reinstalled. What am I missing. Running php 7.4.3 and Mysql 8

This post has a perfect solution if anyone else need it. I will be glad to share my code if needed.

I am looking for a clean way to remove the "Media Manager" pages from the top search in the admin for a certain user role. When searching, these pages are being returned and confusing the user that they can edit them instead of using the Media Manager tool. Attached is an image to help describe what I mean. Make note of the page types "Media Manager: ect" I was thinking a hook using ProcessPageSearch? Any thoughts or suggestions are appreciated. example

Typo. Its fixed now.

Simple $var = $page->getUnformatted('field_name'); foreach ($var as $v) { //your markup //table column name $v->column_name }

Hello! Looking for a bit of advice or suggestions here. I don't claim to be a nginx expert, but I have PW version 3.0.62 powering an app running on a cloud server with nginx. Everything operates fine for the most part, but from time to time I am getting a network error message when trying to navigate in the admin or just a plain ole 500 error. Specifically when logging in initially and trying to view the page tree. A pop up window appears with the network error message (I will grab a screen shot next time I see it). Also when navigating through the admin I get random 500 errors. php 5.6.x nginx cloud hosting service A couple of corresponding logs below. Error log in pw admin: Error: Cannot instantiate abstract class ProcessWire\ProcessPageListRender (line 331 of /xxx/xxx/xxx/wire/modules/Process/ProcessPageList/ProcessPageList.module) Nginx Error log: 017/05/12 10:11:47 [error] 7305#0: *14305329 readv() failed (104: Connection reset by peer) while reading upstream, client: xx.xxx.xxx.xxx, server: theserver, request: "GET /login/page/ HTTP/1.1", upstream: "fastcgi://unix:/xxxxx/dev/.php-fpm.socket:", host: "thehost", referrer: "http://domain/login/setup/logs/view/errors/" 017/06/21 14:15:29 [error] 29093#0: *106631997 readv() failed (104: Connection reset by peer) while reading upstream, client: xx.xxx.xxx.xxx, server: server, request: "GET /login/page/edit/?id=1489 HTTP/1.1", upstream: "fastcgi://unix:/xxxxx/dev/.php-fpm.socket:", host: "thehost", referrer: "http://domain/login/page/" Thanks for your time.

Just used this module with pw version 3.0.62 and it works just fine.

$pages->addHookAfter('saveReady', function($event) { $pages = $event->object; $page = $event->arguments(0); //check if on template if($page->template == 'item') { //is the checkbox checked to add children if ($page->add_children == 1) { //get the values in the page field type field foreach ($page->page_assignment as $child) { //if selected pages have childen if ($child->numChildren > 0) { //loop through those children foreach ($child->children as $grandchild) { //set values. $page->page_assignment->add($grandchild); } } } } } I figured it out. Two things to change if anyone is looking to do the same. 1. Use the right hook. saveReady instead of save. 2. Add the page object. $page->page_assignment->add($grandchild);