By dries on

Over the past weeks, Drupal HEAD has become increasingly more stable. That is not to say that everything is well tested or that there are no bugs left. Fact is that the changes have been less intrusive as of late which probably marks a good time to discuss what lies ahead.

As it stands, I would like to freeze the current development branch on February 15. This would leave us approximately one month to add new features and to refactor existing code before we get to the serious stabilizing and debugging work required to deliver Drupal 4.4.0. Any thoughts? Any last-minute features you plan to work on?

For those that don't track the development, here is a list of the most significant changes that hit CVS the past month:

  • A file API to enable the development of better file and document management. Those who maintain a module with custom file handling code are encouraged to migrate to the new file API.
  • Several RSS aggregator improvements. Drupal's news aggregator now supports conditional GETs as well as several new tags like <image>, <pubDate>, <dc:date>, <dcterms:created>, <dcterms:issued> and <dcterms:modified>. The aggregator pages have also been revamped and RSS feeds can be exported using OPML.
  • We refactored the 404 (file not found) handling to support custom 404 pages.
  • Effort is put in improving the developer documentation.
  • Theme UnConeD has been replaced by a new theme called Chameleon and theme Marvin's code has been updated to use less tables and embrace CSS.
  • We improved the performance and memory footprint of the locale module.

See also: previous development update.

Comments

moshe weitzman’s picture

moshe weitzman commented

that feb 15 date looks good to me.

we had some excellent work submitted early in the 4.4 cycle with respect to menus [menus.module, navigation.module] and fine grained access control. neither of these 2 issues is resolved, and is starting to look doubtful for 4.4, which is a shame. in particular, the access control issue is blocking menu management. i've already submitted my best effort - hopefully we can work together to get something worthy into core.

i am not planning any significant work before 4.4. I will continue to shephard my outstanding patches.

drumm’s picture

drumm
he/him
Location NY, US
commented

My best effort is quickly maturing and will go to Drupal contrib CVS soon. I don't think we will decide from the approximately four solutions we have for 4.4. What needs to be done first is making sure that every method of viewing content in a node is secured and the _access hook is respected so these solutions have something to build upon that works.

My node module can say it's content is off limits and node/view/n goes away (with no message), but it remains viewable at comment/reply/n, node, tracker, node/feed, taxonomy/..., and statistics (which also seems to ignore the theme and log node view which were denied). Lets fix whats already in there for this version.

dries’s picture

dries commented

My node module can say it's content is off limits and node/view/n goes away (with no message), but it remains viewable at comment/reply/n, node, tracker, node/feed, taxonomy/..., and statistics.

I think fine-grained access control can't be done as a standalone module; it is an essential component and should integrate with the core system for various reasons such as performance, completeness and much more.

Maybe you can explain us first what your module is about: what does it do? How does it do it? What are its advantages and its limitations? Maybe share some screenshots if that would help us understand its functionality.

drumm’s picture

drumm
he/him
Location NY, US
commented

The quoted paragraph was really about any module. It points out that the functionality for finer grained access control capability is already there in nodes, but needs to be handled much better throughout Drupal since I can easily circumvent it by changing the url.

Right now I'm on a deadline to help out a site with 1000+ groups, scaling up to potentially 5000, which is being migrated to Drupal in about 3 days. Its version will be somewhat forked from my version because that number of groups is quite insane and the site needs to be quite customized. I'll post a link and walkthrough of the module once both exist.

I see group support happening somewhat like taxonomy, which is a module, but integral part of Drupal. From what I have seen on the mailing list and such it is now working its way out of a module and futher into Drupal because it has become so integral to how many things work.

dries’s picture

dries commented

The outstanding patches are at the top of my TODO list along with a number of usability issues. I hope that, all together, we can resolve most outstanding issues in time. As you know, everyone can help by either submitting and refining patches or by reviewing the patches in the patch queue. Also, it might be a good idea to summarize and revive some of the discussions here on drupal.org. Some ideas and concepts need time to mature.

Stefan Nagtegaal’s picture

Stefan Nagtegaal commented

Well, a link-management module would be a very valuable and nice thing that would bring drupal an even higher level than where already is..
I would like to work something out for this, so we can get rid of the $custom_links(), but it's kind a hard todo this without having a good start.
Is there someone here who would like to vollunteer helping me with this?

