When the options tabs are hidden, adding a node through the node form defaults to not published, regardless of the default publish setting for the content type. However when I show them again and save, it is published, I'm not sure why hiding part of the form would effect this but I tested extensively and it does.



This is what is happening. subscribing.

Yes, I'm seeing this as well. To elaborate when I hide the vertical tabs field, then edit and save a page its status becomes unpublished despite the fact it was previously published and I had no access to the checkbox to unpublish it.

Happy to test any suggested fixes.

El B

Likewise. Any advice or workarounds appreciated. Can the Publishing tab be shown but "hidden"?

Has anyone found a way to solve this? I would also be happy to test any patches.

I implemented a workaround for this by including the following css code in my subtheme. You will need to inspect the webpage elements of your site to check that the class is correct for the revision field - in this case it is form-item-revision, but it may be different for your theme.

.form-item-revision {

So although the revision box is included in the HTML page (and therefore will pick up the default setting that we want), it does not appear on the page and cannot be changed by an end user.

This only hides the revision box, which doesn't stop someone from hacking the revision setting on a form submit if they knew what they were doing. However, for end users this gets around the problem.

Status:Active» Needs review
new718 bytes

Attached patch helped me to solve this issue in Drupal7

Issue summary:View changes
Status:Needs review» Postponed (maintainer needs more info)
new1.03 KB

I'm tempted to mark this as 'works as designed'. Does anybody have a use case for hiding the tabs with nodeformcols? These are the ['additional_settings'] for a node, they're hidden automatically for any user without the permission "administer content".

I actually think we should disable the ability to hide "Vertical Tabs" in nodeformcols, as it shouldn't be an option in the first place.

If there is a use case though, I'd still want to go with a different approach. We shouldn't use wrapper html for all additional settings, they shouldn't be rendered. What we'll have to do is iterate through the child elements of additional_settings and set the #access for those individual elements to FALSE. I attached a patch to show you what I mean, but what's in that patch really should be implemented in a custom module if really needed.

Status:Postponed (maintainer needs more info)» Needs review

Let's go ahead and test this patch, we should fix the bug first before talking about disabling that feature.

I'd like to get somebody from the community to test this, anybody out there want to test it out and mark it RTBC?