-
Joomla 5.1
For running J!5.1 you must https://fabrikar.com/forums/index.php?wiki/update-from-github/ or include the new file manually https://fabrikar.com/forums/index.php?threads/joomla-5-1-and-fabrik-cannot-find-files-error.54473/post-285151 See also Announcements
-
Subscription and download (Fabrik 4.1 for J!4.2+ and J!5.1) are working now
See Announcement
We are still working on the Joomla update.
all uploaded files info is gone after changing group settings
- Thread starter fanta00
- Start date
cheesegrits
Support Gopher
Hmmm. If you turn repeat back off, is the data still there?
-- hugh
-- hugh
No, it's all gone even when I turn the repeat back off, all the uploaded files disappeared from all the lists (and I have a lot of them!), I don't want to use backup as I made some other changes since last one, is there any way to retrieve those links?
Changing simple settings always screw the fabrik, this is really annoying!!!
Changing simple settings always screw the fabrik, this is really annoying!!!
cheesegrits
Support Gopher
My apologies.
OK, I've found what I think should get your original, un-repeated data back. What you need to do is:
Make sure the group is set to repeat, with your existing setup.
Update to the latest github, by grabbing the zipball from https://github.com/Fabrik/fabrik/zipball/master, unzipping it and uploading it to your server via ftp.
Once the upload is complete, turn repeat off again on your group.
-- hugh
OK, I've found what I think should get your original, un-repeated data back. What you need to do is:
Make sure the group is set to repeat, with your existing setup.
Update to the latest github, by grabbing the zipball from https://github.com/Fabrik/fabrik/zipball/master, unzipping it and uploading it to your server via ftp.
Once the upload is complete, turn repeat off again on your group.
-- hugh
cheesegrits
Support Gopher
PS - I'd suggest doing a full database backup before doing anything else ... but make sure you don't overwrite any previous backups, just in case we need to grab some old table data.
-- hugh
-- hugh
cheesegrits
Support Gopher
Ah yes, I forgot to explain that bit.
When you change a group to repeatable, Fabrik is actually creating a new "one to many" joined table in MySQL, and starts storing the group data in that table, rather than in the main table for that form.
At the moment, for a variety of reasons, we don't move any pre-existing data from the main table to the newly created joined table. It's something we've looked at doing, but it's not really practical to do within the constraints of the J! backend processing. It'd be OK for situations where there is very little data, but for tables with a lot of rows, it would cause lengthy delays in the page loading after hitting "Save", and could cause PHP script processing timeouts.
We are looking at an "asyncronous" method for kicking off housekeeping tasks like this, so they don't have to happen during the page load processing. But that's not going to happen any time real soon.
So for the moment, it's up to you to move any data you have accumulated for that group, into the new joined group. Which itself isn't that easy, as you can't do it with a simple MySQL query.
We should really put a warning on that feature, to explain that existing data is not going to be moved.
On the bright side, we don't delete the original data when creating the repeat table, which is why it's still there when you change it back to non-repeat. Or at least, after the code fix from yesterday, which fixed a bug where we weren't actually turning repeat off for that group, even tho it looked like we were!
-- hugh
When you change a group to repeatable, Fabrik is actually creating a new "one to many" joined table in MySQL, and starts storing the group data in that table, rather than in the main table for that form.
At the moment, for a variety of reasons, we don't move any pre-existing data from the main table to the newly created joined table. It's something we've looked at doing, but it's not really practical to do within the constraints of the J! backend processing. It'd be OK for situations where there is very little data, but for tables with a lot of rows, it would cause lengthy delays in the page loading after hitting "Save", and could cause PHP script processing timeouts.
We are looking at an "asyncronous" method for kicking off housekeeping tasks like this, so they don't have to happen during the page load processing. But that's not going to happen any time real soon.
So for the moment, it's up to you to move any data you have accumulated for that group, into the new joined group. Which itself isn't that easy, as you can't do it with a simple MySQL query.
We should really put a warning on that feature, to explain that existing data is not going to be moved.
On the bright side, we don't delete the original data when creating the repeat table, which is why it's still there when you change it back to non-repeat. Or at least, after the code fix from yesterday, which fixed a bug where we weren't actually turning repeat off for that group, even tho it looked like we were!
-- hugh