Drupal development open

By Dries on 28 Apr 2006 at 14:11 UTC

The code freeze is over! We're accepting new features in the development version of Drupal while the forthcoming Drupal 4.7.0 release is being finalized and maintained parallel to that in the newly created DRUPAL-4-7 branch. That said, bear in mind that the current focus is to release Drupal 4.7.0, and not to add features to the development version.

[edit. Instead of throwing here every feature request in mind, please use the the request new feature facility of the issue tracker but only after you have given a lot of consideration that your feature is truly core worthy. chx]

Comments

I don't understand. Does

nathandigriz commented 28 April 2006 at 14:21

I don't understand. Does this apply to 4.8? or 4.7? Does this mean that i18n.module work can start for 4.7 or is it delayed because 4.7 may change? Jose said no i18n until 4.7 is finalized. Doesthis mean that it is finalized?

Releases

Dries commented 28 April 2006 at 14:42

Drupal 4.7 is in "maintenance mode", meaning we just fix bugs. We don't add new features to Drupal 4.7.

Note that there is no i18n.module in core. However, as of today, people can start pushing a i18n.module for inclusion in the development version of Drupal. Eventually, the development version will be released as Drupal 4.8.0. So, as of today, we start shaping what will be Drupal 4.8.0.

Actually I am quite happy

nathandigriz commented 30 April 2006 at 17:48

Actually I am quite happy with i18n not being part of the core. Because being part of the core would not guarantee that contributions would be i18n compatible. Nothing about bringing i18n to core would force compliance which is what would be needed for it to work.

I just would like to be able to have a starting point for creating i18n sites in 4.7 in a similar fashion that Drupal 4.6 does now.

As far as 4.8 goes I would like it to be i18n.module "compliant" more actually seeing the module in core. Something in the lines of providing database fields and soft checks for i18n presence

Daylight Saving Time

Sage-1 commented 28 April 2006 at 14:55

Any chance daylight saving time support will be a priority for the next release? I know crunchywelch suggested having the DST support from his event module added to Drupal core, but not much seems to have happened on this. I think this is the one major feature still missing from Drupal. I'd like to assist any effort to get this included, but I'm not much of a coder -- what can I do to help?

+1

praseodym commented 28 April 2006 at 14:59

+1 on that. Especially since changing the time zone totally ****s up events with event.module, because all times are saved together with the timezone. If you then set your timezone forward one hour, all dates will change one hour forward (so event times, node submission times, etc.).

Many things

Boris Mann commented 28 April 2006 at 15:03

There are a couple of things you can do. First, suggest and lobby for features much earlier in the cycle. Start today. Write a forum post or handbook entry suggesting all the features/improvements you would like to see. Gather support, put together some funding, and get people to build it.

Once things are built, you can help by testing and providing feedback, bug reports, and so on.

Of course I will do this,

Sage-1 commented 30 April 2006 at 17:32

Of course I will do this, but it bears noting that I did exactly what you suggest back when 4.6 was originally released, requesting the feature be added for 4.7. Killes wrote a rudimentary patch to address it, and discussion pretty much stopped after it was suggested that the DST support in cruncywelch's event.module be included in core. I asked about it again last year at the first code freeze announcement for 4.7, and was referred to Killes' patch, and the attempt to include the event.module's DST support in core had either been rejected or stalled, for unknown reasons.

If there is any sort of organized effort to add this feature, I want to be in on it. I've tested patches and the like before and can do so again, but it would be nice if there was some kind of formal organization to it. Is there a way to start a new project, like a module but for outstanding features (particularly complicated ones like this), so that there can be a more organized effort to get this feature into the next release?

If those working on it get

sepeck commented 1 May 2006 at 03:40

If those working on it get distracted and you want it in, then you will need to carry advocacy of your inclusion. Submit patch, advocate, respond and refine patch.... rinse and repeat. Some thigs take a long long time and several Drupal versions to get in. Some because the necessary infrastructure isn;t there to support it, or it;s a hack instead of an elegant solution, simply no time or no attention or got forgotten.

If you want a feature, then you need to follow up on it until it is acceptable to the other developers. Either through convincing them or demonstrating a convining solution.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}

