All aspects of the UI are available for customization. For example, the toolbar
can accept additions, modifications, and deletions per the needs of end-users.
The UI markup is compiled by recursive, functional React calls. The recursion
tree is reflected by the directory structure containing the modules which
compose the UI. To override any given module, copy the directory structure
leading to the module from
source/_ui/index/html, respective to your implementation. Modifications to
modules in that directory will override the corresponding modules in core.
Additions (so long as they are correctly nested) will also be recognized.
A working example of UI customization can be found at
The Fepper for Drupal project overrides its HTML title to read "Fepper for
Drupal" instead of "Fepper". In order to do so, it has the
module nested in directories that correspond to the tags that nest the
HTML element. Both
head.component.js and its nesting directories must be named
similarly to their corresponding elements.
.component.js indicates that the
file is a module to be rendered by React.
It must export properties that
The numeric prefix to
00-head orders it to precede
01-foot, even though
"foot" precedes "head" alphabetically.
In this example, by allowing customizations in the
00-head directory separate
from the core components, core updates will be respected for all components
except for the HTML head.
this way as well. While a head element is unlikely to have associated scripts or
styles, the UI's main element does have its scripts and styles componentized as
index/html/01-body/40-main. A big advantage
for this type of componentization comes when elements are renamed or deleted.
When you rename or delete the element, are you absolutely sure you'll rename
or delete accordingly in some far-flung, monolithic script or style file?
Alas, no one should be forced to componentize this way. Generic modifications
to UI scripts can be added to
Similarly, generic modifications to UI styles can be added to
source/_styles/pattern-scaffolding.css. (The file is named this way to adhere
to the Pattern Lab convention on defining pattern states. It should not be
relied on for pattern scaffolding.)
View All markup can also be overridden by copying the .mustache files in
and pasting them to
source/_ui/viewall (nested correctly). Modifications will
then be recognized and displayed in the UI. (No additions are allowed.) Custom
View All styles can be added to
You will need to compile the UI in order for the browser to pick up custom changes to the UI:
New UI customizations will not be picked up simply by restarting Fepper.
The UI exposes these additional tasks:
fp ui:build- Build the patterns and output them to the public directory
fp ui:clean- Delete all patterns in the public directory
fp ui:compile- Compile the Fepper User Interface from its components
fp ui:copy- Copy frontend files (_assets, _scripts, _styles) to the public directory
fp ui:copy-styles- Copy _styles to the public directory (for injection into the browser without a refresh)
fp ui:help- Get more information about Fepper UI CLI commands