[D7] Field conditional state

Hoping you get your application accepted soon - really need this for a project I'm working on at the moment!

Sounds like great functionality for a module... I'm also hoping your application can be reviewed soon!

Link to sandbox project for review: http://drupal.org/sandbox/peem/1073388

Subscribe

We have duplicate project application issues.
I'm not sure which one should be closed.

Edit: The other one was closed

Subscribe

subscribing

Love this. Hoping for Field Group powers.

subscribe

Additional Feature Request. Moved to feature request: http://drupal.org/node/1085406

Hi Wallace123455,

this thread is for promote "field conditional state" as project applications in drupal.org.

You can post your question in Issues for Field conditional state

Robertom,

Thank you, I am new to Drupal and learning how the community support works. I definitely would recommend "Field Conditional State" as an approved module. I use it everyday and am very appreciative of the hard work.

Tried out the module - it worked very well.
Is there anything holding this application up other than just waiting for someone to have the time for a review?

Subscribing...

@peem83: Have you reached out to the maintainers of http://drupal.org/project/conditional_fields (via an issue or e-mail) asking if your code might be appropriate to become the 7.x version of that module? I'd love if we could cooperate with them and have one great conditional fields module rather than two different efforts. Could you post a link to the Conditional Fields issue if you've already created one or when you do create one?

@Dave +1. It'd be great to see everyone cooperate and make this happen. This module rocks and peem83 has done a fantastic job.

It seems people on the D7 Conditional Fields discussion thread #658012: Plans for Drupal 7 Conditional Fields are starting to think the same thing about nominating Field conditional state as the heir apparent.

One issue seems to be whether or not an upgrade path is possible from D6 Conditional Fields...

Aye, peem83 has previously indicated that he won't be creating an upgrade path - but this may change if he gets to be a maintainer of conditional fields.

Aye, peem83 has previously indicated that he won't be creating an upgrade path - but this may change if he gets to be a maintainer of conditional fields.

an upgrade path could be provided also by a third person... I know that peem83 is open to apply patch provided by other persons (see #1025338: [D7] Field Conditional State)

+1 for join forces

Any updated from peterpo?

See http://drupal.org/node/658012#comment-4393116

Peterpoe has converted conditional fields to D7 independently.

What about this module application, then? Does it still need review? Has OP done anything since a few weeks ago? This thread is quite a mess, I'd need some information whether I should review this module or not.

Have you tried contacting Conditional Fields' maintainer to add these features?

I know you'd like to have your module published, but module duplications is an issue drupal.org wishes to avoid.

Can you describe in particular what this module does that the D7 version of Conditional Fields does not do?

Those mentioned above are not in the latest conditional fields module but have been in the queue as a feature development for the past year =)
The maintainer of Conditional Fields is very busy so is not able to work on them it seems.
It would be great if Conditional States work can be merged into Conditional Fields,
or if Conditional Fields D6 can have an upgrade path to Conditional States.

Agreed. I think this is certainly a case where collaboration is strongly encouraged. Conditional fields maintainers may be very busy, but hopefully not too busy to work with contributed patches if possible. Conditional fields was popular in D6 and despite the changes to fields there's no sense in competing in D7. We would love to see these features Integrated into a popular existing module by any means possible.

I say let us please have this as a full module. Not just to honor the continuous effort (kudos!) but also because it works beautifully with a very comprehensible UI and unique features.
it is already used on production sites and I am sure if we get some hands on it we might manage a merge with conditional fields by D8 =) having similar modules brought us far in the past, so what if one gets obsolete at some point

I really like this module and agree with discipolo's comments in #31.

I agree with #31 and #32. I know I use this module in production and it works well. Last I looked, Conditional Fields still only had D7 dev which clearly said "Drupal 7 version (3.x): 7.x-3.x is currently in development. It is a complete rewrite of the module that leverages the new entities system and the States API. Not ready for use on production sites yet. ".

Field Conditional State is ready to roll. I also believe Peem83 has put in a lot of effort. I never used D6 and started directly on D7. Field Conditional State was the only option I have had to implement conditional features which work prior to save on the node. Peem83 was really good to answer questions and implement fixes/patches.

IMHO Conditional Fields is still not ready for production if the module still says "Not ready for use on production sites".

