I've now run into the 2nd "help make our lives on d.o vastly easier by improving the workflow for X" issues where "if only we had CCK and node_reference" was the best answer:

#569552: Provide a mechanism for issue meta discussions
#648218: Make API changes in Drupal core be nodes

Fields are in D7 core, so it doesn't seem like this introduces a d.o upgrade blocker.

CCK and its included node reference field are obviously well maintained, highly supported code used by a large minority if not an outright majority of all Drupal sites.

Part of me wants to just turn it on and be done with it, but I know we need to discuss such decisions and coordinate relatively bigger infra changes like this. So, let the fight begin... ;)

I'm marking this critical since it's blocking two other major d.o UX/DX initiatives...

CommentFileSizeAuthor
#25 issue_relationship-depndency.png21.95 KBklonos
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greggles’s picture

+1 from me.

I believe the redesign work, currently very much under way and with partial delivery in January, will require CCK and a few field modules. So, this is really a question of "when" more then "if."

Crell’s picture

I am not sure if nodereference specifically is in D7 core or if that's staying in contrib. Either way, it's no big deal. +1 from me as well.

yoroy’s picture

Me wants! But you knew that already :)

drewish’s picture

+1 from me.

Gerhard Killesreiter’s picture

Status: Active » Needs work

Please try this on scratch.

greg.harvey’s picture

Better late than never, but +1 from me too. Been following these discussions over the last few days and trying to work out how I can pitch in. But I don't even know what "try this on scratch" means, so I guess not here. ;-)

rfay’s picture

So let's try it on scratch.
+1

I think I'll have perms on scratchvm before long, so can certainly help out with this.

rfay’s picture

Title: Enable CCK and node_reference on d.o » Enable CCK and node_reference and comment_driven on d.o

IMO, we should try to get http://drupal.org/project/comment_driven at the same time. That will give us a great set of tools.

yoroy’s picture

Why? Please explain a bit if you can :)

rfay’s picture

I'm glad you asked!

Currently we use comment_alter_taxonomy to change issue tags from within a comment. In the future it would be fantastic to be able to update things like an issue summary field from within a comment. There are many other fields that it would be nice to add to the issue, including checkoffs (security, usability?, api change notification?). If we had comment_driven, I think we could accomplish those, and it would make project_issues far more malleable as well as we find future needs for workflow modification.

Related conversation: #648218: Make API changes in Drupal core be nodes

pwolanin’s picture

@rfay - sounds like project module would need to be reworked to have that as a dependency

Damien Tournoud’s picture

+1 for CCK (obviously), but big -1 for comment_driven. All those modules are pretty hackish (I know, I wrote a big part of comment_alter_taxonomy), and we are not rewriting project_issue before migrating to D7 (which solves everything is a very elegant way).

yoroy’s picture

Thanks rfay. Technology issues aside, I'd much prefer to testdrive smaller steps sooner than bigger 'more perfect' ones later.

dww’s picture

Title: Enable CCK and node_reference and comment_driven on d.o » Enable CCK and node_reference
Status: Needs work » Needs review

Let's have a separate issue about comment_driven:

A) It's not universally agreed we need it
B) It's not already blessed by the sec team and infra team for d.o deployment
C) Discussing it here is likely to delay improvements that can come from just having CCK and node ref.

Thanks,
-Derek

p.s. We tried some stuff on d6.p.d.o using just CCK. It (obviously) does what it does for 100s of thousands of sites. ;) @killes: not sure what else you want us to try before we can push this live on d.o. Is it just that you want to see better proof-of-concept approaches to the linked issues?

Gerhard Killesreiter’s picture

The problem with deploying a largish module such as cck is usually that somebody just switches it on, walks away, something else breaks, and I either have to find that person to fix it or do it myself. That's why I asked it to be tested on scratch.

One thing we'll need to do is to update our memcache config to take care of cache_content.

Both of the linked-to issues don't seem to be universally agreed to, though.

Nick Lewis’s picture

Both of the linked-to issues don't seem to be universally agreed to, though.
I'd say its almost universally agreed on that node reference is a powerful tool that we want to put in drupal.org's toolbox.

The disagreement seems to be on the consequences -- and with good reason... ...the wrong hands nod reference can do naughty things... (e.g. back references that go through a hierarchy of more than 5 nodes into infinity...).

+1 from me - node reference, like views is a tool where fools are allowed to crash their own webservers... we're smart right? :-D
More importantly, the only alternative is probably another *only on d.org* module...

p.s. pardon my ignorance, but can we benchmark changes on scratch to assess possible performance implications... not fully understanding the use of node_reference, this is my only worry...

dww’s picture

@killes: Right, neither of the linked-to issues are "RTBC" yet. We're just trying to keep this going in parallel so that when they're ready, we don't have to delay deployment even more while arguing about this.

Given that none of our scratch sites actually have the memcached config like d.o, it makes it hard to test that aspect of changes like this.

Gerhard Killesreiter’s picture

