Bad luck with repeating group changing element's names

joit

joit

Active Member
I played around with the repeating groups feature and decided not to use it. But all my element's names in this group still have the "_90_repeat" in it.
This is bad for my other language. I copied the elements in the other language's group and the "_90_repeat" is gone. This is bad because the elements don't have the same name anymore. So I decided to do the same 'trick' again (saving as repeat group and then savin as non repeat group) but now they have "_97_repeat" in them.
What should I do?

Thanks Hannes
 
Hmmm.

At the moment, your best bet is probably to delete those groups and elements, and recreate them. You've just hit a rather nasty bug I thought we'd fixed a year or so ago, but apparently not.

The problem is that when you set 'repeat' on a group, you are actually creating a new database table, with a one-to-many relationship, which we create that group's element in (or move them in to). So a repeated group is actually a joined table. Which is why the full element names change, as our elements always have the tablename___elementname format, so the tablename changes to the automatically created table (the 90 and 97 you are seeing are the numeric group ID's of your groups, which we use as part of the automatic naming of that table).

When you turn repeat off, our code *should* undo all that, and move the elements back into the main table, etc. And that's the code I thought I'd fixed a while back. But looking at the code, I see where the fix I put in has been commented out by @rob , as apparently it was breaking something else.

It's going to take me a while to fix it.

-- hugh
 
I have around 80 elements in this group and a translation of this group. Recreating them would be a real pain.
Is there no way to rename the full elements names?
 
I assume this "playing around" is related this (I'd posted in your other thread, deleted it now)

Trying to log into your frontend I get
Too many tables; MySQL can only use 61 tables in a join SQL=SELECT SQL_CALC....
I think instead of separate tables with (I assume) one-to-one-relations like
LEFT JOIN `cm3` AS `cm3_24` ON `cm3_24`.`id` = `cargo_90_repeat`.`WohnenSchlafen12`
LEFT JOIN `cm3` AS `cm3_25` ON `cm3_25`.`id` = `cargo_90_repeat`.`WohnenSchlafen13`
LEFT JOIN `cm3` AS `cm3_26` ON `cm3_26`.`cm3` = `cargo`.`Kueche3`
LEFT JOIN `cm3` AS `cm3_27` ON `cm3_27`.`cm3` = `cargo`.`Kueche4`
LEFT JOIN `cm3` AS `cm3_28` ON `cm3_28`.`cm3` = `cargo`.`Kueche5`

you should use repeated groups/one-to-many-relations (one table Wohnen/Schlafen, one table Kueche etc).


Do you have a backup?
This all is on your test site?
 
The test site is this one
150401/index.php/

It's interesting, I can login in the frontend and backend without any problems.
I had a backup and I'm doing a backup right now.

This cm3 is a database join dropdown that I use for many elements.
 
uuh so true. I can't even view the data in the backend.
Is that because there are too many database joins in the table?
 
I have 2 questions about repoeating groups.
1. Do I need a repeat group for every row of elements? I set this up for 2 rows here (schrank1 and schrank2)
150401/index.php/ladung-eingeben
This way I'd need many groups...
2. Since every element gets a new name (XX_repeat), how can I set up translation?
 
I don't understand your schrank1/2 in your example.

In some other form you had (if I remember correctly) something like
group Schlafzimmer1, elements Bett, Schrank...
group Schlafzimmer2, elements Bett, Schrank...
...
group Schlafzimmer10, elements Bett, Schrank...

here you could create one group Schlafzimmer (elements Bett, Schrank) set to repeat, then your form will first show one "set" of fields (Bett, Schrank...), after clicking the + it will add one more set of fields.

I think I see your problem with joins. You have a lot of elements (all kind of things to move), every element as a dbjoin to your lookup table (holding the selectable number and I assume the size per type).

This will create a join for every element and MySQL can't handle such a lot.
You could use normal fields, maybe with a mask (so the user can just type an integer) and/or a validation and do the lookup only during your calculation (BTW:you really could move 1000 Fl?gel;)?)
 
"after clicking the + it will add one more set of fields."
Well, I want to give the elements to the user instead of having the user click + and add elements.
Is this possible with repeat groups?

"This will create a join for every element and MySQL can't handle such a lot."
OK, if this causes the problem "Too many tables; MySQL can only use 61 tables in a join" I can change it. I had that database join from another element and was just reusing it here!

So there just remains the problem with the renamed element names that can't be used for translation right now.
 
Have you created any new elements in the groups since you first turned repeat on for them?

