Debugging
more_horiz
close

on 10th March 2015 / by deepa.n
Recently, we came across an error - "Forbidden You don't have permission to access / on this server" while trying to run a new virtual host on our Ubuntu 14.04 machine. The first step to troubleshoot this type of issue would be to check at your Apache error logs as this specific type status can be thrown due to many reasons. Since we have Apache 2.4.7 installed on our system, each virtual host file should have the .conf extension. We corrected the extension also. But the issue was still there. However this information lead us to think on it further and finally we found the reason for the issue. The access control configuration has changed in the newer version of Apache and many of the old configurations are deprecated in Apache 2.4. The old configuration 'Allow from all' is no more compatible and 'Require all granted' is the new equivalent. Here are some examples for Apache 2.2 Vs Apache 2.4 access controls. Apache 2.2 config: Order allow,deny Allow from allApache 2.4 config: Require all grantedFor fixing the above issue, just replace Order allow,deny Allow from allwith Require all grantedin your new virtual host .conf file. Hope this helps. We provide Drupal offshore development services. To know more feel free to contact us. Apache Debugging Ubuntu Leave a reply Your email address will not be published. Required fields are marker * Avi (not verified) access_time 23 May 2019 - 18:34 I just spend the whole afternoon trying to figure out why apache2 won't come up. I must have gone through 10's of sites. This is the only one that helped. Thanks! Anonymous (not verified) access_time 23 May 2019 - 18:34 Fyi... That message can also occur in some browsers when a client (user) uses a VPN addon extension in her/his browser & tries to connect to a server which forbids such connections (yes, some servers can be configured to respond with that message when traffic from specific IPs (i..e known VPN servers) are received. If you are using a VPN, disable it to see if that message disappears. Gary (not verified) access_time 23 May 2019 - 18:34 Just installed Mac Yosemite 10.10.5. initially http://localhost worked fine. After configuring the Virtual Host configuration. I get the error: You don't have permission to access / on this server. Require all granted That option is set in my httpd.conf Any suggestions. Karla (not verified) access_time 23 May 2019 - 18:34 Thank you so very much. Add new comment
more_horiz
close

on 24th December 2014 / by jagadeesh
When I was calling CRM_Core_DAO::executeQuery() it gave error. I don't have any idea what went wrong. Not sure whether the SQL statement was correct or not. After searching for some time I found one function, composeQuery() in CRM_Core_DAO. It can be used to verify SQL query. echo CRM_Core_DAO::composeQuery($sql, $params);This will display the exact SQL Query which is going to run on the database. SO from that we can identify whether there is any issue in the query or not. Drupal MySQL Debugging CiviCRM Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 26th July 2013 / by muhammed.junaid
While working on Drupal Views, we might want to examine the query executed by the View to get its data. Analyzing the query may help us to identify why the view does not produce expected result. Read on to know how to view the SQL query executed by a View. You need a patch that can be applied temporarily to views_plugin_query_default.inc file of the view module. --- a/sites/all/modules/views/plugins/views_plugin_query_default.inc +++ b/sites/all/modules/views/plugins/views_plugin_query_default.inc @@ -1393,6 +1393,19 @@ class views_plugin_query_default extends views_plugin_query { $query->range($offset, $limit); } + $query_string = (string)$query; + $query_string = str_replace('{', '', $query_string); + $query_string = str_replace('}', '', $query_string); + $query_params = $query->getArguments(); + foreach($query_params as $placeholder => $value) { + if(!is_numeric($value)) { + $query_string = str_replace($placeholder, "'$value'", $query_string); + } + else { + $query_string = str_replace($placeholder, $value, $query_string); + } + } + drupal_set_message($query_string); $result = $query->execute(); $view->result = array();Now if you run your view page you will get the query as a message. The advantage with this custom logic is that it does not require you to install any other module. Moreover you can copy and paste the output directly to the MySQL terminal or phpMyAdmin box and execute the query. Sure, we can use dpq() here instead of this custom logic. But dpq() does not remove the curly braces in the query. We will have to remove the curly braces before we execute the query within our favorite SQL terminal. Hope this article was helpful. We would love to hear your feedback regarding the comments form below. Drupal Debugging Drupal Views Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 03rd June 2013 / by naveen.pl
We had recently faced an issue in one of our client's website running on Drupal 5. The site had crashed and we were unable to continue development. We began analyzing the problem by checking the free space on the site and came to the conclusion that the now deprecated PHP Ereg function was causing the site to crash. If you are facing the same issue in one of your Drupal sites, read on to know how we successfully fixed the bug. First let us explain how we found the bug. We began by checking the free space on the website and found that more than 50% space was still available. Then we checked the database and we found that the watchdog table had become corrupted. We truncated the table and it actually started working! We may not have actually gone for truncating the table, since it was a watchdog table. But the issue was due to the corrupted table. We also realized that a few pages that were working, no longer worked. They were all showing WSOD and we found around 20 pages of warning messages recorded in a short duration of time. Interestingly, they were all generated around a PHP ereg function. elseif ($depth >= $min_depth && ereg($mask, $file)) { We have also noticed that the server was upgraded recently from 5.1 to 5.3. Then we had a look into the PHP manual for ereg and noticed the following warning about function. "This function has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged." We realized that the solution to this problem was to replace it with preg_match which is somewhat similar to ereg and supported by PHP. Here is how we did it. example code // Original code elseif ($depth >= $min_depth && ereg($mask, $file)) { // Replaced code. elseif ($depth >= $min_depth && mb_ereg($mask, $file)) { // Original code if(!ereg("^[A-Za-z0-9\-|_]*$", $name)) // Replaced code. if(!preg_match("/[^A-z0-9_\-]/", $name)) This fixed the issue caused by ereg function which is deprecated after php 5.3. Hope this article was helpful to you too. Drupal Drupal 5 Debugging Leave a reply Your email address will not be published. Required fields are marker *
more_horiz
close

on 23rd May 2013 / by nidhi.sen
As a drupal developer, there were times when I was stuck at some point. At these times, 'devel' module came to my rescue. There are many debugging functions provided by devel. Those are dpm, dpr, dvm, dvr etc. Here, I am going to explain 'dpr()' provided by devel module. 'dpr' is actually an alias for 'dprint_r' function. dpr function prints a variable in the browser without using krumo other than 'dpm()s' which uses krumo display. The output of dpr function is printed inside the page header. So even if you haven't given $messages to print in your template file, you could see the result. The dpr function is defined as follows: function dpr($input, $return = FALSE, $name = NULL) { return dprint_r($input, $return, $name); } The syntax to use dpr is same as that of dpm. Suppose you want to print the variable $form. To use dpr, just add dpr($form); If you don't want to print the variable but to return it as a string, then you may use: dpr($form, $return = TRUE, $name = NULL); // The parameter '$name' distinguishes different call to dpr(). Trust me when I say that dpr has its own advantage while comparing with print_r(). Refer the screenshots if you don't believe me. Hope this helps!!!Reference:http://ratatosk.net/drupal/tutorials/debugging-drupal.html Drupal Debugging Leave a reply Your email address will not be published. Required fields are marker * shine (not verified) access_time 23 May 2019 - 18:34 I am a professional drupal developer since three years and I do wish to admit the fact that your blog is very much useful for me. The header of the drupal modules has a dpm functions supported by the devel module. Add new comment
more_horiz
close

on 29th April 2013 / by Anoop John
In Drupal 7 Image module offers an image field which makes available an image widget for file fields that can be added to content types. This will allow for upload of images to the image field which can then later be processed by the image module and be presented using the different image styles as configured. This means that image module should have the ability to process files uploaded using this field. The image_field_widget_form extends the form created by file_field_widget_form and adds additional validation on the file extensions to ensure that the extension is something that is supported by the module. However by default the file_field offered by the file module allows any set of extensions to be configured in the field widget settings. Image module silently filters this list in image_field_widget_form (http://drupal.org/node/1014816#comment-5656548) and takes out extensions that are not supported by the module. The currently supported extensions are ('png', 'gif', 'jpg', 'jpeg' - line 321, image.field.inc in image module) This means that TIFF which is not an extension supported by the module will be silently filtered out by image module causing a validation error during upload even when tiff is added as a valid extension in the field widget settings. There is work going on (at the time of writing this article) to add support for different image types via plugins and this has already been added to Drupal 8 (http://drupal.org/node/1664844). So till tiff is supported by image module the extensions that can be uploaded will remain 'png', 'gif', 'jpg', 'jpeg'. You can patch image.field.inc to support more extensions but there will be problems while displaying these images. Drupal Drupal 7 Debugging Leave a reply Your email address will not be published. Required fields are marker *
close

on 01st August 2012 / by deepa.n
We were testing our newly implemented modal popup for a login functionality. It was working pretty good in Firefox, Opera, and Chrome but not in IE8. When attempts to login by clicking on a login link the login modal was not appearing in IE8. Firebug said nothing, but jquery-1.7.2.min.js in IE showed the following error: Message: Invalid argument. Line: 4 Char: 190 Code: 0 URI: http:// example.com/files/js/js_05f008a1c47b8161d7e4a8e6bbff1b3f_0.js The referred line is as follows: this.parentNode.insertBefore( a, this.nextSibling ); The surrounding script is as follows: after:function() { if (this[0]&&this[0].parentNode) { return this.domManip(arguments,!1,function(a) { this.parentNode.insertBefore(a,this.nextSibling); }); } if (arguments.length) { var a=this.pushStack(this,"after",arguments); a.push.apply(a,f.clean(arguments)); return a; } } Here’s how to deal (how we dealt with) this issue: First of all, when you identify some js error in IE be sure that it is because of violating the standards. To start off, just check for HTML errors and fix them one by one. All you had to do in this case was: Perform HTML Validation using http://validator.w3.org/ Check for HTML errors. For details about the most common errors found during xhtml validation, refer this. Correct the listed HTML Errors one by one. Try the same if you are facing the same issue. That should pretty much solve this one. If that does not seem to do the job for you, just put in a comment below. We’ll try our best to help. Javascript Web Development HTML Debugging Leave a reply Your email address will not be published. Required fields are marker *
close

on 02nd July 2012 / by Anoop John
We recently saw this error on a Drupal 6 site that had not been updated for quite a while."warning: call_user_func_array() expects parameter 2 to be array, string given in sites/all/modules/contrib/views/views.module" means what it says. call_user_func_array expects the second parameter to be an array whereas a string was given instead. You can troubleshoot problems like this by writing a bit of debug code before the line where the error is reported. In this case you would want to write a condition that checks whether the second parameter that is passed to the call_user_func_array is indeed an array and if not, use debug_backtrace to print the backtrace for call and see where the request originated from. Since debug_backtrace prints out the arguments that are passed to these function calls as well you will be able to trace and find the location where the error crept into the system. In our case the error originated from an incorrect implementation of the get_access_callback method in class views_plugin_access_perm class present in views_plugin_access_perm.inc file inside plugins folder inside views. The callback was called with the second argument as a permission string instead of as a single valued array. The solution to the problem was to first patch the file to change the second argument to a single valued array with the single permission as the parameter. The above may not be the problem in your case but you can follow a similar approach to find the solution to your problem. Drupal Drupal Development Debugging Leave a reply Your email address will not be published. Required fields are marker *
close

on 29th June 2012 / by jiby.john
As the world of internet grows day to day, the more educated and ever-wanting userbase now needs more data asynchronously. They don’t like to wait or load another page to see their data. In such situations we developers need to use more and more AJAX (Asynchronous JavaScript and XML - http://en.wikipedia.org/wiki/Ajax_(programming)) in the development of websites. Using AJAX in your web-development workflow is not that much difficult as you think. There is already a wide range of famous ajax libraries that make handling asynchronous requests easy for us. The next problem that quickly comes to our minds is how to debug these requests. Debugging such requests primarily involves seeing the requested URL, the parameters passed and of course the responses. Here comes FireBug to your rescue. Yes that’s the same FireBug you use to debug common HTML and CSS issues from within Firefox. If you haven’t already heard about FireBug, it is a Firefox addon (https://addons.mozilla.org/en-US/firefox/addon/firebug/) that turns your favourite opensource web browser into an almost complete realtime web-development IDE. Fire up Firebug in your browser window and click the console tab, along the top of the firebug panel that shows up. You might have to enable it if it’s not already populating data. Refer the attached screen shot (fig.1.1) Then initiate your ajax request with whatever initiation method you have defined for that (clicking a link/button, or something like that). Then you can see the corresponding ajax request url in the console. If you want to see more details about that request, just click on that line in the Firebug panel. Every request contains 4 sections - Headers, Post, Response, HTML. Select each of the tabs to see more details on what’s happening underneath. That should be it. Enjoy the vast amount of information that turns up at your fingertips, and make the best use of what you have. Happy Debugging! Web Development Debugging Leave a reply Your email address will not be published. Required fields are marker * Anonymous (not verified) access_time 23 May 2019 - 18:34 Thanks. That helps me alot sancolgates (not verified) access_time 23 May 2019 - 18:34 thanks! it help Add new comment
close

on 11th May 2012 / by vimal
As a Drupal developer, when we get an error, we may want to know the functions that are called before the system called the function where we get the error. In this case, views_trace() function comes to your help. This function is available if Drupal’s Views module is installed and enabled. Here is the function from views.module function views_trace() { $message = ''; foreach (debug_backtrace() as $item) { if (!empty($item['file']) && !in_array($item['function'], array('vsm_trace', 'vpr_trace', 'views_trace'))) { $message .= basename($item['file']) .": ". (empty($item['class']) ? '' : ($item['class'] .'->')) ."$item[function] line $item[line]" ."\n"; } } return $message; } Drupal Drupal Development Debugging Leave a reply Your email address will not be published. Required fields are marker *