Problem fileupload element in repeatable group

Yes, indeed, I understand. And I confess I will need to do some things like that...

Do you need help do to theses tests ?

Cordially
 
Hi

Indeed, thanks, it is better, but :
when I have have at least one group, no problem ; but when I have no group (first record for example), icons to add (or delete) a first group has disappeared !
 
I just checked projets/form/80/251 and (for example) the Photographies group is empty, but has +/- buttons top right.

Can you give me the steps I need to take on your site to duplicate the problem?

-- hugh
 
Hi

No, I have not updated my main website, sorry. I have updated this website:
http://ohmi-nunavik.in2p3.fr/
http://ohmi-nunavik.in2p3.fr/administrator/index.php
You can log in with the exactly same id and pwd. To log in front:
http://ohmi-nunavik.in2p3.fr/accueil/connexion

Then, you can see this record for example, with the problem:
http://ohmi-nunavik.in2p3.fr/projets/form/4/437

Since the commit, I note another thing which can helped:
In my template detail, I have a rule to hide my groups if a field is empty, like this for example:
Code: 
if ((int) $group->id === 8 && $this->groups['PROJETS_LISTE- [projets_photos]']->elements['description']->value === '') :continue;endif;

This worked fine before the commit, but does not work now, like you can see here (empty groups are visible):
http://ohmi-nunavik.in2p3.fr/projets/details/4/437

Thank you in advance for attention !
 
You seem to be using a custom template. The default bootstrap template should show those +/- regardless of whether there is any groups present. Can you check your default_repeatgroup.php and make sure it has this code:

Code: 
        // Add the add/remove repeat group buttons
        if ($group->editable && ($group->canAddRepeat || $group->canDeleteRepeat)) : ?>
            <div class="fabrikGroupRepeater pull-right btn-group">
                <?php if ($group->canAddRepeat) :
                    echo $this->addRepeatGroupButton;
                endif;
                if ($group->canDeleteRepeat) :
                    echo $this->removeRepeatGroupButton;
                endif;?>
            </div>
        <?php
        endif;
        ?>

... after it renders the repeat-group-intro, so around line 28 in the out-of-box bootstrap template.

-- hugh
 
Yes, I have.

I have try to choose the Boostrap template, but no change.

In all case, I have the +/- icons, but only if the group has already a record.
 
Hmmm, check out the JS debug when you load a page. It looks like it's trying to load a bs3 spinner icon, and is hitting a bug which I thought I'd fixed a while back in the bootstrap3-layouts github repo.

-- hugh
 
Yes, I see the error about the spinner, but I can not explain that.

You have the FTP details about my Nunavik website in my "My sites" options.

I note that I load Protostar as default template, the error spinner disapear, but no change with the +/- icons.

I note also that in form view, in Nunavik website, if you mouse over my main meny, you can see some strange things. It is maybe related with the bug with boostrap.

You have not this problem in your test website after the commit ?
 
OK, the problem was that you had "cherry picked" files from github. You had the group.php from this commit:

https://github.com/Fabrik/fabrik/commit/a0466687fa5194c71f009a48bcc9bcd7f7a79c28

... but NOT the form.php ..

files.png

... group.php and list.php were from 11/30, everything else is from 11/2. And that change in group.php was to the repeatCount() method,. which relied on a change in form.php to interpret a return of 0, and change it to 1 so the form code creates the hidden group that the form needs to set up repeats that have no current members. This is why we say again and again, DO NOT CHERRY PICK FILES FROM GITHUB, always upload EVERYTHING. Yes, it's a pain, but unless you actually run git on your server so you can "git pull" to get ALL the changes, it is absolutely necessary. If you didn't know that before ... please bear it in mind! I spent 4 hours tracking this down, on top of the 13+ hours it took me to fix the actual bug on this thread.

BTW, while debugging this I removed two of your joins, the one-to-one joins for the user data. One of those joins won't work, as you weren't joining to a PK, you were joining from a user ID on the main form to a user ID in the joined table. In list joins, one "end" of the join has to be the Primary Key for one of the list, so either to parent.id from child.parent_id, or from parent.child_id to child.id.

So you'll have to figure out a different way to do that second one, the "user extras".

I'm running a full github update upload to your site at the moment.

-- hugh
 
OK many thanks ! I will test !

I will do the complete update now, promise !

But a question about my false joins : were they partly responsible for the problem, or not at all ?

Because they were maybe false, but they worked. So I do not know what is the better.
 
No, they weren't related to the problem, I was just grasping at straw at that point, and those joins were immediately preceeding the broken ones, so I just figured I'd try removing them.

The one that was to the non-PK may work, but it could cause weird issues. Basically we make the assumption that one of the keys involved is going to be a PK. Sometimes that isn't a problem, sometimes it is, depending on your overall join setup, and whether you are creating new rows in the child table via the parent's form.

The main problem is, when you save a form with joins in it, we have to know which is the "foreign" key, so we know whether we have to update it's value ... so, say you save a form with a one-to-one join from parent.child_id to child.id. First we write out the parent table ... but at that point (if it's a new row) we don't know what the child_id is ... so then we write out the child, now we know it's PK id, so we update the parent to write that value in to parent.child_id. Or, if it a one-to-one to parent.id from child.parent_id, when we write out the child row, we stick the parent's id into the child's parent_id field. However, if you aren't joining to the child's PK ... we can wind up writing a PK value into something which isn't an FK.

It's something I'm going to fix one day, but for now ... just be aware you could wind up overwriting the user_id in the child with the wrong value.

-- hugh
 
You must log in or register to reply here.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    Total: 106 (members: 3, guests: 103)
    Back
    Top