This module's functionality completely duplicates the functionality of the long-existing Prepopulate module. Rather than starting a new project, patches should be filed to Prepopulate.

Comments

phayes’s picture

I looked hard and long for a module that does this, and I never found prepopulate. Examining...

phayes’s picture

Looking at prepopulate I can see the use for the urlfill (this) module.

Prepopulate requires you to know the form path you are trying to prepulate, and allows prepopulating on all forms.

This one is different as it allows you to turn on certain fields on for autofill, set the variable the fill will be pulled from, and also set other actions if the fields is auto-filled or not. (display 404, lock fields, hide field).

Looking at the code they are not really compatible, so this deserves to be a different project IMHO.

rcross’s picture

+1 for duplicate. I would suggest adding the additional features to prepopulate.

quicksketch’s picture

I'd also prefer that features were added to prepopulate than making a new module that is fundamentally the same with a few new features. Prepopulate is in use by over 2000 sites according to usage statistics. Not that usage necessarily indicates quality of code, but it does mean that a lot more people would immediately benefit from improving the existing module rather than moving to a different module with different APIs.

phayes’s picture

Thanks for your comments quicksketch.

I'd like to go over prepopulate, nodereference_url, and urlfill (this module), and help push this conversation forward in terms of how they are different, how they are the same, and how they might be combined under a single API.

Prepopulate:
This is a beautiful module weighing in a only 64 lines of code! It basically allows the user to do something like this
drupal/url/form&[path][to][form][item]=new_value
Which is very awsome because it allows advanced users who know something about form API to very quickly inject new default values into any form field in all of drupal. prepopulate is basically parsing that path on every form view and seeing if there is a corresponding path in the form array. The downside to this approach is two fold:
1. The site builder must know something about the structure of the form they are trying to modify. As a developer, I would like a tool I can pass to the site builder that does not require them to var_dump or dpm a form in order to know how to implement an autofill. Admittedly there are cookbooks on how to do this for certain well-known form structures, but if they are using a form that isn't covered, then they really need to know how to examine the form using code.
2. Adding data to multi-value CCK fields isn't straight forward. You can't just implement drupal/url/form&[cck_field][#default_value][999][value]=new_value because there is all sorts of other supporting structure and data like weight etc. that needs to be added pretty deep in the form.

nodereference_url
This is quicksketches awesome module. It takes a totally different approach and concentrates it's energies only on node references. This is cool because you can do auto-fills from the URL without knowing anything about form structure. You can also assign other functionality like displaying 404 if the value isn't there, and automatically adding a link from referencable nodes. Very cool! The problem as I see it is that it's implemented as a widget. This means that I can't use autofill to fill in a value automatically from a link, but allow the user to change it after the fact using some other widget like node-reference exporer.

urlfill
nodereference_url is good for node references, but obviously isn't applicable to any other field type (including title or body fields). urlfill basically expands on the functionality of nodereference_url to include other cck and node fields. The main difference is that instead of using a widget, it detects *which* widget the user is using, and based on the widget finds the correct path in the form property that needs to be filled. Like noderefernce_url the site builder doesn't need to know anything about the form API in order to use it. It is not a general solution like prepopulate that can be used on any form, because it is not parsing the url looking for a matching path. It is much closer to noderefernce_url, and if we where to merge projects, nodereference_url would be a much better match.

So is there room for a generalized API for autofilling data from the url?

I think a general API that other modules can make use of might look something like this.

1. Module declare through a hook that they will auto-fill forms through an API.
2. When a form is displayed, the API passes the form to the module to see if it is potentially interested in this type of form. (prepopulate would always return TRUE - heck prepopulate might be part of the API).
3. For each of the extra values found in the URL, the API passes the module the form object and the _GET variable asking 'is this your variable?'. If so then the module may alter the form using the variable provided.

What do you think? We should likely get eafarris, maintainer of prepopulate in on this conversation.

Cheers,

Patrick

Flying Drupalist’s picture

What does the url look like if it doesn't include the form name, and how would the module know which field to fill in?

phayes’s picture

The user defines the URL variable in the node or field admin. When you save a field, it will give you an example url in the field overview page for all your fields that have auto-fill from url turned on.

Oh yes, Multi-valued fields are referenced using mycustomvariable[]=value1&mycustomvariable[]=value2. I'm willing to look at other ways of implementing multi-value fields, but this seemed easiest for now.

I would encourage you to check it out from cvs and have a gander. Things are still rough around the edges, but it should mostly work as advertised for regular situations. If you peek under the hood at the code you'll see i'm still missing quite a bit of inline documentation, and there are quite a few //@@TODO comments. This will come - I thought I might as well release it as dev just to get it out there at this stage.

johnthomas00’s picture

For me, this module is very helpful. I have needed something like this. Prepopulate was too complicated for me. nodereference_url was too restrictive (uncomfortable widget).

Thank you!

hanamizuki’s picture

I've tried these three modules and here is how I see them. I've been looking for this kind of module for a long time, I'm glad that I found urlfill.

Prepopulate:
It was good in the begining. But later I found three shortcomings. 1) It is not working if you use Chinese character in the url. 2) It can't define variable, so sometimes it will have problems when the variable is in use by other module. like this issue. 3) it's not easy to find the variables. you need to know the form element very well to define the prepopulate in the url.

