pagetable - Notes about missing required content

[tbba]

I now started playing with pagetables. I tried this:

a) set pagetable field to Modal: Automatically close on save (default)

• Edit a page with such a field, adding some template that has a required field
• Save+Publish that element.
• It shows as unpublished. … No hint that this change was because of missing content
• Editing it again … No hint here that there is content missing

b) changed pagetable field to Modal: Keep window open, close manually

• open for edit … No hint that there is missing content
• Save+Publish that element.
• The element stays open … the hints about missing content are finally there
• Then I am able to save and close the popup.

EDIT:

• Now the "masterpage" stops loading: Sanitizer::purify requires a string#0... Sanitizer::purify requires a string#0 /wire/modules/Inputfield/InputfieldCKEditor/InputfieldCKEditor.module(388): Sanitizer->purify(NULL)

I am asking whether it would be good to have hints about missing content inside of a table row kind of like the repeater does it.

Or did i use this in a not intended way? (PW 2.5.7.dev)

[ryancramerdesign]

Good points, and you did you use it in the intended way. I'm not really sure how to solve "a" because it closes the window before waiting for the save to complete. Maybe there's a way for it to wait for it and capture any error messages, but getting a little beyond my JS skills there. I'll look into it though. Another possibility is that I may be able to use the new SystemNotifications to pass the error message through to the parent window after the page (that was in the modal) finishes saving. This I'm pretty sure I could figure out how to do, but there may be a few seconds delay before the error actually appears.

As for "b", the PW page editor never produces error messages unless you've submitted a form. So for the first bullet point there, that's expected that it's not going to show an error message. I don't think we necessarily need to account for the instances where people switch their field settings between modal-close and modal-open mode in between page saves. :) But it sounds like currently if you've got required fields in your PageTable items, it's a good idea to use the new modal-open mode so that error messages will be seen. However, I'll keep thinking about more ideas here, as I'd love to find a way to get the error messages shown in the modal-close mode too.

I'm not clear about what you mean with the "masterpage" and purify error? But since I've got a module name and line number from your error message, I can add a check for null there pretty easily.

[tbba]

Sorry, I did the mistake again of putting 2 different issues in one report. I try to learn from that. (Should I move this subject over to the forum?)

"masterpage" means simply the edited page holding the table field. "block" is the table row. (I am trying to mimic basic features I know from the Wordpress plugin "visual composer". It makes my designers happy if they can set the column width layout via CMS, row by row... That's where the wording comes from).

1. The Required alerts: To me it sounds complicated too to leave this to JS alone. For "repeaters" you did find a way, there it works perfectly. But maybe that means delays if the script has to loop through all rows on every page edit to look for problems. Is a hidden field an option for every row page that hold the result of the checks on it's last save attempts? This hidden field could communicate with the pagefield.
2. The problem I have with saving is not fixed. In my setup all rows are saved under /blocks/ and I set automatic names "block"... On saving a modal row "page" I get a blank page and see that I the browser redirected to /blocks/block-2. This redirect is unexpected and maybe unintended. In the end the row-pages have been generated within /blocks/ but the pagetable shows them not. Should I not use the central storage?
3. In that scenario I also find if complicated that the name is set automatically but the title field (required) is not. - In your repeaters- eco system one does not need to bother about namings of those page fragments, that is done automatically and the editor does not need to care about it and to keep that unique (the latter might be not easy if all rows are saved under one central location).

[ryancramerdesign]

The Required alerts: To me it sounds complicated too to leave this to JS alone. For "repeaters" you did find a way, there it works perfectly. But maybe that means delays if the script has to loop through all rows on every page edit to look for problems. Is a hidden field an option for every row page that hold the result of the checks on it's last save attempts? This hidden field could communicate with the pagefield.

Repeaters and PageTable are fundamentally different. Repeaters are actually edited as part of the page they live on. PageTable fields pop open a modal window to edit an entirely different page. Though both have JS dependencies, but the error reporting behind Repeaters is able to work exactly the same as any other Inputfield. Not so with PageTable, as the main page really knows nothing about the edits that occurred in the modal window. If there are required fields and the inability to publish a row isn't enough of an indicator, the best bet is to turn off the automatic close option, so that the editor can see the results of any save operation they perform. If I can find some way to make the windows communicate errors back and forth I'll do it... but it's probably a little ways off.

The problem I have with saving is not fixed. In my setup all rows are saved under /blocks/ and I set automatic names "block"... On saving a modal row "page" I get a blank page and see that I the browser redirected to /blocks/block-2. This redirect is unexpected and maybe unintended. In the end the row-pages have been generated within /blocks/ but the pagetable shows them not. Should I not use the central storage?

Central storage should be fine. I think I just need to know how to reproduce the issue you describe. What steps do I need to take to setup the same scenario where I can duplicate it here? The redirect you mention definitely doesn't sound right, assuming it's redirecting to a front-end page on your site.

In that scenario I also find if complicated that the name is set automatically but the title field (required) is not. - In your repeaters- eco system one does not need to bother about namings of those page fragments, that is done automatically and the editor does not need to care about it and to keep that unique (the latter might be not easy if all rows are saved under one central location).

For this reason, PageTable is far more versatile than repeaters. It can be used for more things than PageTable can be used for. It's creating front-end pages in your site. Repeaters are creating back-end pages to pull data from, that will never themselves be dedicated front-end pages. If you don't have a need for a "title" field in your PageTable, remove it. It's not required that you have one. You may need to first edit the title field and uncheck the "global" box on the Advanced tab.

[tbba]

1. You describe the difference between repeater and pagetable from the technical side, my comments are more seen from the user side (consistent look and feel).
2. The redirect from the modal to the frontend page after save (that's what it is, you are right) comes from an incompatibility with the module "adminbar" ("Use slide overlay" option on or off, it's the same.) After the module is uninstalled, the problem is gone. You both use the same var "modal=1. (The Sanitizer::purify alert is fixed, thank you.)
3. I thought the title field is mandantory for make the backend work. Changing it in the template as not required and hidden, worked. The name is shown on the backend pages list and that is what I want. Is there a way to show template.label in the pagetable list, without creating an oversized 2 row headline for it?

[tbba]

Summary of open issues (in preparation of closing this issue):

• BUG: incompatibility with the module "adminbar" leads to redirect to front page, after saving and closing the modal window of a table row-"page".
• WISH: Error handling for "required" errors (and pattern-match errors?) in modal window.

[ryancramerdesign]

I don't think there's anything we can do about the item you've identified as a bug, because it appears to be AdminBar that's performing the redirect, not the PW core: https://github.com/apeisa/AdminBar/blob/master/AdminBar.module#L116

I don't think this is a bug, rather AdminBar only indicates compatibility with ProcessWire 2.1 and 2.2: http://modules.processwire.com/modules/admin-bar/

I may have a solution for the Wish item. I'm testing out something on the dev branch for the new modal tabs option. When you save a modal tab and there are errors, it doesn't close the tab. I believe the same can be applied here, so will be looking closer at this here soon.

[tbba]

This is an old thread - I close this for now.