Please review and promote Field Conditional State because it is ready to go and has unique features. I also believe Peem83 is eager to maintain it. At a later point, if Conditional Fields is every also promoted to a production version for D7, then perhaps the maintainers can work together to deliver one great product.

Can't wait to see this in full modules.

+1

@Dave Reid, what's needed for this module to become a full project?

I think that the mere fact that Conditional Fields is not ready for production leaves the way out for alternative modules.

I think its a sad fact, that such a usable module does not get approved. The "competitor" to this module, conditional fields is still not ready for production use (as peterpo says on the module description page).

Seems like a decent project is killed here...

http://drupal.org/project/issues/conditional_fields?text=&status=Open&pr...

Conditional Fields is full of unsolved bugs, and unsuited for production sites.
Attempts were made to join forces, but the good code is being prevented to receive a proper project page.

Enough time has passed and Conditional Fields is still not up to the task it proposes.

@peem83, how is Field conditional state ?

i would say this needs review again? its hard to figure out from http://drupal.org/node/532400 what needs to be done. i would almost say it is reviewed by the community unless someone finds code problems.

it says at http://drupal.org/node/894256
"Duplication is different from similarity. A similar project that explains how it is different is helpful to the growth of our project."

so in order to describe whats better than the alternate module in one sentence i would say:

it puts conditional state configuration into the field ui where it is expected instead of a general configuration form.

imho that is its main selling point.

Please don't mind me commenting though not knowing anything particular about this module, there are those 2 cents left in my pocket and I need to spend them ;)

1. I really really do appreciate the thought of avoiding module competition and duplication. From a user's point of view (assuming those who just want to find a plugin, install it in the backend UI and go being "users" and seeing myself as a user for some two years before I started developing modules myself) the current situation is really horrible. Regardless of what module you search for, you either find none (rare) ore at least five dozens, having lots of dupes within, where try-and-error in a test environment is the only way to find out what is useful. That said, I can really understand that any chance to block duplication is being taken. But:
2. Once approved, anyone can promote as many (duplicate) modules as he wants. Right? And be it even something like in the case here, where an existing module has been released but obviously is not being maintained properly(?) - nobody would intervene and say "hey, unpromote this please". Right? Considering this, you will find every new Drupal user ("user" as defined above)
   confronted with another problem: Hey, that module sounds good. But is not ready yet. What do? I, personally, either patch and contribute or, if an existing module is really "bad", sometimes construct something totally new. This might have been the case here. What I have noticed in probably one year of contributing patches is that, while some few maintainers actually appreciate any support, many of them sadly don't even check their issue queue.

What I want to point to is that we should eventually re-think the general process? E.g., shouldn't a project's status probably by changed to "left alone" automatically if the gap between raised issues and fixing grows too big? And, in consequence, shouldn't such modules probably be regarded as not being "challenged by a competitor" if someone moves his ass and tries to help out of the problem? And/or, couldn't there be something like an "appliance as spare maintainer" (without the original maintainer issuing the blessing) for such modules, which I think would also often help to prevent duplicate work?

Just one out of many thoughts I have already had on that and, most obvious, not the best place to post it (btw, where IS that place? Surely there is already a permanent discussion on that, links appreciated). Anyhow I think there is a real issue but not yet a real adequate solution.

Sorry again for being partly OT.

Drupal is more fun when there is more coding and less bureaucracy.

I don't see the harm in letting this code be its own module. People are lobbying hard for it so why such resistance? It's not like this would be the first similar module ever.

I'd rather have one that works than one stuck perpetually in a broken/buggy state for Drupal 7 and another stuck in this thread. Who knows, perhaps this module becomes the only module available for Drupal 8, 9 and 10...

Master Branch

It appears you are working in the "master" branch in git. You should really be working in a version specific branch. The most direct documentation on this is Moving from a master branch to a version branch. For additional resources please see the documentation about release naming conventions and creating a branch in git.

README.txt

Please take a moment to make your README.txt follow the guidelines for in-project documentation.

coder on minor

I noticed some very small code style issues. Please run the Coder module on "minor" setting to help catch these. The coding standards have even more information in this area. I'm also attaching a patch which will fix most, if not all of these, please review the changes.

