No Devel gracefully handles PHP errors that are caused by calls to dpm() and related functions of the Devel module when Devel is not installed/enabled. Anyone who has encountered "Call to undefined function dpm()" during development, or accidentally "white screened" an entire live site when moving code containing a stray Devel function call to staging and production servers may find use for No Devel.

With this module, Devel function calls (when Devel is not enabled) are handled as warnings in Drupal, instead of raw PHP errors. No Devel is intended to be installed as insurance on live servers and to aid development, particularly in multiple-server environments where installed modules and configurations may vary, not as an excuse to sloppily leave unnecessary function calls in production code.

The following Devel functions are protected against: dpm(), dvm(), dpr(), dvr(), kpr(), dargs(), dd(), ddebug_backtrace(), and db_queryd().

Very simple, but convenient. I do not know of any other modules that accomplish this.

This module is for Drupal 7.x

http://drupal.org/sandbox/komlenic/1454374
git clone http://git.drupal.org:sandbox/komlenic/1454374

Thanks!

Comments

komlenic’s picture

komlenic commented

Passed PAReview.sh.

iler’s picture

iler commented
Status: Needs review » Needs work
  • You should move install function to no_devel.install file instead of having it in .module file.
  • Why is this module better than seeing those errors and cleaning the obviously unwanted code away? IMO it's bad to have unnecessary code in your implementations.
komlenic’s picture

komlenic commented

Thank you for the feedback and helping me to better define this module's purpose.

I have rewritten the module to better reflect the intention - it now adds a warning to watchdog for all calls to Devel module functions if Devel is not enabled.

To more specifically answer your question, this module serves two purposes:

  1. "Insurance" on live sites where code is pushed from an upstream location (such as a staging or development server), especially with multiple developers (who may not all be as careful as you) -- A stray dpm() or other function call can effectively force an entire site offline or "white screen" it if Devel is not installed. This module gracefully removes that possibility, by eliminating the raw errors in favor of logging them.
  2. To aid development across multiple dev environments and local installations where Devel may or may not be installed -- With this module installed, you don't have to worry about whether Devel is installed and enabled on another dev's machine, or your laptop, or the "other" server, or have to comment out/un-commenting Devel function calls, or remember to enable the module after getting a raw error, etc - you don't have to worry about it until later in development when you need to.

I agree completely with your thoughts, and it is not intended to encourage "unnecessary code in your implementations". I've updated the project page and README.txt to reflect this and better explain the module.

Passed PAReview.sh http://ventral.org/pareview/httpgitdrupalorgsandboxkomlenic1454374git-7x-1x, as well as Coder.

Reviews welcome, thank you!

komlenic’s picture

komlenic commented
Status: Needs work » Needs review
komlenic’s picture

komlenic commented
Issue summary: View changes

Updated to reflect module changes, corrected git repo location.

komlenic’s picture

komlenic commented
Issue summary: View changes

Fixed typo.

btopro’s picture

btopro commented

Have encountered this issue many times in D6 development. Simple enough project, could see a useful backport to D6 which I'd be happy to jump on with if it helps get this pushed to a full project sooner.

patrickd’s picture

patrickd commented
Issue tags: +PAreview: single application approval

Not a too bad idea!
As it is bad(ass) practice to leave dpm's and sisters in code, what about showing a warning message to admin users after one of your replacement-functions is called?

Please take a moment to make your project page follow tips for a great project page

This project is too short to approve you as git vetted user. We are currently discussing how much code we need, but everything with less than 120 lines of code or less than 5 functions cannot be seriously reviewed. However, we can promote this single project manually to a full project.

as there are currently many applications in queue we need more reviewers,
so think about getting a review bonus and we will come back to your application sooner.

komlenic’s picture

komlenic commented

@patrickd and other friendly Drupal module reviewers:

I have added a warning message for admin users, which is a great suggestion. It is more difficult to ignore (than the warning in watchdog) and fits the module's purpose perfectly.

I have attempted to make the project page follow the tips for a great project page where applicable (for example there are no known problems or similar projects, etc so I have omitted those sections.) Since this is a relatively straightforward module, I do not know if screenshots are recommended, but I do have them (though I cannot find an obvious way to upload/attach them to a sandbox project) Please advise on this.

This is a fairly simple module, so I understand the need for a minimum requirement for a vetted user and the difficulty in that needing to ultimately be a subjective decision in many cases. (Although this does arguably exceed 120 lines and 5 functions, albeit very barely.)

Thank you!

patrickd’s picture

patrickd commented

For some reasons only vetted users can upload images on the project page, but if you want to add one anyway you can upload it manually at https://drupal.org/node/add/image and use img-tags to include it on your project page.

komlenic’s picture

komlenic commented

Added screenshots. Thanks patrickd.

komlenic’s picture

komlenic commented
Issue summary: View changes

Add Drupal version.

luxpaparazzi’s picture

luxpaparazzi commented

It should be good practice adding unneeded blank space in t() function:

$message = t('Call to undefined function @func() in @file, on line @line.
Devel module not enabled.', $vars);

Either use string-identation or put it on one line.

This project is too short to approve you as git vetted user. We are currently discussing how much code we need, but everything with less than 120 lines of code or less than 5 functions cannot be seriously reviewed. However, we can promote this single project manually to a full project.

The project has about 200 lines of code and only 4 true functions, I agree patrickds that it's still somehow to limited for a propper evaluation, but I definetly like the idea of the project.

Would it not be possible to add an override for the die() function, as I tend to often use die() for fast debugging, and sometimes forget to remove those lines ;)

patrickd’s picture

patrickd commented

module was already tagged for single project promotion on #6

nope overriding global functions is hard
either you must have APD installed and enabled (nobody has this and this should never be done on a productive site) to use function_override()

or you must be working within a namespace.

I'm currently working on an alternative approach to solve this problem by the sandbox module

btopro’s picture

btopro commented
Status: Needs review » Fixed

have jumped on as a comaintainer for this project and am promoting to full project status based on approval in #6. As the maintainer requesting the project be promoted initially didn't reach the number of lines of code threshold to apply for full git project access no additional action should be required on the part of d.o. site admins.

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

(not verified) commented
Issue summary: View changes

Updated to reflect slightly changed module functionality.