By gatezone on

Here's the way it looks to someone who has been wrestling with Drupal for a few weeks.

Development is way out ahead of the production (which makes documentation almost impossible). For the poor person who wants to use the system for an organization where users are using it for mission critical functionality it's a nightmare. This has been stated elsewhere and is often met with the response of hey why don't you contribute.

This is a chicken or egg situation whereby people who are attracted to core features of Drupal but are not coders are in a very difficult postion when it comes to contributing documentation clarity. Not sure if the egg is trying to catch up with the chicken or vice versa but it hides the positive work done on Drupal and the modules under a curtain of obscurity and insider knowledge.

At this point in what appears to be well 'logged' (as opposed to 'documented') development it is obvious Drupal is leaving a wake of disappointed, frustrated, and discouraged people who really wanted to use it. I'm not ignoring those of you who are using it to good advantage, but from the list of 'broken' and hobby sites (including developers sites) in the example site list there is a lot of room for improvement.

Each issue I run into, and many are simply lack of understanding on my part, leads me to a confusing array of terminology and choices about versions, matching modules, and patches. If the production version is held in such low esteem by the developers that most are encouraged to use the in progress version (I'm still not clear about 'head,' vs. CVS -- well I know *some* meanings of the term).

My point is that maybe this is a unique time in Drupal's history but it appears extremely confusing and somewhat chaotic to a person trying to actually use it in an organizational (not hobby or blog) environment.

I'm a person who installs three platforms of operating systems, routinely sets up servers and installs & modifies phpbb, gallery, and web environments, and creates databases (albeit not complex ones) in mysql via phpadmin. In other words I'm not unfamilar with the basics. And to me Drupal has more potential than most systems, but along with it is a difficult to understand system of finding relevant information (forums, mailing lists, projects, sandboxes, etc.) - remember I find answers all the time in other open source support forums and googling.

As I've said in other posts I'm interested in contributing, but like anyone who works with technology professionally I have to get to a certain level of understanding before contributions are worth anything. If it is so difficult to get to that level it explains the eccentricity and obscurity of the support information. I don't think it has to stay that way. A better newbie area would be helpful. A more rigorous procedure about the various development streams and how they are recommended to solve production system issues.

A project that has the potential of Drupal can't indulge in defensiveness and unfortunately there may only be a small number of you who can actually
'midwife' this system to a greater rebirth.

Still hanging in here but not for too much longer. GZ

Comments

adrian’s picture

adrian commented

Each issue I run into, and many are simply lack of understanding on my part, leads me to a confusing array of terminology and choices about versions, matching modules, and patches. If the production version is held in such low esteem by the developers that most are encouraged to use the in progress version (I'm still not clear about 'head,' vs. CVS -- well I know *some* meanings of the term).

I can understand how Drupal can seem to be a very confusing project, one of the more difficult things is actually keeping up to date with what has happened since the last time you looked at the project,

I must however state that Drupal HEAD (another name for the current development version) has always been supremely stable, and sadly , a lot of the functionality that I have seen requests / interests in previously were just not implemented yet in the stable release. It's a simple case of having the latest and greatest, or living with a percieved stable version.

When Dries releases a stable release, he creates a seperate branch for that specific release and nothing, save for bug fixes, then gets added to that release. At this point, the actively maintained modules generally get updated and tested/verified to work with that specific branch. Except for bug fixes, development generally moves to the HEAD for the modules aswell.

So what you have (with the current schedule) is up to about 5 or 6 months of VERY active development, in which patches might be accepted which change the entire api (always in the favor of better , cleaner code) .. this results in anything classified as stable not being guaranteed to work with HEAD anymore, however all the major new development / features get added. When the release candidates come out, all the actively maintained contributions get tested and branched.

As you may already know, the 4.4.0 release candidate is on it's way , and all that's currently unstable will start moving it's way to a stable release in the next 2 months.

I have run sites on all of the versions (and a lot of HEAD too) since 4.1.0 , and I must say that the improvement is actually really really impressive. We have a lot more to do though , but I feel stuff currently in development (like my install api and a few others) , will leave us with an incredibly user-friendly , but more importantly, incredibly developer friendly environment.

gatezone’s picture

gatezone commented

Thanks for your response.

So "Head" is the head or most recent consolidated collection of versions in the CVS system? I'm sure this is said elsewhere but I see the terms used a lot and am not sure they are always used in the way intended.

From what you are saying one of the drawbacks to using the head version of Drupal is that major modules may not work with it. One of the benefits is that some major module's functionality may be included which makes the original module unnecessary.

Would you say that the current Head versions usually or do not work with what you consider to be the most essential modules? From my limited experience I'd include filesstore2, taxonomy menu (maybe other taxonomy modules that I haven't used yet), and image modules. I'm sure other people would have a variety of favorites.

Is there a clear location that a person could go to to see what modules are currently compatible or patched to work with head? When it comes to using Head or a specific CVS version this module compatibility would be my first (and maybe last) question. My experience going into the CVS system is not real positive. It is, no doubt, built for developers not users, but so many answers reference using it that this creates an unintentional 'torque' stress in our newbie consciousness.

adrian’s picture

adrian commented

Correct, at the moment the image module is undergoing some major work to be brought up to date with the current state of HEAD.. for instance.

Thankfully they are also refactoring (updating / simplifying / rethinking ) the code , since that module has been with us since drupal 3 days, and has just become far too large for it's own good..

The idea is though that all nodes would be able to have images attached to them, etc .. as soon as this is all done.

If you are looking for a menu module, I _HIGHLY_ recommend 'menus' , filestore 2 (which was only recently BACK ported.. because of the new File API in cvs head) is working as far as I know, but I can't give you conclusive information though.

I think the closest you can get to seeing if a module is up to date is looking at it's cvs log. Maybe we should link that more cleanly against contrib modules, to show exactly when last it was updated.. and what was done to it.

dries’s picture

dries commented

Thanks for sharing your experience. I'd be nice if you could translate this into a one or more concrete action points (battle plan) that could help overcome some (or all) of your issues.

gatezone’s picture

gatezone commented

I could/would commit to working in a consistent way on newbie to intermediate level How to's, tutorials, and participate to help with "high level" (non-code) support... *If* I know those of you with deep experience will have the patience to deal with what I think will be necessary to create the necessary support system.

The 'mission' is to translate incomplete, scattered, and self-referential, Drupal information into more central, organized, and easy to understand documents for implementating Drupal in organizational/enterprise settings. This should, in most cases, include more than enough for the hobbiest or individual user/implementer. This information should not be buried or difficult to search, find, print, or understand... duh.

The target, I am most interested in, are users *un*familiar with Drupal, and who need basic Drupal, file, and server orientation with referenced terminology in clear "Drupal for Us Dummies" format.

Because there seems to be such a strong development process here I think initial goals would be updating or establishing explanations of the building blocks that will not change *quite* as rapidly as everything else. I think it may be surprising how helpful it would be to read something about the basics written by someone who remembers being as clueless as the person reading it.

1. "You are here" -- initial orientation which assists hatchlings and juvenile (just kidding about the terminology) users understand production release, CVS, Head, and the benefits and the respective risks and benefits of working with each.

2. "Staying on the Autobahn" -- Major Releases. How to install and work with production release - probably seems insanely easy to you old-timers but I think it can be made easier to understand. Obviously the new installer will be a big help.

2.1 "Module Madness" -- There is room for greater clarity about installing, adapting, and understanding why there are so many modules. Empahsis on current basic ones that seem essential for basic functionality on most sites (taxonomy menus, filestore2, etc. types of stuff)

3) "Going Off-Road *or* Giving and taking Head" -- I sure hope there is a diverse gender base here... How to work with CVS/Head - I'm ready to take this step and might as well document how to do it from a rank newbie's perspective.