As that aside, I would like to ask your opinion about a patch that includes Clean urls using mod_mime for servers which doesn't support mod_rewrite.
I already wrote a patch before but never got much feedback on this. I hope to get some more while posting the idea here..

spooge’s picture

spooge commented

I've used this sneaky method before. I'm sure there are some downsides to this, but it does work. And also you can put all the logic for checking for nodes and whatnot in the php, a lot easier to change dynamically than mod rewrite rules.

.htaccess

ErrorDocument 404 /spooge/viewer.php<br />

viewer.php

... probably some code to test if node exists<br />
... and give an appropriate response if we need to<br />
header("HTTP/1.1 200 OK");<br />
.... page renderer<br />
judah’s picture

judah commented

I agree completely. I would like to help but if someone else is reading this, you may be more qualified to help. Do not prevent yourself from helping. Do it. I am a experienced programmer but Drupal structure is still pretty new to me so I still need to get up2speed and do not want to hold progress back on this. Stefan contact me at judah_at_drumbeatinsight_dot_com because I do not know how to contact another user on drupal.

ax’s picture

ax commented

please discuss issues of link managment at the corresponding feature request

patman’s picture

patman commented

I may be being naive, but it seems that attaching access controls to taxonomy terms would get problematic. Suppose I have a taxo that reads "/Content/Projects/Software/ProjectX". Some nodes of ProjectX should be public, some should be private to the project team. Sounds to me like I'd have to create "/Content/Projects/Software/ProjectX/Public" and "/Content/Projects/Software/ProjectX/Private", and then re-classify nodes from ".../Private" to ".../Public" when I'm ready to show them to the general public.


Would it not reasonable to assign group ownership of each node, and modify the permissions to provide for "Access Public Content" and "Access Group Content"? Then attach a GID to each node, and indicate the permissions granted to "owner group" in the DB.


Granted, this only provides for two dimensions of access control for each node - e.g. "Owner Group Rights" and "Everybody Else Rights", but I bet someone smarter than me could expand upon this basic idea to provide for multiple group permissions per node.


Hope this isn't too incoherent - it's 5:00 am here, and I'm still workin' on my first cup of coffee...

mred’s picture

mred commented

How about this: create a second vocabulary with two terms, public and private. Make it required.

patman’s picture

patman commented

...multiple vocabularies, but that's a pretty good idea. If this were hybridized with moshe's taxonomy_access patch, interesting things could happen. Don't think you'd want the "all terms / one term" option his patch currently provides, tho, and I still need to get my head around how this might work with the current role system. Ponder, ponder, ponder. Wish I were a better coder...

tavon’s picture

tavon commented

I totally agree with patman. I would very much prefer the ability to assign group ownership to each node rather then by taxonomy...

Group permissions can be solved by either including the user to multiple groups or by simply assigning multiple groups permissions to each node much like drupal currently handles parent-child relationships of taxonomy hierarchy(ie (node_id, group_id) x however many groups you want).

Besides access control, Drupal simply rocks~!

malfunct’s picture

malfunct commented

I think each item should have an access control list (whether it be a node or a taxonomy). You should be able to add single users or groups to this list with allow/deny permission. The most granular permission should apply so if member1 was part of group1 and a node had member1 denyed but the group was allowed then member1 of course would be denyed. Also if member1 was allowed for taxonomy1 but denyed on node1 that is part of taxonomy1 he would be denyed. I almost took the time to implement something like this but didn't see an easy way to add it as a module since it would require some changes to the content access functions but shouldn't be too hard to do.

Bèr Kessels’s picture

Bèr Kessels commented

We definetly need to find some way to solve the filters clashing issue.
When the filter system is defined, and frozen, the next step would be to make some kind of weighting system. The way you filter email in kmail/mozilla/firebird etc would be a nice thing.

I haven't looked into the new filter system yet, but i beleive it will solve lots of problems as it is right now. now the final bit still needs some attention.

Ber
Mediarevolution.org :: het platform voor online muziek

dries’s picture

dries commented

The 'filter clashing' is more important than the 'filter caching'. Not sure if anyone is working on that though. Any idea how other systems address this problem (given they have a notion of filters)?

moshe weitzman’s picture

moshe weitzman commented

one other blemish in HEAD is timezones. Kjartan posted a patch for this once but I understand it was deficient in some way. I'd like to see this sorted before 4.4

mason’s picture

mason commented

