Module Batch Child Editor

[adrian]

@virtualgadjo - does that error happen every time you try to unpublish them all or did it only happen once like this?

Is "weekendatbinnys-champagne-tasting" a field or child page name?

Is ID 1019 a language page?

 

 

[virtualgadjo]

Hi @adrian

it happens every time i tried (actually, the first time, it was my client who ran into the error and called me asking what he could have done wrong ? )
even both ways, publishing and unpublishing, after having added my custom admin action and i tried many times before and after

"weekendatbinnys-champagne-tasting" is a page name name1019 the default language name of the page (website with six languages...)
i've tried changing the name in english but, same result

of course every child page has a different name but the name is only set in the default one (english), running

select count(name1019) as dups, name1019
from pages group by name1019 having count(name1019) > 1

returns an empty result

what's funny is that the website is now 5 years old and the client has already used the batch child 4 times without any alert (i've tried with the last release of your module but it didn't change anything)
what was interesting to me was that once i've unpublished all the children with my action, trying to publish them back, i only worked with the hidden one, no displayed error but funny result... and it's the first time the client hid some pages during the events announcement without unpublishing them, up to this year he just unpublished the events before launching the next harvest ?

have a nice day

[adrian]

I'm at a bit of a loss at the moment - I can't replicate the original error and I can't replicate any weirdness with hidden page behaving differently when publishing/unpublishing. I feel like it's due to something in here: https://github.com/adrianbj/BatchChildEditor/blob/9cdf3b7f317d9f8c07bc75faf150e5ba9490dfb6/BatchChildEditor.module.php#L1348-L1355 but not really sure why if page titles / names aren't being changed at the time you are unpublishing. Can you check to see if this section of code is being called and maybe dump the value of $name for all the child pages in the loop to see if there are indeed any duplicates at this point?

[virtualgadjo]

Hi @adrian
thanks a lot for the tip; i'll have a close look at this piece of code but right now, having a look at this name/title thing i may have an idea
those page are created by the api when validating an event and each one has a different name but ha has used the same title for many events and it looks like language names, well, the default language one in fact, in changed after the page title and the creating duplicates before running the action

i will try restoring the original db but unchecking the overwrte page name checkbox to see if it changes something

that's where the admin custom action doesn't run into any issue as it just targets the template, no matter the names, titles or whatever else...

have a nice day

[virtualgadjo]

Hi again @adrian,

just tested it, i restored the db, unchecked this overwrite names checkbox

and... it worked! it was looking at the snippet you pointed me to that i had this idea, thanks again ? ? 

have a nice day

[adrian]

Hi @virtualgadjo - I am glad unchecking the overwrite names option solved things for you. I dug into that section of code and discovered an issue with duplicate titles (when both set during a batch update) and fixed that in the latest version. I don't think this change will help what you were seeing - I think that is something ML that I haven't been able to reproduce, but at least I found and fixed something else :)

[virtualgadjo]

Hi @adrian

i'm happy to "hear" my little post was at least useful for something ?
i thought the issue i ran into was due to those pages with the same title and no names for 5 out of 6 languages but couldn't really understand where to dig more...

i'll update the module in the website but you know, i'll keep my custom admin action as for the client, he won't have to wonder about all the other columns meaning and will continue to use the batch child editor he really likes to export a csv of all those pages and keep track of its events historry ?
this way, whatever he does with those "pages", targeting their ids won't be impacted

i'm must say those pages are a little special as i don't need a name for each language, they are pages as everything in pw but actually mode data sets i use to fill a json where to get a leaflet map markers position and popup big content and even if i create those page with a really unique name, if ever he changes their title and, why not, names afterwards even if not useful, it may generate the problem you've just fixed

thanks again and a lot for your time and help (and of course modules ? )

have a nice day

[MarkE]

Hi @adrian. Is there any reason why, in the batch child editor, 'edit' opens in a modal but 'view' opens with a new tab. I would prefer consistency (with view opening in a modal) and have done a simple hack to replace the link (target="_blank") with a modal link (class="pw-modal") but obviously that is not a good answer. I appreciate that changing it might upset others (and there may be a good reason why you did that way). Perhaps it could be configurable (panel, modal , new) as in the main page edit?

[adrian]