nodereference_url
it's good and simple. Useful in many place but only node reference. and it's not working with forum since they use the same path construction.

urlfill
This is the best auto-fill/prepopulate module I've ever seen. It doesn't have any of module.prepopulate's problem, and very very simple and flaxible to use! You can define your variable at every field. It support Node Title, Node Body, Textfields, Number fields and Node Reference.

I think urlfill is even better than the other, I don't think it should not be merge into Prepopulate.

phayes’s picture

Status: Active » Closed (fixed)

I'm closing this issue as it sounds to me that this module fulfills a different enough use-case than the other two modules. Please re-open if you disagree and wish to continue this conversation.

jeff.k’s picture

What about Form element defaults? ( http://drupal.org/project/elementdefaults ). I had found this a while back when I found Prepopulate wasn't doing it for me. These seem very similar. How does yours differ?

rcross’s picture

Status: Closed (fixed) » Active
phayes’s picture

Title: This module is a duplicate of Prepopulate » URLFill / Elements Default Integration

URL Fill was created September 17th, 2009, Element Defaults was created October 7th 2009.

So really, Element Defaults is a duplicate of URLFill.

But the point still stands - how can we integrate Elements Default and URLFill to have less code / module duplication - I will have more to say on this when I review Elements Default in more detail.

I'm moving this over to Elements Default so that the maintainer there can have a say.

phayes’s picture

Project: URL Fill » Form element defaults
Version: » 6.x-1.4
Component: Code » Miscellaneous

Moving to Elements Defaults

phayes’s picture

Just to recap:

We have now four modules that do very similar things:

- prepopulate
- nodereference_url
- urlfill
- elementdefaults

Am I missing any else??

This situation is a little silly and any work that all the maintainers can do to brings these modules closer together would be a good idea.

alexbk66-’s picture

doublejosh’s picture

alexbk66-’s picture

I've tried all of them and ended up using prepopulate.

doublejosh’s picture

@alexbk66- Mind putting a few notes into the table in the "Key Notes" column?

alexbk66-’s picture

@doublejosh, it was almost a year ago, I don't remember much, but I'll try when I have time.

rokr’s picture

I've been using prepopulate and nodereference url widget since years. URLfill fills a gap where you want only special fields prefilled. For example a node reference field but let it editable. Prepopulate allows to prefill all fields on all forms sitewide to be populated. I don't think this is a good approach for a simple use case.

Just my 2 cents and yes, it would be great to see these features merged in a future module.