the same objective isn't coded twice. As a downside, doing it this way
will not squeeze every last inch of CPU cycles out of this loop. Whatever.

CCK checks for itself before calling it, but who knows how it gets abused
in evil other ways, so let's be prepared for that situation.

should display a file or not, in case they're not using the regular
CCK formatters. Since I removed the access check from theme_filefield(),
this function's premier use is probably to salve my conscience.

Right. So add a few more.

for whatever reason. Not that I like writing such text, but hey, these
were the last two @todo items in filefield.module. Coolio.

The even better news is that I've been able to get completely rid
of the annoying 'view filefield uploads' permission by replacing it
with the more fine-grained field-level permissions from content_permissions
which ships with CCK 6.x.

The new code makes our hook_file_download() a bit more complex,
but on the other hand only cares about files that are actually
contained in at least one file field. Yay for correctness and flexibility!

* Use an error string similar to what Drupal core is using.
* Passive JavaScript errors (in a red error box) instead of alert().

  than this, only CSS gurus should be able to improve it even more.

* On the coding side, file edit widgets are now real form elements.
  That means no buttons for such widgets, but instead they can come up
  with their own value callbacks and widget theme functions.
  Plus I now have them in their walled garden where they belong.

Includes a bit more modularization of the uploading/deletion code.

Known bugs:
* Uploads work in Firefox but not in Konqueror, that is a regression
  compared to the D5 version. An ahah.js bug? (Drupal isn't even invoked.)
* The AHAH submit-replacement behaviour won't attach to the new form,
  it seems. I experienced the same thing with the CCK "add more" button,
  let's have a look what goes wrong there.

* Re-add '#name' properties for the buttons, so that the right one
  is selected on submit.
* Scrap the broken condition (using a wrong, previous variable name)
  so that the replaced file is added to the form state again on uploading.

  That way we can encapsulate as much as possible, and that's good for
  grouping the code. Consequently, widget code order is now sane at last:
  first comes hook_widget() which decides between upload and edit widget,
  then comes the upload widget, and then comes the edit widget.
  Finally some structure where I immediately find stuff.

* Move file uploading from the value callback to the submit callback.
  I'm pretty convinced that we don't want to upload selected files
  if *any* button is pressed (not just the "Upload" button).

* Rename $fieldname to $field_name, like used in core CCK code.

Nice side effect: more filefield-classed divs for detailed themeability.

by defining a relationship to the {files} table, we get all
the file filters for free. That's pretty neat.

* Remove some more code that we most probably won't need anymore.

Looks at least as good as the 5.x version, imho.

* Comment out the stuff that still has to be ported
* Include the max filesize label from the D5 version
* Add a new token for the formatted filesize (e.g. 7.34 MB)

  so that we can have a nice value callback in order to separate
  form structure and result value (as CCK widgets are inside a '#tree').

* Convert filefield back to CCK multiple value handling, replacing the
  "Delete" checkbox with a "Delete" button and storing the previous file
  as temporary property of the new one, until the node is submitted.

multiple value widget. This was actually quite a bit of effort
due to the "replace uploads for single value widgets" special case.

I probably also fixed some bugs along the way, the one that I can
actively think of is cleaning up hook_field($op='insert','update')
so that it doesn't try to save deleted files.

consistency with filefield_field_{setttings,info}(). Might screw up
the CVS history, but I can hardly find my way around the module anymore
without searching, so something needs to change.

because it was only generated inside an element process function.

Fix that by going back to a more imagefield like approach, but not quite -
upload and editing widgets are now separated, with the upload widget only
returning the fid. The combined form element is now gone, and the widget
is directly composed in filefield_widget().

Bonus feature (on the way to deprecating imagefield): other modules can now
provide their own replacement edit forms, with priority based ranking of
which one is used. Might need a bit of work, but it's a good start.

Don't expect anything usable yet - it works, but still has a long way to go.

Thanks a lot to Crell for getting this thing rolling.

and Crell's D6 patch at issue #269073. filefield.module is not yet being
committed though, I don't feel like it's ready even for a -dev version
in the current state. Regard this commit as move to make it easier to work
on the #269073 patch.

Why is that? Bah. [insert random cursing]
So at least now everything should be in sync again.

by an "Always list files" field setting (= !$show_list).

No upgrade path (yet?) - it's not possible to have a universally applicable
upgrade path, but most people probably don't use different widget settings
in different instances of that field... so, I'll try a heuristic solution.
Scheduled for the next commit, that is.

instead of the formatter.

with something more useful for filefield users.
Not completely comprehensive, but way better than what was there before.

in hook_file_download() but also in the formatter.

so that the newly introduced JavaScript callback path works.