Drupal 6: status update

By Dries on 2 May 2007 at 16:48 UTC

It's been a while since we provided a status update. And because not all of you are subscribed to the development mailing list or keep track of the issue queue, I figured a quick status update would be in order. Here is a list of some of the key features that already made it into the development version of Drupal and that will be part of the final Drupal 6 release:

Various theme system improvements: modules will be able to provide template files (.tpl.php) for their themes without having to create theme_ functions. In addition, Drupal will automatically pick up template files in the theme directories without having to write a single line of code. Just copy the template file from the module directory to your theme directory and start modifying your theme's copy. That's all you'll have to do.
Moved various internationalization features into core. Language setup screens are now separated from interface translation. It is also possible to have arbitrary path prefixes or domains set up for different languages. Posts can have languages associated with them. Multilingual websites have been a key focus for Drupal 6 and will continue to be for the remainder of the development cycle.
Improved logging functionality. We made it possible to have custom logging functionality, via your own modules. This is useful for large Drupal sites because it lets you customize how you want to get notified about certain events. For example, you could now configure Drupal to send a SMS or text message to your cell phone when someone leaves a comment, as well as integrate with external monitoring infrastructure, such as syslog, and enterprise network monitoring applications. Logging to the watchdog table is now optional (but on by default), so large sites can decrease database load by disabling the new dblog module and using something else instead (e.g syslog module).
Various usability improvements: made the installer look pretty, made it easier to deal with teasers, made signature support optional , etc.
We rewrote the menu system from scratch. The code of the new system is easier to understand and maintain and Drupal will require much less memory meanwhile performing at least as good as Drupal 5.

There are a lot of other things that are still being worked on, but more about these later once they hit the development version of Drupal.

The code freeze for Drupal 6 was originally scheduled for June 1 (4 weeks from now), and I think that by then, we'll have a couple more nice improvements. We'll see how things go but all in all, things are shaping up nicely, and we're well on track to make Drupal 6 another great release. Of course, there is still time to champion your favorite patches, or to get improvements into Drupal 6. Best to start working on this now, as things gets super-busy as we get closer to the code freeze.

Comments

Great features are expecting

yngens commented 2 May 2007 at 16:56

Great features are expecting us, in Drupal 6! Huge thanks for everyone who makes it possible for us to use them.

documentation is critical.

JohnForsythe commented 17 June 2007 at 16:33

With great features comes great responsibility.. to document them ;)

--
John Forsythe
Need reliable Drupal hosting?

Is there any WYSIWYG Editing API being developed?

John Bryan commented 2 May 2007 at 17:39

One of the biggest usability problems for site visitors, especially for charity & community sites, is the lack of any "WYSIWYG" editors for Drupal. (PLEASE: See other posts for the difference between pretty editors such as TinyMCE and W.Y.S.I.W.Y.G.)

Part of the problem is the lack of a proper API/functions to allow interaction and control between Drupal and GUI based text editors. Some key aspects of this interface would be:-

Passing the culmative CSS formating information to the editor
Passing the CSS context of the text being edited (i.e. is it going to be a Page node, custom block type etc.) so that the right formating from the CSS can be applied.
Drupal to control what fields the GUI editor can be enabled for
Drupal to control permissions for who can use the active editor
Drupal to generate user button to Enable/Disable GUI editor for fields
Etc.

This would allow the GUI editors to just do the editing, simplifying editor development and providing consitent administration of API based editors.

Some or all of the passing of CSS information may(?) be possible just by ensuring that, when a field is enabled for WYSIWYG editing, it is immediately preceeded by the style tags that would be present when actually published. All an editor may need to do then is apply the currently active CSS styles. Currently a node content editing field operates in the CSS context of a generic edited field and not that of the context that it is published under.

The detriment this lacking of WYSIWYG is not apparent to most computer literate it seems. But for the non-computer literate it is a substantial obstacle to userability e.g.

Little O'l Granny
Mr Corner Greengrocer
Visually impared
The not so bright etc.

For charity use, non-commercial organisation and other uses I find the great functionality of Drupal severely impaired as a community portal by users being scared and confused when trying to add content.

P.S. For those about to point out how many WYSIWYG editors do 'exist' for Drupal - please find out what WYSIWYG means ;¬). And before pointing out how TinyMCE etc. can be hammered to simulate WYSIWYG, that is not pratical when either maintaining multiple sites or sites with multiple or evolving themes.

P.P.S. I say this because I like Drupal 8¬)
Regards

John Bryan
www.ALT2.com
Application Integration Specialists
Tel: UK 08700 3456-31

...

sepeck commented 2 May 2007 at 18:30

Freeze is June 1st. You have until then for patches. If you don't get stuff in before then, then you can shoot for Drupal 7.

P.S. I say this because getting functionality you want to get in, is done through proposal, patches, use case, issue queue, revision and refinement per comments.

-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}

Apology & Request

John Bryan commented 3 May 2007 at 14:26

Apology

Apology for accidentally hi-jacking this thread. Other than my original post I have tried not to add or encourage the discussions that spun-off from it. For fuller apology see:- http://drupal.org/node/126233#comment-228213

REQUEST

Can anyone who wants to expand on the WYSIWYG debate please also go to http://drupal.org/node/126233#comment-228213 instead

How can you help contribute to solve this problem?

Steve Dondley commented 2 May 2007 at 18:33

Now that you've identified the problem, maybe you might be able to help solve it.

--
Prometheus

...

crbassett commented 3 May 2007 at 00:32

Sometimes I bristle at comments such as these. I am an avid user of Drupal, but I do not have the expertise in PHP to provide any help in coding. I am not a coder at all. I develop relatively simple websites using Drupal contrib modules. A lot of my expertise (if it can be called that) is in theming Drupal.

I understand that everyone needs to be encouraged to contribute as best they can, but so many times I read a comment posted by someone saying that they wish Drupal could do this or that...and I am sure those comments are motivated by a very real need for the features. In the case of WYSIWYG, I know that many of the clients I develop sites for have little or no background in HTML and the like. Small businesses and small organizations generally look for something that is elegant and easy to use and does not require them to write any HTML. I wish I could deliver something that would knock their socks off...something more than TinyMCE. I look at the WYSIWYG editor at wordpress.com and I think, "Wow, I wish I could do that on my sites!"

So, to my original point. The problem is that I generally am afraid to offer suggestions or feature ideas on Drupal.org because I know someone is going to write, "hey, submit a patch then." And I can't. So, I feel that my feature request would really mean nothing. I mean, often I can't even get an answer to a question on a forum (another philosophical issue entirely), so why would anyone care to listen to a feature idea.

