CSV Export anomoly

[Bauer]

I've mentioned this problem before - but just thought I'd take another crack at trying to give it some attention.

When CSV Export is used on a table containing joined data, on a list that is configured to not allow 'Front end options', it provides different results than when it is set to allow Front end options.

To detail the problem... When configured to not show 'Front end options', any columns from the joined table are always put at the end - in the last columns. This is contrary to any settings that might already exist in the 'Show in list' option set in the Menu (or the List configuration itself? I haven't tested that).

It works as expected so long as the 'Front end options' is set to Yes.

Here's how to duplicate the problem...

• Create or use a list that has a joined table and edit the list configuration.
• In the Publishing - CSV tab, set 'Front end options' to No.
• Add the list as a menu item and in the menu configuration, set 'Show in List' to include one of the columns from the joined table - but put it as the 2nd or 3rd column in the list (somewhere other than the last element in the 'Show in list' list).
• Now open the list via that menu option on the front end and Export as CSV.
• Note how the element from the joined table it always added as the last column despite the 'Show in list' order specified in the menu configuration?
• Now edit the list configuration and set 'Front end options' to Yes and repeat the export on the front end.
• Note that the element from the joined table is now shown in the correct column as configured in the menu?

THAT is how it should always work - regardless the 'Front end options' setting.

Why, in csvexport.php, there are 2 different routines being run - based on that configuration option, has always baffled me. Why not run the same routine (the one that works correctly, i.e. the one that is run when options are selectable) - if for no other reason than to assure consistency in the results (not to mention losing the need for duplicating code) - and simply not show the options if the list configuration is set to not show the Front end options???

 

[troester]

I didn't test but I assume with frontend options= no it's taking the backend settings, ie, what you have selected in "Which elements" and "Elements" (and if "visible" is selected it's taking the list's settings not menu settings)

 

[Bauer]

I didn't test but I assume with frontend options= no it's taking the backend settings, ie, what you have selected in "Which elements" and "Elements" (and if "visible" is selected it's taking the list's settings not menu settings)

No it's processing the correct elements either way - it's just how they are being processed that changes. (The past problem with the csvexport popup form script not respecting the list options as defaults has been fixed).

I looked into this extensively when I first noticed it. There is really 2 different processes being run - depending on the 'Front end options' setting. If Front end options is off it basically uses the code that is used for the csv export cron plugin, otherwise it's done right. I should have done a screen print of the backtrace log I had when when I was comparing between the 2 settings. (I probably still have it saved somewhere, but for all I can remember) One set of code uses the 'Show in list' settings - and the other just always 'figures out' the joined elements as the last process, That's what made me write that last paragraph. I'm sure there's something 'historical' or 'legacy support issues' going on here - where it might make sense to do it that way - but it sure seems like it would be best to always use the same php code to process from list view, regardless the setting.

 

[coullet]

List ordering can not mix group, you can not have
group1 element1
group2 element1
group1 element2

even if you can set this in backend, and it's very disappointing, list display:
group 1 element1
group1 element 2
group2 element 1

So if csv export taking list's settings, it's the same ordering.

 

[Bauer]

Yes you can - at least, for certain, if the join is a one-to-one relationship (I never tried with repeat groups). I do it all the time.

It's exactly as I explained it. If you set the ordering via the menu it orders the columns just like you have it set in "Show in list'.

I attached screen snips to prove my point. In the showInList.png you can see that the 4th item in the list is the element from the joined table (fb_jobcodes.job_description) - with the label shown in the header of both of the other (CSV export) snips as 'Job Description'.

As you see, when I don't have the list configuration set to 'Front end options' the 'Job Description' gets put in the last column (and for that matter, the other elements from the parent table aren't in the order specified in the 'Show in list' list either) .

That's why I introduced a change at github to make it easier to hide the individual options in the CSV options popup (via css or javascript) - so I could use the 'Front end options' but hide the options I don't want the user to change via css (except for the file type), and still make it work! (So I didn't start this thread just to complain. I already have the problem 'solved' as far as I'm concerned. I just want the Fabrik team (and other users) to be aware of this problem and hopefully get it fixed so that it doesn't cause more problems in the future.)

As far as the list configuration... I don't have any elements selected - but instead have 'Which elements' set to 'Visible'. That's because there are 7 different menu items using this same list - all with different filters - and most with different 'Show in list' elements.

The bottom line is - you would expect the CSV export layout to be exactly as it is in the HTML table/list that you are exporting from. And it works just fine if you create a menu item and use the "Show in list' option to set the columns you want included - and in the desired order.