Giter Club home page Giter Club logo

typo3-formlog's Introduction

Form log CI

Form log for TYPO3

Installation

This extension is installable from various sources:

  1. Via Composer:

     composer require pagemachine/typo3-formlog
    
  2. From the TYPO3 Extension Repository

Purpose

One feature absent in the TYPO3 form extension is logging of form data. If you have ever used the now defunct Formhandler extension you know how valuable this can be. You can easily check if form submissions are working as they should, see internal values are generated correctly and perform some basic analysis thanks to exports to CSV or similar.

See our blog post about the TYPO3 form log extension.

Start logging

Logging can be enabled for any form by adding the LogFormData finisher to its form definition:

finishers:
  - ...

  - identifier: LogFormData

  - identifier: Redirect

The LogFormData finisher should be the last finisher or right before the Redirect finisher if used. Logging after a redirect is not possible.

Additional variables stored in the FinisherVariableProvider can also be logged by using the finisherVariables option:

  - identifier: LogFormData
    options:
      finisherVariables:
        MyCustomFinisher:
          - myCustomVariable

The keys within finisherVariables are identifiers of finishers used in a form, the value of each entry is a list of finisher variable names. In the example here the finisher variable myCustomVariable provided by the finisher MyCustomFinisher will be logged.

Form log module

By default the form log module displays a few basic fields like page, form identifier, language and date of form submission as columns.

Additional columns can be added with the list.columns setting in ext_typoscript_setup.txt:

module.tx_formlog {
  settings {
    list {
      columns {
        100 {
          property = data.email
          label = LLL:EXT:my_site/Resources/Private/Language/Extensions/Form/locallang.xlf:element.email.properties.label
        }
      }
    }
  }
}

Within list.columns an arbitrary list of columns can be added where the property option refers to a property path in the FormLogEntry domain model. Simply speaking data.* provides access to form data by a form element identifier, e.g. data.email for the value of the form element email. The label option is used to retrieve a translatable label. Usually one can simply use the same label that is used for the field within the form itself.

Similarly finisherVariables.* does the same for additional finisher variables by utilizing the finisher identifier and variable name:

module.tx_formlog {
  settings {
    list {
      columns {
        200 {
          property = finisherVariables.MyCustomFinisher.myCustomVariable
          label = LLL:EXT:my_site/Resources/Private/Language/Extensions/Formlog/locallang.xlf:formlog.entry.finisherVariables.MyCustomFinisher.myCustomVariable
        }
      }
    }
  }
}

Here myCustomVariable of MyCustomFinisher is added as column to the list.

Form log export

Out of the box form log entries can be exported to CSV and Excel (XLSX). Basic fields of form log entries are exported by default, additional columns can be added with the export.columns setting in ext_typoscript_setup.txt which is configured exactly the same as the list.columns setting:

module.tx_formlog {
  settings {
    export {
      columns {
        100 {
          property = data.firstname
          label = LLL:EXT:my_site/Resources/Private/Language/Extensions/Form/locallang.xlf:element.firstname.properties.label
        }
        101 {
          property = data.lastname
          label = LLL:EXT:my_site/Resources/Private/Language/Extensions/Form/locallang.xlf:element.lastname.properties.label
        }
        102 {
          property = data.email
          label = LLL:EXT:my_site/Resources/Private/Language/Extensions/Form/locallang.xlf:element.email.properties.label
        }
        200 {
          property = finisherVariables.MyCustomFinisher.myCustomVariable
          label = LLL:EXT:my_site/Resources/Private/Language/Extensions/Formlog/locallang.xlf:formlog.entry.finisherVariables.MyCustomFinisher.myCustomVariable
        }
      }
    }
  }
}

Log entry cleanup

The Table garbage collection Scheduler task can be set up to automatically delete old form log entries. Select tx_formlog_entries as Table to clean up and a suitable value for Delete entries older than given number of days, 180 by default.

Testing

All tests can be executed with the shipped Docker Compose definition:

docker compose run --rm app composer build

Thanks

Development of this package was proudly sponsored by TÜV Hessen.

typo3-formlog's People

Contributors

lsascha avatar mbrodala avatar nemo64 avatar ohader avatar renovate-bot avatar renovate[bot] avatar sabbelasichon avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

