Internally, the hiding is done via CSS on the client-side, and CSS syntax and selectors are used to identify the elements to remove.
You often want to hide the form elements "wrapper" div, so the containing
element of items starting with #edit- will also be hidden.
Eg, if you are trying to hide '#edit-menu-description'
, then the whole
.form-item-menu-description
will be hidden.
Inspect the source of any form on your site to see the new classes that have
been added to the form element to assist this utility.
node-form:[.form-edit-date, .form-edit-sticky]
will demote the date editor and the sticky checkbox from the interface for all node types.
node-form:[#edit-author, #edit-revision-information, #edit-options, .filter-wrapper]
is quite aggressive, but makes your interface really clean by removing most admin UI elements. In D7, when using vertical-tabs, the tabs remain, but may be blank if you hide their content.
If you want, you can also enter arbitrary css-selectors. Hiding :
node-form:[.description,label]... will make your form really hard to use by removing the labels. Hiding :
node-form:fieldset.collapsed
will doubly-hide unused (normally collapsed) things.
The [] array syntax is optional if only setting one value.
node-form:#revision-information node-form:#urland
node-form:[#revision-information, #url]are equivalent, both will work.
Normally the first token in your configs should match the specific form id.
<form ... id="block-admin-configure" >Node forms are treated as a special case. You can target specific content types with their explicit form id, eg:
<form ... id="article-node-form" >A generic form rule for all node forms can also be defined using the pseudo-key
node-form
,
This will be applied to edit forms for all types.
node-form:#revision-information page-node-form:#edit-date article-node-form:[#menu, #url] article-node-form:{.user-role-editor:[#book-outline]}This will:
#node-form.node-type-page
)
[*] The Book module permissions allow admins to add any content type to books, which is nice, but you can\'t turn that feature off if it\'s unwanted. There are a few user permissions like that throughout Drupal, because admins or UID-1 bypass most of the access checks. This presents us with too many widgets onscreen a lot of the time. Rather than hack the core permissions system, we just remove these options from normal use.
An additional class (.node-new
) is added to "new" nodes
being created. This allows us to hide even more fields if they are decided
to be irrelevant when first making a node, and really clean up the first edit
page.
node-form:{.node-new:[#revision-information,#flag-for-archiving]}
This will make the named form elements unavailable on brand-new nodes.
node-form:{.user-role-authenticated-user[#comment-settings]} node-form:{.user-role-content-editor[#file-attachments]}This will:
The rules define the things to be excluded and they match cumulatively (an OR rule) so take care with per-role settings. Using a rule for .user-role-authenticated-user will also apply to admins and UID-1, as they are authenticated. Using a rule for .user-role-content-editor will apply to admins if that user is also a content editor
Per-role rules are available to all forms, not just node forms.
The class to use is always the string user-role-
followed by a
css-safe version of the role name.
Any selectbox on the form will also insert an additional selector
into the form element you can use.
The format is selected-tag
node-form:{.selected-marketing[#file-attachments]}This will:
The rules are created using CSS syntax, keyed by the classes that are added to the node form. You can inspect the DOM on the edit page to see which classes have been added for you. Combine the selectors with a "." and no space to create specific restrictions.
page-node-form:{.user-role-content-editor.selected-marketing>:[#comment-settings]}
This will:
With this sort of rule in place, you can allow content editors to control things on other node types (like story or blog) but remove that option from static "page" types. This works around the limitation of Drupal permissions that only enable or disable this feature on a global level.
This is not a substitute for real permissions as the user can choose to expose and use that feature if they really want to. It just removes the clutter from the form for everyday use.Are your users scared of complexity, but you still need to give them access to some Drupal internals?
block-admin-configure:{.user-role-content-editor:[#edit-user,#edit-role]}
This will remove some advanced elements from the block edit form, but still leave it usable for everyday administration. *
If you want to inspect the CSS rules that are created by this utility,
you can check out the URL /advancedform_css/node-form , where "node-form"
is any form id.
You will see that and "advancedform-filtered" instance of that form will
have the named form elements hidden, and if the form is switched
(to no longer have the "advancedform-filtered" class), then the hidden elements
will show up again.
This utility works client-side with javascript,
and has no effect with javascript off (all fields dispaly as normal)