porthd / simpledataedit
Simple frontend-editing with TYPO3
Installs: 3
Dependents: 0
Suggesters: 0
Security: 0
Stars: 0
Watchers: 1
Forks: 0
Open Issues: 0
Type:typo3-cms-extension
Requires
- typo3/cms-core: ^10.1
- typo3/cms-extbase: ^10.1
- typo3/cms-install: ^10.1
Replaces
- porthd/simpledataedit: v10.0.1
This package is auto-updated.
Last update: 2022-01-24 18:20:02 UTC
README
Prologue auxiliary sentence for scribes
A good newspaper article outlines the following motto of information needs in the first paragraph/sentence:
- Who does what with whom/with what when, where and how?
- The why in the second paragraph, like the 2nd law of thermodynamics, is always a matter of belief?
- Anyone who asks the wrong questions will always get one thing for sure: wrong answers! ( I hope I haven't answered too many wrong descriptive questions here. ;-)
Who does what with whom/with what, when, where and how?
The extension saves simple text changes in editable areas of the front end of the website directly in the database via Ajax/JavasScript, if the editor is logged into the backend at the same time and if the integrator has provided for this in the templates. In this way, the editor can make simple text changes directly in the frontend and enjoy your WYSIWYG feelings.
From a technical point of view, the extension only defines the sealing off of a single field in a specific database at a specific record using a generalized AJAX process. A hash value for each data record ensures that the change is always based on the text just seen before. Several editors cannot unknowingly (!) Overwrite each other's texts.
How does the editor work?
- The editor logs into the backend of the website.
- He opens the frontend view of the website in a second tab of the browser.
- The editable areas are highlighted in color.
- If he gets an error message, the editor has to reload the frontend in the browser.
Technical requirements?
- a modern browser
What is not working?
From CRUDE (Create, Read, Update, Delete, Edit), only RUE is currently limited.
- In multi-domain setups, the BE_TYPO3_USER cookies are only used in the current domain in which the editor has logged in. If you want to change something in domain B, you have to be logged into the backend via domain B.
- Formalized fields of the backend such as RTE fields, date fields or data embedded in f: translate cannot yet (!) Be edited.
- Changing relations (pictures, similar messages, ...) is currently not supported.
- The creation or deletion of data records is not supported.
- Changing data in attributes or empty, undisplayed data fields.
What could happen in the future?
I hope for the community on the following two points:
- Formalized fields make the editing process more complex.
This should be able to be done with new editor classes.
The extension allows the definition and integration of
Editor
classes. - Changing relations requires special methods in the front end and a generalized process in the back end.
This should be able to be done with new editor classes.
The extension allows the definition and integration of
Editor
classes. - Changing data in attributes or empty, undisplayed data fields
This should be able to be done with new editor classes.
The extension allows the definition and integration of
Editor
classes.
The other two points require a slight rethink on the part of the developers.
- The creation and deletion of data records is not supported.
- The creation and deletion of new relations to existing data records is not supported.
- The creation and deletion of new relations to new data records to be created is not supported.
Why is it necessary to rethink? (I'm inferring from myself to others.) In the TYPO3 backend, a data record is only created when it is explicitly saved. This allows the data record to be edited before saving. With the concept presented here, on the other hand, you have to create a default data record. You probably have to reload the page to see all editable fields available. So you have to think more deeply than before, which data an initial data record must contain and anchor this not only in the TCA but also in the model.
What does the integrator have to do
Currently only trimmable plain text fields are supported.
The integrator only has to enter the corresponding data fields with the Viewhhelper
Include <simpledataedit: editor ...>
.
Is there a sample code for integrators?
In order to enable a trouble-free test in a live system and a classic form of extension upload, the extension has its own backend layout. In order to be able to use this for the test, the exemplary TypoScript must also be integrated.
The backend layout defines a test column with the ColPos value (7387).
After activating the test TypoScript of this extension, a test page in the column (7387)
made the header
field editable in a special template for the TYPO3 text-only
content element.
(see code simpledataedit/Resources/Private/Templates/FluidElements/Text.html )
Customize styles
The path to the JavaScript is in the settings of the extension and given to the styles.
What is the working principle of the extension? How is the workflow?
The working principle is simple. The Viewhelper stores all data for frontend editing in the frontend. With font rendering, the JavaScript functions of the editors are also rendered and the basic JavaScript libraries for the Ajax process are integrated. As soon as you leave a changed field (focusout), the Ajax process is started and processed in a middleware.
In the event of an error, the Ajax process writes an error message with a note on redirection. if successful, the new hash value is returned.
Parameters of the view helper
The basic viewhelper attributes are also available in <simpledataedit: editor ...>
.
Parameters | Type | Default | function |
---|---|---|---|
editor | string | mandatory | Identifier for adapted editor processor class |
pid | int | mandatory | Page ID where the content item is displayed. |
raw | string | mandatory | This contains the raw data. It is the basis for the hash value. |
Field name | String | mandatory | Name of the field in the model. It may be absent if a custom process uses a self-defined get and update process to get the data. |
uid | int | mandatory | Number of the UID that specifies the line in the model through the UID field. It may be absent if a custom process uses a self-defined get and update process to get the data. |
Type | Int | 2 | Name of the type of value (int = 1, str = 2, bool = 5) for the field in the model. It may be absent if a custom process uses a self-defined get and update process to get the data. |
Table | String | 'tt_content' | Name of the model. It may be absent if a custom process uses a self-defined get and update process to get the data. |
identname | string | 'uid' | Name of the ident field with which the line is specified in the model. It may be absent if a custom process uses a self-defined get and update process to get the data. |
paramList | string | "[]" | A list of arguments for custom parsing processes, in array format. It is converted to a JSON string |
Roles | String | undef | The comma-separated list of user groups with their UID and/or their title). |
always | bool | false | Always allow front-end editing for everyone. The allowance must be released in the expansion configuration |
What can developers do
Create your own editor
An editor class must provide the functions of the interface CustomEditorInterface
.
The parameters are transferred via a CustomEditorInfo
class,
which is derived from the interface CustomEditorInfoInterface
.
It is currently not possible to override the CustomEditorInfo
with a separate class.
Example for editor class
see in the code simpledataedit/Classes/Editor/PlainTextEditor.php
Installation of the editor class in its own extension
If you have defined your class MyVendor\MyExtension\Editor\MyEditor, this must of course still be made known to the system.
Define the following code block in your ext_localconf.php
:
/**
* define your own editor-class, if you have special elements
*/
$whoAmI = 'whoAmI'; // if i use the name directly, PHPStorm remarks it with a warning ;-(
$listOfCustomEditorClasses = [
\MyVendor\MyExtension\Editor\MyEditor::$whoAmI() =>
\MyVendor\MyExtension\Editor\MyEditor::class,
];
\Porthd\Simpledataedit\Utilities\ConfigurationUtility::mergeCustomGlobals(
$listOfCustomEditorClasses
);
The static method ensures that your class name is entered in $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['simpledataedit']['editor']['editor'] ['your-whoAmI-name']. To avoid the likelihood of unwanted overwrites, your whoAmI name should contain your vewndor name.
To do
- Cache for referenced pages and records. ( a big problem)
- I have not yet understood how to set cross-domain cookies. Or how to simply implement an OAuth process. I will gladly accept suggestions with code examples.
- It would be desirable if Simpledataedit would support the following
- Date and time in datetime format
- Date and time in UNIX timestamp format (integer)
- comma numbers
- Editing of data integrated in translate fields.
- Generalized queries for creating/deleting/changing simple relations
- Generalized queries for creating/deleting/changing MM relations
- Deleting relations and creating new default objects