typo3-formlog's Issues

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

composer
composer.json
  • league/csv ^9.1
  • nimmneun/onesheet ^1.0
  • psr/http-factory ^1.0
  • psr/http-message ^1.0 || ^2.0
  • psr/log ^1.0 || ^2.0 || ^3.0
  • typo3/cms-backend ^11.5.4 || ^12.4
  • typo3/cms-core ^11.5.4 || ^12.4
  • typo3/cms-extbase ^11.5.4 || ^12.4
  • typo3/cms-fluid ^11.5.4 || ^12.4
  • typo3/cms-form ^11.5.4 || ^12.4
  • typo3/cms-frontend ^11.5.4 || ^12.4
  • typo3fluid/fluid ^2.3
  • ergebnis/composer-normalize ^2.3
  • friendsofphp/php-cs-fixer ^3.41
  • helmich/typo3-typoscript-lint ^3.0
  • jangregor/phpstan-prophecy ^1.0.0
  • michielroos/typo3scan ^1.7
  • php-parallel-lint/php-console-highlighter ^1.0.0
  • php-parallel-lint/php-parallel-lint ^1.2
  • phpspec/prophecy-phpunit ^2.0
  • phpstan/phpstan ^1.0.0
  • phpunit/phpunit ^10.0
  • rector/rector ^1.0.0
  • saschaegerer/phpstan-typo3 ^1.0.0
  • sclable/xml-lint ^0.7.0
  • ssch/typo3-rector ^2.2
  • typo3/cms-scheduler ^11.5.4 || ^12.4
  • typo3/coding-standards ^0.7.1
  • typo3/testing-framework ^7.0 || ^8.0
docker-compose
docker-compose.yml
github-actions
.github/workflows/ci.yml
  • actions/checkout v4
  • actions/checkout v4
npm
package.json
  • bower ^1.7.9
  • grunt ^1.0.1
  • grunt-bower-task ^0.6.0
  • grunt-contrib-clean ^2.0.0
  • grunt-contrib-less ^3.0.0
  • grunt-contrib-uglify ^5.0.0
  • grunt-contrib-watch ^1.0.0
  • grunt-text-replace ^0.4.0
  • grunt-umd ^3.0.0
  • load-grunt-config ^4.0.0

  • Check this box to trigger a request for Renovate to run again on this repository

fields like "date" or "date_picker" would not be displayed in the BE-list!?

I have a date-field in a form.
I put this field (beside others) into the list and export view:

