Profields Table CSV Importer / Exporter

[VeiJari]

Hi @adrian I have Profields Table installed and can use the table. But when I try to install this module it says "Module 'TableCsvImportExport' dependency not fulfilled for: FieldtypeTable"

Any idea what could cause this?

 

[VeiJari]

2 hours ago, VeiJari said:

Hi @adrian I have Profields Table installed and can use the table. But when I try to install this module it says "Module 'TableCsvImportExport' dependency not fulfilled for: FieldtypeTable"

Any idea what could cause this?

 

Nvm, I was using some way old version of Profields Table. My bad ?

[VeiJari]

Hey @adrian, I'll start of by saying thanks for this module!

I have a slight problem with it though. I'm trying to filter results to the csv export by page references with their ids with the selector option:

 $modules->get('ProcessTableCsvExport'); // load module
    $options = array(
        'delimiter' => ',',
        'enclosure' => '"',
        'extension' => 'csv',
        'multipleValuesSeparator' => ' | ',
        'namesFirstRow' => true,
        'columns' => array('sessiontoken', 'logintime', 'pr_ticket.title', 'pr_location.title', 'pr_exhibition.title'), // columns to export can be index starting at 1, or column names
        //'selector' => 'pr_location=1025|1027', this doesn't find anything
        'selector' => 'logintime>= ' . $dateStart . ',loginTime<=' . $dateEnd . ',pr_ticket=' . $selectorTicketIds . ',pr_location=' . $selectorProvidersIds,
    );
 
    try {
        $page->exportTableCsv('log_usage_table', $options);
    } catch (exception $e) {
        $log->message('Virhe viennissä' . $e);
    }

If I use 'selector' => 'pr_location=1025', it works fine. So I suspect the OR selector doesn't work. Is there way to circumvent this or what should I do?

Thanks for the help in advance!

[adrian]

Hi @VeiJari - this isn't an issue with this module, but rather the selector system for the Table field. You can test that yourself with the Tracy console:

d($page->log_usage_table('pr_location=1025|1027'));

and you'll see the same problem. So, I think this is a question for Ryan. Here is a discussion about OR selectors in Table (https://processwire.com/talk/topic/24508-what-is-it-with-profields-table-and-or-selectors/), but it's not specific to Page Reference subfields so you'll need to bring that up specifically.

[VeiJari]

On 12/4/2020 at 7:38 PM, adrian said:

Hi @VeiJari - this isn't an issue with this module, but rather the selector system for the Table field. You can test that yourself with the Tracy console:

d($page->log_usage_table('pr_location=1025|1027'));

and you'll see the same problem. So, I think this is a question for Ryan. Here is a discussion about OR selectors in Table (https://processwire.com/talk/topic/24508-what-is-it-with-profields-table-and-or-selectors/), but it's not specific to Page Reference subfields so you'll need to bring that up specifically.

@adrian Hey, I see. I'll wait for the next version then. Follow up question: Is there a way to get the labels for the table fields to the exported CSV?

[adrian]

6 hours ago, VeiJari said:

@adrian Hey, I see. I'll wait for the next version then. Follow up question: Is there a way to get the labels for the table fields to the exported CSV?

Hi @VeiJari - are you referring to table subfield labels vs names? Names can already be added to the header row with the poorly-named "Column labels" option. Does this do what you need, or do you want an option for the actual Label instead of the Name?

 

[adrian]

18 hours ago, VeiJari said:

I'll wait for the next version then

Looks like the OR selector you were trying to use is now working in the latest version v20 that Ryan posted in the PF download thread. Note that this is actually "0.2.0" - I have never understood why he is inconsistent with those version numbers like that ?

There are also changes to the PW core around this issue, so you should probably update to the very latest dev commit, although I actually found that what you were trying to do worked before I did that update.

[VeiJari]

2 hours ago, adrian said:

Looks like the OR selector you were trying to use is now working in the latest version v20 that Ryan posted in the PF download thread. Note that this is actually "0.2.0" - I have never understood why he is inconsistent with those version numbers like that ?

There are also changes to the PW core around this issue, so you should probably update to the very latest dev commit, although I actually found that what you were trying to do worked before I did that update.

Hey how did you get it working exactly?