It is no secret that those who develop Drupal are generally extremely reluctant to lay hands on anything that has to do with WYSIWYG. But, some of us have ideas that we don't have the skills to implement for ourselves. But that is the point of Drupal--it allows people to create powerful websites even without extensive knowledge of PHP and MySQL. So, is it bad for those people to post ideas without the means to make those ideas a reality? Or do we just wait silently until a coder thinks of the idea for themselves.

Please forgive me if I've offended anyone or misread someone's comments and/or intentions. I've been waiting a while to write this in an effort to make sure I had gathered my thoughts and could write them in a level-headed fashion.

Keep up the good work on Drupal. It is a fantastic system. It caters to a very broad set of people, and that is a testament to the community here. I'm not taking issue with much here, just expressing a concern that I perceive.

Option for non coders

Michelle

she/her

English

Wisconsin, USA

commented 3 May 2007 at 00:43

You sound like you have a business with paying customers. You could always offer to sponsor the development of a module that fits your needs. There's a paid Drupal services forum where you may have some luck.

Michelle

--------------------------------------
My site: http://shellmultimedia.com

Isn't there another way...

STyL3 commented 3 May 2007 at 03:40

I think it is obvious that any non-developer should just keep quiet. This is obviously a developer eat designer world.

The guy was simply trying to explain the thoughts of MANY, MANY designers in the community and you assume that he is making money off his sites. For all you know, he could be theming all kinds of drupal sites for absolutely nothing, giving back in the way he knows how, and you throw out the "pay for it" line.

i'm not trying to be brash, but it's obvious you either totally missed his point, or proved it. either way it appears "designers" should stay out of it. attitudes like the one above really deter people to even try and learn how to develop for drupal b/c they are afraid to ask questions.

Again, I don't want this to come off the wrong way, but by saying this, i'm assuming that it has. just try not to come off so harsh sounding on non-developers.

heck, give them a starting point to go and learn php, instead of just downing them.

:cD

...

Michelle

she/her

English

Wisconsin, USA

commented 3 May 2007 at 03:49

I didn't assume anything. I said it sounds like he has paying clients. Usually people don't refer to clients when all they're doing is making themes for the community. I offered an alternative for him since he said he's unable to code it himself and paying clients are often willing to pay for modules as well as design. I really don't think that warranted being jumped on by you.

Michelle

--------------------------------------
My site: http://shellmultimedia.com

As i said in my post...I

STyL3 commented 3 May 2007 at 17:02

As i said in my post...I wasn't trying to be brash. after re-reading I can see that maybe it was.

All I was simply saying was, everytime the "designer" type asks a question, it seems like they get clowned on. I've been reading the forums for awhile now and I see it alot. Unfortunately it kind of all spilled over on you. It was not a personal attack and I've actually talked to you before on another thread, and I realize you do a lot for the community.

I simply suggested that he may be giving back to the community in other ways than by coding and developing.

As for your response and re-reading your intial post, your above remarks are warranted. For the rest of you below, hopefully this has clarified things and if not, oh well.

And yes I realize throwing money at the situation is a way to contribute, but it seems like the ONLY acceptable way for many developers on this site.

=-=

VM commented 3 May 2007 at 17:30

Not sure I'd consider it throwing money at the situation. I think its more paying for a service rendered.

Think like this :
A Developer can make his rent working on a paying project, or not make his rent working on a pro bono project. Time is a valuable thing when you are a developer and paying rent is important. The same holds true for a designer, no ?

You can make 1000$ working on a paying project or make nothing on a probono project, which one gets more priority ?

I absolutely agree! I'm not

STyL3 commented 3 May 2007 at 19:45

I absolutely agree! I'm not against spending money on anything and actually have done so...but when money becomes the driving force, by a developer in this community, it doesn't send a very good message and it seems like that's the only reason they are here...they wait for someone who needs something and then all you hear is "i want a fee". To me, this is just as bad as those who say "i want it free".

Now i know that the majority do not act in this way, but some come across this way. 9 times out of 10 it's probably due to the frustration of the abundance of leechers who come through wanting nothing but free stuff w/o giving back. however, in this instance, i don't think that was the case.

All members of the Drupal community should be here for Drupal...not to simply make money, and not to simply leech off someone elses hard work.

this is of course, my opinion.

Designers vs Developers

Michelle

she/her

English

Wisconsin, USA

commented 4 May 2007 at 12:53

