As much as I struggle with Drupal and love some bits of it there are still problems. At the moment I'm trying to setup two sites that really need a good forum and good wiki and good blog. All three. Drupal can just about do all of them, but still lacks many necessary features of MediaWiki and phpBB.
I *want* to just use one system for all (Drupal) because it integrates users and search and everything else. This is the great thing about it... BUT... it just doesn't hack it against phpBB and MediaWiki for what they're best at.
Someone try and convince me either to stay with Drupal or go for the phpBB, MediaWiki and Drupal all on the same site. I notice that http://gnomedesktop.org/ that was, I think, trying to just use Drupal has opted for Drupal/phpBB/MediaWiki combination. Probably for the same reasons I'm thinking of doing this. But as a result, search only searches the system you're curently in, users have to register three times etc. Not ideal.
Comments
I read a comment somewhere
I read a comment somewhere on the net along the same lines, with someone saying they would rather have best of breed applications, than some of Drupal's "well meaning" but hardly state of the art modules.
Maybe the future lies in making other excellent open source applications (like PunBB for instance) compatible with Drupal.
note the answer i was hoping
note the answer i was hoping for! But yes, the way I see it the most crucial things to integrate are:
- user login details
- search facility
Though however you look at it, having three separate systems will never be perfect
Jake
---
School and university yearbooks and Drupal web services, London
Search Facility
The search can't be a part of Drupal or ANY similar system but will always be integrated via some glue. None of the systems mentioned have any integrated search beyond the limits of what the underlying RDBMS can offer. This is, of course, not terribly good but not really the fault of Drupal. Drupal can work fine integrated with search. The quality and magic of the search is really the quality and magic of the search software.
--
Edward C. Zimmermann <edz@nonmonotonic.net>
BSn's Nonmonotonic Lab
one is easier to administrate
On one server I'm involved in administrating, we are moving to Drupal everything and away from other "best of breeds" options because we are administering too many sites. For security reasons, we've decided it's much easier to keep Drupal upgraded than to have to manage too many different applications.
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
focus
You need to decide what's best for your environment and your needs. Personally I am confused by this need for all these features that the other forums have but that's just me (and I'm not building your site).
In addition to maintaining three seperate products, you have maintain accounts for each... You can probably sync accounts through webauth module or something but no wyou have added complication to your setup that has to be maintained going forward.
You lack integration. You can promote 'one' sites posts/information/announcements to one of the sites, but then you have to write and article and/or link it on the front page instead of merely promoting it as you could using Drupal alone.
While Drupal does not necessarily have all of the Forum features that others might have, what are you missing that you desperatly want? A lot of functionality can be gained through add in modules. If it doesn't exist, then it can probably be written. It will not be written until someone is interested enough to do it or pay for it.
There have been several attempts at integrating wiki type functionality as a module in the past with varied results. Most disappear. We'll see if any of the current tries survives to be contributed.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
The ideal, of course
The ideal of course is to use just Drupal, rather than face the complexity of integrating other open source software. However, since Drupal relies on modules for a lot of crucial functionality, I don't think the attitude can be "let the modules sink or swim, and watch with interest".
Instead, I think Drupal should move more towards CMS because it will never compete (and I'm sure isn't trying to compete) as a solo blogger with the competition. Therefore:
CMS already
Drupal is a CMS with blogging capabilities not the other way around. The general life cycle of Drupal is, if it;s not needed in core, it should live or die as a contrib module.
phpTemplage started as a contrib with 4.5. Then in 4.6 it was not quite ready when 4.6 freeze went in. Work still went on. It is already commited to HEAD for 4.7.
Define necessary. I have gotten along fine for almost two years without flexinode until I needed to install it for the event module. Flexinode is contrib module. People learned a lot with it. It drives me nuts but that's all right. It is being replaced with the CCK (Content Construction Kit). Why? Becuase a lot was learned with it as a contrib module. Will CCK be in core? We'll see.
Node weighting... umm... What? /me wonders what the code to apply lead sinkers to nodes would look like :). In any case, I haven;t needed that either. But if YOU want it, file a feature request and make a patch, review comments, resubmit.
As to the handbook, start writing. We don't have that many people donating documentation that we arn't in desperate need of more. Themeing is easy to get into, but Drupal is not a simple bblogging tool where every page is the same. With blocks paths, each page is potentially a bit different. Themeing takes care and time. Need more. Need more docs.... someone start writing. It goes into moderation queue for approval. This is a hobby for me. In no way do I get paid for using or supporting Drupal :). Besides, what is missing?
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
CMS already ...
I don't know too much about Drupal, so you'll have to excuse me if I'm using the wrong terminology :) but it appears that there is no way to configure the exact order of nodes on a page. This means if I am trying to incorporate say eight nodes on a static page, I can't easily control the order they appear in (without using modules which might not be supported in the next version of Drupal).
If this is the case, it severely limits my use of Drupal as a CMS. If it isn't the case, then I have been searching for two or three weeks for the information I need unsucessfully.
My frustration with the various menu systems led me to write my own menu in php.
Either Drupal has limits as a CMS, or the documentation should be improved.
Your comment
nicely sums up the current attitude. The point I am trying to make, is that if developers of Drupal spent some time writing better documentation, Drupal would be far more accessible. I wish Drupal had documentation like WordPress, and unfortunately I'm not in a position to write it. Maybe a start could be to remove the outdated information in the handbooks?
BTW, I wouldn't be in this forum if I thought there was any other software that suited my needs better than Drupal, so I'm not meaning to sound too negative.
choice
I suspect there is a way with a contrib module but could easily be wrong. There are some various layout modules but I haven't used them.
As to the menu system, I have posted several items on them, you will need to find them as I am to busy to dig them out for you. The menu is fairly powerful depending on what you want to do. I really should add somethign to the handbook but my job and my kid keep me very busy and he's cuter than you.
Well, let's turn this around.... if someone PAID the developers for their time to write this documentation perhaps they would? Drupal currently is for developers, site admins and the dedicated power user/hobbyist to setup there own fairly custom sites. With a series of standard modules and contrib, youre site can be very different than mine and still run lean and clean.
I wouldn't know nor am I interested. Never used it, doubt I ever will. However, it will only get some if users contribute documentation. Without help it will remain as it is.
and here you are wrong. You are in the perfect position to write docs. As you figure things out that you feel are not sufficiently documented, write it. Drupal is a community and without COMMUNITY participation, these things will not develop. Without user involvement, it will not improve. There are only so many active developers at any given time and I would rather them focus on developing and bug stomping.
Four months ago we didn't even have a documentation team. Think about it. We've made a lot of strides. If you feel infomration is outdated, the file a bug report against the documentation project. It will be addressed.
The handbook was recently completely re-ordered. The modules section was given some serious attention in an effort led be Amazon. puregin lives in the handbooks as far as I can tell from all the activity.
You have a right to your opinion. Stick around, help out, make it better. It's about community involvement. Remember, better for you is not necessarily better for me. :). THis is not a bad thing, merely what is.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
You make a lot of good
You make a lot of good points. Fair enough - if Drupal is for developers etc, as you say, then I can see why documentation isn't seen as a priority.
Node order
You can, of course, tweak the order of items in a page. The pages are little more than rendered nodes and its relatively trivial to write a little module to sort whatever items you want to any sort criteria to build a node. The main limit we've seen with Drupal is that the current implementations of node model have made a (limiting) assumption that node objects have been dervied from the underlying RDBMS. We have extended nodes (and, of course, the themes and theme enginges that render them) in our search module and it works fine. It was simple to code.
You talk about weights but how should one use them? Assigning fixed ranks to content might sound appealing to you this moment but as soon as you have it you'll find it insufficient and will want more.
As I've pointed out in other threads: The direction I see for our use is to have all "front pages" being generated by search queries to a (or a network of) search servers and ordered as per the query (be it chonologically or by some other ranking and whatever weighing). Since each Drupal can pull its content from other's RDBMS in a network of peers we can have a fully distributed network of Drupals where content is distributed and access is distributed. This can scale.
--
Edward C. Zimmermann <edz@nonmonotonic.net>
BSn's Nonmonotonic Lab
I'll be shot for this
(at the risk of posting in the wrong forum) ... if I have one page where I want to display 10 or 20 nodes in a particular order, what method would you advise?
I need to upgrade my module
I wrote a module to handle this in 4.5. I need to bring it into 4.6. But I think it will still work in 4.6 (no guarantees).
Try downloading from http://drupal.org/node/13906 and let me know if it works. Read the README. It has some instructions on how to order nodes.
--
Get better help from Drupal's forums and read this.
--
Prometheus Labor Communications
I tried your module, but
I tried your module, but couldn't seem to get it working. It installed no problem, but I kept getting "page not found" when I tried to access its url. Actually, the teaser module provides node weight - I was wondering how other people have managed this problem though; maybe they write their own modules?
What version of Drupal?
Which version of Drupal did you try it with? Let me know so I can maintain it properly.
--
Prometheus Labor Communications
4.6.2
4.6.2
Why to choose a several apps over all Drupal
After struggling with Drupal for several months, I have found some compelling reasons to choose a collection of applications instead of pure Drupal.
If you have a site with an organizational section, a blogging section, a community section and perhaps a store, you might want to consider a collection because when Drupal goes from one version to the next, there is no compatibility policy. In fact, the opposite is true (there is a school that believes that code should not be allowed to gather dust).
What this means is that every time Drupal goes through a revision many (if not most) modules must be rewritten before they will work on the new version. If the person who kindly donated the module you need defers rewriting the module for whatever reason, you cannot upgrade.
There is often reference to CVS or HEAD in the documentation and especially in the forums. After a new version comes out you don't know which version of the instructions to use. A good example is the fact that I have been trying for 2 weeks to get anyone to confirm which method of building DHTML menus works on 4.6.2. The only thread I was able to find was written when 4.5 was out and said that the way of doing it in HEAD would be better. Is it the "HEAD" that became 4.6?
As an example, if you use Drupal for your community section, and OSCommerce for your store, you can be assured that the ability to have on-line sales WILL be important to the OSCommerce developers, and you will not loose it while waiting for a key module to be rewritten.
In your case, using another Wiki system might be a good choice for similar reasons. Although if you are using something else for community too, what are you using Drupal for?
I have to admit i'm coming
I have to admit i'm coming to this conclusion as well now. I'm currently trying out MediaWiki and seem to be loving it. Its very capable software, and the way it allows you to include pages inside other pages and have template variables etc. means it can do a lot.
Equally, phpBB is great at forums. Two things are really bugging me at the moment about getting Drupal to do forums: the way it handles signatures and the way it handles links to comments spread over multiple pages (it doesn't).
In both aspects - wiki/easily-editable-pages and forums - the best-of-breeds run circles around drupal. And as you say, upgrades are a pain between version numbers.
Jake
---
School and university yearbooks and Drupal web services, London
phpBB et al.
I have to say I agree about phpBB. Forums software has just been in focused development for too long to not have a healthy advantage in features. Using forums in Drupal is still rudimentary, but they aren't hopeless, and who knows what a flurry of development might come up with? (Maybe something for a bounty offering?)
MediaWiki is just most familiar to people who've used sites like Wikipedia. Drupal is almost too powerful to be a wiki. There are too many other ways to use the software. It does the wiki thing, and so much more, so in a sense Drupal might not be the best choice if you want to have a separate wiki setup with limited permissions etc.
But on balance it's the most flexible open source LAMP-based CMS around, in my book, and the sky's the limit.
As for frustrations at the state of things today, expressed by people up-thread, I'd like to offer this: How much did you get paid to come to this site today? That's how much everyone else got paid, too.
===
Laura
pingV
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
now now
This is not true or accurate and is in fact WRONG. Core modules will always have an upgrade path. I have upgraded core from 4.4 to 4.5 to 4.6 with no issue's that were not self inflicted.
This is not accurate. Contributed modules are maintained by people for their own reasons on their own schedule. Every contrib module I use has had an upgrade path provided by the maintainer.
You are free to update any contrib module that you feel has not been updated iin a timely manner and provide a patch to that project. The one section of the handbook that has been consistently updated is the module upgrade section. It has very good instructions for how to update modules. Also, you are free to pay someone to do this if the free work currently being donated to the community is insufficient to your needs.
As to the ecommerce modules for Drupal. Well metta has been maintaining them for a while now and more people are working on it so it's an active project and gaining more features all the time. So you can be SURE that ecommerce suite IS important to some Drupal developers. Saying it's not is well....
Wouldn't building a DHTML menu be a theme issue anyway? I found a resource for you that may help: http://simplythebest.net/scripts/DHTML_scripts/dhtml_menu_scripts.html
Rather then trying to confirm it in the forums, why don't you take the example code from where you found it and try it on a test system? Then you can ask more specific questions on how to deal with any issues rather then trying to get someone else to build something that you want.
You can generally get an approximation of which Drupal version in the forum by comparing the post date with the release date of a given Drupal version. HEAD is the live development version. Often Drupal.org runs on it. It is refered to as HEAD until a release. You shouldn't be using HEAD in any case. We cannot mandate that people in the forums use a specified vocabularly for any given version. What is accurate to say for HEAD, may not be accurate in the final release version.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Frustration aside....
I'm trying not to let my frustration with the learning curve of Drupal make me sound like a troll, but your own words when I had the bad timing of starting with Drupal just before the 4.5 - 4.6 upgrade were:
When I started this project, one of the key modules in the decision to use Drupal was the ability to show the number of emails a user has waiting. This module was never ported to 4.6. It seemed reasonable to expect that if a module says 4.3 that means that a minimum of 4.3 is required, not exactly 4.3.
And I have built dhtml menus into my template (using a variation of the css menus technique), but the methods of populating it from the Drupal menu given in http://drupal.org/node/5943 are inconsistent and incompatable. So I have a template with static menu items, stuck for over 2 weeks. (This is off-topic and should be discussed elsewhere).
versioning
Module version will only work with the current Drupal version. The first line on this page: http://drupal.org/project/Modules and this page http://drupal.org/project/Modules/4.5 is
This is to deal with that cruft I was mentioning. :)
As to other stuff, if it doesn't work the way you want it to, then of course you want it changed. There is a process for this and there has been discussion on the dev list about the menu module. I haven't had time to track it so you would have to go throught the dev list archives for it for details and if it was relevant to what you want.
So I will repeat what I have said before. File a feature request. Write your own module that does what you want it to. Submit patches to the existing ones. Present 'how' you think it should work and hopefully someone will write it for you. Pay someone to write what you want.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Drupal still rather immature but it's definitely good enough
Drupal is still rather immature as a platform (I mostly refer to the modules here but it's still true for some of the core code). And the problems you mention are real. But I think as the more talent and money gets attracted to Drupal and as more modules get incorporated into the core, you will see these problems decrease. Also, as the code matures and stabilizes, the lag time between a new core release and module releases will decrease. The modifications needed to upgrade modules will become minimal so that even developers not familiar with the module will be able to quickly pick up the slack and make the changes in no time.
I myself have gotten burned by customizing the hell out of my first Drupal installations and not keeping good track of my modifications. Upgrading all my sites cost me a few days of work. Since then, I've learned to keep my customizations more modest and document them well.
But I'm definitely sticking with Drupal because the benefits of having all these tools on one platform far outweighs having a series of balkanized technologies that don't/can't interoperate well. I don't need a supersonic wiki or forums with all the bells and whistles that mostly just end up distracting users anyway. I can only speak for myself but Drupal serves my needs quite adequately and I'm very happy with it.
My opinion is that Drupal developers are proceeding wisely. They're stressing quality, reusable code architecture over trying to be all things to all people. This greatly increases their odds of success and that, in turn, translates directly into the improved functionality in the future that some folks can't seem to do without now.
In the end, I think it's wise for some power users to try to exercise a little patience. So you won't have cool function X, Y and Z today. Yeah, there's some features and functions I wish Drupal had, too. And I have to spend quite a bit of time hacking together some temporary customizations to make things work. However, the way I see it, I'm sacrificing a little today for a much bigger payoff tomorrow.
--
Prometheus Labor Communications