Deprecated - Drupal core

I am experimenting with the forum module and noticed in the forum code that it is currently not possible to add terms from other vocabularies to forum documents. Within the taxonomy edit form of a vocabulary I am able to associate the vocabulary with forum document types, but the dropdown with terms is not visible when I add/edit forum documents. Why is it not possible to select additional terms for forum documents?

Hi. Following the code freeze, I did my duty and upgraded a test site to drupal CVS HEAD and played around and discovered a bug in user.module. I posted a bug report (http://drupal.org/node/view/5965), and some kind soul (TDobes) posted a patch from weitzman's sandbox. It's in the patch queue now, and so it stays.

I just thought I would leave a note to tell you guys that my mini-wizard api I was developing for the install system took on a life of it's own , and not only is enabling a very nice and clean install process , but is also completely re-usable for ANY form of sequential user input.

At this point in time, i dont think there's a way in hell this install stuff is getting into core for 4.4.0 , but we should still look at some of the stuff I have done..

There is currently a level of ambiguity between Drupal-implementation and browser-implementation of
the standard regarding empty URI refences. This might be an issue. At the very least it should be clear
why the current implementation is considered the best one (it might already be, but I'm just not in the know.)

I want to start working on an implementation for the Node Permissions that have been talked about. While I have no idea just yet how I'll do it all, I have an idea of how the project can be divided into manageable "parts". Node Permissions, as it is, will probably result in a lot of refactoring in the Drupal core (and I'm not familiar enough with the system to be the sole designer).

I've been randomly thinking, and I've broken down the idea into smaller, hopefully more-manageable parts that can be integrated on an incremental basis.

1. Users can belong to Multiple Roles. I started this and then gave up when I realised I didn't know what I was doing, but I'll probably start it up again. A new database table (something like "users_in_roles" needs to be added that maps the uid to an rid. (Right now, the user table maps directly to the role table.) All of the SQL will need to be changed, of course. My primary problem with this, as of now, is Serialization in the user.module. I don't know what it does. I have a feeling that it might have to do with authentication in the Drupal Network - if that's the case, then adding Multiple Roles might break cross-compatibility.
2. Adding a moderator to roles. Assuming that people like the idea of appointing a moderator to look after a user role, this would be one next 'feature' step.
3. Adding permissions per taxonomy We can adapt the node system to start checking permissions baesd on the taxonomy permissions. Not sure what needs to be done here, though.
4. Adding the set of "standardized" permissions. The Permission Requirements thread mentions a few schemes for standardized permissions, and I think this is a great idea - it'll cut down on the "maintain book" vs. "edit book" vs. "administer book" kind of permissions we see right now. This will also probably break every
   module.
5. Customized User Groups. This should be done in tandem with per-node permissions, since one without the other isn't very useful.
6. Per-node Permissions. When taxonomy permissions are set, then per-node permissions shouldn't be a big deal.

I'm really just brainstorming at this point and I haven't looked too much in detail for many of the above issues (especially permissions). However, if we plan to implement this well, I am very confident that database renormalization must occur (therefore breaking a lot of SQL) and the Module APIs for permissions will change (therefore requiring a lot of module rewrites). As a result I plan to start looking at the code in detail so that, if we do make major changes, there'll be plenty of time before Drupal 4.5.0 is released to look at the design issues.

From what I understand, Clean URL support in achieved through mod_rewrite using the following rule:



^(.*)$ index.php?q=$1



What that means is that URL's of the form http://somesite.com/node/view/1 are rewritten as http://somesite.com/index.php?q=node/view/1



According to RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax, Page 14, section 3.4,

3.4. Query Component

   The query component is a string of information to be interpreted by
   the resource.

      query         = *uric

   Within a query component, the characters ";", "/", "?", ":", "@",
   "&", "=", "+", ",", and "$" are reserved.

Which means that the "/" character when it appears in the Query Component has to be escaped!



I read somewhere that Mozilla used to complain when it encountered an unescaped "/" character in the query component, but since IE did not seem to mind, they eventually turned a blind eye toward it too. So, having an unescaped "/" in the query component does not create an immediate problem.



That aside, if my interpretation is correct, then wouldn't the right thing (following standards) to do be escaping the "/" character in the query component, that is, shouldn't url() in includes/common.inc escape $url?