3 ms·

1. It's not clear what you're referring to by "multi-field support", but if it's something that's only available in the 3.x branch of CCK for Drupal 6, note tha

1. It's not clear what you're referring to by "multi-field support", but if it's something that's only available in the 3.x branch of CCK for Drupal 6, note that that branch is not stable anyway (only has an alpha release and should not be used on production sites). The 2.x branch is the one that's stable. Perhaps you're talking about http://drupal.org/node/695636 http://drupal.org/node/695636, in which case you'll see that the new Field API allows that feature to be implemented in a much cleaner way in Drupal 7, and there's already a contributed module for Drupal 7 being worked on to do it (which only has a beta release itself, but appears on the surface to be further along than the equivalent Drupal 6 CCK code). 2. Your comment about the database API is incorrect. Simple one-line select queries do not need to use the new OO syntax (and in fact, should not). See http://drupal.org/node/310072 http://drupal.org/node/310072. As for queries that do need it, it seems like you've missed the point; it's not "added complexity with no win attached", but rather the purpose is to support things like cross-database compatibility and access control. Sure, it was simpler in Drupal 6, as long as you didn't mind that your code might not work at all on certain websites :) If you're writing custom (site-specific) code for Drupal 7 and still don't care about that, you can likely use the simpler syntax for more things than it is intended for (although it's obviously still not recommended).

knieveltech 15y ago
CCK 3's stability isn't the issue here. Given the module maintainer's track record nobody in the community doubts that 3.x would have reached maturity. That development effort was halted when it was announced that Fields API was going in core. In the mean time you still can't sync multiple instances of multiple fields using pure Fields API, not to mention the huge number of field types entirely unrepresented in the core implementation. So again, we have traded 30 extra sections of time spent on an initial site installation for a feature locked partial implementation that cannot change for at least the next 3 years. Even if the implementation was complete, given how quickly the web changes I don't think any of us can confidently say that it will be well positioned to meet the needs of the day 3 years from now and now that it's in core, it cannot grow between major number releases, which is really what this is all about. My statement about the database is not incorrect, but I recognize that it's an unpopular position. I am well aware of the stated design goal of the new API. The problem remains that core devs have troweled a ridiculous amount of additional complexity into core to satisfy a small contingent of potential enterprise users that are hell-bent on running MSSQL or Oracle. I recognize the tradeoff here. On the one hand you have ease of use. On the other you have huge stacks of enterprise client cash. I don't think anyone's confused about which way Acquia went on this one.
- chrisstrahl 15y ago
  I'm an Acquia Project Manager that started working with Drupal in a company that I owned and was one of the PM's for the drupal.org redesign. 2 quick things... First, I'm struggling with relating Acquia to the MSSQL and Oracle work that was done with the new API. Didn't that come out of AF83 / CG getting a significant amount of investment from Microsoft? Hasn't the decision to put it into core led to a lot of really good conversations and partnerships with other technology providers including everything from additional funding for contributed modules, core, drupal.org features and other things? To be sure, it's easier to develop for just one DB, but it creates a choke-point for adoption that has the potential to stifle a lot of really good things that come out of it. While Acquia has supported the new API, I think it's a stretch to say that Acquia went for the cash as I think we've only done one or two projects of any significance that were not based in MySQL. I've heard of several other projects, and even some really big ones, but they're all at other shops. Singling out Acquia is a clear case of misperception here, and I think if you're going to bash, you should do so fairly. Second, what's wrong with developing in a direction because you're being paid for it? SOMEONE needs to make money off this, and contributions like the ones your pointing out are both significant shifts in what a group of invested organizations, developers, peers, and business-types decided was the right way to go. The sell-out argument is weak - nobody is running a charity because there are too many of us that have to have jobs so we can pay for things. I agree that the endless pursuit of revenue is not the only thing that matters, but I struggle to see where our (both Drupal's and Acquia's) purpose has become unmoored from our profit motive. The new DB system, fields in core, overlay, and the myriad of other D7 changes are big. There are sacrifices. However, they will continue to improve as more development work gets done and we'll see significant incremental improvements in what many smart, dedicated, and yes... even non-Acquia people agree is the right direction.
  - knieveltech 15y ago
    tl;dr: Don't piss in my pocket and tell me it's raining. I understand what you're getting at but I've been with the project since 4.7, and I feel like the time for happy-fun-time talk has passed. Like most community developers, I supported the overwhelming majority of the changes that went into D7 when they where being discussed among the community. Now faced with the reality of D7, I see that some (maybe most) of these additions where a mistake. Assuming Dries' keynote wasn't based on random numbers, Drupal had reached the "1% of total websites" threshold well before D7 was released. There was no choke point. Look at the following web server statistics http://greatstatistics.com/ http://greatstatistics.com/ MSSQL support doesn't service the majority of potential consumers of a CMS, just a small minority of potentially well-heeled clients that run Microsoft-based environments. It's counter-intuitive but I've come to realize that sucking module functionality into core is stupid. Example: your choice of forum, aggregator, or blog. All crusty, useless modules that any serious implementation will either ignore, patch heavily with additional contributed modules, or just go with a fully contrib alternative. Why do these modules all suck? They've been stuck in core and thus cannot change. When a major release is planned everyone's busy focusing on the shiny new stuff to cram into core and modules like this are typically neglected. Why should the fields API be any different, given the track record of the last five years? Also, you may not want to lose sight of the fact that it makes Drupal shops (you know, the little guys who are busily engaged with growing and maintaining Drupal's adoption base) look bad in front of clients when they've been on the receiving end of Acquia-sponsored D7 marketing blasts, meanwhile we're waving them off from migrating because core isn't stable and critical contrib modules are either unstable (RC$n or beta) or entirely non-existent in D7. I know several contrib module developers that have thrown their hands up in disgust and gone on to work with other communities while new developers are struggling with the unprecedented complexity in D7. I agree, the changes are big. Some of them are awesome (new menu structure, new AJAX api). Others range from obnoxious and/or useless (overlay) to actively harmful (see also core bug queue explosion). There was a large and VERY vocal contingent among the community that was calling for smallcore years before D7 shipped and a blind eye was turned by a vanishingly small yet disproportionately powerful minority, and now it's biting everyone who isn't vying to become a Microsoft Enterprise Partner in the ass. And that is my take on the Drupal community as it stands currently. You don't have to agree with me but it would be a mistake on your part to assume I'm an outlier.