4) "Making it your own" -- Activating, installing, and initial modifying of themes like logo's, links, etc. Again this is basic and many of us figure it out, but why not make it a little easier for the next person...

5) Enterprising Drupal" -- Organization implementation considerations and recommendations. Such as: How to work with a system that doesn't have robust individual and group permissions (hopefully this will change to how to work with a robust and granular permission system)

Does this seem like a completely wrong direction? Obviously there is existing documentation and information to build on. What else? Does the development community here support a more consistent approach to newbie and intermediate support documentation? It's an impossible 'mission' without developer support, but it might relieve a bit of the burden from developers.

GZ/Kent

adrian’s picture

adrian commented

also, I personally would like to see the module list cut down to only modules that are currently in head , or in the last release..

and pages specifically generated for each branch

ie : project/modules/4.3 and project/modules/cvs

I think the sheer number of unmaintained modules give a false impression of the state of the project.

The best training manual I have ever seen, is aimed at total newbies.. and i feel a more 'poignant' guide to drupal would rock =)

gatezone’s picture

gatezone commented

...and i feel a more 'poignant' guide to drupal would rock =)

Love the use of the work 'poignant' I think all the definitions fit the before and after experience:

1) Physically painful: “Keen, poignant agonies seemed to shoot from his neck downward” (Ambrose Bierce & Drupal newbie).