Thanks a bunch for your helpful advices!

[VeiJari]

14 hours ago, adrian said:

Hi @VeiJari - are you referring to table subfield labels vs names? Names can already be added to the header row with the poorly-named "Column labels" option. Does this do what you need, or do you want an option for the actual Label instead of the Name?

 

Hi, I would like to test this option, but I didn't found a way to implement it in the code, could you give me an simple example of this?

[adrian]

@VeiJari - you already have the option in your code above:

'namesFirstRow' => true,

That will add the field names to the first row. If you want labels instead, then that would be a new option I would need to add.

However, I did find a couple of bugs when exporting via the API which I have fixed, so please update to the latest version.

 

10 hours ago, VeiJari said:

Hey how did you get it working exactly?

I didn't do anything other than upgrade the Table module (and also the PW core) like I mentioned above.

[VeiJari]

13 hours ago, adrian said:

@VeiJari - you already have the option in your code above:

'namesFirstRow' => true,

That will add the field names to the first row. If you want labels instead, then that would be a new option I would need to add.

However, I did find a couple of bugs when exporting via the API which I have fixed, so please update to the latest version.

 

I didn't do anything other than upgrade the Table module (and also the PW core) like I mentioned above.

@adrian I changed the names of the field now, but It would be nice to implement an option to import the actual labels of the fields, this way we get more tidy up exports for our customers and end-users.

[adrian]

6 hours ago, VeiJari said:

@adrian I changed the names of the field now, but It would be nice to implement an option to import the actual labels of the fields, this way we get more tidy up exports for our customers and end-users.

I'll take a look at implementing this.

FYI - looks like I made a mistake about the OR selector - seems like it's still not working for page reference fields - you should ask Ryan about this on the Table field support board.

[adrian]

Actually, regarding the name vs label in the first (header) row, I am curious what you think about the subfield for page reference fields. This module supports exporting other subfields of the selected page reference (ie not just the title), so the header row currently shows things like pr_location.title or perhaps pr_location.body - these look fine for field "names", but I am not sure how these should be best formatted formatted for field "labels". Perhaps with the title subfield, it should be just left off, but with the body example, maybe: PR Location > Body

Any thoughts on what would look best?

[Robin S]

Hi @adrian,

