Blogs

If your servers using non-standart SSH port, then Drush can fail using aliases for some commands (in my case it was sql-sync). The fix is already committed to HEAD, but until then you can apply patch from here
http://drupal.org/node/820514

And the fix is - convert all your CSS files into UTF-8 encoding.
From here: http://drupal.org/node/881132

Symptoms:
1. XDebug is not working
2. Code completion is not working
3. "Go-to definition" is not working (CTRL+Click on function name)
4. Eclipse do not see your PHP errors

Usually this means that Eclipse do not know that your project is PHP type, sometimes it happens when you create a project via checkout from SVN. So, what to do:
1. Create new PHP project and save it. Check if everything working with the new project.
2. Check .project file in the root of the new project directory you just created. You should see something like this:

If you didn't know it before - there is a nice module which will provide autocomplete functionality to all of the search forms on your Drupal site. Recently i have installed this module on our development box and everything was pretty fine. Today i pushed a new version of the site to the preproduction box and autocomplete stops working with errors:

PHP Fatal error: Uncaught exception 'Exception' with message '"0" Status: Request failed' in /sites/all/modules/apachesolr/Drupal_Apache_Solr_Service.php:272
Stack trace:

The reason - core search module is still indexing content. The solution - go to admin/settings/search and set "Number of items to index per cron run" to 0. This will prevent core search module to work. And to clear the tables you can press "Re-index site" button.

Return the path to the current themed element.
The main thing is that if you will call it from the module preprocess hook - it will return the
path to the module.

So if you want to keep your logic in code and still be able to help your designer/js-coder (who doesn't know for sure where is the custom module files, but know the theming a bit):

drupal_add_js(drupal_get_path('theme', variable_get('theme_default', 'garland')) ."/js/cooljavacriptfilehere.js");

From api.drupal.org:

As you may already know, you can control the comments module behavior with user permissions and with per node-type settings. But what if you want to change the node comments access on the fly?

The problem:
On some nodes i want to disable the comment form for current user, but show him the comments. It is possible with the default comment settings of this node type or with access permissions. But what if the permissions are configured for full read-write access for the current type of node and current user have permission to post comments?

Solution:

This time again there were some really critical bugs in alpha2, like in some conditions passwords were saving in plain text, so after some time we now have the alpha3!
Changes since DRUPAL-7-0-ALPHA2:

• Drupal 7 now ships with jQuery 1.4.2 and jQuery UI 1.8.
• API change: AJAX commands are now defined as array('#type' => 'ajax', '#commands' => $output) rather than array('#type' => 'ajax_commands', '#ajax_commands' => $output).
• API change: There is a new form element #type 'text_format', should be used for textareas with format selectors (e.g. body fields).
  

Security fixes in 6.16:

Installation cross site scripting
A user-supplied value is directly output during installation allowing a malicious user to craft a URL and perform a cross-site scripting attack. The exploit can only be conducted on sites not yet installed.

Open redirection
The API function drupal_goto() is susceptible to a phishing attack. An attacker could formulate a redirect in a way that gets the Drupal site to send the user to an arbitrarily provided URL. No user submitted data will be sent to that URL.