Deprecated - Drupal core

- drupal 4.4.1-1 (Debian)

- GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)

---------------

bazar:~/tmp# diff /usr/share/drupal/scripts/cron.sh my_cron.sh
9c9
< if [ "$URL" -ne "$conf" ]; then
---
> if [ "$URL" != "$conf" ]; then

---------------

The first case gives me a Bash error, since the test operator requires an INTEGER value, while $URL and $conf are STRING values.

Anyway, the second form (with '!=' operator) it's OK for me :)

bye

a.

All,

I have found that deep inside the node module there are "divs" put in there which 1st denote that the form is a "node-form" and then separately denote whether or not it is "admin" or "standard".

My thought is that this is really in the wrong place. First I'm not entirely sure I understand why these are in here. If anyone knows why this bit of form information should be treated different than other form information, please let me know.

Second...it seems odd to me that only "node-forms" are called out as different (and hence can be themed using CSS). I'm cool with the concept of differentitating different types of forms...and even different pieces of a form...but there may be a cleaner (more themeable) way to accomplish this.

I'd propose that we add a parameter to the form function in the common.inc that would allow for a "type" to be specified. Then we can assign the type to the form itself (allowing CSS to handle different classes of forms separately.

Second, If it is important to have sub-groupings within forms we should create a construct for such a thing. I would suggest adding another form function ("form_chunk","form_set","form_section" are names that come to mind) that (following the model of from group) you would add a "section" to which in turn would hold form elements or groups. The new form function ("form_section") would also allow for a title (if folks wanted to name their sections). The form section would be a themeable so that theme developers can customize how they want the output of their forms to look, and developers can create different types of forms.

With the release of PHP5.0 comming up, it seems like it might be a good idea to start thinking about what Drupal 5.0 is going to be like?

Has anyone thought about this yet? It would be nice to get started thinking about what we want Drupal 5.0 to do, what features the core will have, and what fundamental issues with the 4.0 branch do we want to address.

Obviously we are not going to start development anytime soon, but I think that this is a good time to start thinking about what Drupal 5.0, and maybe start do some planning.

Hi there,

I have been sent to this wb site in the hopes that someone may be interested in assisting me with a project I am working on.

I run a magazine in Australia for students. We are a business that does not make alot of profit as most of our money goes back into the business to offer better support services for students everywhere.

I discovered a bug in my system, which I traced back to Apache's mod_rewrite.
I hacked together a workaround for myself, and want to mention it here because I guess this forum has higher visibility than the issues list... and you guys might know if:
- this is really a general bug in mod_rewrite or not; (I'm not an Apache (or PHP/Drupal) wizard)
- a workaround should (not) be created in Drupal, and it should (not) be done in the way I did it...

(I'll create an issue accordingly, afterwards.)

My issue is: I'm using special characters '/' and '&' in some URLs, and my mod_rewrite (apache 1.3.29) cannot cope with them.
The specific situation is, I'm using the article module, and some article categories contain a '&'. A link to the category 'this & that' translates to an URL
'http://SITE/article/this+%36+that'

However,
- mod_rewrite screws up, translating the '%36' back to '&' (at least, I think so, because $_GET["q"] just contains 'article/this ')
- if mod_rewrite encounters a '%2F' in the URL, it just throws a 404 immediately. (I saw this mentioned as a mod_rewrite bug somewhere when Googling, too.)

My solution is to patch common.inc like below...
This will just force an 'unclean version' of the URL whenever it encounters a %36 or %2F.

Is this good for Drupal core?
Or should there be a third option for Clean URLs ('clean except when special chars used') which enables this?
Or is there a better way to achieve this?
Or should Drupal not care at all (because my config is just stupid and normal Apache's don't have this problem)?

I currently have the luck to have access to a php5-enabled production server, in which I can test directly how drupal works with the latest version of php.
I am being patching for a couple of hours, I think now most things are fixed. I havent fully tested it, so chances are something is still not parsed ok.
Main issue were raised by new array_merge behaviour, so some additional type cast were required.