I really don't think it has anything to do with being a designer or a developer. The problem arises when someone makes a feature request, especially on a thread like this which isn't the proper place for one, that has already been requested a billion times. If you have an idea for something new that hasn't been done to death, write up a spec for it to the best of your ability, and post it in the appropriate place, you're not likely to get jumped on. (I say not likely because there's always someone in a group this big...)

Look at Dries' accessibility thread. I don't see anyone getting jumped on or being told to go do it themselves. That's because it's a thread designed for getting suggestions and not a status report. It's a proper place and input is being welcomed. It's all about place and attitude. I've been around for over 2 years and see the same theme over and over again. Putting feature requests in the wrong place and/or having an attitude of "Drupal should do X" rather than "Here is something I would like to see" gets people riled up.

In addition to that, having someone suggest you contribute to getting it done is not in and of itself a bad thing. There are many ways that a person, designer, coder, or interested newbie can contribute to getting something done. But all too often the person wants to just post a "Drupal should" and leave it at that and doesn't want to actually get involved in making it happen and gets offended at the suggestion.

Disclaimer: I'm addressing the situation in general here. I'm not saying the OP on this FR did anything more than post it in a bad spot. IIRC, it was actually someone else who took this thread down this path, not the FR poster.

Michelle

--------------------------------------
My site: http://shellmultimedia.com

The problem arises when

crbassett commented 5 May 2007 at 14:17

The problem arises when someone makes a feature request, especially on a thread like this which isn't the proper place for one...

I guess I am the one who took this entire thread in the wrong direction. My original post was to voice a concern I had seen over the last year or so on Drupal. Be it WYSIWYG editor debate or debate over making an automatic installer, it doesn't matter to me. What mattered was the tone and tenor of discussions on the forums and how that relates to people of differing roles in the community.

From my own experience, I know that when I am making a website and someone suggests something, my first reaction is to go on the defensive. "Hey, I'm the expert here. You should shut up," is my natural reaction. After a few moments of reflection, however, I realize that the ideas that my clients (yes, I have a few, no I don't make big bucks...) have often help me develop a better website. Therefore, I understand how coders must feel when someone suggests something, perhaps even ad nauseam. Again, my original intent was to encourage patience, understanding, and civility on all sides. If the developers snap at the designers and the designers disrespect the developers, and so on, the Drupal community is what suffers.

Might I make a suggestion then? Perhaps on threads that are not the proper place for discussion ought to have the comment thread closed from the start. If this were indeed just a status update and not a forum for discussion, then comments ought to be disabled on it. What else would appear on the thread other than questions and suggestions (which are inappropriate for a status update) or "you've done a great job" platitudes. This would prevent pesky people who post ideas and suggestions (indeed, even ones that have been suggested a "billion" times) from doing so. Thoughts?

Yes and no

NancyDru

she/her/hers

English

Boston

commented 5 May 2007 at 14:56

There are posts on this thread that should be here, and posts that should not be. The burden is really on the poster as to whether or not this is the appropriate place. Unfortunately, we here at DO don't do a great job of showing people where is the right place to put their posts (look at how many "how do I do such-and-such with the xyz module" that are in the regular forums instead of in the module support page). And then it's sometimes real easy to tag onto something that is already started.

However, having said all that, the forum moderators could delete posts that don't belong here, but that might anger some people.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

You do and you missed hers

sepeck commented 3 May 2007 at 03:53

Michelle did not miss his point. She mentioned a perfectly legitimate way for non-coders to get code into Drupal. Sponsor someone to do it. And you just attacked her.

Michelle is a hobbyist. She has learned to use Drupal as a hobby. She bought the Pro Drupal book and is learning how to code her first module. She helps others in IRC and in the forums. She contributes back in the documentation and testing things.

Your assumptions are wrong about this community. Wow, way to introduce yourself.

-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}

Just a quick word to say

patchak commented 3 May 2007 at 05:10

Just a quick word to say that Michelle is totally right. When you don't code at all, like me, and you want to use drupal for advanced projects, the only real solution is to go ahead and sponsor some modules.

I've already spent more than 2000us dollars for a big project of mine, working with great drupal devs, and I'm really happy that I took the courage of my ideas and went ahead with the developpement of these modules. Those modules are already back into the community, so it's a great way to contribute back too!

michelle did miss his point...

stephit commented 4 May 2007 at 03:55

"Michelle did not miss his point. She mentioned a perfectly legitimate way for non-coders to get code into Drupal. Sponsor someone to do it. And you just attacked her."

His point wasn't that he couldn't get certain features implemented, it was that he feels he gets attacked for even *suggesting* a feature.

People should be able to suggest improvements without getting jumped on. I made a suggestion myself once and was immediately attacked by some overzealous coder just for making a comment.

Not everyone who does Drupal for a fee gets paid enough by clients (particularly small businesses) to fund the major development of a new module.

Of course we're grateful for all the wonderful modules put out. But just because not all of us are hardcore programmers doesn't mean we shouldn't pipe up if there's a feature we'd like to see. Sometimes the developer just doesn't think about all the different issues that might come up from a user's standpoint. Being open to suggestions (and they are not demands, but suggestions) will only help the developer and everyone else.

I find the attitudes here to be strangely unwelcoming for some reason. I know, when you are a code wiz, that people who aren't as smart as you in that area can be a bit annoying. But chill out a little bit!

And as for Michelle's response, when I originally read it, it came off to me as a bit patronizing at best. So that's why she was "attacked." She possibly meant well but she missed the entire point of the original message, which was, "why can't I just make a suggestion without people jumping down my throat?"

My 2 cents, as a person who can hack some code but can't program from scratch.

...

Michelle

she/her

English

Wisconsin, USA

commented 4 May 2007 at 12:43

My post was in response to

I wish I could deliver something that would knock their socks off...something more than TinyMCE. I look at the WYSIWYG editor at wordpress.com and I think, "Wow, I wish I could do that on my sites!"

I didn't have any desire to get into the whole rant on not being "allowed" to post feature requests because it's tiresome. I saw a bit in his post that I thought I could help with and responded to that.

Or am I not "allowed" to make a partial response to a post unless I address the entire thing? :P

Michelle

--------------------------------------
My site: http://shellmultimedia.com

RE: "you assume that he is making money off his sites."

bonobo commented 3 May 2007 at 13:16

RE: "you assume that he is making money off his sites." -- Given that original poster said "I know that many of the clients I develop sites for", it's a pretty safe assumption that there is money involved.

Sponsoring modules is a legitimate contribution to Drupal, and a great way for non-coders to be involved. Many designers *shouldn't* learn php, they should design! There's nothing wrong with doing what you do well.

There are many ways to contribute back, and it's fine if the contribution matches an individual's skill set. That's a good thing. If a designer has clients, then contributing toward specific module improvements is a great thing to do.

Many people bristle, however, when pointed toward a path that involves more than simply *talking* about a problem. Discussion is an excellent first step, but it needs to be followed by constructive action.

Cheers,

Bill

-------
http://www.funnymonkey.com
Tools for Teachers

-------
http://www.funnymonkey.com

announcement thread

sepeck commented 3 May 2007 at 03:04

This is an announcement thread. Not really a "hey want feature" or "complain about not getting something reviewed" thread. So many do this kind of thing in announcements and then others get resentful when they get the predicable response as people 'bristle' in response at being told to do work they aren't interested in or paid for. This is just the pattern.

Drupal has a spot for Feature requests in the issue queue. Non coders can add feature requests. If they cannot code, then they should include as much detail about how they see such a thing working. Preferably after they searched existing feature requests. GUI mock ups could be useful as well. I myself have done this.

It's not that devs are against a wysisyg feature, it's that virtually all implementation have serious short comings or issues in one way or another. Lack of clean code, abandoned, to bulky, to likely to interfere with other things, not cross browser compatible... There have been discussions about how an api that provides better hooks for such modules would be welcome... if of course, someone worked on contributing it.

This thread was Dries just giving the less involved members a heads up on what's been going on and a gentle reminder that June 1st is fast approaching.

-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}

More than TinyMCE

Boris Mann commented 3 May 2007 at 03:07

I wish I could deliver something that would knock their socks off...something more than TinyMCE. I look at the WYSIWYG editor at wordpress.com and I think, "Wow, I wish I could do that on my sites!"

The Wordpress.com WYSIWYG editor *is* TinyMCE.

Well, that really nails it, doesn't it?

Leeteq commented 3 May 2007 at 09:10

That being the case, we are perhaps "closer to heaven" than what the current implementations leaves of impression...

