Kill krumo and procedural debug functions [#2209705]

As Kint is now in: #2034919: Kint debug tool for Drupal, the roadmap for this could be:

- Find and document an alternative way to dump stuff for each procedural call we have (dpm, dsm, dd, etc).
- Create an issue for each one that we can't replace and figure out if we should wrap it or try to extend Kint.
- Remove krumo library and any procedural wrapper we have replaced

Comments

Comment #1

salvis

he/his

CreditAttribution: salvis commented 29 June 2014 at 23:15

Coming very late to the party, I'd still like to put in my 2 cents:

From donquixote's comment in #2034919-32: Kint debug tool for Drupal :

In the last year I used both dpm() and Drupal\krumong\dpm() for debugging.
I personally perceived the shorter spelling for dpm() as a huge advantage. It made me use Devel dpm() a lot more than the Krumo NG version.

I agree. Since dpm() returns what it receives, you can even put it inside expressions. Having a short and well-known name is a great advantage.

The common expectation is that you get dpm() and friends when you install Devel. This is firmly engrained in the Drupal literature and in most Drupaller's heads. It would be a pity to lose that.

OTOH, the user should be free to swap the functionality behind dpm() and friends for whatever s/he prefers, and even be able to remove them from the global namespace if s/he wants — as long as it's easy to tell which module is serving which function.

I could imagine a table with a row for each debug helper function and a column for each module that wants to provide an implementation, something like

                       removed | inactive | Devel | KrumoNG | whatever
dpm()                    ( )   |    ( )   |  ( )  |   (o)   |   ( )    
kpr()                    (o)   |    ( )   |  ( )  |         |   ( )    
ddebug_backtrace()       ( )   |    ( )   |  (o)  |   ( )   |    
fancyx()                 ( )   |    ( )   |       |   ( )   |   (o)
etc...                   ( )   |    (o)   |  ( )  |   ( )   |

Devel would start out with all of its functions selected.
The user would be able to remove any or all of them from the global namespace.
The user would be able to (temporarily) deactivate any or all of them, without having to remove the calls from the code.
Cooperating modules would provide their own list of whatever functions they want to replace (or even add). On installation they should get their full list selected by default, but the user should be free to selectively drop back to Devel or some other third-party module.
On uninstallation, the active items should automatically drop back to Devel, if provided.

Comment #2

moshe weitzman CreditAttribution: moshe weitzman commented 3 July 2014 at 17:24

I'm really not interested in creating plugin system where modules take over functions wholesale like dpm(), kpr(), etc. I'm just fine with the Issue Summary as written here. I think we could change the fallback in devel when Kint is not installed so that it suggests Kint and does nothing more. That would really lead folks to enable kint and alleviate the "i used to just enable devel and I don't want to learn anything new, ever" problem.