module.tx_formlog {
    list.columns {
      100 {
         property = data.name
         label = Name
      }
      105 {
         property = data.telephone
         label = Telefon-Nr.
      }
      110 {
         property = data.email
         label = E-Mail
      }
      115 {
         property = **data.datum**
         label = Datum
      }
    }

Field nr. 115 will always be empty in the list and also in the detail-view!?

Define export fields based on form

hi
I can not find in docs and from the code looks like its not possible to define export fields based on form.
Do you have some nice trick for that?

Feature request: specify log data

Many thanks for this smart and useful extension.
it would be a helpful feature if the identifiers of the form fields could be specified, which are then stored in the column tx_formlog_entries.data.

I can imagine it like this:

identifier: LogFormData
options:
  logDataIdentifiers:
    - firstname
    - lastname
    - email

I would be very happy if the feature would be realized. If necessary I can offer support for the implementation.

Make it easier to export all form data

As an editor I want to be able to export all form fields without having to configure them via typoscript because I do not have the rights in my environment to add typoscript configuration.

Background
Currently only the basic fields of submitted forms will be exported. More fields can be configured to be exported as described in https://docs.typo3.org/typo3cms/extensions/formlog/ ("Form log export").

Since editors may add their own forms using the visual form editor and they can have access to the formlog module, it would be great if they could export their form data without having to add typoscript configuration.

It would be great if there would be an option to automatically create a column for each property of the "data" object in the CSV and XLSX export file.

exception after updating

After updating from ver. 1 to 2 with exact the same settings I get an exception after submitting the form.

Doctrine\DBAL\Exception\NotNullConstraintViolationException

An exception occurred while executing 'INSERT INTO tx_formlog_entries

Column 'pid' cannot be null

type: FileUpload is not saved at all

Thanks a lot for this very cool extension. Very clever implementation.
But type: FileUpload is not saved in the JSON. Or am I doing something wrong?

Problem with export on filtered data

Hallo,

I have a problem with the export function on filtered log entries.
We have a site with multiple forms and we want to export the data
for each form separately. But when I try to export the filtered data,
the export file includes the data from all forms. This happens
with the CSV and Excel export.
I don't know if this is a bug or a missing feature.

If it is a bug we have following environment:
-TYPO3 10.4.8 in composer mode
-formlog 1.3.1

Display of logging entries not possible

When trying to check the logged entries, I get the following error:

Oops, an error occurred! The type of property Pagemachine\Formlog\Domain\Model\FormLogEntry::page could not be identified, therefore the desired value (NULL) cannot be mapped onto it. The type of a class property is usually defined via php doc blocks. Make sure the property has a valid @var tag set which defines the type.

Am using T3 v10.23. In the table tx_formlog_entries the data seems to be stored correctly.
Any hints?

Feature request: add upload file path to log data

the uploaded files get logged with file name, it would be awesome when also the path get logged.

on upload the files get saved in the selected storage inside a generated folder like "form_7c4bf264b5c1236827517ad756d0c71988d24296"

so it would be helpfull if i could get the storage path from the formlog entry

thanks

Add finisher to form editor

Currently the finisher can only be added manually in form editor YAML files. The logger finisher should be available in the form editor for visual selection.

Check conformity to GDPR

The GDPR becomes active with May 25, 2018. We need to check what changes are required to conform to that regulation.

TYPO3 v12 compatibilty bug: the sys_language table is no more used

In TYPO3 v12, the sys_language table is no more present.
So, when asking for the detail of a log entry, this error happens.
Field language of table tx_formlog_entries reference to foreign table sys_language, but this table is not defined in TCA

See these changelogs:

Configuration error

I have a site with a couple of existing and working forms, one of which I would like to log. Upon installing the form log extension, the existing forms don't render properly anymore and following error prompts on screen: TYPO3.CMS.Form.mixins.formElementMixins.BaseCollectionEditorsMixin does not exist within the configuration.
At this stage no form has been yet configured with the form log finisher. The extension has just been installed.
Configuring the finisher on any of the forms does not clear the error.
I'm using CMS 8.7.10.

make filters configurable

as an integrator i want to declare each column in Form log module (module.tx_formlog.settings.list.columns) as filter.

Currently its only possible to filter by Page-Title and Date.
Moreover Page-Title filter can grap wrong entries if some Page with same Title exists.
This makes cleaning of CSV export impossible. For Example we could disable some CSV columns by TypoScript condition by using the filter(PID of the Form):

[globalVar = GPmerged:tx_formlog_web_formloglist|filters|pid|value| = {$global.myForm.pageuid}]
  module.tx_formlog.settings.list.columns.export.columns >
  // declare clean list of fields to export
[global] 

and the setting could look like this:

module.tx_formlog.settings {
   list {
     columns {
       1000 {
         property = pid
         label = PageUid
         filterable = 1
       }
     }
   }

The finisher preset identified by "LogFormData" could not be found. For TYPO3 V11.

I am getting this error on TYPO3 11.

Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1328709784: The finisher preset identified by "LogFormData" could not be found, or the implementationClassName was not specified. | TYPO3\CMS\Form\Domain\Model\Exception\FinisherPresetNotFoundException thrown in file /html/typo3/typo3_src-11.5.3/typo3/sysext/form/Classes/Domain/Model/FormDefinition.php in line 552.

Also the Log Form Data finisher selector in the BE form is broken.

Restricted pages not visible in backend module anymore

If a page of a form is getting restricted with e.g. hidden or start/endtime, the page title won't be shown anymore in the backend module. Our customers uses a lot of forms, especially for stuff like quizzes and those pages are e.g. time restricted.

As a quick fix I did this

diff --git a/Classes/Domain/Model/FormLogEntry.php b/Classes/Domain/Model/FormLogEntry.php
--- a/Classes/Domain/Model/FormLogEntry.php	(date 1622447981000)
+++ b/Classes/Domain/Model/FormLogEntry.php	(date 1622447981000)
@@ -15,16 +15,16 @@
 class FormLogEntry extends AbstractEntity
 {
     /**
-     * @var \Pagemachine\Formlog\Domain\Model\FormLogEntry\Page
+     * @var int
      */
     protected $page;
 
     /**
-     * @return \Pagemachine\Formlog\Domain\Model\FormLogEntry\Page
+     * @return array
      */
     public function getPage()
     {
-        return $this->page;
+        return \TYPO3\CMS\Backend\Utility\BackendUtility::getRecord('pages', $this->page, 'title,uid', '', false);
     }
 
     /**

but I propose to remove the extbase models in total and use raw queries directly which would also improve performance I guess

TYPO3 V11: Export Button -> No effect/function

Hi,
I don't know if I maybe missed some configuration work, but the "export"-Button has simply no function when clicked. (TYPO3 11.5.5., formlog 2.0.0).
Formlog entries get listed correctly, even with my extra-configuration for the list-view...but I can't export anything (even in basic mode before any changes to the list-settings). Clicking the export-button has just no effect.... (Tested in Chrome, FF and Safari, no js-errors in the console)

tx_formlog {
    settings { 
     list {
#some list config -> correctly displayed in "Form log entries" table-view
     }
  }
}

Thanks for any hints.
Michael

Log finisher options

Currently the only way to log additional data from arbitrary finishers is by having them or other finishers store variables in the FinisherVariableProvider.

It would be way more convenient if one could instead specify a list of finisher options to log.

Update to Typo3 8.7.25 failed with Classic Mode

After the Update from Typo3 8.7.24 to 8.7.25 the System crashed with the following Error:

Warning: Uncaught TYPO3\PharStreamWrapper\Exception: Executing phar:///home/www/p*****/html/updatetest/typo3conf/ext/formlog//vendors.phar/vendor/autoload.php is denied in /html/updatetest/typo3_src-8.7.25/typo3/sysext/core/Classes/IO/PharStreamWrapperInterceptor.php:39
Stack trace:
#0 /html/updatetest/typo3_src-8.7.25/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72): TYPO3\CMS\Core\IO\PharStreamWrapperInterceptor->assert('phar:///home/ww...', 'stream_open')
#1 /html/updatetest/typo3_src-8.7.25/vendor/typo3/phar-stream-wrapper/src/Manager.php(110): TYPO3\PharStreamWrapper\Behavior->assert('phar:///home/ww...', 'stream_open')
#2 /html/updatetest/typo3_src-8.7.25/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(421): TYPO3\PharStreamWrapper\Manager->assert('phar:///home/ww...', 'stream_open')
#3 /html/updatetest/typo3_src-8.7.25/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(256): TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///home/ww...', 'stream_open')
#4 /html/updatetest/typo3c in /html/updatetest/typo3_src-8.7.25/typo3/sysext/core/Classes/IO/PharStreamWrapperInterceptor.php on line 39

Fatal error: TYPO3\CMS\Core\Utility\ExtensionManagementUtility::main(): Failed opening required 'phar:///home/www/p*****/html/updatetest/typo3conf/ext/formlog//vendors.phar/vendor/autoload.php' (include_path='.:/usr/local/pear') in /html/updatetest/typo3conf/ext/formlog/ext_localconf.php on line 17

Export not working on TYPO3 11

hi

can someone confirm (or not) that after clicking the Export button in TYPO311 there is no div shown with possibility to choose cvs/xls? I checked the console. There is no JS errors and in network all file are loaded. Tnx.

Using 2.0.0.

Disabled pages missing in log/export

In case a page is disabled, nothing is shown in the log module and an empty value is exported.

This should be changed to also include disabled pages.

variants condition 'finisherIdentifier in ["LogFormData"] not working

i have field that i want to display only in finisher
the condition condition: 'finisherIdentifier in ["EmailToSender", "EmailToReceiver", "Confirmation", "LogFormData"]'
working for Mails but not for LogFormData. The field does not appear in form log

my form.yaml looking like

-
            defaultValue: ''
            identifier: my-field-1
            label: my-field
            type: Text
            properties:
              fluidAdditionalAttributes:
                placeholder: 'my-field (hidden)'
              elementDescription: 'filled in automatically'
            variants:
              -
                identifier: hide-in-form
                condition: 'stepIdentifier == "page-1"'
                renderingOptions:
                  enabled: false
              -
                identifier: show-in-email
                condition: 'finisherIdentifier in ["EmailToSender", "EmailToReceiver", "Confirmation", "LogFormData"]'
                renderingOptions:
                  enabled: true

Expand documentation

There should be a proper documentation with more details and especially screenshots of the log module.

Can't update to TYPO3 V9.5.6 in Classic Mode

When updating TYPO3 V9LTS to V9.5.6, the following error comes from formlog extension (1.1.7). Then I can't use the latest TYPO3 version without deactivating formlog extension :

Failed opening required 'phar:///var/www/web/typo3conf/ext/formlog//vendors.phar/vendor/autoload.php'

Add tx_formlog_entries to TableGarbageCollectionTask

Related to #5

It should be easily possible to automatically remove old entries from fromlog.
The most out-of-the-box way I know of would be to add it to the TableGarbageCollectionTask.

I'm thinking of something like this:

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['tasks'][\TYPO3\CMS\Scheduler\Task\TableGarbageCollectionTask::class]['options']['tables']['tx_formlog_entries'] = [
    'dateField' => 'tstamp',
    'expirePeriod' => 90,
];

I'm not sure where I read it but 90 days was how long you should keep the data but also when you should delete it.

finisherVariables working example

With the poor explanation of the Readme file, I can't make finisherVariables working well.
When inserting a custom variable 'email-confirmed' in YAML form definition file, I've got the following error :

Argument 1 passed to TYPO3\CMS\Core\Utility\ArrayUtility::getValueByPath() must be of the type array, null given, called in /var/www/clients/client30/web321/typo3_src/typo3_src-8.7.19/typo3/sysext/form/Classes/Domain/Finishers/FinisherVariableProvider.php on line 100

TypeError thrown in file
/var/www/clients/client30/web321/typo3_src/typo3_src-8.7.19/typo3/sysext/core/Classes/Utility/ArrayUtility.php in line 178.

32 TYPO3\CMS\Core\Utility\ArrayUtility::getValueByPath(NULL, "email-confirmed", ".")

Could you provide a working exemple of a YAML form configuration file with implementation of custom finisher variables.
Thanks.

Error after updating 1.x to 2.x

After updating formlog the module shows an error:

Oops, an error occurred!
The type of property Pagemachine\Formlog\Domain\Model\FormLogEntry::page could not be identified, therefore the desired value (NULL) cannot be mapped onto it. The type of a class property is usually defined via php doc blocks. Make sure the property has a valid @var tag set which defines the type.

After clearing the table 'tx_formlog_entries' everything is fine. When I send a new form the error comes again.

I'm using Typo3 v 10.4.24

missing date fields in the data-result in DB

Form-fields like "date" or "datepicker" wouldn't be written into the database date-field!?
So it is not possible to show them nor in the list.columns neither in the export.columns.

With the Ext. "form_to_database" you'll get them in this structure (sub-array):
"datum":{"date":"2022-05-16 08:06:44.000000","timezone_type":3,"timezone":"Europe/Berlin"} e.g.

PHP Warning addQueryStringMethod = GET,POST or POST,GET is not supported

Just trying the extension in v10 triggering warnings:

PHP User Warning

Core: Error handler (BE): PHP User Warning: Assigning addQueryStringMethod = GET,POST or POST,GET is not supported anymore since TYPO3 v10.0 - falling back to GET. in /var/www/html/public/typo3/sysext/extbase/Classes/Mvc/Web/Routing/UriBuilder.php line 366

Date range filter lost on page switch

A custom date range filter is lost when switching to a different page. This does not affect the Filter by this option which is properly forwarded in pagination links.

Provide compatibility with EXT:repeatable_form_elements

Hi,

thanks for your extension.

We use EXT:repeatable_form_elements for different kind of seminar registration for a user definable amount of participants.

Sadly, the formlog extension currently is not capable of handling repeated form elements, which are in the end nested form elements in an array representation.
"repeatable_element.counter.field_identifier" instead of a plain "field_identifier"

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.