What is needed to have Tiny implemented "out of the box" just as slick for Drupal as for Wordpress? (Time and resources, I know, but that is not the question here now: Technically speaking, what have they added or tweaked that we should find resources to do for Drupal as well?

It would hopefully be possible to make a variant where Drupal site admins does not need to be programmers to plug it in "seamlessly".

So: What have Wordpress done with Tiny that the current Drupal module is "lacking"?

If we were to get a bounty together to "get there", what would the total cost of development be, and what could the time frame be? (I guess we should aim for making a solution for both 4.7 and 5.x here.)

"Psychologically" and "saleswise" when promoting Drupal to potential new clients that has to really pull themselves together to grasp the true power of Drupal (sales challenge, I know, but still...), issues like "awkward" or non-slick WYSIWYG editor behaviour and user-unfriendly image attachment are making it harder to promote.

These issues also is part of a "showstopper" for us seeing killer Drupal-for-bloggers distributions and the like, I believe.

By making these aspects "slick" and well working, it would further fuel the popularity of Drupal and position it even better in even new areas. For normal users (including potential clients), it is hard to accept that such issues are not resolved. It gives the impression of an unfinished product.

So I think resolvoing these WYSIWYG issues has great psycolocical impact on how Drupal is conceived by non-tech users. Many of which are desicion makers...

.
--
( Evaluating the long-term route for Drupal 7.x via BackdropCMS at https://www.CMX.zone )

Better continue WYSIWYG discussion at node 126233

Leeteq commented 3 May 2007 at 09:17

As this was an announcement for Drupal 6 status, it is better to continue the WYSIWYG discussion in for example this thread:

("Does any WYSIWYG exist at all for Drupal?")
http://drupal.org/node/126233

(There is a list of specifications being made in that thread, in order to find out exactly what would get us "there". Hopefully there will be a bounty or two coming out of that.)

.
--
( Evaluating the long-term route for Drupal 7.x via BackdropCMS at https://www.CMX.zone )

...

crbassett commented 3 May 2007 at 13:14

I had a hunch that was the case, although I had not checked it out yet. I was thinking also of the tabs that let you switch between code and visual editing. Since I don't code, I don't really understand how that is done anyway...oh well.

I'm just glad to get some feedback on my thoughts. I'll post this one last thing here and then take these concerns to another thread if necessary.

Could I sum up what I've read with this statement?

If you want to suggest something, then you need...

...to start coding the project yourself.
...to offer to pay for someone else to code it.
...promise to help with testing or GUI mockups or something like that.

That is fine if that is how it is. I'm not a "pro." I can get thigns done the way things are now. In fact, Drupal allows me to do truly amazing things. I appreciate that. I'll just let those with more skills do all the thinking and wait to see what they come up with. The reason I posted originally was simply because I saw someone post an idea and I thought, "hey, that would be nice. That's something I would never have the guts to mention on these forums..."

One last thing. I've noticed that when a person posts something on drupal.org along the lines of "wouldn't it be nice if..." most people take it as a criticism of Drupal. I would encourage those who spend a great deal of time contributing to Drupal to recognize that they have made an amazing product, and that when someone posts a "wouldn't it be nice if..." post, please don't take it as hatred toward what Drupal is, but rather, input on what people would like to see in Drupal *someday* or something...

Finally, if the only people who can offer input on the system are those who are coders or paying customers, then the Drupal community may be missing out on a lot of visionary input.

Again, thanks so much for the feedback, and the great work. I appreciate the general tone of civility as well.

Feature requests

Michelle

she/her

English

Wisconsin, USA

commented 3 May 2007 at 13:16

You can suggest whatever you want. There's an option for feature requests in the issue queue. What gets tiresome is that every time the status is posted like this, people come up with Drupal "must have" the same list of feature requests that have been going on for some time. Wanting a WYSIWYG in Drupal is nothing new. The fact remains that it requires someone to code it and just saying "Would be nice to have this" isn't going to add anything to the 50 million other "Would be nice to have this" that we already have.

So, yeah, the standard response is "Go for it". If you want to be responded with "That's a great idea" then you need to post a great idea that hasn't been posted to death already. Doesn't mean the community doesn't welcome input. We just get tired of rehashing the same ideas over and over and over.

Michelle

--------------------------------------
My site: http://shellmultimedia.com

Oh my god!

clemente commented 19 February 2008 at 00:25

When someone asks for something like a WYSIWYG editor or an integrated file and image manager is not asking for the moon. He is asking for something that should be there since drupal 1.0. We are talking about content manager system! Just have a look at WebsiteBaker, an application much much smaller and less developed and hyped than Drupal, and you'll find it. So, instead of putting there all the trendy Ajax features, or improved theming system, why don't we start from the basic? I am developing for the health sector. What do you think the doctors prefer: improved API calls or editor with integrated file and image manager?

Go for it.

NancyDru

she/her/hers

English

Boston

commented 19 February 2008 at 00:39

Luigi, I'm sure that as soon as you get this coded and submitted to the core project it will get lots of attention.

I bet you'll uncover all the reasons why it's not there yet. Of course, the first one will be that there are some of us who don't want all the overhead of a WYSIWYG editor.

NancyDru

Sigh

Michelle

she/her

English

Wisconsin, USA

commented 19 February 2008 at 01:13

You're ressurecting a nearly 1 year old thread just to bitch at me? Don't you have anything better to do with your time? Like write a WYSIWYG that will satisfy the hundreds of thousands of people using Drupal that all have a different opinion on what sort of editor belongs in core?

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

The poster bringing up

catch

he/him

English

commented 3 May 2007 at 11:37

The poster bringing up wysiwyg editors advertises this company: http://www.alt2.com/ , suggesting he's making money (or trying to) from providing Drupal sites (his own site uses a modified Garland theme), I think it's therefore reasonable to expect some kind of contribution (be it documentation, patch testing, even feature requests on the issue tracker) as well as, or instead of, repeating very similar feature requests on forum topics like these. I don't think anyone complains about feature requests, just people who show up only a few weeks before code freeze to post feature requests on random forum topics, which is a different thing entirely.

Response at http://drupal.org/node/126233

John Bryan commented 3 May 2007 at 13:40

http://drupal.org/node/126233 "Does any WYSIWYG exist at all for Drupal?"

Trying not to make my thread abuse here even worst 8¬}

I like what you said.

rikimaru0007 commented 22 June 2010 at 02:49

"it allows people to create powerful websites even without extensive knowledge of PHP and MySQL. So, is it bad for those people to post ideas without the means to make those ideas a reality?"

As of now. I'm just an End User of Drupal. The best thing to do is "Study on your own", use common sense. Read manual and do not rely too much from others.

Well...

NancyDru

she/her/hers

English

Boston

commented 22 June 2010 at 11:51

I think I would have to disagree with "...do not rely too much from others." These forums are a great way to learn from others and to ask questions when you get stuck with a problem. The mailing lists and IRC are also great ways to get help.

NancyDru

I've been thinking about a different approach to this problem

reikiman commented 2 May 2007 at 23:09

The CSS based editors all have serious problems that aren't fixable by improving their interface into drupal. But maybe I see these because I'm a Mac user and do not ever touch Windows. But try doing COPY/PASTE with one of them and you'll be greeted by a dialog box saying your a loser mac user and you can't do that because it doesn't work. Bleah. Another problem they all have is proper interpolation of content composed assuming Drupal's blank-line-filter ... they don't recognize the blank line as a paragraph marker and then run the content together into one mishmash.

What I'm thinking about is using the Services module to plug in an external editor using a more powerful API than Blogger/MetaWebLog/etc ... the problem with existing API's is they have a simplistic model which probably works well for blogspot.com or wordpress .. but Drupal content types can be so much more comprehensive and featureful.

In the Services module there are "node load" and "node save" which could serve as the basis for most of the editing needs. It looks like there's a bit more which would be needed ... such as, a query to return the list of available content types the user can create, a query to return the fields and field types for a given content type (assuming CCK is installed), and a method to create a new node of a given type, and queries related to editing and entering taxonomy information including taxonomy hierarchy, taxonomy relationships, and the flex-taxonomy interaction.

- David Herron - http://7gen.com/

+ David Herron - 7gen.com/, The Long Tail Pipe, davidherron.com/drupal-blogging-hints

P.P.S. I say this because I

VValdo commented 3 May 2007 at 01:47

P.P.S. I say this because I like Drupal 8¬)

Is drupal 8 out already?

Emoticon

ThatPerson commented 3 May 2007 at 04:07

That was an emoticon.

Uhhh....

Vallenwood commented 3 May 2007 at 16:16

I'm a comedy writer, and I'm prettttty sure VValdo already knew that. : )