Keenly distressing to the mind or feelings: poignant anxiety.
Profoundly moving; touching: a poignant memory. See Synonyms at moving.



2) Piercing; incisive: poignant criticism.


3) Neat, skillful, and to the point: poignant illustrations supplementing the text. Astute and pertinent; relevant: poignant suggestions.


4) Agreeably intense or stimulating: poignant delight.


Middle English poinaunt, from Old French poignant, present participle of poindre, to prick, from Latin pungere. See peuk- in Indo-European Roots.

TDobes’s picture

TDobes commented

I think that's a good idea, Adrian... I've filed a feature request.

gatezone’s picture

gatezone commented

Big agreement here too even more so since I've been experimenting with CVS/Head versions and the sluggish, shall we say response to issues with modules - not everyone. But I'd say if the response rate and clarity went up 25% the user stats vs visitor stats would also go up which would mean more people would use the system which means it would be helping more people... etc.

I've put in a request to start a project that may appear to be part of documentation but I see it as a supplement type of documentation. Momentum, time, and energy is not always easy to sustain but I'd like to try and help with "Drupal for Dummies."

dries’s picture

dries commented

The suggested outline sounds good. Such contributions are (obviously) welcomed and I'm sure many people - including myself - would be happy to assist were needed (and as time permits).

Below’s picture

Below commented

well, what did happen? I'd imagine for someone who knows and uses drupal, a document like this wouldn't be too much of a mission, since the outline is there already.
i seem to see lots of similar requests raised in other places in the forum as well...
caspar/london

tdailey’s picture

tdailey commented

I have to disagree with the original post. I run an internal portal for a bunch of salespeople on Drupal, and I don't experience any of the issues mentioned. Yes, there are nicer things in CVS than there are in the Production release, but that's always going to be true. I've going from 4.2 to 4.3 with no troubles. While there are features I'm really looking forward to (ACLs), Drupal is great for us right now.

I found Drupal pretty easy to get into. I've worked with a few portal frameworks over the years, and Drupal is one of the nicer ones, holding up well compared even to commercial products.

To me though, Drupal is going to require some diving into the code for a few revisions more, if not forever. The PHP code is well documented and logical. Ultimately, you need to decide if Drupal is the right project for you.

gatezone’s picture

gatezone commented

It is good to hear it's working well for you and the sales people you work with. Your experience may be helpful for others who want to use it in a similar way.

I wouldn't put time into it if I didn't think it was a good system. My interest is just to work together to clarify things for people who may otherwise pass it by when it may be the best thing for their requirements. There are people and organizations that need a system like Drupal but people tell them it is for developers and it takes a lot of technical skill. My experience is that it has some great architectural cornerstones and is suffering from growing pains and some missing Drupal for Dummies information. Let's face it we're all dummies at some point with something we're learning.