The problem is that the elements now reside on another table. There's no built in way of moving them back to the main table, we'd have to do it by directly changing the metadata tables (#_fabrik_groups, #_fabrik_joins) and by manually removing the id and parent_id elements which got created as the PK and FK on the joined tables. That's what the "fix" I thought I'd applied to this did, but I can see from looking deeper at the code why @rob commented it out ... the way I had written it, it would have been breaking legitimate non-repeated joined groups when saving them.

The good news is that we don't delete the original fields on the main table, when you turn repeat on ... we leave those there when we re-create the elements in the joined table. So as long as you haven't added any elements to the groups since setting them to repeat, then all the database fields are still there, and it's just a case of manually tweaking the metadata to tell the elements / groups that they are no longer on separate tables.

The bad news is that any data you may have added for those groups since starting them as repeated groups will get lost, as it's on different tables. It might be possible to manually copy it over, but only for one of the repeat rows (that's kind of the whole point of using those one-to-many joined tables, so you can have multiple rows of data for the group, which can't be done when the group is on the main table).

-- hugh
 
yeah, I probably added some elements since turning on the first repeat. But since I have to change the database join elements there is still some work to do.
Can you please give me a hint how to do this?
"manually tweaking the metadata to tell the elements / groups that they are no longer on separate tables"
Then I'll decide if I tweak or delete everything and start over.
 
First, back your database up!!

Then you need to make three changes for each affected group. First, establish the group_id of the group you are working on, which is the ID in the left most column of the Groups back end tab, and will be the number in the yourtable_X_repeat prefix those elements now have. Then fire up your database client of choice, like phpMyAdmin.

1) Edit your #_fabrik_elements table, and remove the 'id' and 'parent_id' elements from that group, eg. the ones that have the group_id you are looking for. By 'remove', I mean delete those two rows from the #_fabrik_elements table. Make CERTAIN you are not removing the 'id' element from the main group!

2) Edit your #_fabrik_groups table, find the row with the 'id' of the group, and set is_join to 0.

3) Edit your #_fabrik_joins table, find the row with the corresponding group_id, and delete it.

I just tested those steps, and they seem to work OK for me.

The only remaining issue is any elements which were created after you turned repeat on, which will not have a field on the main table. I think you can fix this by going to the Forms backend tab, and doing a "Update database" for the affected form(s).

Assuming all this works, you will then be able to manually deleted the extra tables you no longer need, which will be named yourtable_X_repeat. Well, you know what I mean.

-- hugh
 
"At the moment, your best bet is probably to delete those groups and elements, and recreate them."
Hey, wouldn't it be enough to just create a new group and copy the Elements into the new group?
This way they get new names.
 
You can try that, although you may have issues with those names already existing in the main table. Just make sure you backup before trying anything.


Sent from my HTC One using Tapatalk
 
Half way there I wanted to make a test. Saving the form works as expected but when I view the list I run into a problem with this
http://fabrikar.com/forums/index.php?threads/bootstrap-tabs-doesnt-hide-group-in-details.42186/
The reuslt is that no elements are shown in the hidden/shown group and I have no idea why.
This is my js for hiding the tabs

var form = Fabrik.getBlock('details_19');
var formid = form.block;

if (form.formElements.get('cargo___cargo_details').getValue()[0] === '8') {

jQuery('#' + formid + ' ul.nav-tabs li:nth-child(2)').hide();
jQuery('#' + formid + ' ul.nav-tabs li:nth-child(3)').show();
jQuery('#' + formid + ' ul.nav-tabs li:nth-child(4)').show();
jQuery('#' + formid + ' ul.nav-tabs li:nth-child(5)').show();
} else {

jQuery('#' + formid + ' ul.nav-tabs li:nth-child(2)').show();
jQuery('#' + formid + ' ul.nav-tabs li:nth-child(3)').hide();
jQuery('#' + formid + ' ul.nav-tabs li:nth-child(4)').hide();
jQuery('#' + formid + ' ul.nav-tabs li:nth-child(5)').hide();
}


any idea?
 
I think it's fixed.
It seems to be my hoster that caches js files. No idea how to prevent that.
I took caching out of the .htaccess file, deleted J!'s cache, deleted browser cache, reloaded the site with ctrl f5 and tried incognito mode - the site loads always an on js file...
 
I run in to that problem on some of my client's sites. Some hosts seem to run a server side cache for JS and CSS assets. Never found a workaround. Pain in the backside when working on Javascript, I have to just sit and wait for the server side cache to update every time I make a change.

-- hugh
 
It's not fixed :-(
I have to hide the groups in the form view and the tabs in the details view and that seems to interfere. When it's set up 'correctly', I don't see any elements in the details view.
I talked to my hoster and they told me that they don't cache anything. It seems that the interference appeared to be the caching to me.
 
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

    No members online now.
    Total: 96 (members: 0, guests: 96)
    Back
    Top