Yeah... I didn't think I

VValdo commented 3 May 2007 at 23:21

Yeah... I didn't think I needed to explain it, but yes- I was kidding.

WYSIWYG

Dries commented 3 May 2007 at 05:10

I realize that WYSIWYG editors are very important for many people.

I don't think we'll include a WYSIWYG editor in Drupal 6, but I believe there are a couple of things we could do to help the WYSIWYG developers integrate their WYSIWYG tools.

So let's start by supporting those who build or integrate WYSIWYG editors. If people can point me to discussions or patches regarding this subject (i.e. making it easier to integrate WYSIWYG editors), I'll have a look at what can be done.

Once these people have the hooks it takes to integrate their WYSIWYG editor in a clean and elegant fashion, we can talk about adding a WYSIWYG editor to core.

Do you want to have a WYSIWYG editor in your website ?

dropcube commented 3 May 2007 at 07:14

May be, there is not need to add a WYSIWYG editor to core. If the hooks are well defined and the modules are working well, someone with minimum Drupal knowledge will be able to install them. Otherwise, during the installation process, would be good that the user select if he/she wants to install a WYSIWYG editor.

Also, this may be applied to other modules, that need setup configuration.

These are only some ideas, what do you think?

wysiwyg integration

ontwerpwerk commented 16 July 2007 at 18:27

There are some ideas for integration that show promise IMO:

One is to use an extended version of form store http://drupal.org/project/form_store to determine what textareas should be replaced

Another way is to use filter module to initialize (it's a logical place because filter also manages if nodes may use HTML, php and more)

And the last one is explained in those two issues: http://drupal.org/node/122008 http://drupal.org/node/81297 but boils down to: module developers should use a standardized property to tell a wysiwyg it should initialize (which is possible and easy in form API)

All of those ideas have drawbacks... so the best solution is still some discussion and code away...

--
I work for Ontwerpwerk

Nice

bonobo commented 2 May 2007 at 18:15

The theming, menu, and internationalization alone are great improvements -- but the logging features are just another bit of icing on the cake.

Nice work. Very nice work.

Cheers,

Bill

-------
http://www.funnymonkey.com
Tools for Teachers

-------
http://www.funnymonkey.com

New Blue Marine Theme?

CHEETAH commented 16 December 2007 at 06:03

woot woot!
http://stylepl.us

Logging and SLM

davidtrainer commented 2 May 2007 at 18:42

#3 sounds awesome.

Nice work!

Minimal Media. Building and Hosting Websites on Open Source.

CCK?

imerlin commented 2 May 2007 at 19:22

Is it planned to include CCK in the core of Drupal 6?

I've been waiting for CCK in core since I first read of it when looking into flexinode.

ummm

sepeck commented 2 May 2007 at 19:29

CCK is already essentially in core. Adding the contrib cck module merely extends it.

-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}

indeed, by default most

pamphile commented 2 May 2007 at 20:12

indeed, by default most nodes are CCK ready . You can even extend the blog.

Marcel
http://BloggerWanted.com
http://ComputingNews.com

Well then...

VValdo commented 3 May 2007 at 01:47

will the CCK field addition stuff in contrib be in 6.0, and if so, will all the fields currently in 5.x revs be included automatically?

=-=

VM commented 3 May 2007 at 03:37

There are no signs of them in Drupal 6 at this stage.

Maybe

Dries commented 3 May 2007 at 05:35

I was hoping we'd see more of that in Drupal 6, but so far that hasn't happened yet. It can still happen though. ;-)

Upgrade from 5.x to 6.0 ?

tesliana commented 3 May 2007 at 01:50

I am just starting out with Drupal and I need multilingualism eventually. I would rather start with 5.x and the new book in hand and then upgrade to 6.0 later. How much different is 6.0 at the data/db level and will there be automated upgrade/data conversion routines ? I could wait a few months for 6.0 to come out and then likely struggle with it while it gets documented and new [hand]books written. What do you recommend ?

---
We are all prisoners of our own experiences.

Hi,

patchak commented 3 May 2007 at 05:06

Hi,

I suggest to start with 5 without hesitation. The code freeze is in june but drupal 6 is still far away, as there will be a beta phase that could take a couple of months. Normally all drupal versions have a really clean and working upgrade path, so there is no problkem on that side. The real problem when it comes to upgrades is more the contrib modules, but then again all the big ones are converted very fast, and normally all other contrib modules are converted in a couple of weeks/months after the first RC release of a new drupal version.

Welcome to drupal btw,
Patchak

Using D6 for anything but testing is extremely risky

robertDouglass commented 3 May 2007 at 13:01

You are in for a world of pain if you start developing real sites on the current D6 development branch. The whole point of having a code freeze is to ensure a period when anything and everything can and will change and get broken. This isn't even beta software yet. Please download it, test it, make suggestions and become familiar with it. Start planning what you want to do with it. But *do not* try to build real sites with it. Wait for a beta release at the soonest.

- Robert Douglass

-----
Lullabot | my Drupal book

the upgrade process is fairly painless

suzanne.aldrich commented 6 May 2007 at 06:07

Welcome to Drupal! I'm not sure about 6.0 but I think your idea to start with 5.x is good, since it will take awhile for the new version to be thoroughly tested. I would rely on as few contributed modules as possible to implement the necessary features of your site, especially if you are concerned about their ability to keep up with 6.0, but in general the upgrade process is fairly painless.