Please note: The Coder module currently has an unresolved flaw which will prompt you to add file declarations to your .info file even when it's not necessary to do so. Please do not try to make this warning go away by declaring files which do not contain classes or interfaces.

files[] without classes or interfaces

It's only necessary to declare files[] if they declare a class or interface, and you don't have any of these.

Please note: The Coder module currently has an unresolved flaw which will prompt you to add file declarations to your .info file even when it's not necessary to do so. Please do not try to make this warning go away by declaring files which do not contain classes or interfaces.

Functions not documented properly

Please review the Doxygen and comment formatting conventions. In the attached patch, I made changes to field_conditional_state.admin.inc, but left @todo comments in field_conditional_state.module.

Javascript not using Drupal.behaviors

In settings_form.js, I switched document.ready to Drupal.behaviors. I left the other files as is, but please review them to see if they can be converted.

I don't know if anyone has gotten this problem but in Internet Explorer, this module doesn't function properly.

I've set some conditions so that one select list would appear depending on the item selected in another select list.
It works fine in Firefox and Chrome, but conditional select list refuses to show up in IE.

Any help would be appreciated.

I'm having the same issue as @slickk.

hi slickk and sweimer,

i remember having problems with field_condition_state and IE9 - what helped for me was getting the most current version from git.

might be worth a try at least..

best,
walter

PS: Seems like this should be a separate Issue, by the way.

I say thank you peem83! Ive been struggeling for some time now with Conditional Fields, trying to get i to run along with the Commerce module (that by the way wont work at all). This module though, is way up to the task...thanks a lot!

Can't wait for the official stable version. Thanks for your hard work!

Is it just me or field conditional state totally broke after drupal 7.14 update?
- the javascript part.
it works with 7.13 tho, so it must be something with new features. anyone else experiencing this?

I've tested the module on 7.14, and it seems to be working very well.

I tested it by creating a checkbox (controlling field) and a textbox (controlled field) which would be toggled depending on the checked status. Furthermore, I also checked it by creating a list (controlling field) to see if selecting given elements would work.

It all worked very well.

One question though with regards to the scenario with a list as a controlling element. I set the controlled element to be required. Would this setting "override" the conditional "requiredness"? That is, would the field always be required if i set the field itself to be required, regardless of the conditional "requiredness"?

1. Your project page is not very detailed about installation instructions, please have a look at the tips for a great project page. Also the contents of the readme should repeat the synopsis on the project page.
2. _install: // Set the module weight to 1000. Actually your setting it to 100, also you may document why you need to do this.
3. @todo. is a not very good function documentation, please avoid this. Rather a bad function description than none.
4. your making really rarely use of inline comments; that's not directly a problem but you'll make the live of other developers who want to provide quick patches hard as they have to read through the actual code first to understand what's going on.
5. Avoid putting html into t() if possible
6. admin.inc, line 109: '#options' => array('or' => 'OR', 'and' => 'AND'), maybe OR and AND should also be translatable?
7. t('@c', array('@c' => $condition_settings['condition_type'])); It makes no sense to make this string translatable, also @c won't really tell translators what'll be put in.

Anyways, could not find any serious issues and it looks to me that you've more than enough drupal development knowledge for being a vetted user. Generally I'd please you to take more care about in-code documentation.

RTBC for me, let's get this done after a year...

Review of the 7.x-1.x branch:

• Drupal Code Sniffer has found some issues with your code (please check the Drupal coding standards). See attachment.

This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. Get a review bonus and we will come back to your application sooner.

manual review:

1. Quite a view coding standards errors, please fix them.
2. field_conditional_state_field_delete_instance(): why do you need the select query? Always running the delete query should do no harm? Same for field_conditional_state_field_attach_delete_bundle().
3. "drupal_alter('field_conditional_state_entity_view', $field_conditions, $entity, $data);": Hooks that are provided by a module should be documented in MODULENAME.api.php, see http://drupal.org/node/161085#api_php

But that are no blockers, so ...

Thanks for your contribution, peem83! Welcome to the community of project contributors on drupal.org.

I've granted you the git vetted user role which will let you promote this to a full project and also create new projects as either sandbox or "full" projects depending on which you feel is best.

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

As you continue to work on your module, keep in mind: Commit messages - providing history and credit and Release naming conventions.

Thanks to the dedicated reviewer(s) as well.