DBFM for 6.x

Not at this time, although i'm sure it will *eventually* happen.

I had the same question...
Very useful module.

subscribe, because it's a very useful module.

At the moment I'm just adding search to the module. After that we might have a chance to look at 6

The WebFM module and this one are much alike, yes... But this one is FAR superior IMHO.

+1 for a D6 port.

Thank you for the compliment. Early on WebFM and dbFM looked and acted in an almost identical way (except WebFM was saving to the file system rather than a database) but we've kinda diverged since then! I notice WebFM now has a port for 6 and I'm sure ours will come eventually. There are more important things at the moment - I'm currently adding search, and performance issues need to be sorted out especially for IE.

subscribing!

subscribing

We're thrilled at the interest in this module, however it would be unrealistic to expect a port to v6.

In the event we upgrade, we will likely jump straight to 7 at this stage.

Anyone wanting to port DBFM is welcome to try, but it's just not within the scope of what we're trying to achieve right now.

Kind Regards
Michael.

Its funny that providing a 6.x release is not treated as a priority (What exactly is the point of a module that _may_ be supported, that too only in alternate versions?!)

Not really; We're still actively developing the module for our production platform, which is running 5.x

subscribing

What about adding custom metadata to search with, and the capability to search for a certain word in a file? Is the latest version going to be capable of this?

A 50% yes here. The next release doesn't include the ability to customise the metadata. However the release does include a full document search, but only for a few document types - xls, ppt, doc, csv, txt, htm/html, pdf and ps. The release is currently being tested and should be out very soon now.
The release after should allow searching on a few more document types and I'm hoping it will include improved upload (so that you can upload whole directories).

Shame there's no plan to port this to D6 - it's an amazing tool and we'd be interested in using it.

No *current* plan.

Ultimatley we'll have to port it to *something* - Drupal 7's arrival will mean a cease of maintenance of 5, so we'll have to move it along.

Right now we're cramming functionality into it - which will mean when it finally DOES arrive on the later platforms it'll be a hellurva lot better :)

Roo.

Any idea when the new release will be out? Any idea when drupal 7 will be out?

subscribing

subscribing

Delaying porting a Drupal 5 module until Drupal 7 is out and skipping porting to Drupal 6, appears a bit ignorant to me.

When Drupal 6 was released early 2008, only a small number of contributed modules was already available for Drupal 6. Heavily used modules such as CCK and Views were available as out-of-beta modules only more than a year after the release of Drupal 6. Anyone whose production server depended on a module that was only ported from Drupal 4 to 6 (skipping 5) in addition to being dependent on CCK or Views, would have run his production server for a year with unsupported software.

Assuming a similar scenario when Drupal 7 is out, I can not afford to build a production site based on DBFM, although it is an interesting module and I would really like to make use of it.

Groen

Delaying porting a Drupal 5 module until Drupal 7 is out and skipping porting to Drupal 6, appears a bit ignorant to me.

But you're getting this for free? - if you'd like to put in the hours to make the changes to port to 6 your efforts would, I'm sure, be most appreciated.

When Drupal 6 was released early 2008, only a small number of contributed modules was already available for Drupal 6. Heavily used modules such as CCK and Views were available as out-of-beta modules only more than a year after the release of Drupal 6. Anyone whose production server depended on a module that was only ported from Drupal 4 to 6 (skipping 5) in addition to being dependent on CCK or Views, would have run his production server for a year with unsupported software.

I don't feel that's a fair comparison. As a long-term drupaler you obviously remember the change from 4 to 5 was huge. The changes from 5 to 6 and 6 to 7 are much more managable (and much less work).

But you're getting this for free? - if you'd like to put in the hours to make the changes to port to 6 your efforts would, I'm sure, be most appreciated.

Yes, I know it is for free, and it is really appreciated. But tying yourself to a module that might put you into a situation where your production server runs for an extended time on unsupported software introduces a risk. One has to decide whether he wants to take that risk.

I don't feel that's a fair comparison. As a long-term drupaler you obviously remember the change from 4 to 5 was huge. The changes from 5 to 6 and 6 to 7 are much more managable (and much less work).

Unfortunately, I am not that long-term a drupaler. I got in when 5 was out, so I can't say too much about going from 4 to 5. In my example I talked about when 6 came out and it took one year for the major modules to be released for 6 too. You just said the changes from 5 to 6 were more managable. If the changes from 6 to 7 will be as managable, I should still expect another year for the major modules to be released for 7. I hope you see my point.

Anyway, since the beginning of this year I am at Drupal 6, so currently I can't even consider using DBFM.

Groen

subscribe - drupal 6 : )

My company may put in some hours to convert this module to Drupal 6, but I can't promise anything. I'll post back here when we've reached a decision.

subscribe - drupal 6

subscribe

This module looks great, but I use D6.
If, when D7 is released, it has everything else I need, I may look into using the D7 version of this, but there's no way I'm going to downgrade to D5 for this.

So?

subscribe

subscribing for drupal 6 version

The salient point is whether the maintainers are interested in Drupal 8 as well as Drupal 7. If every other version is going to be skipped, it's a difficult module to invest in.

This was exactly what I meant, but I think I didn't make it clear enough. Drupal maintains two versions concurrently. This done to ensure that there is at least one version that is fully matured and allows you to run a production site including the major contributed modules. If a module skips every other version of drupal, and I depend on that module, my site will run unmaintained software for say a year. And this repeats every other version. This might be acceptable for a small private site, but not for a slightly bigger production site.

Of course I am aware that the module is contributed to the community and that is a favour in itself. It is up to the individuals in the community to use it or not, or even to initiate a port to a new version of drupal. However, unfortunately I am not in the position to take that upon me know. I am just at the receiving end here.

So basically, my point was that I found it an awkward decision (especially for a company) to skip every other version. But of course I have no insight in the decision making behind it.

For me personally, I assess what modules are kind of "crucial" for my site. I only decide to start using them if there are some signals reassuring that the module will probably be maintained constantly for some time. For less critical modules, the nice to haves, it is less important. If I decide to use DBFM, I kind of lock myself into it, because if it is not available in a new version and I decide I need to upgrade, my files are stored in the DB, and the only thing I can do is manually add files again to my nodes based on file system storage.

Actually I should not care if a Drupal 6 version will be issued. The question is, if a version is released (whether it is 6 or 7), what are the chances that the next version will be released too (id est 7 or 8 respectively).

At the other hand, I appreciate the maintainers inform us that this is there current policy. This is useful information to me, which happens to make me decide not to use the module (at least for the time being).

Groen