This directory primarily contains php-scripts which are meant as 'external modules' as opposed to features included in the typo3/sysext/cms/tslib/ libraries. Although they are distributed with TYPO3 just like tslib/ they form a basis for externally developed front-end functionality. So for most of these scripts, be inspired by them to write your own code. Notice the word 'most'; because some are written long time ago and does not represent the state-of-the-day to do it.
For each plugin script there is one or more example templates. These templates are a part of the documentation of the features in the plugin because they describe the features of the markers and subparts and present an example to learn from. Therefore the example templates may be change when new features come along or of other reasons.
You should therfore not rely on using the default templates unless you'll except the fact that they may change in the future! So make a copy, modify it for your own purpose if need and set up the TypoScript of the plugin to use your own template file!
File: | Description: |
|---|---|
fe_adminLib.inc | Main class used to display the fe administration forms Call it from a USER_INT cObject with 'userFunc = user_feAdmin->init'. See the static_templates for examples. Note: Using the USER_INT cObject allows the script to work regardless of the page-cache which is necessary!! |
fe_admin_dmailsubscrip.tmpl | Example template file for subscription to newsletters of users to the tt_address table. This template is used by the static_template 'plugin.feadmin.dmailsubscription' |
fe_admin_fe_users.tmpl | Example template file for creating new front end users (fe_users). This template is used by the static_template 'plugin.feadmin.fe_users' |
This class is used to create forms for database-administration in the front-end independently of the backend (TBE). Thus you may want to use this, if you would like front-end users to edit database content.
Authentication goes through either fe_user login in which case you can stamp the records with the fe_user_uid so a record belongs to a certain fe_user. The other authentication option is email authentication. In this case you have access to the record if your email is found in a certain field. By fe_user authentication you can get a menu of items to edit when you're logged in. With email-authentication, you can request an email to be sent to your email address. This email contains a list of the available records.
It's all based on HTML-template files which you have to design by your self, so there's some design work to do. On the other hand you get total freedom to design your forms.
Name: | Description: |
|---|---|
cmd | Command; |
preview | Preview flag. |
backURL | Back URL. |
rU | Record UID. |
aC | Authentication Code. |
fD | fixed Data (array of fields) |
FE | Frontend Edit data array, syntax, FE[tablename][fieldname] = value |
Property: | Data type: | Description: | Default: |
|---|---|---|---|
templateFile | resource | The template file, see examples in media/scripts/fe_user_admin.tmpl | |
templateContent | string | Alternatively you can set this property directly to the value of the template. | |
table | tablename | The table to edit. Notice: The ultimate lsit of fields allowed to be edited for the table is defined in TCA with the key ["feInterface"]["fe_admin_fieldList"] for each table in question. For an example, see the table definition for fe_users which is a good example. | |
defaultCmd | string | Defines which action should be default (if &cmd= is not set when calling the page) | |
clearCacheOfPages | [list of integers] | This is a list of page-ids for which to clear the cache on any successfull operation be it EDIT, CREATE og DELETE. | |
debug | boolean | If set, debug information will be output from fe_adminLib which helps to track errors. | |
Actions: | |||
edit | boolean /actionObject | If set, editing is basically allowed. But you need to specify: .fields (list of fieldnames) which determines the fields allowed for editing. Every field in this list must be found as well in the ["feInterface"]["fe_admin_fieldList"] found in the TCA array which ultimately determines which fields can be edited by the fe_adminLib. .overrideValues.[fieldname] (value string) defines values for specific fields which will override ANY input from the form. Overriding values happens after the outside values has been parsed by the .parseValues-property of fe_adminLib but before the evaluation by .required and .evalValues below. For example this may be useful if you wish to hide a record which is being edited, because you want to preview it first. .required (list of fieldnames, subset of .fields) which determines which fields are required to return a true value. The valid fields entered here will have the subpart ###SUB_REQUIRED_FIELD_[fieldname]### removed from the templates if they evaluates to being true and thereby OK. See below for information about this subpart. .evalValues.[fieldname] (list of eval-codes) defines specific evaluation forms for the individual fiels of the form. See below. .preview (boolean) will enable the form submitted to be previewed first. This requires a template for preview to be found in the template file. See below for subpart marker names. .menuLockPid (boolean will force the menu of editable items to be locked to the .pid (edit only) .userFunc_afterSave (function-name) is called after the record is saved. The content passed is an array with the current (and previous) record in. | |
create | boolean /actionObject | The same as .edit above except where otherwise stated. Plus there is these additional properties: .noSpecialLoginForm (boolean) - if set, fe_adminLib does NOT look for the subpart marker TEMPLATE_CREATE_LOGIN but always for TEMPLATE_CREATE .defaultValues.[fieldname] (value string); Like .overrideValues but this sets the default values the first time the form is displayed. | |
delete | boolean | Whether or not records may be deleted. Still regular authentication (ownership or email authCode) is required. Setting the var “preview” lets you make a delete-preview before actually deleting the record. | |
infomail | boolean | Infomails are plaintext mails based on templates found in the template file. They may be used for such as sending a forgotten password to a user, but what goes into the infomail is totally up to your design of the template. Normally you may have only a default infomail (infomail.default) for instance for sending the password. But you can use other keys also. See below. | |
infomail.[key] | (configuration of infomail properties) | In order to make fe_adminLib send an infomail, you must specify these vars in your GET vars or HTML-form. fetch - if integer, it searches for the uid being the value of 'fetch'. If not, it searches for the email-field (defined by a property of fe_adminLib, see below). key - points to the infomail.[key] configuration to use Properties: .dontLockPid (boolean) - selects only records from the .pid of fe_adminLib. .label (string) - The suffix for the markers, see 'Email Markers' beneath. | |
setfixed | boolean /properties | Allows set-fixed input, probably coming from a link in an infomail or notification mail. Syntax: .[fixkey].[fieldname] = fieldvalue - is used to setup a setfixed-link insertable in the infomail by the SYS_SETFIXED_*-markers. See above (setfixed-property of fe_adminLib). Special fixkey 'DELETE' is just a boolean. .userFunc_afterSave (function-name) is called after the record is saved. The content passed is an array with the current (and previous) record in. Concept: The 'setfixed' concept is best explained by describing a typical scenario - in fact the most common situation of its use: Imagine you have some users submitting information on your website. But before that information enters the database, you would like to moderate it - simply preview it and then either delete it or approve it. In the 'create' configuration of fe_adminLib, you set up the hidden field of the record to be overridden to 1. Thus the record is hidden by default. Then you configure a setfixed-fixkey to set the hidden field to 0. This set up generates a list of parameters for use in an URL and those parameters are finally inserted by a corresponding marker in the email template. The link includes all necessary authentication to perform the change of values and thus a single click on that link is enough to change the field values. So this will - by a single click of a link in a notification mail sent to an admin - enable the record! Or of course a similar link with a cmd=delete link will delete it... There is a special “fieldname” you can use, which is '_FIELDLIST” and that lets you specify a list of fields in the record to base the auth-code on. If nothing is specifyed the md5-hash is based on the whole record which means that any changes will disable the setfixed link. If on the other hand, you set _FIELDLIST = uid,pid then that record will be editable as long as the uid and pid values are intact. Example: This is a common configuration of the email-properties with a simple setfixed setting: email.from = kasper@typo3.com email.fromName = Kasper Skårhøj email.admin = kasper@typo3.com setfixed.approve { hidden = 0 _FIELDLIST = uid,pid } setfixed.DELETE = 1 setfixed.DELETE._FIELDLIST = uid Now, if you insert this marker in your email template ###SYS_SETFIXED_approve### if will get substituted with something like these parameters: &cmd=setfixed&rU=9&fD[hidden]=0&aC=5c403d90 Now, all you need is to point that to the correct url (where fe_adminLib is invoked!), eg: ###THIS_URL######FORM_URL######SYS_SETFIXED_approve### and for deletion: ...###SYS_SETFIXED_DELETE### | |
Others | |||
authcodeFields | [list of fields] | Comma separated list of fields to base the authCode generation on. Basically this list would include “uid” only in most cases. If the list includes more fields, you should be aware that the authCode will change when the value of that field changes. And then the user will have to re-send an email to himself with a new code. .addKey (string) adds the string to the md5-hash of the authCode. Just enter any random string here. Point is that people from outside doesn't know this code and therefore are not able to reconstruct the md5-hash solely based on the uid .addDate (date-config) You can use this to make the code time-disabled. Say if you enter “d-m-Y” here as value, the code will work until midnight and then a new code will be valid. .codeLength (int) Defines how long the authentication code should be. Default is 8 characters. In any case TYPO3_CONF_VARS[SYS][encryptionKey] is prepended. Advice: If you want to generate authCodes compatible with the standard authCodes (used by the direct mailer by t3lib_div::stdAuthCode()), please set TYPO3_CONF_VARS[SYS][encryptionKey] to a unique and secret key (like you should in any case) and add “uid” as authcodeField ONLY. This is secure enough. | |
.from (string, email) Defines the sender email address of mails sent out .fromName (string) Defines the name of the sender. If set, this will be used on the form NAME <EMAIL> .admin Email address of the administrator which is notified of changes. .field (string/integer) Defines the fieldname of the record where the email address to send to is found. If the field content happens to be an integer, this is assumed to be the uid of the fe_user owning the record and the email address of that user is fetched for the purpose instead. | |||
pid | int+ | The pid in which to store/get the records. | Current page |
fe_userOwnSelf | boolean | If set, fe_users created by this module has their fe_cruser_id-field set to their own uid which means they 'own' their own record and can thus edit their own data. All other tables which has a fe_cruser_id field configured in the 'ctrl' section of their $TCA-configuration will automatically get this field set to the current fe_user id. | |
fe_userEditSelf | boolean | If set, fe_users - regardless of whether they own themselves or not - will be allowed to edit himself. | |
allowedGroups | [list of integers] | List of fe_groups uid numbers which are allowed to edit the records through this form. Normally only the owner fe_user is allowed to do that. | |
evalFunc | function-name | Function by which you can manipulate the dataArray before it's saved. The dataArray is passed to the function as $content and MUST be returned again from the function. The property “parentObj” is a hardcoded reference to the fe_adminLib object. | |
formurl | ->typolink | Contains typolink properties for the URL (action tag) of the form. | |
parseValues.[field] | [list of parseCodes] | ParseCodes: int - returns the integer value of the input lower - returns lowercase version of the input upper - returns uppercase version of the input nospace - strips all space alpha, num, alphanum, alphanum_x - only alphabetic (a-z) and/or numeric chars. alphanum_x also allows _ and - trim - trims whitespace in the ends of the string setEmptyIfAbsent - will make sure the field is set to empty if the value is not submitted. This ensures a field to be updated an is handy with checkboxes random[x] - Returns a random number between 0 and x files[semicolon-list(!) of extensions, none=all][maxsize in kb, none=no limit] - Defining the field to hold files. See below for details! multiple - Set this, if the input comes from a multiple-selector box (remember to add ...[] to the fieldname so the values come in an array!) checkArray - Set this, if you want several checkboxes to set bits in a single field. In that case you must prepend every checkbox with [x] where x is the bitnumber to set starting with zero. The default values of the checkbox form elements must be false. uniqueHashInt[semicolon-list(!) of other fields] - This makes a unique hash (32 bit integer) of the content in the specified fields. The values of those fields are first converted to lowercase and only alphanum chars are preserved. | |
userFunc_updateArray | function-name | Points to a user function which will have the value-array passed to it before the value array is used to construct the update-JavaScript statements. | |
evalErrors.[field].[evalCode] | This lets you specify the error messages inserted in the ###EVAL_ERROR_FIELD_[fieldname]### markers upon an evaluation error. See description of evaluation below. | ||
cObjects.[marker_name] | cObject | This is cObjects you can insert by markers in the template. Example: Say, you set up a cObject like this: cObject.myHeader = TEXT cObject.myHeader.value = This is my header then you can include this cObject in most of the templates through a marker named ###CE_myHeader### or ###PCE_myHeader### (see below for details on the difference). | |
wrap1 | ->stdWrap | Global Wrap 1. This will be splitted into the markers ###GW1B### and ###GW1E###. Don't change the input value by the settings, only wrap it in something. Example: wrap1.wrap = <b> |</B> | |
wrap2 | ->stdWrap | Global Wrap 2 (see above) | |
color1 | string /stdWrap | Value for ###GC1### marker (Global color 1) | |
color2 | string /stdWrap | Value for ###GC2### marker (Global color 2) | |
color3 | string /stdWrap | Value for ###GC3### marker (Global color 3) |
[tsref:(script).fe_adminLib]
There are a certain system in the naming of the main subparts of the template file. These markers below is used when an action results in “saving”. The [action] code may be DELETE, EDIT or CREATE depending on the cmd value.
Subpart marker: | Description: |
|---|---|
###TEMPLATE_[action]_SAVED### | Used for HTML output |
###TEMPLATE_SETFIXED_OK### (general) ###TEMPLATE_SETFIXED_OK_[fixkey]### | Used for a successfull setfixed-link. |
###TEMPLATE_SETFIXED_FAILED### | Used for an unsuccessfull setfixed-link. Notice that if you click a setfixed link twice, the second time it will fail. This is because the setfixed link is bound to the original record and if that changes in any way the authentication code will be invalid! |
###EMAIL_TEMPLATE_[action]_SAVED### | Used for an email message sent to the website user |
###EMAIL_TEMPLATE_[action]_SAVED-ADMIN### | Used for an email message sent to the admin |
###EMAIL_TEMPLATE_SETFIXED_[fixkey]### | Used for notification messages in the event of successfull setfixed operations. |
###EMAIL_TEMPLATE_SETFIXED_[fixkey]-ADMIN### | Ditto, for admin email |
Likewise there are a system in the subpart markers used for the EDIT and CREATE actions to display the initial forms:
###TEMPLATE_[action]###or if a fe_user is logged in (only CREATE): ###TEMPLATE_[action]_LOGIN###
... and if the &preview-flag is sent as well (including DELETE)
###TEMPLATE_[action]_PREVIEW###
Must-have subparts:
These are subparts that should exist in any template.
Subpart marker: | Description: |
|---|---|
###TEMPLATE_AUTH### | Displayed if the authentication - either of fe_user or email authentication code - failed. You must design the error display to correctly reflect the problem! |
###TEMPLATE_NO_PERMISSIONS### | This error message is displayed if you were authenticated but of other reasons (like wrong fe_user/group ownership) did not posses the right to edit or delete a record. |
All email subparts can be sent as HTML. This is done if the first and last word of the templates is <html> and </html> respectively. In addition the t3lib_htmlmail class must be loaded.
Subpart: | Description: |
|---|---|
###EMAIL_TEMPLATE_NORECORD### | |
###EMAIL_TEMPLATE_[infomail_key]### | |
###SUB_RECORD### |
The forms used with fe_adminLib should be named after the table their are supposed to edit. For instance if you are going to edit records in the table 'fe_users' you must use a FORM-tag like this:
<FORM name=”fe_users_form” method=”POST” action=”....”>
The fields used to submit data for the records has this syntax, FE[tablename][fieldname]. This means, if you want to edit the 'city' field of a tt_address record, you could use a form element like this:
<INPUT name=”FE[tt_address][city]”>
Submit buttons can be named as you like except using the name “doNotSave” of a submit button will prevent saving. If you need Cancel button, please resort to JavaScript in an onClick even to change document.location.
###GW1B### / ###GW1E###: Global wrap 1, begin and end (headers)
###GW2B### / ###GW2E###: Global wrap 2, begin and end (bodytext)
###GC1### / ###GC2### / ###GC3###: Global color 1 through 3
###FORM_URL###: The url used in the forms: index.php?id=page-id&type=page-type
###FORM_URL_ENC###: As above, but rawurlencoded.
###BACK_URL###: The backUrl value. Set to the value of incoming “backURL” var
###BACK_URL_ENC###: As above, but rawurlencoded.
###REC_UID###: The UID of the record edited. Set to the value of incoming “rU” var
###AUTH_CODE###: The “aC” incoming var
###THE_PID###: The “thePid” value - where the records are stored.
###THIS_ID###: Set to the current page id
###THIS_URL###: Set to the current script url as obtained by t3lib_div::getThisUrl()
###HIDDENFIELDS###: A bunch of hiddenfields which are required to be inserted in the forms. These includes by default 'cmd', 'aC' and 'backURL'
In addition you can in most cases use markers like this
###FIELD_[fieldname]###
where [fieldname] is the name of a field from the record. All fields in the record are used.
Finally you can insert cObjects defined in TypoScript with this series of markers (see .cObject property in table above):
###CE_[cObjectName]###
###PCE_[cObjectName]###
(###PCE_* is difference from ###CE_* cObjects by the fact they are rendered with a newly created cObj (as opposed to the parant cObj of fe_adminLib) where the data-array is loaded with the value of ->dataArr which is the array submitted into the script. This makes then useful for presenting preview data. Finally both PCE_ and CE_ types cObject markers may be used with each single element in a edit menu (list of available records) by prefixing the marker with 'ITEM_', eg. ###ITEM_PCE_[cObjectName]###
Printing error messages for REQUIRED fields
When a form template is displayed all subparts with the markers
###SUB_REQUIRED_FIELDS_WARNING###
and
###SUB_REQUIRED_FIELD_[fieldname]###
are removed. If there is a simple “required”-error (a field is not filled in) then the SUB_REQUIRED_FIELDS_WARNING is not removed and thus the error message contained herein is shown.
Lets say that more specifically it's the 'email' field in a form which is not filled in. Then you can put in a subpart named
###SUB_REQUIRED_FIELD_email###
This is normally removed, but it'll not be removed if the email field fails and thus you are able to give a special warning for that specific field.
Printing other error messages
However you may use other forms of evaluation than simple “required” check. This is specified for “create” and “edit” modes by the properties “.evalValues.[fieldname] = [list of codes]”. In order to tell your website user which of the possible evaluations went wrong, you can specify error messages by the property .evalErrors which will be inserted as the marker named ###EVAL_ERROR_FIELD_[fieldname]###.
Lets say that you have put the code 'uniqueLocal' in the list of evaluation code for the email field. You would do that if you want to make sure that no email address is put into the database twice. Then you may specify that as:
create.evalValues {email = uniqueLocal, email
}
Then you set the evaluation error messages like this:
evalErrors.email {uniqueLocal = Apparently you're already registered with this email address!
email = This is not a proper email address!
}
If the error happens to be that the email address already exists the field ###EVAL_ERROR_FIELD_email### will be substituted with the error message “Apparently you're already registered with this email address!”.
You can pass default values to a form by the same syntax as you use in the forms. For instance this would set the name and email address by default:
...?FE[tt_address][name]=Mike%20Tyson&FE[tt_address][email]=mike@trex.us&doNotSave=1&noWarnings=1
Notice the blue value names are the field values (must be rawurlencoded. In javascript this function is called escape()) and the red values are necessary if you want to NOT save the record by this action and NOT to display error messages if some fields which are required is not passed any value.
Eval-code: | Description: |
|---|---|
uniqueGlobal | This requires the value of the field to be globally unique, which means it must not exist in the same field of any other record in the current table. |
uniqueLocal | This is like uniqueGlobal, but the value is required to be unique only in the PID of the record. Thus if two records has different pid values, they may have the same value of this field. |
twice | This requires the value of the field to match the value of a secondary field name [fieldname]_again sent in the incoming formdata. THis is useful for entering password. Then if your password field is name “user_pass” then you simple add a second field name “user_pass_again” and then set the 'twice' eval code. |
Requires the field value to be an email address at least on the form [name]@*[domain].[tld] | |
required | Just simple required (trimmed value). 0 (zero) will evaluate to false! |
atLeast atMost | Specifies a minimum / maximum of characters to enter in the fields. Example, that requires at least 5 characters: atleast [5] |
inBranch | inBranch requires the value (typically of a pid-field) to be among a list of page-id's (pid's) specified with the inBranch parameters. The parameters are given like [root_pid; depth; beginAt] Example, which will return a list of pids one level deep from page 4 (included): inBranch [4;1] |
unsetEmpty | This evaluation does not result in any error code. Only it simply unsets the field if the value of the field is empty. Thus it'll not override any current value if the field value is not set. |
[tsref:(script).fe_adminLib.evalErrors.(field).(evalCode)]
fe_adminLib is able to receive files in the forms. However there currently are heavy restrictions on how that is handled. Ideally the proces would be handled by the t3lib_tcemain class used in the backend. In fact this could have been deployed but is not at this stage. The good thing about tcemain.php is that it perfectly handles the copying/deletion of files which goes into a certain field and even handles it independent of the storing method be it a list of filenames or use MM-relations to records (see tables.php section in 'Inside TYPO3').
This is how files are handled by fe_adminLib and the restrictions that apply currently:
You can upload files ONLY using “create” mode of a record. In any case you cannot edit currently attached files (this may be improved in the future). You can however use 'delete' mode.
However you can use PREVIEW mode with 'create'. Works like this: if the mode is preview the temporary uploaded file is copied to a unique filename (prepended with the tablename) in typo3temp/ folder. Then the field value is set to the filenames in a list. When the user approves the content of the preview those temporary files are finally copied to the uploads/* folder (or whereever specified in TCA). Limitations are that the temporary files in typo3temp/ are NOT deleted when copied to the real upload-folder (this may be improved) and certainly not if the user aborts (can't be improved because the user may go anywhere). If the user cancels the preview in order to change values, the files will need to be uploaded again (this may be improved).
The TCA extensions allowed for the field is ignored! However you can specify a list of extensions of allowed for the files in the .parseValues property of fe_adminLib
The TCA filesize limitation for the field is ignored! However you can specify a max file size in kb in the .parseValues property of fe_adminLib
Works only on fields configured for comma-list representation of the filenames (non-MM, see “Inside TYPO3” document on MM relations for files).
It's recommended to use a dedicated folder for files administered by the fe_adminLib. The TYPO3 testsite does that by using the uploads/photomarathon/ folder for images. This makes it much easier to clean up the mess if files and their relations to the records are broken.
Fieldnames for files
Lets say you have a field named “picture” of a table name “user_cars”, the form-element should look like this:
<input type="file" name="FE[user_cars][picture][]">
If you wish to upload multiple files to that field, the form-elements should look like:
<input type="file" name="FE[user_cars][picture][]">
<input type="file" name="FE[user_cars][picture][]">
<input type="file" name="FE[user_cars][picture][]">
Use blob-types for the file-fields and reserve a minimum of 32 characters pr. filename.
NOTE: Make sure to always add the last square brackets ('...[]') to the fieldname! Otherwise it will not work!
File: | Description: |
|---|---|
tipafriendLib.inc | Main class used to display the Tip-a-Friend form Call it from a USER cObject with 'userFunc = user_tipafriend->main_tipafriend' |
tipafriend_template.tmpl | Example template file. |
Property: | Data type: | Description: | Default: |
|---|---|---|---|
templateFile | resource | The template-file. See example in 'media/scripts/tipafriend_template.tmpl' | |
code | string /stdWrap | Code to define, what the script does. Case sensitive. | |
defaultCode | string | The default code (see above) if the value is empty. By default it's not set and a help screen will appear | |
wrap1 | ->stdWrap | Global Wrap 1. This will be splitted into the markers ###GW1B### and ###GW1E###. Don't change the input value by the settings, only wrap it in something. Example: wrap1.wrap = <B> |</B> | |
wrap2 | ->stdWrap | Global Wrap 2 (see above) | |
color1 | string /stdWrap | Value for ###GC1### marker (Global color 1) | |
color2 | string /stdWrap | Value for ###GC2### marker (Global color 2) | |
color3 | string /stdWrap | Value for ###GC3### marker (Global color 3) | |
typolink | ->typolink | TypoLink configuration for the TIPLINK to the TIPFORM page. .additionalParams is added the parameter “&tipUrl=” | |
htmlmail | boolean | If set, the page is fetched as HTML and send in HTML (a plain text version is sent as well). |
[tsref:(script).tipafriend]
File: | Description: |
|---|---|
plaintextLib.inc | Main class used to display plain text content Call it from a USER cObject with 'userFunc = user_plaintext->main_plaintext' |
plaintext_content.tmpl | Example template file. |
Property: | Data type: | Description: | Default: |
|---|---|---|---|
siteUrl | url | Url of the site. | |
defaultOutput | untrimmed string | Default output if CType is not rendered. | |
uploads.header | untrimmed string | Header for uploads | |
images.header | untrimmed string | Header for images | |
images.captionHeader | untrimmed string | Header for imagecaptions | |
images.linkPrefix | untrimmed string | Prefix for image-links | |
.header | |||
defaultType | int | Which type to use as default | |
date | date-config | For header date | |
datePrefix | untrimmed string | Prefix for header date | |
linkPrefix | untrimmed string | Prefix for header links | |
[1-5].preLineLen | int | Lenght of line before header | |
[1-5].postLineLen | int | Lenght of line after header | |
[1-5].preBlanks | int | Number of blank lines before header | |
[1-5].postBlanks | int | Number of blank lines after header | |
[1-5].stdWrap | ->stdWrap | for header text | |
[1-5].preLineChar | string | Character to pre-line | |
[1-5].postLineChar | string | Character to post-line | |
[1-5].preLineBlanks | int | Number of blank lines between header and pre-line | |
[1-5].postLineBlanks | int | Number of blank lines between header and post-line | |
[1-5].autonumber | boolean | If set, a number is prepended every header. The number corresponds to the content element number in the select. | |
[1-5].prefix | untrimmed string | Header string prefix | |
bulletlist.[0-3].bullet | untrimmed string | Bullet for bullet list, layout [0-3] | |
bulletlist.[0-3].secondRow | untrimmed string | If set, this is used for lines on the second row of bullet-lists. | |
menu | cObject | cObject to render menu. The output is stripped for tags and the links is extracted. Further all <BR> chars are converted to chr(10) | |
shortcut | cObject | cObject to render other elements. See config below which simply uses this object to render more tt_content elements as plaintext. | |
bodytext.stdWrap | ->stdWrap | stdWrap for body-text. See config example below. |
|
userProc | function-name | Lets you proces the output of each content element before it finally is returned. Property “parentObj” of the conf-array holds a references to the plainText object calling the function. |
[tsref:(script).plaintextLib]
Datatype 'untrimmed string' means that you can enter a string as usual, but if you enter a value between two vertical lines, that value will be used and NOT trimmed. Normally values are trimmed.
lib.renderObj = USER
lib.renderObj.userFunc = user_plaintext->main_plaintext
lib.renderObj {header.defaultType = 1
header.date = D-m-Y
header.datePrefix = |Date: |
header.linkPrefix = | - Headerlink: |
header.1.preLineLen = 76
header.1.postLineLen = 76
header.1.preBlanks=1
header.1.stdWrap.case = upper
header.2 < .header.1
header.2.preLineChar=*
header.2.postLineChar=*
header.3.preBlanks=2
header.3.postBlanks=1
header.3.stdWrap.case = upper
header.4 < .header.1
header.4.preLineChar= =
header.4.postLineChar= =
header.4.preLineBlanks= 1
header.4.postLineBlanks= 1
header.5.preBlanks=1
header.5.autonumber=1
header.5.prefix = |: >> |
siteUrl = {$plugin.alt.plaintext.siteUrl}defaultOutput (
|
[Unrendered Content Element; ###CType### ]
|
)
uploads.header = |DOWNLOADS:|
images.header = |IMAGES:|
images.linkPrefix = | - Imagelink: |
images.captionHeader = |CAPTION:|
bulletlist.0.bullet = |* |
bulletlist.1.bullet = |# |
bulletlist.2.bullet = | - |
bulletlist.3.bullet = |> |
bulletlist.3.secondRow = |. |
bulletlist.3.blanks = 1
menu = <tt_content.menu.20
shortcut = <tt_content.shortcut.20
shortcut.0.conf.tt_content = <lib.renderObj
shortcut.0.tables = tt_content
bodytext.stdWrap.parseFunc.tags {link < styles.content.parseFunc.tags.link
typolist = USER
typolist.userFunc = user_plaintext->typolist
typolist.siteUrl = {$plugin.alt.plaintext.siteUrl} typolist.bulletlist < temp.renderObj.bulletlist
typohead = USER
typohead.userFunc = user_plaintext->typohead
typohead.siteUrl = {$plugin.alt.plaintext.siteUrl}typohead.header < temp.renderObj.header
typocode = USER
typocode.userFunc = user_plaintext->typocode
typocode.siteUrl = {$plugin.alt.plaintext.siteUrl}}
}