Can't edit flexinode: flexinode requires image upload and can't update

I am not sure this is a bug. (Although it is confusing.) There must be a value in the max size. The module interprets the null value as zero instead of infinity.
This is true of all the image related sizes. If you leave the thumbnail size blank, you get a divide by zero error.

Please help me find a better bug to hijack than this one, b/c while I think bomarmonk has identified an issue, I think it's merely symptomatic of a general issue with image on flexinode (from my observation and limited understanding). Has anyone got image to work on flexinode in 4.7?

Frustrated, I went in to flexinode.module and started dumping variables. I var_dump'd $_POST, and here's all I got (see attached txt). My form, on the other hand, has the req'd title, two image fields ("edit[flexinode_3]" and "edit[flexinode_4]"), and a number field (edit[flexinode_5]) to boot. Where have my _3 and _4 fields gone? Yet.. my administration[Log] does have a msg that an image was received ("For /tmp/phpRbYCNR the system thinks its MIME type is while the user has given image/jpeg for MIME type").

hth

A thousand-and-one apologies. One first impression, right?
Uploading a file in multipart/form-data populates the $_FILES array, and indeed that's chock full of good info.

Looking at line 610 of flexinode.module:
$validation = flexinode_invoke('validate', $field, $node);
does $validation ever even get used? I have verified that the img file is being rec'd and sort of processed, b/c it will bark at me if I exceed max file size, for instance...

It appears to me that in flexinode_validate, $node->fieldname will never return true on a file upload b/c $node needs to be manually populated with the appropriate fields of the $_FILES array.

I'm having a tough time following the awesome mojo that is drupal. I'd be very happy, however, to learn and offer my modest php skills to help debug this issue if someone can put me in the loop.

wpd is correct in his assessment that there must be a value specified for max size. This in itself doesn't seem to be too bad, but the fields should be marked as #required => TRUE if they're going to throw ugly PHP errors if their not filled out.

More importantly, this issue affects everyone upgrading from the 4.6 version of the module. 4.6 didn't have options for preview and thumbnail sizes, it only had max dimensions and max size (in KB) for editing image fields. Since flexinode uses a numbered array in storing it's variables in the database (not a great idea) and the 'max size' option was changed from option 2 to option 4, you'll find your settings all screwed up when upgrading from 4.6 to 4.7 branches. Here's an example

4.6 Image Settings
Maximum picture dimensions:
[1600x1200]
Maximum picture size:
[1500] (in KB)

4.7 Image Settings (after upgrading)
Maximum picture dimensions:
[1600x1200]
Preview dimensions:
[1500]
Thumbnail dimensions:
[(empty)]
Maximum picture size:
[(empty)] (in KB)

So you can see where the problem is. I think it might be too late to fix this problem (for other users upgrading) in Flexinode however, since the problem cropped up when they changed the order of the fields.

I just encountered this problem today. There are two separate problems: (1) the max image size setting got moved to the wrong field during upgrade, which is easy to fix by editing the field settings, and (2) uploading flexinode image fields just does not seem to work at all because it keeps saying " is required" even though (a) a file is already uploaded so it should NOT be required and (b) I actually did specify a file to upload.

I'm looking into it, but I did not want to learn this much about flexinode. :-)

Barry

Actually, that does not fix the initial problem you reported. You said, "after upgrading to 4.7 beta 2, the flexinode fails to recognize the previously uploaded file and requests that the required field be filled with a new image upload." This is caused by a bug in the way flexinode uses the Forms API; I found the bug earlier this evening and will post a fix after I get home from my bridge game. :-)

I'm guessing you worked around the problem by making your image fields not required. If your flexinode image fields are still required but you are able to edit existing nodes, please let me know as I do not think that is possible.

BTW, yes, you need to include base_path in your URL; I would use

<img src="<?php print url($node->flexinode_8->filepath); ?>" />

but your approach works too. It has no bearing on the required image bug, however.

Barry

Here is my patch for allowing required image fields in 4.7 flexinode. The logic behind it is explained in a comment (which is three times longer than the code changes!).

Note that I am still concerned about something. Flexinode file fields have the same problem as image fields: if you mark them as required, you can never successfully edit the node. But something is different about how file and image fields are handled that I do not understand yet and until I do I won't be 100% certain this patch is right.

Here is the comment from the attached patch:

// Most field elements (e.g. text fields) can have a pre-existing
// value loaded into them for display to the user, but a file upload
// input cannot. Therefore, if a previous value for this field
// exists, we add a pointer to it to the form as a hidden element
// with a _old name suffix. When flexinode_submit uses our _execute
// function to obtain the file object for the field, it uses the new
// value if available or the old one if not.
//
// As a consequence of this approach, even if this field is
// "required" by flexinode, it cannot be marked #required => TRUE in
// the form because it is not in fact required in the Forms API
// sense; it is not an error for it to be absent in a submission if
// a corresponding _old value is available. Therefore, always mark
// it as not required. If the field is required by flexinode, our
// _validate function, called by flexinode_validate, will verify
// that it has a new or old value.
//
// Not marking the form field as #required => TRUE means that it
// will not be themed as a required field even though (from the UI
// perspective) it is. This could be solved by teaching the Forms
// API a new attribute, #display_required, which if TRUE means to
// theme the element as required even if #required is FALSE; i.e. it
// would be for any element whose required-ness is enforced by a
// custom validate function.

I am now fairly certain my patch is incorrect. It works (it allowes required image fields in flexinodes to work) but it solves the problem in the wrong place.

The underlying problem is that the Forms API does not support required file fields at all. When checking if required fields are supplied, it only looks in $_POST, not in $_FILES, and thus always thinks no file was uploaded.

Since this is an issue with the core I will take it up on the developers list.

Barry

The "required" issue has been reported as a bug in Drupal core at http://drupal.org/node/64984. A patch to form.inc is available at in that thread.

The code needs more work. Also, as stated, the "required" issue should be dealt with elsewhere.