Deprecated - Drupal core

drupal 4.4.1
debian sarge

when posting events on one drupal instance, we get:
warning: Invalid argument supplied for foreach() in
/var/www/potomacalliance.us/modules/subscriptions.module on line 192.

(whether or not the 'subscribe' checkbox is checked)

I can get around this by enclosing the offending line:
foreach ($node->taxonomy as $tid){
$strsent = $strsent . subscriptions_mailvars ($tid, $nid, $user->uid, "taxa", $strsent);
}

in an if ($node->taxonomy) {

Well not today actually, in August when my holiday is over is more accurate ;) oh and please be patient with types etc. I've this heavy fever kicking around in my head...

Since the Drupal 4.5.0 release schedule (http://drupal.org/node/view/9023) has been posted I've started thinking about the user, permission & taxonomy related features keeping me from deploying drupal in house at work. A while back Kjartan gave me (and two collegues) a very good demonstration of Drupals possibilities, (thanks again Kjartan :)) and during and after that meeting we have been discussing the following points internally :

I suspect that a fair amount of this is already possible using modules, but I would really prefere these things to be in the core. I have not been able to track down any information stating the plans for drupal regarding my thoughts below, and have not yet gained good enough knowledge or drupal so I might be asking for already existing features.

• Role and/or group based pages, nodes & blocks; In my organisation we want to show the employies different information based upon what kind of job they have. The consultants have other needs the leaders, the people on the switchboard, the economy people, etc. So basically we want to be able to push the most relevant information to the screen depending to reduce everyones time spent clicking on links to find the most relevant information.
• Role and/or group based access; Basically we want to be able to publish information that will only be accessable to those who belong to the right groups. This could be members of a trade union, the top leaders, supervisors, etc.
• MyDrupal; Functionality so that each user can choose the content of one or more blocks in different sections of the site. In addition every user would typically have there own MyDrupal page that they completely controll the content of. This could be an extention of the profile page, a page where you find & controll everything about yourself & your interests.
• Groups; We to be able to categorize the emploies into groups, and have them inherrit that groups rights. It should also be possible to be a member of several groups and nested groups in an hierarki. An example could be that all consultants are granted access to a discussion forum for topics that aren't mature enough for the general public and at the same time they also have access to diffrenet dicussion forums of they're unions, but not each othors unions.
• "Interactive" taxonomy; We would like the taxonomy to control the content on chosen parts of each page. If I'm reading an article about mobile phones, I would automatically want drupal to show me links to related articles in a block without any action taken by any if the authors, a part from them giving the articles some kind of metainformation during publishing.

Though I probably could have drawn up a better picture of I'm looking for what's most important for me right now is to get a clearer idea of where Drupal is heading reagarding these things.

Not sure if this is where I should ask about this...

I have link lists in the form of OPML files I want to include in the sidebar. Since they change very infrequently I decided to be lazy and write a script that parses it into a series of <a> tags. Where can I put the include() statement so that it's visible in the custom blocks?

In drupal, theme system makes the page looks better. But I feel strange that why theme system controls the layout of the page. I mean that some element on the page are fixed in theme, but not module or block, for example, the top block of the page. I think this is a bad idea that theme system can control the layout, except looks style. For the example above, I think there should be a block called "top" or "banner" to decide the layout of the top block ( logo, link, or so ).

Any chance to integrate D4B (Drupal for Bloggers) before the 4.5.0 code freeze?

http://james.seng.cc/wiki/wiki.cgi?Drupal_For_Bloggers

It seems that at least one D4B patch has been accepted into Drupal, but the process appears to be too slow.

The vanilla drupal-4.4 has only barebones blogging features. I've seen users accustomed to Movable Type and other popular blogging platforms kinda shrugging at Drupal, saying it does not provide features that they consider essential for a modern blogging software.
D4B seems to fill this gap; it adds powerful blogging extensions to Drupal, and the same users who are used to blog via MT and other apps said that Drupal + D4B is essentially equivalent to MT from a functional perspective.
Especially nowadays, after the changes (restrictions) in the licensing of certain blogging applications, there's a rather large user base in search for a good, free blogging software. Drupal + D4B could meet this need, if only the migration of the D4B patches into Drupal could be accelerated somehow.
I'm no Drupal or PHP expert at all, but from the little i can tell, the D4B patch does not seem exceedingly invasive. It affects the blogging components (obviously) and that's almost it.

I first experimented with Drupal as a blogging software, but it was barely usable (after being used to the "big" blogging apps).
I migrated then to D4B, which was much better, i had no problems so far, but patching Drupal at each and every new release with the D4B patch is a waste of time. A Drupal already containing D4B would be awesome.

Thank you in advance.

Most everybody agrees that Drupal search is lacking in some ways. Two of the main problems are the lack of support for multiple keyword searches and the lack of real fuzzy intelligence when evaluating keyword matches. This is, of course, a huge programming task, and Drupal programming resources are generally scarce and going to really important issues like permissions, flexinode, themes and features that are distinct to Drupal. Many people have ventured to tweak the search results, but I think that the problem would best be solved by using an existing external solution and abstracting the search in the Drupal core to an unimplemented API. Supporting pluggable search solutions through contributed modules and a well defined search API would open up a world of freedom and result in high quality search solutions.

One external package that I know of is PHPDig (http://www.phpdig.net/), and after installing it and testing it for a day, I think it could be used as a complete search solution for Drupal. It produces nice search results that don't violate the principle of least surprise, and the results can be optimized both through the administration interface and through the inclusion of tags that inhibit indexing.

Potential problems with this approach are the inherent redundancy of a Drupal site (many roads to Rome) which tend to clog the results a spider produces, the dependence that PHPDig has on using HTTP (it would be nicer if it could search the database), the need to install 3rd party (non Drupal) software, and in 4.4.1, the irritating fact that the embedding the PHPDig scripts and includes causes database connection conflicts.