Question about CVS

ajwwong commented 28 April 2006 at 15:21

So, I've been downloading Drupal CVS (through CVS) (and a bunch of contrib modules CVS) every couple days or so to keep current with the latest bug fixes for Drupal core and the modules. If I want to just keep with 4.7 does this mean that I should now switch my "CVS settings" so that I'm downloading Drupal 4.7 core and contrib (rather than CVS core and contrib)?
Albert
www.ithou.org

DRUPAL-4-7

Dries commented 28 April 2006 at 16:12

Yes, you have to use the DRUPAL-4-7 tag when you checkout a copy of core. Like that, you'll get all the latest fixes in the Drupal 4.7 release series (and none of the experimental features in the development version). More information is available in the Drupal handbook and/or in the CVS manual.

Thanks, Dries!

ajwwong commented 28 April 2006 at 17:31

Appreciate the response!

I guess I'll do my research into SmartCVS and how to switch my project from one that updates from CVS to one that updates from the 4.7 branch.

Albert
www.ithou.org

Accessibility

rstamm commented 28 April 2006 at 16:07

attribute accesskey in menu items

http://drupal.org/node/57826

Definately no accesskeys

vigo-1 commented 28 April 2006 at 20:49

Strong -1 from me. Accesskeys can, and generally do, cause more harm than good - by being confusing (specific to each site), locale specific and interfeering with assistive technology shortcuts. Right motivation, wrong implementation - the potential for misuse by well-meaning admins alone nixes it for me. See my breif comments in the issue for more details.

All I can hope for is more and more AJAX :D

jacauc commented 28 April 2006 at 16:51

I would love to see full-fledged AJAX in Drupal! We now have a platform that supports it, so we might as well embrace the possiblities.
E.g. having users log in without a page refresh... or having a Who's online block that updates dynamically. etc etc.

Thanks
jacauc

http://www.dieinter.net

Just remember AJAX isn't

solipsist commented 28 April 2006 at 16:54

Just remember AJAX isn't some universal solution to every problem, it can confuse users as the Back button doesn't work as they expect. Traditonally a browser hasn't worked like a software application, so we can't just make it behave like one all of a sudden and expect people to "get" it. :)

--
Jakob Persson
web design and usability consulting
http://www.jakob-persson.com

--
Jakob Persson - blog
Leancept – Digital effect and innovation agency

AJAX Drafts

bradlis7 commented 28 April 2006 at 19:03

I really want to push for node drafts, that are automatically saved through ajax, like GMail's mail composer. When people lose an article they've spent 30 minutes writing, it can be very discouraging.

--
Bradlis7.com | Churchofchristnet

JS must make things easier - not run them

vigo-1 commented 28 April 2006 at 20:55

Another thing to remember is many users either cannot run javascript (or to use the incorrect initialism that all Javascript seems be labeled as these days AJAX) or cannot access data in the DOM changed on the fly (no current screenreader technology can access dynamically generated or changed DOM content, and there is no way to notify the screenreader that content has changed). Javascript is great, but it must be used carefully and always to enhance interfaces and make them easier to use - never as a requirement. Careful testing is required. Care must especially taken when "hiding" and "showing" content with a JS switch - if you use the CSS property display: hidden as the default a screenreader user will never see that content.

Let's be careful, enhance Drupal to make it prettier and easier for all who use it and keep Drupal wearing the crown of being the most accessible free content management and commmunity platform available today.

Very good points, vigo. We

Gunny-1 commented 1 May 2006 at 22:03

Very good points, vigo. We got to substantiate with pros and cons when it comes to include Ajax feature(s) in the core modules, instead of jumping in everywhere.

Project issues?

markus_petrux commented 28 April 2006 at 18:37

How this affects Drupal project issues? I mean, when one is filed against 'cvs' does that mean it is no longer related to 4.7? ...and things like that. :-)

Doubt is the beginning, not the end of wisdom.

I was going to ask the same

nathandigriz commented 28 April 2006 at 18:52

I was going to ask the same thing about patches. It is already very confusing trying to find the right one because use of the term "cvs" does not have a version tied to it.

Battle Plans, results of the Roadmap discussions at DrupalCon