aigeanta

.......

misty3 commented 3 May 2007 at 02:45

Thats a great news and MANY congrats to the team !!

It will be nice to know how well optimized it can be for those hosting on shared servers
and have resource usage limitations.

Some options which have so long NOT been provided will be great welcome in version 6
namely
1) ability to switch off watchdog when wanted
2) ability to inactivate RSS completely when wanted
3) a benchmark sticker for every version 6 module w.r.t cpu resource consumption
4) making cron.php inaccessible by url by any user
5) ability to have different teaser settings for different core content types

Thanks again.

Best regards

protecting cron.php

jmarkantes commented 7 May 2007 at 22:44

Here's a discussion about protecting cron.php using the htaccess file. Another solution is to rename it. Each one presents a potential issue on the next upgrade cycle, however, so neither solution is ideal.
J

Ummm

dmitrig01 commented 10 May 2007 at 00:28

#1: is possible
#2: submit a patch
#3: this will never get into core, but if you can make a module, then great!
#4: under debate. start an issue
#5: what do you mean

[Drupal++]

....

misty3 commented 10 May 2007 at 04:19

Thanks a lot.

# 1 : How ? Does it harm if I make watchdog file a blank file ?
# 2 : Sorry, I am not expert , but like to know if I delete a file ( which file ) does this stops
# 3 : it is not question of core/module but labelling the modules in the module list page of drupal.org
# 4 : ? issue is already there, any output ?
# 5 : meaning this : http://drupal.org/node/134657

Best regards

.....

dmitrig01 commented 12 May 2007 at 14:21

#1: disable syslog.module and dblog.module
#2: I don't know exactly
#3: oh
#4: issue number?
[Drupal++]

#5

Michelle

she/her

English

Wisconsin, USA

commented 10 May 2007 at 00:39

Can be done with contemplate.

Michelle

--------------------------------------
My site: http://shellmultimedia.com

Two Bug Fix Patches

NancyDru

she/her/hers

English

Boston

commented 3 May 2007 at 02:53

I submitted two bug fix patches for node.module; it sure would be nice if they were actually fixed in 6.0.

It would be even nicer if all the modules I needed were ready for 5.1 yet... sigh

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

Wow.., I missed this

bs commented 3 May 2007 at 04:24

Congratulations. Some how I missed this great news.
My hearty congrats for your hard work and dedication.

More customisation and ajax(jquery)

Sharique commented 3 May 2007 at 08:05

My wish list
Are they in 6.0

Drop down and and pop menu
Make customisation of theme easier
Improved performance

beside of these I want to know, What are the changes in

Login module
user module
taxonomy system
Which version of jquery is used.

---
Sharique uddin Ahmed Farooqui
IT head, Managefolio.com

Sharique Ahmed Farooqui
http://www.openahmed.com

Roadmap available?

hass commented 3 May 2007 at 08:13

Hopefully, the release will not take longer then one/two month(s) after the code freeze. i really need the i18n stuff...

Too optimistic

robertDouglass commented 3 May 2007 at 13:03

A realistic estimate is 4-6 months after code freeze before we see a stable release. There is no roadmap and this is just my personal guess, based on watching the last 4 release cycles.

- Robert Douglass

-----
Lullabot | my Drupal book

