DTools is a package of very useful Diagnostic Tools.
It contain following modules:
* bench_chart (See attachment)
it will shows you how much your Drupal application spend on specified hooks
its perfect when you want to optimize your website or there is some problem with specified module and you don't know which one
* WSOD
Got WSOD (White Screen of Death)?
You don't know why?
You are sick, because you've got lot of modules and you can't lost your time to disable them each by each to check what's wrong and at the end the reason is because of some cache?
This module is for you.
But how I can enable it, if I've got still WSOD?
Simply go to: /sites/all/modules/custom/dtools/wsod/wsod_emergency.php
It's secure, if there is no wsod detected, this script is useless for anybody.
* string2module
Working in big team? Or some module showing you unneeded string on the page? var_dump() or print_r() nightmare?
You lost couple of hours to find out which place cause the problem and you couldn't find?
Just type the string and it will show you which module generated specified string.
TODO: This module is under development, it's not finished yet. If you like an idea, I'm happy to cooperate.
The issue queue is not the place for this. Please read the Contribute code section of the Contribute handbook to learn how you can make this a proper project.
Two fully working modules of this packages has been refused by CVS admin.
Two other modules has been refused as well (one was related to database tweaks and second with booking timeslots).
And I've no patient to lick somebody's boots.
If you are not happy to keep them here, I'll upload it to external server.
It's possible that your module(s) violate the CVS usage policy somehow (I couldn't tell from a brief inspection of the code). But if you wanted to host it on d.org, instead of posting everything here you should really get in touch with the CVS admins via the infrastructure queue using the 'CVS' component.
And 'won't fix' is the most appropriate status for this issue.
There is unofficial CVS usage policy that says there is no need to use diagnostic modules, because Drupal is not babysitter and it's working fine so probably you using bad programmed contributed module so contact your module maintainer (even it's suspended = we don't care about your problems), because there is everything fine with the Drupal. For me this policy is the same as in MS, Windows is working fine in clean installation and tested by experts, but there is no support when you've got 1k viruses after 15min of using it and there are blue screens each 10 minutes, that mean you (as the end-user) doing something wrong.
Nobody wants to spend weeks for checking which module failed to run if there is something wrong in your production server. And why some page is loading 5 minutes.
Other wrong thinking: Most of the admins here think that if you can't change your server configuration on your hosting provider, change your hosting provider or buy your own server.
So if there is no possibility to change your configuration on the server, so why not use module if there is some possibility to do that? "Message from the CVS maintainer: I'm not entirely sure that fixing a database administration problem is a requirement for a module. "
It was answer regarding to this module: #361967: Increase MAX_JOIN_SIZE and MAX_ALLOWED_PACKET settings in system.install
And I'm sure that wsod module, and some similar modules will get the same answer with very tile thinking.
Answer regarding bench_chart (previous name: hook_stat) module: "Message from the CVS maintainer:
(a) The term and prefix "hook" is reserved for actual Drupal module hooks.
(b) As of the current code, defining hooks inside of hook_stats_gen_hooks() does not make sense, since those functions are defined privately in the scope of hook_stats_gen_hooks(). Please make yourself familiar with PHP's function definitions.
(a) That's fine, I didn't know that I can't use hook name in my module name - no problem at all, I've changed name after few minutes, it was no any problem (ignoring that I'd to wait for this answer about 1 week) and all further replies to this request were ignored. So what? Apply again to get the same answer? Stupid.
(b) Who is familiar with PHP he is. Drupal structure can't list for you all hooks which are used in your Drupal application, so sometimes you have to create them dynamically (like module_builder receiving hook list from the website), so I can't define them manually if I don't know what to define. So how I can calculate execution time of specified hooks when I don't know what hooks are used. If there are some PHP core function available (like eval, where Drupal using it many times), why don't use them? I think it's the next excuse to refuse the next stupid module.
If you don't have space for new modules on your server, just fine, just say it.
Because I'm see a lot of suspended, not proper working modules, without even any dev dumps to test it, or some people even hard-coding the whole html code into module (or using short-tags or even more depreciated code or not OO) which are experienced maybe few days with Drupal and I don't know why, but they module were accepted.
In summary: It is my good will to create those modules and develop them for free, but if somebody don't like it because maybe he don't understand them, so don't judge before public does it. I really don't want to make any problem for anybody, so I think it's the right place to keep them, because I don't want situation, that after somebody will delete them without reason or some policy which is not written, because somebody will not like my code.
I've spend about 1 month for asking to add my modules (because I wanted to do that in Drupal way), but without success, after all it took me only 5 minutes to host them on GoogleCode.
If you want make Drupal more popular and developers to be more enjoyable by creating new exciting modules, change your CVS admin or policy to make it easier.
activelyOUT:
It's white because you don't have wsod on your front page (then change it in ?path to path where you have wsod as described in README.txt), or there is some bigger problem with your configuration or syntax error (then check your php logs if everything is fine).
I have been in diagnostic hell because a few of the modules that I have I updated and they screwed up my config. It would have been easy if I just updated one at a time. but because I had such a great experience upto this point I did it in a batch.
Tools like this are really helpful so keep up the GREAT work!
I was having WSOD problems so I uploaded dtools to try and figure out what was wrong. It didn't help, but by turning on error reporting to page, instead of to a file in php.ini I discovered that the problem was in the date module.
The reason I'm adding to this thread is that after I got my site up again I was having problems with the views module, getting WSODs on view pages and I could not edit views. I started getting errors such as "missing argument 2 in views_ui_analyze_button()..." at various lines in the views admin.inc file. But when I checked the error log it said:
chdir() [function.chdir]: No such file or directory (errno 2) in /home/www/spjdc.org/drupal/sites/all/modules/dtools/wsod/wsod.module on line 31.
After removing dtools from my site my views came back and all seem to work properly. I do not have any idea what the problem was, but I hope this helps you fix it.
Comments
Comment #1
kenorb commentedDTools is a package of very useful Diagnostic Tools.
It contain following modules:
* bench_chart (See attachment)
it will shows you how much your Drupal application spend on specified hooks
its perfect when you want to optimize your website or there is some problem with specified module and you don't know which one
* WSOD
Got WSOD (White Screen of Death)?
You don't know why?
You are sick, because you've got lot of modules and you can't lost your time to disable them each by each to check what's wrong and at the end the reason is because of some cache?
This module is for you.
But how I can enable it, if I've got still WSOD?
Simply go to: /sites/all/modules/custom/dtools/wsod/wsod_emergency.php
It's secure, if there is no wsod detected, this script is useless for anybody.
* string2module
Working in big team? Or some module showing you unneeded string on the page? var_dump() or print_r() nightmare?
You lost couple of hours to find out which place cause the problem and you couldn't find?
Just type the string and it will show you which module generated specified string.
TODO: This module is under development, it's not finished yet. If you like an idea, I'm happy to cooperate.
Comment #2
kenorb commentedDownload here.
Comment #3
kenorb commentedWhite Screen of Death?
Download next version of WSOD in attachment.
Read more in: README.txt
Comment #4
damien tournoud commentedThe issue queue is not the place for this. Please read the Contribute code section of the Contribute handbook to learn how you can make this a proper project.
Comment #5
kenorb commentedTwo fully working modules of this packages has been refused by CVS admin.
Two other modules has been refused as well (one was related to database tweaks and second with booking timeslots).
And I've no patient to lick somebody's boots.
If you are not happy to keep them here, I'll upload it to external server.
Comment #6
kenorb commentedLatest version of WSOD module.
Read README.txt how to run it when you've on got WSOD.
Comment #7
kenorb commentedProject moved here:
http://drupal-dtools.googlecode.com/
Download links:
http://code.google.com/p/drupal-dtools/downloads/list
Happy?
Comment #8
dave reidIt's possible that your module(s) violate the CVS usage policy somehow (I couldn't tell from a brief inspection of the code). But if you wanted to host it on d.org, instead of posting everything here you should really get in touch with the CVS admins via the infrastructure queue using the 'CVS' component.
And 'won't fix' is the most appropriate status for this issue.
Comment #9
socialnicheguru commentedtried it. does it work with clean urls enabled?
i am getting wsod but the wsod page in instructions is white too and nothing is written to logs
Comment #10
kenorb commentedThere is unofficial CVS usage policy that says there is no need to use diagnostic modules, because Drupal is not babysitter and it's working fine so probably you using bad programmed contributed module so contact your module maintainer (even it's suspended = we don't care about your problems), because there is everything fine with the Drupal. For me this policy is the same as in MS, Windows is working fine in clean installation and tested by experts, but there is no support when you've got 1k viruses after 15min of using it and there are blue screens each 10 minutes, that mean you (as the end-user) doing something wrong.
Nobody wants to spend weeks for checking which module failed to run if there is something wrong in your production server. And why some page is loading 5 minutes.
Other wrong thinking: Most of the admins here think that if you can't change your server configuration on your hosting provider, change your hosting provider or buy your own server.
So if there is no possibility to change your configuration on the server, so why not use module if there is some possibility to do that?
"Message from the CVS maintainer: I'm not entirely sure that fixing a database administration problem is a requirement for a module. "
It was answer regarding to this module:
#361967: Increase MAX_JOIN_SIZE and MAX_ALLOWED_PACKET settings in system.install
And I'm sure that wsod module, and some similar modules will get the same answer with very tile thinking.
Answer regarding bench_chart (previous name: hook_stat) module:
"Message from the CVS maintainer:
(a) The term and prefix "hook" is reserved for actual Drupal module hooks.
(b) As of the current code, defining hooks inside of hook_stats_gen_hooks() does not make sense, since those functions are defined privately in the scope of hook_stats_gen_hooks(). Please make yourself familiar with PHP's function definitions.
(a) That's fine, I didn't know that I can't use hook name in my module name - no problem at all, I've changed name after few minutes, it was no any problem (ignoring that I'd to wait for this answer about 1 week) and all further replies to this request were ignored. So what? Apply again to get the same answer? Stupid.
(b) Who is familiar with PHP he is. Drupal structure can't list for you all hooks which are used in your Drupal application, so sometimes you have to create them dynamically (like module_builder receiving hook list from the website), so I can't define them manually if I don't know what to define. So how I can calculate execution time of specified hooks when I don't know what hooks are used. If there are some PHP core function available (like eval, where Drupal using it many times), why don't use them? I think it's the next excuse to refuse the next stupid module.
If you don't have space for new modules on your server, just fine, just say it.
Because I'm see a lot of suspended, not proper working modules, without even any dev dumps to test it, or some people even hard-coding the whole html code into module (or using short-tags or even more depreciated code or not OO) which are experienced maybe few days with Drupal and I don't know why, but they module were accepted.
In summary: It is my good will to create those modules and develop them for free, but if somebody don't like it because maybe he don't understand them, so don't judge before public does it. I really don't want to make any problem for anybody, so I think it's the right place to keep them, because I don't want situation, that after somebody will delete them without reason or some policy which is not written, because somebody will not like my code.
I've spend about 1 month for asking to add my modules (because I wanted to do that in Drupal way), but without success, after all it took me only 5 minutes to host them on GoogleCode.
If you want make Drupal more popular and developers to be more enjoyable by creating new exciting modules, change your CVS admin or policy to make it easier.
Comment #11
kenorb commentedactivelyOUT:
It's white because you don't have wsod on your front page (then change it in ?path to path where you have wsod as described in README.txt), or there is some bigger problem with your configuration or syntax error (then check your php logs if everything is fine).
Comment #12
kenorb commentedComment #13
socialnicheguru commentedJust want to say that I do appreciate this.
I have been in diagnostic hell because a few of the modules that I have I updated and they screwed up my config. It would have been easy if I just updated one at a time. but because I had such a great experience upto this point I did it in a batch.
Tools like this are really helpful so keep up the GREAT work!
And thanks again.
Comment #14
kenorb commentedactivelyOUT:
Thank you.
Did it solved your problem? Or there were some different problem?
Comment #15
socialnicheguru commentedI was able to solve it. I am keeping this module in my list for the next time too.
Comment #16
rsbecker commentedI was having WSOD problems so I uploaded dtools to try and figure out what was wrong. It didn't help, but by turning on error reporting to page, instead of to a file in php.ini I discovered that the problem was in the date module.
The reason I'm adding to this thread is that after I got my site up again I was having problems with the views module, getting WSODs on view pages and I could not edit views. I started getting errors such as "missing argument 2 in views_ui_analyze_button()..." at various lines in the views admin.inc file. But when I checked the error log it said:
chdir() [function.chdir]: No such file or directory (errno 2) in /home/www/spjdc.org/drupal/sites/all/modules/dtools/wsod/wsod.module on line 31.
After removing dtools from my site my views came back and all seem to work properly. I do not have any idea what the problem was, but I hope this helps you fix it.
Comment #17
damien tournoud commentedWon't fix is the appropriate status for this issue.
@kenorb: please get in touch with CVS administrators if you want to host your module on d.o, and benefit from the tools and visibility d.o provides.
Comment #18
kenorb commentedrsbecker:
Thanks for reporting this, I'll test it and I'll try to fix that error.
Damien:
Yes, this status is more appropriate, it won't fix. Thank you.
Why?
Read again: http://drupal.org/node/375629#comment-1302796
Comment #19
kenorb commentedAt least, after 4 months!!! WOW !!!!
I'm sure that somebody put this forward.
I was nearly to create my own Drupal server to be a CVS admin;)
Development moved into: http://drupal.org/project/dtools