knieveltech 15y ago

CCK 3's stability isn't the issue here. Given the module maintainer's track record nobody in the community doubts that 3.x would have reached maturity. That development effort was halted when it was announced that Fields API was going in core. In the mean time you still can't sync multiple instances of multiple fields using pure Fields API, not to mention the huge number of field types entirely unrepresented in the core implementation. So again, we have traded 30 extra sections of time spent on an initial site installation for a feature locked partial implementation that cannot change for at least the next 3 years. Even if the implementation was complete, given how quickly the web changes I don't think any of us can confidently say that it will be well positioned to meet the needs of the day 3 years from now and now that it's in core, it cannot grow between major number releases, which is really what this is all about. My statement about the database is not incorrect, but I recognize that it's an unpopular position. I am well aware of the stated design goal of the new API. The problem remains that core devs have troweled a ridiculous amount of additional complexity into core to satisfy a small contingent of potential enterprise users that are hell-bent on running MSSQL or Oracle. I recognize the tradeoff here. On the one hand you have ease of use. On the other you have huge stacks of enterprise client cash. I don't think anyone's confused about which way Acquia went on this one.

chrisstrahl 15y ago
I'm an Acquia Project Manager that started working with Drupal in a company that I owned and was one of the PM's for the drupal.org redesign. 2 quick things... First, I'm struggling with relating Acquia to the MSSQL and Oracle work that was done with the new API. Didn't that come out of AF83 / CG getting a significant amount of investment from Microsoft? Hasn't the decision to put it into core led to a lot of really good conversations and partnerships with other technology providers including everything from additional funding for contributed modules, core, drupal.org features and other things? To be sure, it's easier to develop for just one DB, but it creates a choke-point for adoption that has the potential to stifle a lot of really good things that come out of it. While Acquia has supported the new API, I think it's a stretch to say that Acquia went for the cash as I think we've only done one or two projects of any significance that were not based in MySQL. I've heard of several other projects, and even some really big ones, but they're all at other shops. Singling out Acquia is a clear case of misperception here, and I think if you're going to bash, you should do so fairly. Second, what's wrong with developing in a direction because you're being paid for it? SOMEONE needs to make money off this, and contributions like the ones your pointing out are both significant shifts in what a group of invested organizations, developers, peers, and business-types decided was the right way to go. The sell-out argument is weak - nobody is running a charity because there are too many of us that have to have jobs so we can pay for things. I agree that the endless pursuit of revenue is not the only thing that matters, but I struggle to see where our (both Drupal's and Acquia's) purpose has become unmoored from our profit motive. The new DB system, fields in core, overlay, and the myriad of other D7 changes are big. There are sacrifices. However, they will continue to improve as more development work gets done and we'll see significant incremental improvements in what many smart, dedicated, and yes... even non-Acquia people agree is the right direction.
- knieveltech 15y ago
  tl;dr: Don't piss in my pocket and tell me it's raining. I understand what you're getting at but I've been with the project since 4.7, and I feel like the time for happy-fun-time talk has passed. Like most community developers, I supported the overwhelming majority of the changes that went into D7 when they where being discussed among the community. Now faced with the reality of D7, I see that some (maybe most) of these additions where a mistake. Assuming Dries' keynote wasn't based on random numbers, Drupal had reached the "1% of total websites" threshold well before D7 was released. There was no choke point. Look at the following web server statistics http://greatstatistics.com/ http://greatstatistics.com/ MSSQL support doesn't service the majority of potential consumers of a CMS, just a small minority of potentially well-heeled clients that run Microsoft-based environments. It's counter-intuitive but I've come to realize that sucking module functionality into core is stupid. Example: your choice of forum, aggregator, or blog. All crusty, useless modules that any serious implementation will either ignore, patch heavily with additional contributed modules, or just go with a fully contrib alternative. Why do these modules all suck? They've been stuck in core and thus cannot change. When a major release is planned everyone's busy focusing on the shiny new stuff to cram into core and modules like this are typically neglected. Why should the fields API be any different, given the track record of the last five years? Also, you may not want to lose sight of the fact that it makes Drupal shops (you know, the little guys who are busily engaged with growing and maintaining Drupal's adoption base) look bad in front of clients when they've been on the receiving end of Acquia-sponsored D7 marketing blasts, meanwhile we're waving them off from migrating because core isn't stable and critical contrib modules are either unstable (RC$n or beta) or entirely non-existent in D7. I know several contrib module developers that have thrown their hands up in disgust and gone on to work with other communities while new developers are struggling with the unprecedented complexity in D7. I agree, the changes are big. Some of them are awesome (new menu structure, new AJAX api). Others range from obnoxious and/or useless (overlay) to actively harmful (see also core bug queue explosion). There was a large and VERY vocal contingent among the community that was calling for smallcore years before D7 shipped and a blind eye was turned by a vanishingly small yet disproportionately powerful minority, and now it's biting everyone who isn't vying to become a Microsoft Enterprise Partner in the ass. And that is my take on the Drupal community as it stands currently. You don't have to agree with me but it would be a mistake on your part to assume I'm an outlier.