Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't save page 1074: /about//: It has an empty 'name' field #1048

Closed
adrianbj opened this Issue Mar 27, 2015 · 6 comments

Comments

Projects
None yet
2 participants
@adrianbj
Copy link

adrianbj commented Mar 27, 2015

This happens if you are using Name Format for Children together with noSettings=1 (or some other way of hiding the settings tab).

@adrianbj

This comment has been minimized.

Copy link
Author

adrianbj commented Mar 28, 2015

I am not sure the best way to fix this, but I wonder if it might be ok to conditionally add _pw_page_name to ProcessPageEdit as an InputfieldHidden field when noSettings is set but nameContentTab is not.

Maybe something like this? It seems to work great when noSettings is on, but nameContenTab is not. The other thing I did is move the position of the name field to be after the title - I found it confusing the way it was - I think users would have started filling it out before the title, not realizing it is automatic.

if($this->page->template->nameContentTab || $this->page->template->noSettings) {
    // name
    $field = $this->page->template->noSettings && !$this->page->template->nameContentTab ? $this->modules->get('InputfieldHidden') : $this->modules->get('InputfieldPageName');
    $field->attr('name', '_pw_page_name');
    $field->attr('value', $this->page->name);
    $field->required = $this->page->id != 1;
    $field->slashUrls = $this->page->template->slashUrls;
    if(!$this->page->editable('name')) {
        $field->attr('disabled', 'disabled');
        $field->required = false;
    }
    if($this->page->parent) $field->parentPage = $this->page->parent;
    $fields->insertAfter($field, $fields->get("title"));
}

The one issue that remains is when the Settings tab is removed by other means, like the new removeTab method. Because this is part of building the content tab, I don't see any way of knowing at this point whether the Settings tab will be removed with removeTab or not. Any ideas?

adrianbj added a commit to adrianbj/RestrictTabView that referenced this issue Mar 28, 2015

Added fix for hiding settings tab when you are using "Name format for…
… children" on a template to bypass the initial page creation step.

This fix checks to see if template setting: “nameContentTab” is enabled
which would add the name field to the content tab. If not, then we add
a hidden version of the name field so that new pages will save without
error.

This fix may no longer be necessary depending on the outcome of this PW
Github issue:
ryancramerdesign/ProcessWire#1048
@adrianbj

This comment has been minimized.

Copy link
Author

adrianbj commented Mar 28, 2015

Just a little more info about other possible interactions. My new RestrictTableView module was affected by this, but I put together a full workaround for it.

Unfortunately it will also impact my PageRenameOptions module here: https://github.com/adrianbj/PageRenameOptions/blob/master/PageRenameOptions.module#L77

The problem here is that it relies on checking the template's noSettings status, but it also needs to consider when the Settings tab has been hidden with removeTab.

I think it would be possible to solve all these issues if you could define a page property ($page->settingsTab or similar) that returns true/false based on whether the tab is included or not. Do you think that would be a reasonable approach? Or maybe a $page->nameField? Or maybe something that ensures that the name field is always present somewhere, either visible on the settings tab or the content tab, or if neither of those, then hidden on the content tab - basically what I have done for RestrictTableView here: https://github.com/adrianbj/RestrictTabView/blob/master/RestrictTabView.module#L90

@adrianbj

This comment has been minimized.

Copy link
Author

adrianbj commented Mar 29, 2015

I know this is getting a little OT, but obviously the big downside to removing the Settings tab in general is that there is no longer a way to unpublish a page once it has been published. Do you think that it was be a reasonable idea to add an Unpublish button next to the save button when editing a page? Either in all situations, or maybe just when the Settings tab has been removed. I think there have been a lot of requests about simplifying the page edit options by remove the Settings tab - it is unnecessarily complex for some users, and I think the addition of an unpublish button could be the only important thing that is missing. Some more thoughts about this here: https://processwire.com/talk/topic/9496-restrict-tab-view/?p=91557

@teppokoivula

This comment has been minimized.

Copy link

teppokoivula commented Mar 30, 2015

@adrianbj: for the record, one of the reasons I've chosen to hide the Settings tab in the past has been making it impossible to unpublish, hide, etc. the page. Thus, for us, current situation is preferable.

OT: in our case only actual issue with the Settings tab itself has been page name, which users very often forget, resulting in rather weird URLs. This is, of course, in some ways intentional, and can be "fixed" by moving the name field to content tab, so.. not complaining, just saying :)

@adrianbj

This comment has been minimized.

Copy link
Author

adrianbj commented Mar 30, 2015

Thanks for your thoughts @teppokoivula - I hadn't considered wanting to remove the unpublish option completely. If I expand Restrict Tab View as is being discussed in the forum, I would make an option for adding an Unpublish button to the Content tab - that way you could choose whether this appropriate for your needs or not.

As for the page name field - there is of course the advanced template relative nameContentTab setting. Restrict Tab View now currently adds a hidden page name field to the Content tab if the Settings tab is hidden - maybe I should provide an option to make it visible/hidden.

I guess I am wondering how much of this should be handled by the core vs Restrict Tab View. I think the key thing from my initial issue here is the "can't save" error because that can happen with the right combination of core settings.

ryancramerdesign added a commit that referenced this issue Sep 30, 2015

Fix issue #1420 and issue #1048 where the combination of page.parent.…
…template.childNameFormat and page.template.noSettings prevented page from being saveable.
@adrianbj

This comment has been minimized.

Copy link
Author

adrianbj commented Sep 30, 2015

Thanks Ryan!

@adrianbj adrianbj closed this Sep 30, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.