A code snippets plugin executes PHP written by an administrator. There is no way around that — it is the entire feature. What you can decide is how many things have to go wrong at once before a site goes down.
SnippetCrate uses eval(). We would rather say that plainly than bury it, because the interesting part is not whether it is used but what it is fenced in by.
Nothing from a visitor ever reaches it
The first and most important boundary has nothing to do with PHP. Snippet code comes from exactly one place: the database, written there by an administrator. There is no front-end form, no AJAX endpoint and no import path that reaches the executor.
Every route that saves or edits a snippet requires the manage_options capability and a valid REST nonce. On multisite a Super Admin is required as well — a single-site administrator must not be able to earn network-wide code execution.
Parse before you save
Code is checked before it can ever be stored, by running it through token_get_all() with the TOKEN_PARSE flag:
token_get_all( '<?php ' . $code, TOKEN_PARSE );That flag makes the tokenizer fully parse the source — the same parse the engine would do — without executing any of it. A syntax error raises, the save is rejected, and the message is shown in the editor as you type. Code that does not parse never reaches the database.
This is a check on syntax, not on sense. It will happily accept delete_option( 'siteurl' );. It is a seatbelt, not a driving instructor.
Catch at runtime, then switch it off
Syntax is the easy half. Plenty of code parses fine and then throws on the fourth request of the day because an API returned null. So every execution is wrapped in try/catch, and a snippet that throws is deactivated immediately.
That last part is what matters. Catching an error and carrying on would mean the same fatal happens on the next request, and the next. Deactivating means the failure happens exactly once.
Keep the admin reachable
Global snippets are hooked to wp, which fires on front-end requests and never in wp-admin, in REST requests or in cron. So even a snippet that manages to be catastrophic cannot lock you out of the dashboard you need in order to delete it.
JavaScript, CSS and HTML snippets are never evaluated at all. They are printed as markup into wp_head or wp_footer. Only PHP is executed, and only PHP can use the global scope.
What none of this saves you from
Being straight about the limit is part of the design. The try/catch contains anything PHP can throw, which is the overwhelming majority of real mistakes. It cannot rescue you from:
- a snippet that loops forever,
- a snippet that exhausts the memory limit,
- anything else that ends the process rather than raising inside it.
PHP cannot catch those, so neither can we. Test substantial snippets on a staging site first — and be suspicious of any plugin in this category that implies otherwise.