Lots of times here I've been told that using views custom php fields, filters or others is a bad practice, because putting php in the sql is dangerous.

My question is, if you only call to a function, that you defined in a module, is it still as bad?

Sometimes, especially for Views, making a custom handler, or, other example, a custom token, can be really heavy.
What are the risks if I make a custom field that only calls a function? Is it as dangerous and "forbidden"?

  • 1
    what exactly are you attempting to do?
    – au_stan
    Commented Apr 17, 2013 at 12:05

3 Answers 3


Here's my take on it:

The PHP docs says about eval:

Its use thus is discouraged

It is always, let me emphasize that again, always, bad to use the PHP module (technically eval, but the PHP module makes a dangerous language feature much worse).

Details discussed in this question: What are the downsides of using PHP Filter code in blocks, nodes, views-args, etc?

The link provided by Clive claims

Sometimes eval is the only/the right solution.

It is possible that this is true, some times, but during quite a few years of professional development, I have never stumbled across a real need for it, in PHP or other languages.

Personally, I've taken it to the level that my servers disable the functionality on the php level itself, with disable_functions = eval.

With that said, on a small personal website, it's likely of less consequence than on a large enterprise one, and there are cases where it's at least not completely horrible to use it.

  • "Personally, I've taken it to the level that my servers disable the functionality on the php level itself, with disable_functions = eval." WOW !!! Thx for the great answer. In my case i'm actually working on one big communautary website (www.beyondcroissant.com) and a big corporate other one. So... uh :) Commented Apr 17, 2013 at 12:54
  • @Letharion I was hoping you'd answer this one ;)
    – Clive
    Commented Apr 17, 2013 at 13:22
  • 1
    For those coming to this question later. It turns out that eval can't be disabled, because it's not a function. I've tried patching eval out instead, which works fine, but because PHPUnit relies on eval for it's mock objects, tests then give false failures.
    – Letharion
    Commented Dec 15, 2014 at 9:03

There are some great answers here, but I don't think they address why it's a security issue to allow php execution inside the CMS.

In my opinion the problem with php.module and other modules that do their own eval is that it makes it so anyone who can exploit your Drupal site (see note below) has the ability to run arbitrary php. The WordPress brute force attack going on now is getting admin (i.e. uid 1) permissions on WordPress sites. If that gives someone the ability to just deface the sites then that's a meddlesome problem, but not much more. If it gives them the ability to run arbitrary php (which it usually does) then it's horrific for those sites, other sites hosted on the same server, and even the internet as a whole: the sites become a massive botnet that can do whatever their owner wants.

If WordPress didn't allow php execution would it be a worthwhile target for this attack? Probably not.

So, what can you do? letharion's tip about disable_functions is a great one. There's also the paranoia module which can help reduce people's ability to execute php.

  • Note: I said "exploit your Drupal site" which is pretty generic. It could be done via brute forcing an admin password, social engineering access to email and then doing a password reset mail, session sniffing, an XSS attack or maybe even a few other ways. But once an attacker has that kind of attack...the eval feature means your whole server becomes a great tool for the aettacker.
  • +1, This is a great answer, I didn't bother elaborating any more because I linked to another answer with good info in it. I'd suggest you edit Berdir's answer over there and add this type of into to it, as it's sort of this sites canonical reference on the topic :)
    – Letharion
    Commented Apr 18, 2013 at 9:51
  • Ahhhh, I didn't read that post. Indeed it is a good resource. Just edited and tried to condense this thought to a bullet point - further edits welcome.
    – greggles
    Commented Apr 18, 2013 at 15:49

Be aware adding invalid PHP code to a form textarea can bring your site offline with a fatal error. It also makes it difficult to determine where functionality is being added from, if nothing can be found in the source code files and is instead in an obscure database field.

While it's tidier to call a function defined in a module, where the source code can be tracked properly, if you're going to do that, it's recommended to export and store those Views etc.. using a module like Features so that the configuration and code can be tracked properly in version control.

In most cases there's an API equivalent where the PHP code would better reside, for example hook_block_view or a custom Views argument handler.

  • Ok, thx for the "bug tracking" part ! Is there something about security I should now too ? Commented Apr 17, 2013 at 12:25
  • 2
    @GregoryKapustin The security problems are caused by the module's use of eval(). The relative merits of eval() are discussed here
    – Clive
    Commented Apr 17, 2013 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.