Drupal Technical

When migrating from Drupal 5, the normal path would be to migrate everything (core/modules/themes) to the latest Drupal 5 versions, and then to the latest Drupal 6 versions, and then over to the Drupal 7 versions. How fortunate would have been the developers assigned the job if everything was as simple as that!

The default behavior of drupal_redirect_form in Drupal 6 is to redirect the user to $_GET['q'] when an explicit redirect location is not set in $form_state['redirect']. So any form submission from a Drupal page with additional querystrings like in a paginated form (for example admin content listing forms or admin comment listing forms) will result in the querystrings being lost. This can be frustrating when you administer content from such forms as you have to click the pager link and go back to the previous page after form submission. This can easily be fixed by adding a submit handler for the form in question and setting form_state redirect correctly.

The default comment moderation system in Drupal 6 is crude at best primarily because of the limitation of the admin comment listings. The information that is shown by default are 'Subject', 'Author', 'Posted in', 'Time' and 'Operations'. Now the main objective of comment moderation is to reject spam comments. None of these fields give any information about whether the comment is a spam comment or not and you will have to view each comment by going to the edit view of the comment and then approve or reject the comment. This is a very laborious and frustrating process. You have three options to solve this problem and get a better comment administration interface - one is to create a comment view, another is to alter the default comment administration form and the third is of course a custom solution for comment administration.

This is how you would normally render a view display passing filter inputs via code: $view = views_get_view('view-name'); $view->set_display('display-name'); $view->is_cacheable = FALSE; $filter_1 = $view->get_item('display-name', 'filter', 'filter_1_id'); $filter_2 = $view->get_item('display-name', 'filter', 'filter_2_id'); $filter_1['value'] = "value1"; $filter_2['value'] = "value2"; $view->set_item('display-name', 'filter', 'filter_1_id', $filter_1); $view->set_item('display-name', 'filter', 'filter_2_id', $filter_2); dpm($view->render());

Blocks are regions on a Drupal website that show small but significant pieces of content. Blocks are an important component from the perspective of a Drupal website. Blocks are usually assigned to regions in a page and they are supposed to be printed on a page. However there are many instances where you might want to print a block within a content. It is not directly possible to assign a block to a region within content (node in Drupal speak) as you can do with a page. But as with everything in Drupal there is a way to do that.

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.