Given how basic of a fix this probably is and how much difference it will make for many drupal users it seems to me that this should be made a priority. I just wish I had the knowledge to fix this myself.

jjanssen’s picture

jjanssen commented

Hi, I'm a new to drupal (just picked it up a few weeks ago) and I'm a little confused as to the relationship of the version numbers of the main package (currently 4.3) and the version numbers of the contributed modules. From looking at the downloads and projects page, contributed modules are generally released to coincide with the core package version, but is that true? I would think that someone maintaining a module wouldn't necessarily want to wait for the next major version number before releasing a stable version of thier module with new features, etc. Just curious.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

It is not possible currently to release a new version of a contributed module between two releases of Drupal, since the contrib modules use the very same version numbers. This lets users easily pair their Drupal version with the available contributed modules. There are a lot of developing contrib modules, and the next major release will also reveal quite a few updated modules :).

beorn’s picture

beorn commented

I'm sure there are many of us, who are just waiting for a good opportunity to use Drupal as our CMS, but we just cannot because of lacking multi-languate support. For some people, mainly English speaking, might be unnecesary, but for other many people it's just a must for choosing a CMS, so the lack of this feature means directly that it is not considered.

I think too, that not only more people would use it, but also that Drupal would grow faster.

Vapor8’s picture

Vapor8 commented

And I assume you read the Drupal Documentation, saw the section labeled "Locale or internationalization support" which can be found at http://drupal.org/book/view/290 and realized that it was lacking something you needed? If so, what exactly more are you looking for?

magico’s picture

magico commented

I understand as multi-language the capability of the site display contents in several languages.
If Drupal already as this option to allow the internacionalization of the labels, there is one point that would be great: the internacionalization of the contents (nodes).

We would have a default language for the site, but we could publish nodes on several languages. This would allow to display a node in the default language, but having switch-icons (like current taxonomy works) we could see that node in a new language (if published by the editor).

Probably the best way to change Drupal to be completely multi-language would implement the country code imediatly after the domain: instead of http://drupal.org/node/... it would be http://drupal.org/en/node/ so when someone choose to see a specified node in another (available) language the site itself would completely ajust to that choice.

For me would be great to have this multi-language option, because I have available several articles in English, but my personal blog is in my mother language (portuguese) and would be nice to give the users a visual indication of that. Of course if we tried to see a node not published in a specific language, the node itself would be ajusted to show the default language.

jose reyero’s picture

jose reyero commented

HI! I am currently working in a module to do exactly this, adding a two letter language code to the url, based on user preferences or the browser language, and then translating it back in the next request, looking for a xx/nodename or defaulting to nodename if it doesn´t exist.

I also use url aliasing to create different versions of the same page or node: en/home, es/home....

I will be releasing it soon. You can see it working (spanish & english) at freelance.reyero.net

https://reyero.net

jose reyero’s picture

jose reyero commented

just released, check for i18n module in contrib/modules

https://reyero.net

beorn’s picture

beorn commented

Hello,

What I meant by my first posting is more what "magico" means in his comment. I know that Drupal can get already be translated. The problem that I see is this:

The international language is already English. Not esperanto or anything similar, but English. If we just have a website into our localized language, that's what we get: localized audience. I think that having a website at least both in English and our localized language is already a must nowadays.

Anyway, I'm already grateful about this good tool that Drupal is :)

killes@www.drop.org’s picture

killes@www.drop.org commented

Have a look at the translate_node module by James Walker.

It is in early development, but already usable:

http://cvs.drupal.org/viewcvs/contributions/sandbox/walkah/translate_node/

http://wsis.ecommons.ca/

--
Drupal services
My Drupal services

Tarlbot’s picture

Tarlbot commented

Themes like XTemplate (where you can specify an Icon graphic and custom css) need a way to specify a custom favicon.ico file. With this improvement multiple sites using one Drupal install can all have seperate favicons without the annoyance of making new templates for each.

Is there a site where we can see Chameleon in action? Quickly looking at the source code didn't tell me anything about if it had setup options like XTemplate does.

duntuk’s picture

duntuk commented

one of the features i'd like to see implemented into the next version:

Ability to specify what info will be displayed on a per page and/or per taxonomy basis...

e.g. in the administrative section, have check boxes when inputing new content, for whether to display: time/date, author, title, taxonomy, etc.

this would especially be usefull for Static Pages...

You can of course do this with some themes/templates, however, it would be nice to have this as a standard feature of Drupal...