Hi @MarkE - this was all done a long time ago before the pw-modal class was available, but the key reason a modal makes sense for editing is that any changes you make while editing in the modal are applied immediately in the row of child page in the table of children once the modal is closed, so I don't think it makes any sense to have different window opening options for editing. 

But for viewing pages, I always thought that would be better in a new tab, but I suppose a modal or panel might be preferred sometimes, so what about this solution which matches the default behavior of PW's page list action buttons by allowing you to open in a modal with a long click, but still open in a new tab so you don't accidentally lose any changes to other pages in the child editing table?

$cp->viewable() ? ' <a class="pw-modal pw-modal-large pw-modal-longclick" href="'.$cp->httpUrl.'" target="_blank"><i style="cursor:pointer" class="fa fa-eye"></i></a>' : '',

Just playing around with this and for some reason the pw-panel class doesn't work, but pw-modal does. Maybe it's not being loaded for some reason in modules.

[MarkE]

15 hours ago, adrian said:

so what about this solution which matches the default behavior of PW's page list action buttons by allowing you to open in a modal with a long click

I guess that makes sense but is not fully consistent with page list which would require a long click for modal edit too.

15 hours ago, adrian said:

but still open in a new tab so you don't accidentally lose any changes to other pages in the child editing table

I'm not sure I understand that - I can't replicate it. In what circumstances is it a problem?

[adrian]

On 10/23/2024 at 10:36 AM, MarkE said:

I guess that makes sense but is not fully consistent with page list which would require a long click for modal edit too.

Understood, but I think the default should be modal to be in the spirit of editing child pages in the one place without opening a page in full.

On 10/23/2024 at 10:36 AM, MarkE said:

I'm not sure I understand that - I can't replicate it. In what circumstances is it a problem?

If you have edited the fields or statuses within the children's table and not saved, and you open a child to view you would lose those changes - hence the need for new tab or modal.

[MarkE]

47 minutes ago, adrian said:

If you have edited the fields or statuses within the children's table and not saved, and you open a child to view you would lose those changes - hence the need for new tab or modal.

Just been playing with this. If I edit a field in a child (in a modal) and click 'save' within the modal, then re-edit the child in a modal without saving the parent, then it seems like the change is not saved, regardless of any viewing that might or might not have taken place.

In detail:

1. If I edit the child, change a field, save it and close the modal, then save the parent without re-opening the child edit then the change works.
2. If I edit the child, change a field, save it and close the modal, then re-open the child for editing or viewing (in modal or new tab), sometimes* the change has not been made. If I close it again without changing anything, then save the parent then the change is seen not to have worked.

*"Sometimes": It seems that if this is the first time I have edited a child then the change does not persist without saving the parent before opening the child again. However, if I have previously edited a child in a table (and saved the parent) then edit it again, it seems like the change does persist after saving the child, without re-saving the parent, regardless of any viewing activity.

I'm not sure what is going on here, but it doesn't seem to be anything to do with whether viewing is in a modal or new tab.

PS. Sometimes, in situation 2, I get a 'do you want to leave' message when trying to save the parent, but I haven't worked out exactly which combination of circumstances gives rise to that.

[adrian]

That does all sound very weird, but I don't think it has anything to do with the point I made (that you quoted above) which is about editing things like the title, name, or status in the "Edit child pages" table - those are what would be overwritten if not saved before opening a child page for editing or viewing in the same tab - make sense?

Do you have Ryan's User Activity module installed by any chance? I wonder if it's perhaps dynamically updating things? Otherwise I really don't know, but I also am not sure how it could be related to this module because we are of course just editing in a modal window which is an iframe of PW's page edit process. I don't think any sort of browser caching could impact this, could it?

Unless changing this line: 

$this->editedPage = $this->wire('pages')->get($id);

to 

$this->editedPage = $this->wire('pages')->getFresh($id);

And maybe this one: 

$cp = $this->wire('pages')->get($id);

to 

$cp = $this->wire('pages')->getFresh($id);

fixes things?

[MarkE]

9 hours ago, adrian said:

which is about editing things like the title, name, or status in the "Edit child pages" table

Sorry - I misunderstood the original comment. However it did cause me to investigate the other issue...

9 hours ago, adrian said:

I don't think any sort of browser caching could impact this, could it?

That was exactly what I was thinking - and that 'getFresh' might fix it. Based on a bit of testing, it seems like your 2 changes do the job 😀