Frando commented 28 April 2006 at 19:07

Is there already some kind of first battle plan for 4.8 (or 5.0?) available?

It seems as if cck and views will get into core, and in the mailing list I read that a better installation system is a must-have for the next release...

I know, the development branch had just be reopened, but apart from that - which parts of drupal will be in the main focus for the next release? taxonomy?

I just read on http://drupal.org/node/46638 that this had been a topic on the DrupalCon, but in the handbook there is only the agenda but not the results ...

best regards,
frando

Check- all js function for checkboxes

joshk commented 28 April 2006 at 19:24

It would be good to have a built-in "check-all" function when form-api creates an element of #checkboxes type.

One place where this should definitely be implemented is on the admin/node screen. Also on admin/access.

------
Personal: Outlandish Josh
Professional: Trellon

------
Personal: Outlandish Josh
Professional: Pantheon

Issue #53224 is what you

bradlis7 commented 29 April 2006 at 18:13

Issue #53224 is what you describe I believe.

--
Bradlis7.com | Churchofchristnet

Facility for admin only code

peterx commented 29 April 2006 at 01:17

Some modules have huge chunks of code that is only used in admin. The code can be help screens, settings, or reports. Why have all that code loaded for regular users?

If Drupal had a small number of facilities in core and the right documentation, module developers would be encouraged to split out the admin code. The skinny version of module xxxx could be named xxxx.lite and the heavy full fat version for administrators could be named xxxx.pizza.

Refer to http://drupal.org/node/60103#comment-115273 as an example of a change made to reduce the code added to a module. This is one approach that combines splitting a module into two modules with the second module containing only admin code. The second module loads itself only if the user is in the right directory.

The change to one module might make little difference when you use file and PHP caching software but there could be a significant improvement when all modules go on a code diet.

petermoulding.com/web_architect

Pluggable Admin Tools Module?

Scott commented 30 April 2006 at 19:18

Along the lines of peterx's suggestion...

We might keep superfluous admin code out of non-admin operations and reduce the overall number of modules by creating an admin_tools.module with a plug-in type of design.

Module developers would have the option to take admin-only code out of their modules and make it into an admin_tools plugin that only gets loaded when an admin accesses the admin "toolbox". This might also be a natural way to centralize and organize admin functions -- individual tools could even be assigned taxonomy terms and weights to organize the admin tools interface.

Admin_tools plugins could also be stand-alone tools for admin-only operations such as analyzing traffic patterns, doing bulk operations on nodes/profiles, examining database tables, etc. I think this would be preferable to creating/installing an entire module just to add one admin-only function, which is often required with the current system.

Admin functions that need to be more integrated with non-admin functions could remain in the appropriate modules.

The main admin_tools page could include simple form for uploading new or updated admin_tools plugins.

Fantastic idea

vigo-1 commented 30 April 2006 at 20:43

This is an absolutely brilliant idea. Not only would it increase the encapsulation of modules but has the potential to significantly reduce page rendering time for non-admin users. Please, please, please get this into Drupal 5.0 ("Wombat").

Maintain xyz structure

peterx commented 1 May 2006 at 09:30

You can install module xyz as modules/xyz/xyz.module. If the module is split into user and admin section then it would be nice to keep them together in modules/xyz/. That is the reason I installed statistics_reports as modules/statistics_reports/statistics_reports.module and modules/statistics_reports/statistics_reports.admin.php.

The admin code could be loaded by a separate system but please keep the code in the same directory as the regular module and using the same internal structure so we do not have to learn a separate system or look in several places to find the code for one module.

petermoulding.com/web_architect

KISS indeed, framework needed

pwolanin commented 2 May 2006 at 18:49

I agree with keeping the parts together as suggested by peterx.

Seems like the best mechanism for this kind of dynamic loading needs to be agreed upon, and then a framework and/or example code made availbe for developers to use as a starting point.

