Custom code has to live somewhere. On most sites it ends up in the theme's functions.php or in an mu-plugin somebody wrote once and left. Here is the honest breakdown against both.
functions.php is free and always available, and it belongs to the theme: it leaves when the theme changes and it gets overwritten when the theme updates. It has no toggle, no note, and no way back except FTP. An mu-plugin fixes the theme problem and keeps every other one, plus the code is now invisible to anybody who does not think to look in that folder. Neither can tell you which line broke the site, because neither knows it was running. WP Snippet Studio (this site) puts snippets in their own table, runs PHP through the parser before it will save, records which snippet is executing so a crash can name itself, and puts the emergency switch in wp-config.php where it works with no admin and no database.
There are other snippet plugins, and the well-known ones handle the everyday job: code in one place, a toggle on each piece, a library to start from. We have not audited how any of them behave when a snippet fatals, so this page does not guess. What it does describe is what this plugin does, which is written down, tested, and repeatable on your own install.
| Feature | WP Snippet Studio | functions.php | mu-plugin |
|---|---|---|---|
| Header, body open & footer scripts | ✓ Site-wide or admin only | ◐ If you write the hook yourself | ◐ Same, in a file nobody sees |
| HTML, CSS, JS, PHP & text types | ✓ Five types, each handled as itself | ✗ PHP, and whatever you echo | ✗ PHP only |
| Toggle a snippet off without FTP | ✓ One click | ✗ Editor or FTP | ✗ Rename the file |
| PHP checked by the real parser on save | ✓ Broken code never reaches the database | ✗ Save it and find out | ✗ Save it and find out |
| Records which snippet is running | ✓ Watchdog, cleared on survival | ✗ No | ✗ No |
| Recovers from an uncatchable fatal | ✓ Verified against memory exhaustion | ✗ White screen | ✗ White screen |
| Emergency switch with no admin access | ✓ One define in wp-config.php | ✗ FTP | ✗ FTP |
| PHP needs more than administrator | ✓ Plus edit_plugins or unfiltered_html | ◐ Whoever has the file editor | ◐ Whoever has server access |
| Respects DISALLOW_FILE_EDIT | ✓ PHP snippets blocked outright | ✓ Blocks the editor, not FTP | ✗ Unrelated |
| Library snippets arrive switched off | ✓ Always, so you read before you run (Pro) | ✗ No library | ✗ No library |
| Imports arrive inactive | ✓ Whatever the JSON claims (Pro) | ✗ Copy and paste | ✗ Copy the file |
| Survives a theme switch or update | ✓ Nothing lives in the theme | ✗ Gone, or overwritten | ✓ Yes |
| A note saying why the code exists | ✓ Note field on every snippet | ◐ If somebody wrote a comment | ◐ If somebody wrote a comment |
| Cost | Free tier · Pro from $49/yr · $599 lifetime | Free, plus the afternoon | Free, plus the afternoon |
You run one site, you have three snippets on it, they have not changed in two years and whatever you use already handles them. Swapping a working setup for a different working setup buys you nothing today. Credit where it is due: snippet plugins moved a lot of sites off editing functions.php directly, and that was a real improvement. functions.php is also still the right answer for code that genuinely belongs to the theme, such as a template tag or a theme support declaration. That code should ship with the theme, because it stops making sense the moment the theme goes.
You write PHP snippets on sites that clients depend on, and the question is not "can I add code" but "what happens at 4pm on a Friday when the code I just added kills the site?" The parser gate, the watchdog and the wp-config safe mode are the answer to that question, and they are why this plugin exists.
One honest line: no plugin can promise that arbitrary PHP you wrote will behave, and anyone claiming otherwise is selling certainty rather than software. What this one does is refuse code that will not compile, remember which snippet was running when the request died, switch that snippet off on the next load, and give you a way back in that needs no database. That was tested against a genuine uncatchable fatal, not only against a catchable exception.