Custom code
Named snippets, not one big blob
Site-wide CSS and JavaScript live behind the </> icon in the sidebar header, next to Style.
Each piece of code is its own snippet with a name, a position, and its own on/off switch. Removing a tracking pixel is flipping one toggle — not surgery inside a shared file.
The five positions
| Position | Where it goes |
|---|---|
| Custom CSS | Site stylesheet. Bare CSS — no <style> tag needed |
| Custom JavaScript | Compiled to a real file and loaded deferred |
| Header scripts | In <head> |
| Body (header) scripts | Immediately after <body> opens |
| Body (footer) scripts | Just before </body> |
These mirror Bricks' own positions and are named the same way, so you're not learning a second vocabulary.
Custom JavaScript is the position to use for anything sizeable. It's written to a cached file with a content hash in the name, so browsers cache it properly. The other script positions are inlined into every page response and re-downloaded each time.
For the three script positions, bring your own <script> tags. Custom CSS is the exception — it takes bare CSS.
Saving
Snippets show Unsaved changes until you save them. Each one runs on every page of the site.
Why not just use Bricks' fields?
Because nothing carries them. No export path touches Bricks' global settings, so a site you migrated arrived with all its pages and none of its analytics.
Brickser snippets travel inside your project file — see the next chapter.
Imported snippets arrive disabled, every time. This is deliberate: it means a project bundle can never silently point a client's traffic at someone else's analytics property. Review each one and switch on the ones you want.
Access
Custom code requires full administrator rights. PHP tags are stripped from every position, so snippets can't execute server-side code.