Another impressed visitor

I just wanted to begin with a short thank-you for the work that's already been done on this impressive CMS. I've been working with *phpNuke for a little more than a year, however even with the eventual release of 6.5, I find there's still a lot I wish Nuke could do that can't be done without substantial modification.

Drupal 4.1.0 released

Drupal 4.1.0 is now available.

This release adds support for user profiles, comment moderation, improved forums, an auto-throttle congestion control mechanism, improved statistics tracking, paging, various performance improvements, and much more.

The source code is available at:

http://www.drupal.org/drupal/drupal-4.1.0.tgz

For bug reports or future features use the project page:

New import module

There's a new version of the import module available for testing. In this implementation both feeds and items are nodes. It is able to
read RSS 0.9x, 1.0 and 2.0 and has support for some DC items, the SY module and the content:encoded stuff. In addition
to that it also makes use of RSS 2.0's guid and comments elemens (and some more). Adding a feed is as simple as
supplying the url and all the other options will be filled in automagically. There's also an option to promote news
items automatically Only local images are allowed..

It needs (lots of) testing and bugs fixed, while some features still need to be implemented. I need some help of taxonomy
specialists to find a way to set taxonomy terms on items automatically. When a feed is administered you should be able
to specify a set of taxonomy terms for the items.

If you want to test it out on your own installation read the INSTALL file carefully, as there are some
important changes when using the cron.php script.
You can see it in action on my test site.

Hope you like it. Please send feature suggestions, bug fixes, comments, questions etc. to me Only local images are allowed. (breyten@dataloss.nl)

Taxonomy interface / setting node terms

Linking vocabularies to specific content types (page, story, project etc) is great, and what I think is one of the best features of drupal. However, there are definitely elements of this implementation that could be improved. Here are some of my initial usability impressions. Just some initial rapidfire thoughts, as there are some tricky issues which i am yet to fully get my head around. overall i think that drupal sets a very good standard, and i'd like to see it get better...

1) multiple selects are great, but i would find checkboxes far easier to use in forms. i think this interface for joining nodes to terms could be a little more advanced - maybe the admin could control the input type of a vocabularly- select box, radio, checkbox, etc...

2) rather than being static markers, multiple select terms could be able to be filtered - so you could combine two or three terms, and filter the content of the site from this combination, or cruise from page to page with the filter storing your settings, and loading all content based on those settings...

3) logically following on from this, there could be some capacity for assigning specific terms to certain users, this would be particularly useful for sites with magazine focused categories, where there might be individual sub-editors for different sections...

4) different vocabularies have variations in meaning and weight, it would be good to have more options for the way a specific vocabulary interacts with the content/navigation - there could be built in vocabulary types such as Subject , Section , Topic , etc... focusing on being more of a type language, rather than generic labels... just a possibility, and i really have to think it through a bit more coherently - but just thought i'd float a few things out...

Adaptive design for weblog software; Drupal evolution

On interconnected, Matt Webb is thinking about adaptive and evolutionary design in terms of software architecture in order to discuss considerations for the design of weblog software. In this discussion, he discusses the benefits of a pull model of Unix software design, which focusses on the development of small independent pieces of code that make up the software ecology. Matt describes the software components and abstraction layer within this sort of ecology and how they should function, relate and interact with each other to create an ecology that allows for adaptability and evolvability.

These concepts for a weblog platform/environment clearly describe the ecology that has developed out of the Drupal community. Hidden to most users of our Drupal systems is the open development community that lives largely in the development mailing list which shares and corrects bugs, pores over feature enhancements, discusses core and contributed modules and their interoperability, and continues a thread of discussion about how Drupal should be evolved. The core functionalities of this system have been refined slowly and over recent months new and added effort is finally being given to interface issues as a new group of UI designers have joined to bring usability issues to the fore.

Drupal has been an interesting project for me to watch from the inside. I work in an organization with strong roots in Unix application development, which prides itself on its evolutionary design process. This process, however, is one that involves a small team of programmers that independently create elegant applications that interoperate somehow.

More flexible group based permission system

I'm curious how much work/how feasible it would be to extend Drupal to have a more flexible based group permissions system. I understand that you can setup "user roles" and assign a user a role, then define that roles permissions. However, this is very very limited.

I'd like to see a system where multiple groups can be created, each group has it's own permission settings. Then a user can be a member of multiple groups.

A new admin section might be needed, where the site admins assign a user to a group. Or, each group might be able to have it's own administrator, who has authority to add or delete users from their own group.

In addition, the main site admin could juggle users around into/out of various groups as they saw fit.

In addition, I'd like to see the group permissions extended where users could create a group. Then, the users could define what nodes or content or calendar/events, etc... can be accessed by the public at large, or by the user assigned groups.

This would be basically extending drupal more towards the PHProjekt style of user/group permissions. Instead of dwelling in the land of CMS, moving more into the land of CMS/GroupWare based systems. A lot of the basics to Drupal would lend itself well to expanding into GroupWare, just none of the controls exist to manage this.

Any thoughts? Basically, I want to use PHProjekt for my use, but it's too GroupWare oriented, and Drupal is too CMS and not enough GroupWare oriented.

Pages

Subscribe with RSS Subscribe to Drupal.org RSS