4

When I enter a php snippet into a block (or story or page), it can crash the site.

Two questions:
1) How can the chances of this be reduced? For example, I just crashed a fresh installation because a function name was not recognized. Would placing the code in a try/catch block been likely to prevent that crash?
2) If/when I do crash the site due to malformed php code, how can I recover the site?

4

Two common errors occur while entering PHP code, syntax error & function not defined error. To avoid syntax errors, write your code in any IDEs which supports syntax checking. And always use if(function_exists()) when calling any custom functions. Once you have both these checked move it to dev, test and move it to live site.

As indicated by others there are loopholes entering PHP codes but when you cannot avoid above two points might help you.

  • @user I think you should accept greg's answer as he has answered both your questions I just added my 2 cents to prevent errors in PHP code. – GoodSp33d Oct 31 '12 at 13:55
5

The usual way to avoid problems with your production site is to try out everything first on a dev or staging site, and then push it to production after it is tested. There are two main problems with php in blocks: one is that block data is stored in the database. If you push the database from dev to production, you will lose new content on your live site -- no good. The solution to this problem is to use the features module to export your database configuration to your code files, which allows you to push your config-in-code from dev to live & then re-import on the live site.

The other problem with putting php in blocks, though, is that it opens up a security hole in your site, as anyone who has the right to configure blocks can now run code on your server. This means that your site is one guessed password away from compromise at all times. It is therefore better to write your blocks in code using a custom Drupal module rather than put php in the database.

If you do have a site with malformed code in a block, you can disable the block using the drush block-disable command from the drush_extras project.

  • +1 for advice, but I thought php permissions could be a) role based or b) temporarily allowed during development. – user1706487 Oct 31 '12 at 13:45
2

I suggest you read Develop for Drupal documentation first.

Read about The White Screen of Death (Completely Blank Page) too.

You can find more about Drupal code debugging here.

Follow Drupal's Standards, security and best practices for writing code and maintaining Drupal's security. This documentation also provides a number of best practices that will help you optimize the speed and performance of your application.

Avoid storing php code in the database. It is more secure to create a custom module instead of using php-enabled fields.

Set up your testing strategy appropriate to your use case: at least test your code on your development (or local) environment before it is used in the production (live) environment.

  • +1 for the links and I get the consensus, PHP in content or blocks is bad. – user1706487 Oct 31 '12 at 13:43
1

In case you are stuck because of bad code in the php-enabled field or node, here is how I usually recover.

  1. Remove the "php" folder from modules folder.

  2. See if the site now works without any White Screen Of Deaths.

  3. If the site shows "failed opening .."as a fatal error, set 0 to status for php module in system table.

  4. Or if the site is working now, go to the node edit and remove that bad code.

  5. Place the code in place after fixing that.

However, it's NEVER a good idea to use PHP in nodes. Only places I would suggest using raw php in database-stored values are some Rules module's configuration and Views arguments.

For blocks or pages, it's much easier to make a module with necessary menu hooks and block hooks.

Good luck!

  • Unfortunately your suggestion didn't work for me. If you have bad PHP code in a CCK field, then disabling the PHP FIlter module or moving the "php" folder out won't work. I am stuck at the moment other than to completely delete the field. UFFF! – user785179 Jan 12 '13 at 0:41
  • 1
    Replying to myself: I fixed my issue above. I had a bad SQL query in my PHP Filter box in a field. The "trick" is to select the field's widget type when you are managing its field. Do not select the "EDIT" link or you will crash. Instead, select the field's widget type (e.g. SELECT) in the MANAGE FIELDS page of your content type, and then you will get the chance to fix the PHP code. phew. Hope this helps others! – user785179 Jan 12 '13 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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