See the Mailing lists or Drupal Issue queue. There are also various working groups on groups.drupal.org

Erratic theme behaviour

Running under WAMP5 on XP (sp2).

Depending on which theme I choose (phptemplates), I don't get all my primary links, or I don't get my title and slogan. Fancy Works fine, for example, but spreadfoxfire doesn't show title and slogan.

Anybody experiencing this kind of stuff with various themes?

Limiting blocks by roles: why can't this be built-in to block.module?

Searching on drupal.org, i've found literally dozens of posts asking about how to display or hide blocks based on the role of the user viewing a page. Currently, the only ways to do this are to either:

  1. Define a new custom php block that checks the role
  2. Write a whole new module, just to implement hook_block()

This seems like such a basic, fundamental feature for blocks, something many drupal users want to be able to do. Sadly, neither of these options are very easy, particularly for people not familiar with php or writing code in general. Clearly, many hours of effort have been spent by people trying to get this working, generating traffic in the support forums, etc. Why can't this feature just be built into the block module itself?

For example, we could add another field to the {blocks} table called something like "roles". This would hold a list of role ids for which the given block should be displayed. for any given block being published in block_list(), when we query the {blocks} table, we also grab this field. when checking to see if the given block should be displayed, we add another check to see if any of the roles in the global $user object match a role from this field. if there are no values in the "roles" field at all, that would mean to display the block (assuming the existing logic said the block should be displayed). Then, in the admin/block/configure page to control the "custom visibility settings" for any given block, we could add another form group called "Restrict block to these roles", with a set of checkboxes for each role defined on the system. Just like the existing "Restrict block to specific content types:" set of checkboxes, if none of them are checked, we'd leave the "roles" field blank in the {blocks} table, which would mean it should be displayed for all roles.

Selectively supress the display of blocks using detected Browser as criterion.

I am trying to write a module that enables the display of enabled blocks to be dependent on the users browser using the browsecap module - the purpose here is to get around the problems associated with some of the DHTML menu modules like nice_menu or Shortcuts having trouble with Internet Explorer, but conceivably other blocks might benefit from returning seperate versions depending upon the browser rather than lots of messy CSS or Javascript hacks. (in effect NiceMenus is a seperate version of Menu).

Using Zend profiler with Drupal

Hi All,

I've been trying for some time to use the profiler that comes with Zend Studio to profile a Drupal page render. It works great for other web apps I've got running, but it just hangs when I try to profile Drupal.

I was wondering, has anyone had success using Zend Studio 4.1's profile mechanism? If so, what did they do? What about other profiling mechanisms?

-Josh

hook_settings-details needed

hi all,
i am new to drupal..can any one tell me what the function of Hook_settings function does..Any defining url or definition left here will be helpful

Madhanagopal.k

node.module not php5 compatible?

i've got the latest node.module for 4.6.5 (v 1.485.2.14) but it looks like it isn't php5 compatible. i get errors with eventfinder and other flexinode dependent modules.

the offending lines of code seem to be lines 351-355 (invalid php5):

Pages

Subscribe with RSS Subscribe to RSS - Deprecated - Drupal core