Jump to content

Profields Table CSV Importer / Exporter


adrian

Recommended Posts

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 😄

  • Like 1
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

@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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 10 months later...

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.

2021-10-26_210314.png.0c9883a3883a7b181198b425e4d809f3.png

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

.Inputfield_tableExportIframe { outline:none; }

 

Edited by Robin S
Added note about outline
  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By monollonom
      PageMjmlToHtml
      Github: https://github.com/romaincazier/PageMjmlToHtml
      Modules directory: https://processwire.com/modules/page-mjml-to-html/
      A module allowing you to write your Processwire template using MJML and get a converted HTML output using MJML API.
      This is considered to be in alpha and as such needs some testing before being used in production!

      About
      Created by Mailjet, MJML is a markup language making it a breeze to create newsletters displayed consistently across all email clients.
      Write your template using MJML combined with Processwire’s API and this module will automatically convert your code into a working newsletter thanks to their free-to-use Rest API.
      Prerequisite
      For this module to work you will need to get an API key and paste it in the module’s configuration.
      Usage
      Once your credentials are validated, select the template(s) in which you’re using the MJML syntax, save and go visualize your page(s) to see if everything’s good. You will either get error/warning messages or your email properly formatted and ready-to-go.
      From there you can copy/paste the raw generated code in an external mailing service or distribute your newsletter using ProMailer.
      Features
      The MJML output is cached to avoid repetitive API calls Not cached if there are errors/warnings Cleared if the page is saved Cleared if the template file has been modified A simple (dumb?) code viewer highlights lines with errors/warnings A button is added to quickly copy the raw code of the generated newsletter Not added if the page is rendered outside of a PageView Only visible to users with the page’s edit permission A shortcut is also added under “View” in the edit page to open the raw code in a new tab Multi-languages support
      Notes
      The code viewer is only shown to superusers. If there’s an error the page will display:
      Only its title for guests Its title and a message inviting to contact the administrator for editors If you are using the markup regions output strategy, it might be best to not append files to preserve your MJML markup before calling the MJML API. This option is available in the module’s settings.
    • By Marco Ro
      Hi guys!
      I'm a bit anxious because this is the first module I present! (beta modulo) But I will finally be able to share something with the community too! :)
      This is a BETA version of the PayPal payment system called: PayPal Commerce Platform.
      It is an advanced system (Business Pro account is needed) that brings various benefits in terms of fees and above all integrates direct payment with credit/debit cards. 
      The module integrates with Padloper 0.0.2, which is the current installation I'm using.
      This system integrates the classic PayPal buy button, the alternative or local payment method and the new payment system: credit/debit cards that doesn't go through the PayPal account. It is a Stripe-style payment, it connects directly with the bank and integrates 3D security validation.
      I say that it is a BETA because this module currently only works with Sandbox account, to put it live you need to change API url manually (manually for the moment).
      Because this module is not ready for live:
      I would like to have your opinion on how I built the module (is the first one I do). I don't want to share something that is not fish but I need a comparison with someone more experienced than me, for be sure that this is the best way to code the module.
      If you want to try this I created a git, you will find all the instructions for installation and correct operation. (Git has a MIT licensed)
      https://github.com/MarcooRo/processwire-PayPal-Commerce-Platform I hope I did something that you guys can like :)
    • By monollonom
      (once again I was surprised to see a work of mine pop up in the newsletter, this time without even listing the module on PW modules website 😅. Thx @teppo !)
      FieldtypeQRCode
      Github: https://github.com/romaincazier/FieldtypeQRCode
      Modules directory: https://processwire.com/modules/fieldtype-qrcode/
      A simple fieldtype generating a QR Code from the public URL of the page, and more.
      Using the PHP library QR Code Generator by Kazuhiko Arase.

      Options
      In the field’s Details tab you can change between .gif or .svg formats. If you select .svg you will have the option to directly output the markup instead of a base64 image. SVG is the default.
      You can also change what is used to generate the QR code and even have several sources. The accepted sources (separated by a comma) are: httpUrl, editUrl, or the name of any text/URL/file/image field.
      If LanguageSupport is installed the compatible sources (httpUrl, text field, ...) will return as many QR codes as there are languages. Note however that when outputting on the front-end, only the languages visible to the user will be generated.
      Formatting
      Unformatted value
      When using $page->getUnformatted("qrcode_field") it returns an array with the following structure:
      [ [ "label" => string, // label used in the admin "qr" => string, // the qrcode image "source" => string, // the source, as defined in the configuration "text" => string // and the text used to generate the qrcode ], ... ] Formatted value
      The formatted value is an <img>/<svg> (or several right next to each other). There is no other markup.
      Should you need the same markup as in the admin you could use:
      $field = $fields->get("qrcode_field"); $field->type->markupValue($page, $field, $page->getUnformatted("qrcode_field")); But it’s a bit cumbersome, plus you need to import the FieldtypeQRCode's css/js. Best is to make your own markup using the unformatted value.
      Static QR code generator
      You can call FieldtypeQRCode::generateQRCode to generate any QR code you want. Its arguments are:
      string $text bool $svg Generate the QR code as svg instead of gif ? (default=true) bool $markup If svg, output its markup instead of a base64 ? (default=false) Hooks
      Please have a look at the source code for more details about the hookable functions.
      Examples
      $wire->addHookAfter("FieldtypeQRCode::getQRText", function($event) { $page = $event->arguments("page"); $event->return = $page->title; // or could be: $event->return = "Your custom text"; }) $wire->addHookAfter("FieldtypeQRCode::generateQRCodes", function($event) { $qrcodes = $event->return; // keep everything except the QR codes generated from editUrl foreach($qrcodes as $key => &$qrcode) { if($qrcode["source"] === "editUrl") { unset($qrcodes[$key]); } } unset($qrcode); $event->return = $qrcodes; })
    • By Sebi
      AppApiFile adds the /file endpoint to the AppApi routes definition. Makes it possible to query files via the api. 
      This module relies on the base module AppApi, which must be installed before AppApiFile can do its work.
      Features
      You can access all files that are uploaded at any ProcessWire page. Call api/file/route/in/pagetree?file=test.jpg to access a page via its route in the page tree. Alternatively you can call api/file/4242?file=test.jpg (e.g.,) to access a page by its id. The module will make sure that the page is accessible by the active user.
      The GET-param "file" defines the basename of the file which you want to get.
      The following GET-params (optional) can be used to manipulate an image:
      width height maxwidth maxheight cropX cropY Use GET-Param format=base64 to receive the file in base64 format.
    • By MarkE
      This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API.
      The API consists of a number of predefined functions, some of which include...
      render() for rendering the measurement object, valueAs() for converting the value to another unit value, convertTo() for converting the whole measurement object to different units, and add() and subtract() for for modifying the stored value by the value (converted as required) in another measurement. In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m.

      A simple length field using Fieldtype Measurement and Inputfield Measurement.
      Combination units (e.g. feet and inches) are also supported.
      Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly.
      See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.
×
×
  • Create New...