Will looking for "admin" in the URL be generally applicable (as you put in your code at http://drupal.org/node/60103#comment-115273)? For example, admin-type functions for the webform module happen by default at /webform not /admin/webform. Does this need to be standarized? Also, one could move the menu item to a different part of the menu tree.

---
Work: BioRAFT

Give nodes more access rights

vph commented 29 April 2006 at 02:19

I think the next version of Drupal should enrich the node system. Drupal is based on nodes, and there's an effort to fuse taxonomy into the node structure (category module). Therefore, to enrich the node structure would be very helpful.

My understanding of Drupal's architecture is limited, but I think two properties should be added to the "node rights":

+ preview
+ comment

Currently, node access rights include: create, update, delete and view. There are many applications such as forums, where I think these access rights are not sufficient. Adding the "preview" right to the node structure would add the ability to allow all users to preview (see titles and/or teasers) but only a set of users to view the node contents. Adding the "comment" right would allow only a set of users to comment on those nodes.

Presently, there is no "preview" property. Nodes are viewable if and only if they are previewable. In terms of commentable, you can enable a set of users to comment all on nodes or none. If you turn off comment on the set of users, they can not comment on any pages, stories, etc. If you turn on comment for a story/page, then all users that are allowed to comment will be able to comment on them. This picture is so complicated, because I think it is the wrong approach.

The better approach is to have clearly two dimensions. On the x-axis, you have nodes (including taxonomies if they are implemented as nodes; as in category.module) with properties creatable, viewable, updatable, deletable, previewable and commentable. On the y-axis you have roles. Everything is much nicer.

Premium module, and comment settings

eaton commented 29 April 2006 at 19:23

Unless I'm misunderstanding you, the comment module already exposes global commenting options for each role. In addition, the excellent Premium.module allows you to show teasers to all users while hiding the full node from others. Check it out! :)

--
Eaton's blog | VotingAPI discussion

--
Eaton — Partner at Autogram

Yeah, I'd like to see better

solipsist commented 2 May 2006 at 18:11

Yeah, I'd like to see better access control over all. "Roles" doesn't work if you need hundreds of groups because the access control page will be a mile wide and virtually useless.
It needs to be easy to for example prevent anonymous users accessing a certain site section, but since Drupal doesnot provide any core features that let you structure your site hierarchically for access control and generating hierarchical site navigation, this requires several modules now.
So better access control, better access control at group level, easier way to set access to whole sections of the site (let nodes inherit access permissions) is something Drupal must have in order provide the same basic features as other CMSses.

--
Jakob Persson
web design and usability consulting
http://www.jakob-persson.com

--
Jakob Persson - blog
Leancept – Digital effect and innovation agency

Toward an ontology

vph commented 29 April 2006 at 02:47

In addition to enriching nodes' access rights (as discussed above), the taxonomy system can be extended toward an ontology system. A taxonomy is basically an ontology with an is-a relationship and a concept of relatedness. This is more or less what Drupal's taxonomy is. To enrich Drupal's taxonomy, I think the next relation to have is a "has-a" relationship.

Currently, the "has-a" relationship is realized in a way that is not very clean. If let's say, you want a node to be assigned to two taxonomies (e.g. let's take a movie review application in which each node can be classified with two taxonomies Director and Actor), then as far as I know you can only do this in two ways: (1) pick the story module; if the story module is already used, pick the page module; if it's already used, well copy it and name that something else; (2) use flexinode. The approach of using flexi-node is cleaner, but a flexinode is not a node, so it doesn't have the priviledges of automatically inheriting all the good stuffs that nodes have. Conceptually, it is still not a clean solution. If you need another type of node, say restaurant reviews, then you have to design another flexinode type and then again not having the good stuffs that regular nodes have.

A better solution is to implement the "has-a" relationship, genuinely, in the taxonomy system. When a new taxonomy is created, in addition to specifying properties such as multiple parent, etc., there should be the option of attaching other taxonomies to it. In this example, I can create a taxonomy Movie Review and attach taxonomies Director and Actor to it. This means a new Movie Review node will automatically "has a" Directory category and "has a" Actor category selection. This way, I don't need to duplicate story.module, page.module and name it something else. I don't need to create a new flexinode type either. This "has-a" feature will make Drupal a very powerful tool to create communities that integrate neatly and beautifully many different object types.

Once the has-a relationship is implemented, you can have very nice effects such as initializing nodes with default values. I have seen a few people asking for this "initialization" feature.