My first time using this module - looks amazing, thanks!
(silly me, I've used the awesome import features before)

In my site I have a number of Table fields that are used for various purposes, but just one Table field that I want to allow users to export to CSV from. I couldn't see a way to show the export interface just on this one field. Any tips on how I could achieve this?

Or would you consider adding a hookable method that would determine if the import/export interface gets added to each Table field? (the relevant permissions would still apply)

Thanks.

Edit: very minor thing... in AdminThemeUikit there is an outline around the inputfield that has the export iframe and this looks a bit weird.

Not sure if there is a better way but I hid it with some custom CSS:

.Inputfield_tableExportIframe { outline:none; }

 

Edited October 26, 2021 by Robin S
Added note about outline

[adrian]

5 hours ago, Robin S said:

I couldn't see a way to show the export interface just on this one field.

I must admit I have wanted this at times also. I always assumed I would add a setting that determines whether the module is loaded at all for each table field. I never really considered controlling the access pr field via permissions. Do you actually need that level of control? If not, would you prefer to see a setting on each field's settings, or would you prefer a lists of allowed fields for import and export in this module's settings?

[Robin S]

6 hours ago, adrian said:

I never really considered controlling the access pr field via permissions. Do you actually need that level of control?

I was just trying to think if there was a way to achieve what I wanted without changes to the module. I saw that the module was adding the import/export features according to a permission so thought I might be able to grant that permission selectively at runtime. But I later realised that the permission is checked at the ready state rather than before the InputfieldTable render so even if my idea was possible I'd have to set the permission at every page load which would be a bit over the top.

6 hours ago, adrian said:

If not, would you prefer to see a setting on each field's settings, or would you prefer a lists of allowed fields for import and export in this module's settings?

I think that a couple of extra checkboxes on each Table field config would be ideal - something like "Allow CSV export" and "Allow CSV import", although it would still depend on the user having the relevant permissions so there should probably be a note about that. Existing users of the module would expect to have these options checked on all existing fields and I guess you could deal with that in the module upgrade() method.

Thanks!

[adrian]

2 hours ago, Robin S said:

Existing users of the module would expect to have these options checked on all existing fields and I guess you could deal with that in the module upgrade() method.

I wonder whether it would make more sense to reverse these so that it is enabled for all table fields, except the ones that have these checked?

Another useful extension to this might be to exclude (or include) for all users, or just superusers. I know sometimes I still want to be able to import / export for a particular field, but I don't want other users to be able to do it for that field. 

What do you think?

[Robin S]

11 minutes ago, adrian said:

I wonder whether it would make more sense to reverse these so that it is enabled for all table fields, except the ones that have these checked?

I'm not sure if I'm a typical user, but I would only want the import/export features on fields where I've specifically enabled them, and doing it that way would mean I have to remember to disable the import/export any time I add a new Table field.

If nobody has mentioned this need until now maybe it's quite rare and hookable methods would be enough for those who need it? In the short term I edited the module and added...

public function ___allowExport(InputfieldTable $inputfield) {
	return true;
}

...and near the top of TableCsvImportExport::buildTableExportForm()...

if(!$this->allowExport($event->object)) return;

...and in my ready_admin.php...

// Only show Table CSV export option on selected tables
$wire->addHookAfter('TableCsvImportExport::allowExport', function(HookEvent $event) {
	$inputfield = $event->arguments(0);
	$field = $inputfield->hasField;
	if(!$field || $field->name !== 'plant_votes') $event->return = false;
});

So one option would be to add something like this for both import and export options, and people who need it can use hooks to do tests on field, page, user, etc and return false whenever they don't want the import/export features to be available.

[adrian]

Hi @Robin S - just stumbled upon this randomly - are you still using the modified version of the module with the hook? Do you need any further refinements? Do you want to submit a PR to get those changes incorporated?

[Robin S]

On 3/12/2022 at 11:39 AM, adrian said:

are you still using the modified version of the module with the hook?

I am, but only on a single site and it's for a feature that's only activated once a year for a short period (an annual vote).

On 3/12/2022 at 11:39 AM, adrian said:

Do you need any further refinements? Do you want to submit a PR to get those changes incorporated?

I think I might have a use case for the module in some updates to a site that will be happening in the coming months. When that happens I'll spend some more time getting familiar with the module and can submit any ideas that come out of that. Thanks. 

[olafgleba]

Hi @adrian,

maybe i doing something wrong? Logged in as superuser, i installed the module, published the permissions and tried to export data of a existing table as a test. The interface looks a bit broken (s. below). For example i cannot add or delete Talbe rows selectors and nothing happens when i click on "Export As CSV" also. Do you have any idea, what i am missing? Cleared cache several times, logged out/in. Maybe it is a jquery core issue?

Thx in advance
Olaf

Processwire 3.0.221 dev, ProFields Table 0.2.4, Latest Table CSV Import/Export Module (2.0.16)

[adrian]

Hi @olafgleba - I just tested and everything looks fine here. I am using the latest PW dev and latest Profields Table, but I doubt your older versions are the issue. It looks like a JS error to me with the way the Table row selector and Columns / Order to Export fields are broken. What shows up in your browser dev console?

[olafgleba]

Nothing really helpful, i am afraid. A forgotten console.log from jquery ("JQMIGRATE: Migrate is installed, version 1.4.1"), but no related warnings or errors. It not a browser issue also,- tested in Firefox, Safari, Chrome.

I installed the module on the live server. Next i will install the module on my local project instance and upgrade PW to the latest dev to test it there.

Thx for your answer, regards,
Olaf

[olafgleba]

Hi Adrian, i upgraded PW to latest dev in my local environment. No luck, same slightly broken view and behaviour. No suspicious logs (browser console, tracy). Hm, whats left to do is to renew my Profield package license to get the latest Profield Table version. Although i also doubt this causes the issue.

[adrian]

Hi @olafgleba - I really doubt it's related to the table field itself. 

This is what it looks like for me. If it's not a JS issue, is there any chance you have a module that is somehow interfering with those two fields? Can you try on a fresh PW install with no additional modules and just the table field to test?