I don't think the memcached issue needs to be specifically tested, but people need to be aware of it, configure it, and monitor the memcache bin after deployment for a while.
It is just one specific bit that I remembered right now (for example our new servers weren't able to access the one external memcache bin we use ...).

Once the dependend issues are rtbc, we can install cck, I guess.

Amazon’s picture

Is there an upgrade path from CCK to fields yet?

Can 100K users assume someone else is doing it? Likely.

Could we get the people working on the upgrade path to commit to, or have someone else commit to fund it. I want to know if this is going to become a blocker to upgrading Drupal.org to D7 first.

webchick’s picture

Karen Stevenson is working on an upgrade path for CCK called "Content Migrate" module, part of the CCK package. See #781088: Updating CCK Fields and Data from D6 to D7 and http://drupalcode.org/viewvc/drupal/contributions/modules/cck/modules/co.... She's also writing documentation as she goes on how this was done at http://drupal.org/node/728792 to help other field module authors. And finally, there is a core issue where all of the field API maintainers are strategizing at #366364: [meta] Data migration from D6 contrib CCK fields to D7 Field API.

I think it's safe to say that by the time Drupal.org would actually upgrade to D7, this should be pretty well in hand.

dww’s picture

Right, if there's no way to get D6 CCK fields into D7 core fields, we should worry about not releasing 7.0 instead of worrying about not upgrading d.o to D7... ;)

rfay’s picture

Status: Needs review » Reviewed & tested by the community

Bump. This has been deployed on the scratch site, worked OK. CCK has a long track record. Let's get it deployed.

dww’s picture

Status: Reviewed & tested by the community » Postponed

rfay: killes wrote in #18: "Once the dependend issues are rtbc, we can install cck, I guess."

so this issue is "blocked" ;) on the two issues i mentioned in the original post. whenever either of those have a viable implementation on a scratch site (and any custom code necessary in drupalorg.module or something), we can deploy and enable these modules.

rfay’s picture

@dww, thanks for explaining. I guess we have to actually get to work on those two issues.

klonos’s picture

I love the way this is handled in bugzilla.mozilla.org...

dww’s picture

@klonos: Thanks for the image, but that'd probably be more appropriate to post at #44162: Relationships between issues: support for parent issue and related issues or #569552: Provide a mechanism for issue meta discussions not here.

Cheers,
-Derek

klonos’s picture

I thought so Derek, but I wasn't sure. That's why I have posted a link to my post #25 here in #44162: Relationships between issues: support for parent issue and related issues

The implementation of this would require node reference though. Right? So I am not entirely off-topic ;)

BTW, is there a way to reuse already uploaded files/images so I won't be cluttering the server/db? I am asking because I see no img tag support.

dww’s picture

You can just reference http://drupal.org/files/issues/issue_relationship-depndency_0.png in another issue... ;)

Anyway, the point of *this* issue is about enabling CCK and node_reference on drupal.org. The *other* issues are to talk about the details of the features that would *use* CCK + node_reference. So, your comment was off-topic in here. What this issue needs is to be able to link to progress in the other issues that shows viable solutions ready to deploy on d.o. This issue is not for discussion of any of the dependent issues. It's only a placeholder to re-open once one or more of the other issues are further along and we're ready for them to go live.

Cheers,
-Derek

klonos’s picture

Thanx Derek for taking the time to reply. I did link the screenshot to both of these issues as you suggested.

I know I can link to images (and other files) already uploaded, but I was referring to what for example Daniel (sun) is able to do here -directly insert the image in the post-: http://drupal.org/node/576290#comment-3418158

I guess only some people with the right permissions are able to insert img tags :/

jhodgdon’s picture

Another two issues for Docs infrastructure that need CCK and nodereference:
#1027608: Use forum to make Discussion tab/block for Book pages
#995292: Noderef field on issues for Documentation project

So my understanding here is that if I make a viable system on my sandbox site that everyone agrees resolves one of these two issues (which are major if not critical for docs) or the two mentioned above, and the solution depends on having CCK and Nodereference, that CCK and Nodereference will be added to d.o -- that all that's holding up adding these is that we don't need them at the moment.

Is that correct? Because I don't want to go down the path of making a solution for those two issues if it would just be rejected.

Gerhard Killesreiter’s picture

Yes, that is correct.

jhodgdon’s picture

Issue tags: +docs infrastructure

Thanks Gerhard. Adding tag for docs infrastructure in that case.

dww’s picture

Status: Postponed » Active

This is nearly done thanks to #1100882: Review modules for marketplace. CCK + node reference are now visible at http://drupal.org/admin/build/modules but they're not yet enabled since http://drupal.org/project/issues/search?status[]=Open&issue_tags=drupal.... isn't done yet, e.g. #994350: Create an organization node type. But, it's so close we can smell it. ;)

pwolanin’s picture

@dww - why do we need that search to work if we want to use them first for docs? Can we just enable them?

dww’s picture

We can enable them whenever we have something that needs them which is ready to deploy. My point was that this is now a single "drush en content node_reference" away, we don't even have to get them into bzr vendor branches and all that... Nothing is blocked on marketplace. Thanks to marketplace, this is even closer to being done, that's all...

pwolanin’s picture

There seem to be multiple docs-related uses just waiting for them - can we enable and start configuring?

jhodgdon’s picture

pwolanin: The docs issues are still waiting for details, demo, approval, theming, etc.

drumm’s picture

As much as reasonably possible, we want to have configuration backed by code, using exports, features, or whatever best practices work at the time. Usual drupal configuration deployment problems- not trying to solve them, but do want to work effectively with version control and multiple developers. For example, the issue for the new organization node type has that handled by features.

drumm’s picture

And we do need to carefully consider anything we add, because it is hard to remove things, and they do need attention during upgrades and other times. That should not stop us from adding fields and content types, but we should be smart about it.

drumm’s picture

Status: Active » Fixed

CCK is now enabled. node_reference is there and can be enabled when a specific issue requires it.

Status: Fixed » Closed (fixed)
Issue tags: -docs infrastructure

Automatically closed -- issue fixed for 2 weeks with no activity.

Project: Drupal.org infrastructure » Drupal.org customizations
Component: Drupal.org module » Miscellaneous