Toward a "true" Folksonomy

vph commented 29 April 2006 at 03:07

The free-tagging feature in 4.7 is a great step toward a folksonomy -- or an uncontrolled taxonomy. In my view, it is great not because it has the ajax feature and you don't have to select from a list, but because users can add new terms to the taxonomy. This is what folksonomy is about, giving control to the community.

I would suggest two small features that makes taxonomy even more folksonomy friendly.

1) Have the option to allow priviledged users to add new terms to a node without actually modifying the content of the node. This way not only the author of the node but also the whole community can classify the node content. I think it will be very useful in folksonomy application. It should not be hard, I played around a little with this already.

2) Have the option to allow privileged users to add a new free-tagging taxonomy to a node-type. The reason is similar to the above.

1) and 2) can be easily done

killes@www.drop.org commented 30 April 2006 at 15:48

1) and 2) can be easily done as a contrib module for those who need it.
--
Drupal services
My Drupal services

--
Drupal services
My Drupal services

a media manager as a core module

jimmny.c commented 30 April 2006 at 15:00

- I think drupal need an official media (image, video, sound ...) manager. there is gallery 2 and acid free, and perhaps others, but i think it's better if it will be a "official module" feature.

- I think same for a rich text editor. An official RTE will be better.

- A new drupal user don't see all the drupal features, because he don't know all modules. I already coded an existing feature... I think it's a problem, but i don't have solution. More modules => more features => less visibility on one module / feature.

- A module autoinstaller ?

---------
drupal-france.lxs-cms.com

Better url alias management

sgwealti commented 30 April 2006 at 20:08

URL aliasing doesn't scale. It starts to get impossible to manage URL aliases once you have thousands of them. I'm not sure what the best way to do it is but we need to start thinking about how to implement something to make them more manageable.

conf_url_rewrite

moshe weitzman commented 1 May 2006 at 01:52

you can alias on the fly in php using conf_url_rewrite(). see docs for details. thats the scalable way.

Aliasing in 4.7 was

matt westgate commented 1 May 2006 at 01:57

Aliasing in 4.7 was rewritten to perform much better than its predecessor. Rather than loading the entire alias table per request, Drupal only loads the aliases it needs per page request.

Core Drupal in its own directory, configuration, modules and the

solipsist commented 1 May 2006 at 12:06

"Core Drupal in its own directory, configuration, modules and themes in custom"

Worth considering as a configuration option:
http://drupal.org/node/22269
http://drupal.org/node/22336

Unless I'm totally off the track here and it's been already implemented but it wasn't mentioned on the issue tracker page so I thought I should post it anyway just to be sure.

--
Jakob Persson
web design and usability consulting
http://www.jakob-persson.com

--
Jakob Persson - blog
Leancept – Digital effect and innovation agency

Phoning home

jacauc commented 2 May 2006 at 06:09

How about a "phone home" ability to keep everything on your site up to date.
I think the new "update.php" is great with the added ability to also upgrade contrib modules, but couldn't we add functionality to notify the admin user that a new version of core or any particular module is available for download on the drupal site? (and possibly automatically download/install the updates?)
Something similar to Windows Update for XP or liveupdate for norton...

Just a thought - might be very useful :P

http://www.dieinter.net

sections.module functionality in core

omar commented 2 May 2006 at 13:54

One of the major improvements to Drupal that Dries neglected to mention in his post about the 4.7.0 release is the ability to create theme-specific-block-configurations. IMHO, this is a huge improvement in terms of making it feasible to implement all those crazy ideas that designers come up with ;-)

This is a relatively minor issue as it can be easily accomplished with the sections.module or with hacks to the theme files, but I think that being able to easily create different layouts for different sections of a site would be very appreciated and we are 95% there already anyway.

ooops...

omar commented 2 May 2006 at 14:03

I should be using the request new feature ... sorry for overlooking this.

image support in core please

omar commented 2 May 2006 at 13:58

(I understand that there has been a lot of dicussion about this in the community and I must admit that I have not followed it all so forgive me if I am missing something here but...)

There isn't a single site that I have done where the users/clients didn't want support for images in posts. This seems like a no-brainer to me.