oh no... :-(. i saw for

hass commented 3 May 2007 at 21:50

oh no... :-(. i saw for 4.7.x - it was was more then 6 months :-((( and drupal 5 took ~4 months... but Dries told it took 2 month for bugs and 2 months wait for module updates... today, no words about the time after freeze... hopefully it will not take such long to get this release out!

all it takes is participation

sepeck commented 3 May 2007 at 21:54

If you want it shorter, then people have to download, test and report bugs. Then people have to supply fixes for those bugs. That's all it takes.

-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}

Still waiting

NancyDru

she/her/hers

English

Boston

commented 3 May 2007 at 23:13

I'm still waiting for all my modules to be updated... and some have just said "forget it."

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

...

sepeck commented 3 May 2007 at 23:20

My favorite module or theme is outdated. What next?

-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}

24 hrs in a day

NancyDru

she/her/hers

English

Boston

commented 4 May 2007 at 00:20

The last I heard this law hadn't been repealed. Yeah, I know, I sleep 6 hrs a day when I could be working...

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

menu defective

hass commented 3 May 2007 at 08:17

PHP Fatal error: Call to undefined function () in drupal6\includes\menu.inc on line 459

issue queue

Gábor Hojtsy

he/him

Hungarian

Hungary

commented 3 May 2007 at 11:08

Hass, don't pretend you don't know where is the issue queue to submit these kind of reports (with more accurate details). I know you do.

Documentation

rfsbsb

Portuguese, Brazil

Kitchener

commented 3 May 2007 at 13:17

I agree with John Forsythe! Good documentation is essential! Good documentation is a factor that makes Drupal have a great advantage over other CMS (like Plone) to me!

Count on me to help!

Rafael Ferreira Silva - PHP Developer
http://drupal-br.org
http://rafaelsilva.net

Upgrade path from ver. 4.7.6 to ver. 6

OsterD commented 4 May 2007 at 05:33

These new features sound great.
Especially the theming is a great new advancement.
Also the internationalization mechanism seems to be what was really need which tights nicely I believe with the new logging facility.
I have being using a 4.7.6 distro for a while now and I haven't considered to upgrade to 5 because of some of compatibility issues.
E.g. I am using acidfree module for the multimedia content types of the site which is a photography based site KG Photography
How effortless do you think a site like the aforementioned to upgrade to ver. 6?
I think for the time being to leave behind and not use at all ver. 5, is this a good idea or shall I go to an upgrade path of ver 5 and then 6?

Thanks.

David Oster aka George Pasparakis

Go to 5

NancyDru

she/her/hers

English

Boston

commented 4 May 2007 at 12:37

The AcidFree module is radically different for 5.x. For that reason alone, I would suggest going to 5.1 as an interim step - in the very least on a test site for conversion.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

Go to 5

OsterD commented 5 May 2007 at 20:07

Thanx for the reply.
You mean from 4.7.6 to 5.1 and then to 6 when it becomes available?

David Oster aka George Pasparakis

Yes

NancyDru

she/her/hers

English

Boston

commented 6 May 2007 at 02:09

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

Custom url/page for taxonomy terms

Hor commented 6 May 2007 at 08:55

I suggest to add into taxonomy core one more text field for each term. If it is non-empty, then is used as custom path to generate link in term list, superseding default taxonomy/term/nnn reference.

I see this as a very simple way to provide custom pages for terms. No complex functionality is needed like binding term with page, it is up to site maintainer to provide a page for that path.

In my current Drupal 5 installation I use following modification to taxonomy module:

function taxonomy_term_path($term) {
  $vocabulary = taxonomy_get_vocabulary($term->vid);
  if ($vocabulary->module != 'taxonomy' && $path = module_invoke($vocabulary->module, 'term_path', $term)) {
    return $path;
  }
/*** added code beginning */
  if ($term->description)
  {
    return $term->description;
  }
/*** added code end */
  return 'taxonomy/term/'. $term->tid;
}

I used "decription" field for my needs, sorry I was not able to create full-featured patch, with modification of database tables.

Thanks for this

Michelle

she/her

English

Wisconsin, USA

commented 6 May 2007 at 11:59

I'm currently manually entering in redirects to achieve the same thing. Though I don't like hacking core, this is a fairly simple change and I think it will be much easier to bring this through upgrades than manage all those redirects. :)

Michelle

--------------------------------------
My site: http://shellmultimedia.com

A Duh! Moment

NancyDru

she/her/hers

English

Boston

commented 6 May 2007 at 15:40

Thanks, Hor. You've generated a Duh! moment for me. I've seen that feature in taxo terms and never even thought about how it could be used. Your code sample just helped clarify what I can do with it.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

Why not just use the

patchak commented 7 May 2007 at 18:36

Why not just use the taxonomy redirect module to redirect all terms from a vocab to a certain page??

Taxonomy redirect

Michelle

she/her

English

Wisconsin, USA

commented 7 May 2007 at 20:33

Not sure who you're asking... In my case it's because I don't want all the terms to go to the same page. I want each term to have its own page.

Michelle

--------------------------------------
My site: http://shellmultimedia.com

Why add another module

NancyDru

she/her/hers

English

Boston

commented 8 May 2007 at 02:38

Why add another module when I already have a module? That's the point, I can add a few lines of code to my module rather than load another one. Besides, most of us who want the ability to change the links already do it in hook_link_alter. After taxonomy has already built it's links, we have to come along and change them. It's so much more straight-forward to move that code into a different hook (hook_term_path) that runs before the fact.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

Modules

Nigeria commented 8 May 2007 at 15:08

I'm not sure this is the right place to ask, but its important to me.

Will modules written for 5.x work with 6.x. ?

I ask because modules for 4.x do not work with 5.x. (making migration difficult if not impossible sometimes). It has been alluded to that 5.x modules will not work with Drupal 6.x, but no definitive statement has been made.

If 5.x modules will not work with 6.x, the real question is why? Although upgrading is important, stability is also important and can Drupal not get a stable module framework?

I have had to abandon several sites since the contrib modules, which worked with a particular release, would not work with Drupal upgrades and the authors has ophaned them.

Ade Atobatele

Unfortunately

NancyDru

she/her/hers

English

Boston

commented 8 May 2007 at 21:39

Until all the APIs are firmly defined (if ever), we will face this same problem with every release. And, then, of course, if the module developer does things that aren't by way of the APIs, or use the APIs incorrectly, you face even more hurdles.

The best thing to do is to go to the project page for every module you use and let them know you are interested in a 6.x upgrade. If they aren't planning it, maybe someone else will take it over.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

That's Crazy!!!

Nigeria commented 8 May 2007 at 23:24

Shouldn't the core developers be looking to create a stable API for module development since its the additional modules that entice a lot of people to Drupal.

Ade Atobatele

...

Michelle

she/her

English

Wisconsin, USA

commented 8 May 2007 at 23:41

http://buytaert.net/backward-compatibility

Michelle

--------------------------------------
My site: http://shellmultimedia.com

Life is a series of compromises

Nigeria commented 10 May 2007 at 06:22

Thanks for the link.

No matter how we see it life really is series of daily compromises.

I think that the core developers need to embrace that ideal in taking Drupal forward.

Evolution rather than revolution should be the order of the day in this case. A compromise whereby each release will support the previous release would be such a copromise.

So 5.x would support 4.x, 6.x would support 5.x but not 4.x.

If this was a rule then the developers would be constrained to develop to it and everybody could predict what their upgrade paths would be. This does not mean that brand new things can not be developed, but that they are developed in an atmosphere of predictability.

As the Drupal user base moves from the hobby stage (i.e brochure based websites) into major commercial roles (i.e internet based applications) this will be the only way to sustain its usage in environments where is it not cost effective to have junk a previous site and start over each release.

Ade Atobatele

,,,

sepeck commented 10 May 2007 at 07:34

There is a migration path for core module data. Always.
There is not going to be API backward compatibility. It is not going to happen for several very complex reasons. See other long threads about it.
Drupal has been in corporate and large scale site usage for several years now.

-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}

No Doubt!

Nigeria commented 10 May 2007 at 08:24

"Drupal has been in corporate and large scale site usage for several years now".

I don't doubt this, but after being in the software design business for almost 30 years, I'd have to state that my personal opinion would be that carrying your customers along with you has to be a good thing.

Many corporates are not on "latest" versions of software because of the cost of testing and migrating.

Migration to the latest version becomes a major effort that can only be done when compatibilty tests ensure that they can upgrade their current offerings. Where this can not be done new modules have to be created. This takes time and lots of money.

People often forget that the major, but hidden, investment in a system is not the functionality but the data contained with and the cost of training users.

When the data gets trapped due to functional obselence there is a huge cost to pay in designing and moving to a new system which is made worse by the need to retrain users.

This is what the real issue is. Cost!

We all like Drupal otherwise this conversation would not be taking place. The question is what is the cost of maintaining a Drupal installation that uses modules other than those that constitute core, through Drupal upgrades, and is there a way to lower that cost.

The need for backward for compatibility, even if it is limited to a single version, is real.

Why?

Because it's what the customers want. And they want it because it constitutes a real need. A need to manage costs.

Ade Atobatele

First of all, no one is ever

Frando commented 10 May 2007 at 11:51

First of all, no one is ever forced to update (as long as security updates are available for a certain version). This gives you a cycle of about two years.

And then, please, before posting another response to this thread, read http://drupal.org/node/132496.
Everything has been discussed there.

And this thread here is definitely NOT the right place to revive this discussion (not that I think that there's a right one).

...

Michelle

she/her

English

Wisconsin, USA

commented 10 May 2007 at 13:09

As the Drupal user base moves from the hobby stage (i.e brochure based websites) into major commercial roles (i.e internet based applications) this will be the only way to sustain its usage in environments where is it not cost effective to have junk a previous site and start over each release.

Ok, first of all, hobby != brochure. There's a lot of elaborate hobby sites out there. (Had to get that off my chest ;)

As to businesses, I wonder if the API changes really are the problem people keep saying they are? My thinking is this: Big sites will tend to have a lot of customizations beyond contrib modules. When upgrading, all these customizations need to be upgraded. Even if the devs try and keep things backwards compatible, there is still going to be work involved in upgrading a heavily customized site. In light of that, upgrading your modules to the new API seems like just a little bit extra and not a huge endeavor. I know FAPI was a huge change but, otherwise, it doesn't seem like the API is changing horribly.

Now I'm one of those hobbiests with complicated sites and not a corporate dev, so maybe I don't know what I'm talking about. But I do know that the one site I still have on 4.7 is there due to the number of customizations I made and not because of the API changes.

Michelle

--------------------------------------
My site: http://shellmultimedia.com

I know the feeling

NancyDru

she/her/hers

English

Boston

commented 10 May 2007 at 16:32

Actually, I suspect many of us use our "hobby" sites as guinea pigs for our corporate sites...

But this might help put things in perspective: The Road to Drupal Hell.

Nancy W.

NancyDru

That's what they are trying to do

NancyDru

she/her/hers

English

Boston

commented 9 May 2007 at 00:34

That's what they are trying to do but you and I keep asking for more features...

I see fewer things to change the APIs in 6.x than there were in 5.x, but there ae changes.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

Backward compatibility

Dries commented 11 May 2007 at 07:24

Large parts of the API remain untouched, other parts are still being refined or worked on. As they mature, they too will naturally become stable. We try to design APIs that are future-proof but history learns us that it is really hard to get those right. Three years ago, the web was quite a different place than it is today.

For example, the advent of OpenID might require us to revisit some user module APIs and comment module APIs. Accommodating Open ID so we can use it to its fullest extend strikes me as a good thing, but at the same time, it might break an API or two. The alternative might be poor or cumbersome OpenID integration.

All in all, it is a tricky issue, but I think my blog post sums it up well. Unfortunately, there is no good or wrong. We work hard to help people transition to the updated APIs though, but unfortunately, it won't be 100% painless. Crazy or not, that's how we do it. ;)

taxonomy: minor, useful(?) change

isaac77 commented 9 May 2007 at 13:11

Taxonomy current behaviour:
By default, the first term in taxonomy select boxes is selected (at least for required vocabs). This means that careless/busy users might ignore that selection and leave the "default" chosen by accident.

Proposed change:
Admins need a way to indicate that a given vocabulary should have NULL/no term selected by default. (In required taxonomies, I prefer having NO term selected by default--this forces users to actively choose a correct classification, otherwise they get a validation error. Improves integrity of data, etc.)

I've done a bit of hacking to modify forms and get the desired behaviour, but it would be great to have this built-in... especially for non-programmers.

Thanks to all the folks working on 6, and to everyone who made 5 such an excellent upgrade!

Submit a patch

NancyDru

she/her/hers

English

Boston

commented 9 May 2007 at 15:19

You'll be much more likely to get the developers' attention.

But I have to agree. I don't know how many times I've made that mistake. At least with something like Taxonomy Super Select, it's a bit more obvious.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

Thanks for the advice. Of

isaac77 commented 12 May 2007 at 00:16

Thanks for the advice. Of course you're right... I only wish I had the requisite programming expertise to create a patch. I was able to hack something together to deal with specific situations on a few sites, but I don't have the know how (yet!) to create a patch that would be solid enough to incorporate into core.

I posted here in response to a request for feedback on the front page of drupal.org. If there's a better place to put a note like this, please let me know. Really would like to see this incorporated. Thanks!

Post it as a feature request

NancyDru

she/her/hers

English

Boston

commented 22 May 2007 at 04:01

http://drupal.org/project/drupal

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

You might have a look at

joep.hendrix commented 21 May 2007 at 21:48

You might have a look at this one:
http://drupal.org/node/140783

-----------------------------------------
CompuBase, websites and webdesign

-----------------------------------------
Joep
CompuBase, Dutch Drupal full service agency

Like these

Nystul commented 12 May 2007 at 03:35

Themes, menus, and internationalizations are much better! As for the logging functionality, I hope it be as good then.

Nystul
---
Malaysia Travel Guide: Come visit Us today!

Oracle and multi-database

vadalsa commented 21 May 2007 at 21:10

just curious, if Oracle DB and multi-database support will be available in Drupal-6

thanks

Features wishlist

CodeX4u commented 25 May 2007 at 11:22

Hy!

(First... excuse my bad English...)

I have many ideas for the next version...

1. The menu elements can be hidden by using rightcontrol... that means the registred user can see more menu items as an guest... and it must be configurable for multiaccess...
for ex. Admin can see 19 items the moderator can see 17 items the logget user see 15 items and the annonymous can see only 11 Menu items....

2. Enable Subforums in so many subs that the people like... Forum-->sub-->subsub-->subsubsub-->etc....

3. Disable/Enable editing the profile but let it be visible... for ex. as an accountduration... he can see the date of expired... but cant change anything...

4. Multiple menues... for ex. one on the left side (home, about, contact,...) one on the header (download now, faq, help) and one on the left site... ...Menu1 Menu2 Menu3 ....

5. wysiwyg editor for user&annonymous with many functions but without a possibility to inject bad code... so not full html but many features....

6. integrated wysiwyg template editor... with fields for ex. change: background (insert color or pic) and all possible items... put this left and this right... make 3,4,5 colums....

thats for the moment... i dont wont to make excessive demands...

Already there

NancyDru

she/her/hers

English

Boston

commented 25 May 2007 at 15:03

1. Menu Per Role module. Except I'd like to see the menu.inc hack include in core.
4. Just "Add New Menu" and it creates a block that you can enable to any region you want.

For the others, I recommend that you visit http://drupal.org/project/drupal and create a feature request. I would suggest wording #3 as "access control for profile module."

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

NancyDru

Forum Module in Drupal 6?

farrell commented 3 June 2007 at 15:14

I remember some early discussion about upgrading the core forum module in Drupal 6.

Just curious, is this still on the table?

--
Farrell Kramer
Farrell Kramer Communications

=-=

VM commented 3 June 2007 at 15:56

I do not know how far the forum group (DruBB) on groups.drupal.org have gotten, but from my testing of Drupal 6, the forum is still the forum although it's performance it better. The code freeze which has been extended from June 1st to July 1st may proove fruitful but your question would be better answered by the DruBB group.

here are a list of features that are included in Drupal 6 thus far: see http://drupal.org/patch/spotlight

Thanks much. I'll check out

farrell commented 4 June 2007 at 03:15

Thanks much. I'll check out the group.

I did test out the most recent Drupal 6 dev version last week and noticed the forums looked the same. I was just wondering if there were any broader plans for it.

--
Farrell Kramer
farrell kramer communications