By dries on
It has been a while since the last Drupal 4.5.0 status report so the following is a summary of the key aspects we have been working on since the last status report, posted approximately three months ago.
- Tabs. Drupal pages now use tabs for local tasks as can be seen on this example screenshot.
- Node level permissions. It is now possible to control access to individual posts - either by user, by role or by category.
- Sticky forum posts. You'll be able to make forum posts sticky such that they are presented at the top of the forum topic listings.
- Multiple roles per user. Users can be assigned multiple roles which is very convenient.
- Blogging improvements. We added a 'recent comments' and 'categories' block that are typically available on weblogs, and included support for auto-discovery via RSD.
- Form handling. Form handling has been reworked to ensure consistency across modules and to improve error handling and accessibility.
- Administration pages. We reorganized a significant portion of the administration pages, which makes it more intuitive to administer your Drupal site.
- Gzip compression. To reduce bandwidth, Drupal can send gzip compressed pages.
We are also actively working on the following aspects:
- Internationalization. A new locale module has been developed. The new module facilitates importing and exporting translations (using PO files) and lets you translate Drupal using specialized desktop applications like KBabel and friends.
- Document management. We hope to include a document management module in core that lets you upload documents (typically images) and use them in your posts.
- Filter improvements. Effort is put in improving the filter system so you can select between different input formats (i.e. HTML vs BBCode vs Textile vs StructuredText) as well as define filter settings per role rather than just globally.
Comments
bravo
Good news indeed dries et al. I do think however that drupal.org (the site) should publish more often about the progress drupal (the code) is making.
If one isnt following the very busy mailinglists, one might think drupal's development is not that high. Which is of course not the case.
--
groets
bertb
--
groets
bert boerland
brief rant
drupal.org (the site) doesn't publish content by itself. there have been no updates for 3 months because noone took the time to post here. anyone is welcome to do this. please take advantage.
Communication matters
Right on. The 'news and announcements' forum is open for everyone. Intersting posts have always been promoted to the front page so everyone can help keeping the community up-to-date. More than once, I have encouraged people to.
fantastic
sounds like some great developments - particularly the node level permissions.
Thanks to everyone who has made, and continues to make, drupal such a high quality, feature-rich piece of software, while still being so user friendly, so that relative newbs like me can use it!
regarding using images in posts I have found the image.module and image_assist.module to be really useful and flexible for this.
Thanks again guys
Steve
===
Steve Parks
Convivio - a digital services agency
http://weareconvivio.com
Image handling is currently a
Image handling is currently a hot topic in the mailing lists. I look forward to seeing--and using--the fruit of this labor.
hear hear
in total agreement. can't wait to use it on my personal site, plus the roles and permissions and doc features will be great for our drupal intranet...
Gzip compression
Just a short remark on this: Drupal will send cached pages to anonymous users in gzipped form. Registerd users will still receive uncompressed data and mod_gzip should be used. the advantage of the gzipped cache is that Drupal compresses the cache once and sends it to all page requests. Mod_gzip would have compressed the cached page everytime anew. Some benchmarks indicate that this is an improvement of about 13% on page requests /time for pages served to anonymous users.
--
Drupal services
My Drupal services
gzip compression
I've already enabled gzip compression by simply adding the following lines to my .htaccess:
php_flag zlib.output_compression On
php_value zlib.output_compression_level 5
It makes a pretty big difference - my bandwidth usage is down at least 40% since I made that change.
--
Mike Cohen, http://www.mcdevzone.com/
Pardon my ignorance
I must say I'm a bit confused. Where in the process does the file get decompressed? Is this done by the user's browser? I've actually never head of such a thing.
Re: Pardon my ignorance
The user's browser decompresses the content. This is supported by NS4.05+, IE4+, Opera, Gecko and most other modern browsers.
How to determine if Apache is ready?
Interesting. I honestly never heard of that before. But how do I take advantage of this?
I see the following lines in my httpd.conf file.
<IfModule mod_mime.c>
AddEncoding x-comress Z
AddEncoding x-gzip gz tgz
...
...
</IfModule>
So if I enable thie feature in Drupal, will I be set?
You don't need to do anything
You don't need to do anything. After enabling the cache Drupal will compress the cache automatically. If a browser should not accept gzipped pages Drupal will uncompress the cache before sending the page. Since most browsers do support gzipped pages this will not happen often, though.
But again: This only applies for cached pages that are served to anonymous users. Enabling mod_gzip is still recommended to keep your bandwidth usage low.
--
Drupal services
My Drupal services
Installing mod_gzip
OK, I'll look into installing mod_gzip. Can anyone offer some quick advice/tips on how to do that? I'm running a Debian system but not too practiced with sys admin stuff.
please address your questions in the right place.
The comments under a post are meant to comment to the post and to the comments to the post etc. Asking support on a place meant for discussion and additional information, obscures the original content of the article.
Support can be found in the supprt forums on the support list and in the issue tracker (using Category: sup[port requests)
[Ber | webschuur.com]
Doc Management vs Image Module
Glad to see that an attachment handler will be integrated into drupal core. But, I have been using image module for a long time. I wonder if the doc manager will replace the function of image module in every aspect and will there be a migration tool from image.module to new doc manager.
UGlee
Not exactly the same
The answer is no the "doc manager" is probably not a replacement for the image module in every aspect. At least not the attachment patch I'm working on. There are two very distinct needs:
1) Adding images, download files, or movies to stories as related downloads etc. This is what the attachment patch does. It allows you to upload a piece of content that is binary in nature (any kind of file) and reference it inline to that node. This allow you to add an image to a story which has no context out of the story. The image or attachment is part of the node and does not exist on it’s own. You would use this when you don't want people to search and find the image, or comment on the image the image is only there to support the story or node. You would also want to use the attachment patch when don't want to have to manage your support images and files separately from the story or article itself.
2) Managing images and displaying them as standalone items. This is where the article or story IS the image. People need to comment on, search for, and classify the image itself, or you want to create galleries of images. The image module still has it's place here. There is some working going on right now to make this much more flexible.
All that being said an "upgrade" path is difficult to define. Some sites use the image module as use case 1, some use it as use case 2, and still others use both. I'll add it on my list of things to do to think on how we might accomplish one.
Adrians Template System
Please please please. I think it is doing great. Whip him or something to get it in within the time frame.
dont whip me
I just might like it....
The template system is going smashingly, you can get the latest patch and some screenshots on the project issue, and furthermore. a description of how it all works in this forum thread
Install Framework?
After screwing around with a few things (and breaking everything so wonderfully), I was wondering if there is going to be an install framework? Specifically, something to handle the database changes, updates, and deletes for individual modules. I love the update script for the main application (all changes since and its ability to detect the last one), but I would love that for all the modules.
Some modules do that, but I've had a couple upgrade woes (which is why I included the database changes since...).
Oh, and the ability to detect uninstalled modules and their databases would be cool. I got burned for a bit when the CVS version had menu (or menus) and I was using the old menus module.
Cheers!
it's almost definately not going into core.
For this release, but I am probably going to have an installer-enabled tarball available at release time
Unfortunately, I don't see many contrib modules supporting a third party installer by default, however .. i want to have the code finished and working so it can go into HEAD the moment we start developing in earnest again
Great
I think that if you build it, people will eventually submit patches to make it work. I know I would at least try to get it working, at least for the modules I need. I have 8 drupal sites, each one with a different password (and I don't use easy passwords), so it is frustrating when I forget to update one module in one database. :)
Multiple Template Support?
I heard a rumor that the new version of Drupal would support multiple templates for creating different sections on the site... Is that still true?
Yes. and no.
The new template system will allow you to do this via a contrib module, but I don't foresee the specific functionality getting into core , atleast in a 4.5 time frame. The template system will probably (hopefully?) get into 4.5.
+1 for this
I'd gladly wait longer for a release to see this in core. I've been following the discussion on the dev mail list and consider it to be one of the top new features.
- Robert Douglass
-----
visit me at www.robshouse.net
tabs...
I think the tabs could turn out to be a very nice thing. However, I'd also like to have real ACLs, if possible, with inheritance of user rights on nodes looking at the URL alias if possible....
It would be damn nice if users can't edit other users pages....
Dries wrote: Node level pe
Dries wrote:
Node level permissions. It is now possible to control access to individual posts - either by user, by role or by category.
Read: With Drupal 4.5 you can make your own ACL module. There will be custom modules in a wide range of flavours.
--
Drupal services
My Drupal services
Does that translate to
Does that translate to: You cannot enable node level permissions out of the box with 4.5 ??
I ask because I can't find anything about it, and I can't seem to be able to figure it out in the CVS I installed yesterday.
Dropping in from Langemarks Cafe.
Exactly
There are so many different approaches that it would be difficult to agree on one "standard" approach. You can find implementations in JonBob's sandbox, though.
--
Drupal services
My Drupal services