.. You may want to use the usual include line. Uncomment and adjust the path. .. include:: ../Includes.txt ============ EXT: KB Shop ============ :Author: Kasper Skårhøj :Created: 2002-11-01T00:32:00 :Changed: 2009-09-02T11:33:40 :Author: Bernhard Kraft, Tomas Peterson :Email: kraftb@kraftb.at, info@thomas-peterson.de :Info 3: :Info 4: .. _EXT-KB-Shop: EXT: KB Shop ============ Extension Key: **kb\_shop** Copyright 2000-2002, Bernhard Kraft, Tomas Peterson, This document is published under the Open Content License available from http://www.opencontent.org/opl.shtml The content of this document is related to TYPO3 \- a GNU/GPL CMS/Framework available from www.typo3.com .. _Table-of-Contents: Table of Contents ----------------- **EXT: My Extension 1** **Introduction 1** What does it do? 1 Screenshots 1 **Users manual 1** FAQ 1 **Adminstration 1** FAQ 2 **Configuration 2** FAQ 2 Reference 2 **Tutorial 2** **Known problems 2** **To-Do list 2** **Changelog 2** .. _Introduction: Introduction ------------ .. _What-does-it-do: What does it do? ^^^^^^^^^^^^^^^^ This extension is a special kind of shop system which enables you to dynamically define the table structure of multiple tables similar like in the Extension kickstarter of TYPO3. This allows you to create a shopping system tailored perfectly to your needs. You create “Category” records which define the tables available in the system. Then you create property records like “Title” (Text field), “Description” (RTE field), etc. and assign those properties to the categories. The shop extension automatically creates an ext\_tables.sql, ext\_tables.php and tca.php file for the defined tables which makes them available like in TYPO3 like normal “News” or “Guestbook” tables. But this is not the only sense of this extension. It also offers a very configurable FE Plugin which enables you to output lists generated from those tables – the FE plugin is some kind of “general data display” extension – but only allowing you to display tables generated by this extension. You can dynamically define criterias by which the displayed records shall get filtered. You can either choose to display only records with a criteria set to a specific predefined value or you can decide to let the choice which records to display to the website visitor and display “Criteria selectors” in the FE. The FE plugin is completely extendable via TypoScript as all properties from the tables get passed through stdWrap and custom cObjects can get inserted into the FE Output which get's generated from HTML-Templates. You can not only insert the values of the fields which you created before but also the labels of the specific fields. The extension supports multilinugal content. The extension support a shopping basket by storing the user-data (ordered products, wishlist, etc.) in so called “virtual” tables. Those tables don't really get stored in the database but rather in the FE-User session of the visitor. There exists a mailer extension (kb\_shop\_mailer) which allows to send mails on successful ordering. This is achieved via a hook. When a virtual-table (an basket) get's stored to the database it becomse an “order” - upon such an event a hook get's called which can perform various tasks like performing payment or simply sending mails. .. _Screenshots: Screenshots ^^^^^^^^^^^ This screenshot shows a property which is assigned ot a root- category/table and a record of the resulting table when edited: |img-1| On the left you see how a property/field get's defined. On the right side you see how the generated field looks when editing a record having this field assigned. .. _New-features: New features ------------ Since 0.1.1 (2007-09-03) - Support for PHP 5.x, TYPO3 >= 4.1 required - Overlay tables (This feature allows to overlay the currently rendered record by another record of a shop or T3 defined table - IREE support: Containers/Sections in the backend now get rendered as IRRE fields instead of the old custom-coded container view (which was taken from the kb\_tca\_section extension) - A new type of field “Geographical location” can get added to categories/tables which allows to define a geographical location using the rggooglemaps extension (In a slightly modified version at: `http ://think-open.org/kraftb/index/T3X\_rggooglemap\_\_kb\_shop.t3x `_ , I stay in contact with the author to integrate the required hooks into the mainstream version) - New kb\_shop code-team member: “Thomas Peterson” aka. boonkerz (in #typo3)Web: `http://www.thomas-peterson.de `_ E-Mail: `info@thomas-peterson.de `_ - Newsgroup at: news.think-open.org - SVN repository at: `https://think-open.org/tosvn/kb\_shop/ `_ - add Hooks for Fields - add an noErros for linking direct to an form with selecting an value .. _Users-manual: Users manual ------------ To create or edit records in tables which are created by this extension just go to some page where you are allowed to create the specific records and just use the list module to create them as usual. When you create a record you intially have mostly no fields available an the record look like the following: SCREENSHOT You see a category select in which you can select the category the record should be set to. If your adminstrator has not configured a tree of categories to select you will only have one possible option. He can enable a setting which automatically selects this category when you create a new record so you can skip the task of selecting the only available entry. As soon as you select a category a pop-up window will ask you if you wish to reload the page – do so and you will get a new editing screen with Tabs on the top and more properties/fields available in them. The number and labels of the Tabs are totally dependen on the configuration your administrator set up and can be differenent from installation to installation. You can simply select the Tabs and edit the fields as you would do with normal pages. .. _Multilanguage: Multilanguage ^^^^^^^^^^^^^ If your adminstrator has enabled one of the tables / types of records to be multilanguage you can translate the page on which the original languages records are contained and then translate them. You translate a record by editing it and then selecting “Language (NEW)” from one of the select boxes at the top of the record editing screen. Please note that you must have translated the page before this box appears. .. _Installation: Installation ------------ To install the extension simply download it from the TYPO3 Extension Repository and install it via the Extension Manager. When you are installing the extension it requires to create the categories and properties tables and some relation tables and allows you to setup some configuration options. Some of the options MUST get set to a valid value (sysfolder-page in the pagetree) – some are only optional. Below is a list of the confguration options. Required options are: - **TCA mode** : Must get set currently. KB Shop is intended to also work with flexform storage instead of traditional TCA tables (real database tables) but this is currently not fully implemented. So always let this checkbox stay checked. - **Category Folders** : This must be set to a comma separated list of folders which contain properties. - **Property Folders** : This must be set at least to the UID of one single page which contains the properties. It is currently not possible to distribute properties amongst different Pages (altough they can be contained in subpages of the given folder – in this case add them AFTER the “Base Page” separated with comma) .. ### BEGIN~OF~TABLE ### .. _TCAmode: TCAmode ^^^^^^^ .. container:: table-row Configuration variable TCAmode Type boolean Description When this get's set (default) the extension operates in TCA mode. Which means all properties are generated as “real” fields in the tables and not only as XML field in a Flexform. Currently only the TCA mode works as the work on Flexform mode has been delayed. Flexforms are not that good for searching and ordering the records after their values cause you would have to extract the values to order after from the XML first. .. _dontCache: dontCache ^^^^^^^^^ .. container:: table-row Configuration variable dontCache Type boolean Description When this option get's set no caching of the generated TCA happens. When you have a large configuration this really slows down work and you should of no course ever set it in production environments as it really causes huge load to regenerate the TCA on each page request either in the BE or the FE. .. _categoryFolders: categoryFolders ^^^^^^^^^^^^^^^ .. container:: table-row Configuration variable categoryFolders Type comma-list Description This is a comma separated list of Page UIDs which can contain category records. Those UIDs are checked when generating all tables (Only all tables can get generated at once). .. _propertyFolders: propertyFolders ^^^^^^^^^^^^^^^ .. container:: table-row Configuration variable propertyFolders Type comma-list Description This is a comma separated list of UIDs of pages containing all available properties. The first page must be the “Base Page” for all properties. This page may have subpages which should get listed and get checked for properties under special circumstances but it is not possible to have two different “Base Pages” pages with different properties. .. _fieldPrefix: fieldPrefix ^^^^^^^^^^^ .. container:: table-row Configuration variable fieldPrefix Type string Description This get's used as prefix to all fields in the database. If you do not set it “kbs\_” get's used as field prefix for the fields defined by properties but you can simply insert a shortname for your current project for example. Please note that this value will be directly used in SQL. .. _configExtension: configExtension ^^^^^^^^^^^^^^^ .. container:: table-row Configuration variable configExtension Type string Description This is the extension key of an extension which act's as a container for the generated ext\_tables.php, ext\_tables.sql, and similar files. This is nice to have because when you update the main kb\_shop extension the current configuration will not get lost (altough it would get regenerated on the next site hit from the table/property configuration stored in DB). It is just easier to have those quite often chanign files out of the main shop-extension directory. The extenion itself doesn't need to contain anything. You can simply create a completely empty extension with the kickstarter and insert it's extension key here – a possible candiate for such an extension is the “nothing” extension – which also has a sense now. .. _listItems: listItems ^^^^^^^^^ .. container:: table-row Configuration variable listItems Type integer Description The number of elements/records which shall get shown in List mode. This is the value which get's used when multiple tables are shown in List view. .. _singleListItems: singleListItems ^^^^^^^^^^^^^^^ .. container:: table-row Configuration variable singleListItems Type integer Description The number of elements/records which shall get shown in List mode when only a single table is shown because you clicked on one of the Table- Field names or the Table-Title itself. .. ###### END~OF~TABLE ###### .. _Adminstration: Adminstration ------------- When you installed the extension you probably not have already created an folder for Categories and Properties. If this is the case do so now and go back to the Extension Manager and enter the UID of the created page(s) into the “Category Folders” and “Property Folders” fields. It is completely legal to have categories and properties in two different folders altough this wasn't tested heavily and it is more safe to put categories and properties into the same folder. .. _Creating-a-root-category-table: Creating a root-category/table ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When you have set up the extension fully go to the “Table Configuration Sysfolder” (called TCSF from now on) and create a new record of the type: “Product category”: |img-2| You will then see the record editing screen of the newly created category. **IMPORTANT** : When you create the categories you can create a tree- structure of categories. The “lowest level” of those categories will get created as separate tables. So when you created 3 base categories and in each of them 2 sub-categories you will finally have 3 tables more in your database. The 6 sub-categories will not get created as tables but all of the fields assigned to them will be available in their parent table. But only those fields selected for a category (or inherited from parent categories) will be visible when editing a record assigned to this category. This is achieved via the “types” field of TCA. When you create a category-record on the category-root-level you MUST fill in the fields Title and Alias. Title will be the name of the the table (it is a table because it's a root category) or the Category (or both) and Alias is just required for tables/categories on the root level. The alias will become the name of the table in the database. If you leave away the alias the table will get the uid of the category record as table-name (of course prefixed with some string). .. _The-category-record: The category record ^^^^^^^^^^^^^^^^^^^ A short listing of what the different fields of a category are for: .. ### BEGIN~OF~TABLE ### .. _Title: Title """"" .. container:: table-row Field Name Title Type string Description The title of the table and/or category created. .. _Alias: Alias """"" .. container:: table-row Field Name Alias Type string Description The name of the table in the databse. It will get prefixed with a shop specific prefix but you should define a suitable name for this table here. Only required when you create a root-category==table, for sub- categories it will not be required. .. _Virtual: Virtual """"""" .. container:: table-row Field Name Virtual Type **PALLETE FIELD** select Description This allows you to create “virtual” tables which just exist in the session variable of the clients browser. This is useful for the FE to create ordering forms. (See section: Ordering). You can either choose that a table shall be connected to the browser-session or the logged in FE-User. .. _Allow-Table-on-Pages: Allow Table on Pages """""""""""""""""""" .. container:: table-row Field Name Allow Table on Pages Type **PALLETE FIELD** boolean Description When this checkbox is set record for this table/root-category can get created on normal pages and not only in sys-folders .. _Label-property: Label property """""""""""""" .. container:: table-row Field Name Label property Type **PALLETE FIELD** database relation to shop properties Description Here you can select a property which shall get used as label for the records of this table. Sadly currenlty all properties get shown and not only those which are already selected to be part of the table. This can be very annoying as you can select a field to be the label which is not contained in the table. This cannot be fixed due to a bug in TYPO3's ###REC\_FIELD\_fielname### TCA construct. .. _Sorting-property: Sorting property """""""""""""""" .. container:: table-row Field Name Sorting property Type **PALLETE FIELD** database relation to shop properties Description This property allows you to select by which field the tables is ordered in the BE by default. The same problem as with the above label field occurs here (all properteis shown not only in “Properties” selected ones) .. _Sorting-direction: Sorting direction """"""""""""""""" .. container:: table-row Field Name Sorting direction Type **PALLETE FIELD** select box Description Allows you to select in which order the sorting get's performed. .. _Language: Language """""""" .. container:: table-row Field Name Language Type database relation to sys\_languages Description Shows the language of the current category record. Use the “translate” select-box at the top of the editing screen for translating a category/table. When a root-category/table is translated you will also be able to create translations for the records in the associated table. .. _Parent-category: Parent category """"""""""""""" .. container:: table-row Field Name Parent category Type database relatation to shop categories Description Here you can select the parent category for the actual category. If you select a category the current category will become the child of the selected category and will inherit all it's properties. Sub- categories will be made available in the category selector of each created “product”-record. .. _Image: Image """"" .. container:: table-row Field Name Image Type image field Description Here you can upload an image to each table/category which can get used in different places. .. _Icon: Icon """" .. container:: table-row Field Name Icon Type image field Description Here you can upload an icon (preferrably 18x16 px) which get's used as icon for the table. This is only visible when you didn't select a parent category – so the actual category is a root-category/table. .. _Description: Description """"""""""" .. container:: table-row Field Name Description Type RTE field Description Here you can write a description for each table/category which can get used in different places. .. _Properties: Properties """""""""" .. container:: table-row Field Name Properties Type database relation to shop properties Description Here you assign which properties each table should have. You can also assign properties to sub-categories then the table will also contain those fields but they will only get shown in the BE when a “product” record has this category set. .. ###### END~OF~TABLE ###### .. _Creating-properties: Creating properties ^^^^^^^^^^^^^^^^^^^ Now you can start to create your first properties. Go to the page you configured as “Base Page” for the properties (can be the same page where the categories are located) and create a record of type “Shop Property”. You get a form with some fields of which the Top two (Title, Alias) are **mandatory (REQUIRED)** . Altough alias is no real requirement it should always get filled. The same as with root-categories/tables the alias will become the fieldname of the fields/properties in the database. The fieldname will be prefixed with the prefix you defined in the Extension Manager Installation Configuration of the extension. Now a short list of what the different fields are for: .. ### BEGIN~OF~TABLE ### .. _Title: Title """"" .. container:: table-row Field Name Title Type string Description The title of the field/property. It will get used in the BE as label for the field. When you translate the property record this will be the only available field – letting you define the translated label for BE Users with the language translated to. .. _Alias: Alias """"" .. container:: table-row Field Name Alias Type string Description The alias of the field property will get used in conjunction with the field prefix you configured in the Extension Manager Configuration as the fieldname in the database. If you do not insert a value here the UID of the the property record will get used as field name which results in quite unreadable tables – which is also not nice for export. .. _Language: Language """""""" .. container:: table-row Field Name Language Type database relation to sys\_languages Description Shows the langauge of the current property. Use the “translator” select box at the top to translate the actual property. The page on which the properties reside must be translated for the “translator” box to be visible. .. _Parent-property: Parent property """"""""""""""" .. container:: table-row Field Name Parent property Type database relation to shop properties Description Some types of properties allow to have child-properties. If you have already created such properties (like select boxes or containers) you can select that the current property shall be a child of the selected property. (See explanation of special container types below) .. _Parent-property-value: Parent property value """"""""""""""""""""" .. container:: table-row Field Name Parent property value Type select box Description When you have selected that the current property shall be a child of a select-box property you can select which value the parent-property shall have so the current property is visible. (See explanation of special container types below) .. _Language-mode: Language mode """"""""""""" .. container:: table-row Field Name Language mode Type select box Description Selects how this field/property behaves when the record it is assigned to get's translated. The options are quite self explanatory. But here a short description: **Copy value** : The value from the default langauge get's copied over to the translated record. **Don't translate** : The field is not shown in the translated record. **Inherit if blank** : Nothing get's copied and when the field is empty in the translated record the value from the original record get's used. **Don't copy original contents** : The values from the language original are just not copied. **Prefix with Language Title** : The values from the language original are copied and prefixed with a “[Translate to .....]:” prefix. .. ###### END~OF~TABLE ###### A fully configured RTE field/property looks for example like: |img-3| You can play around a little bit with the different kind of properties but you will soon start to ask yourself what the special property “Container” is and why you can select a parent property. If you want to have a quick start and not get confused at the beginning skip the follwing the follwing two sections. .. _Special-property-type-Container: Special property type: Container """""""""""""""""""""""""""""""" A container is something you probably already know from TemplaVoila FlexForms or from the extension kb\_tca\_section. A section is an area in the record editing screen which can hold an arbitrary amount of “subsets” which each has fields again. A picture is more than thousand words so here is a picture of a section/container field as it get's rendered in the BE: .. _img-4: |img-4| ^^^^^^^ You possibly know that you can add additonal “Zuordnung Segment” entries with the selectbox at the top. Each of those section-elements is again a table in the database which has the shown fields and a relation back to the record they are contained in. So if you want to create such a section in one your tables/root- categories then just create a “Container” property and then assign this Container property as Parent property to all properties which shall be contained in the section. **UPDATE** : Since T3 4.1 supports “Inline relational record editing” (IRRE) - which is exactly the same as containers/sections the extension has been updated to generate IRRE-fields instead of old fashioned containers like in the picture above. So the above screenshot is outdated. .. _Special-property-type-DB-REL: Special property type: DB-REL """"""""""""""""""""""""""""" When you click on relLang you have in your Select boxes only one Lang not all. .. _Special-property-type-Select-Box: Special property type: Select-Box """"""""""""""""""""""""""""""""" When you create a select-box it also counts as property which can get selected as “Parent property”. As soon as you select a Select-Box in the Parent-property field you will get an additonal field called “Parent property value” in the record editin screen of the property. The current property will now only get shown in the BE when you have set the select-box you assigned as parent to the value selected in the “Parent property value” field. This may be a bit of confusing at the beginning but I will shed some light on it. It behaves similar like the “type” field of tt\_content. Depending on which type of content element you have selected when editing a content element you have different fields available. Now when you have created such a parent/child structre with select boxes for one shop-table then the child-fields will only be visilble when the parent (the select box) got set to a specific value. This enables you to create very complex BE forms. For example if you have a book shop and you made a select box which allows you to choose what kind of “book” you have (i.e. “Magazine, Technical reference, Child book”) then the input field “Release cycle” wil only get shown when you selected “Magazine” in the select box (as technical references and children books do not have a release cycle – magazines do). .. _Connecting-Categories-and-Properties: Connecting Categories and Properties ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When you have succesfully created a root-category and some properties the only thing left to do is to go to the category record again and select all properties this table/root-category should have in the “Properties” select box at the bottom and to select the Sortin and Label property. When you have done this delete the Shop-Cache using the Tools>Shop module. Select “Cache” in the select box on the top right and press the button “Clear cache” once. When you now visit a page in the List module and choose to create a record you should see your newly created table available. If this is not the case you most probably didn't check the “Allow Table on Pages” checkbox in the category record and tried to create the record on a different page than a sys-folder. When you have created your first record you may suddenly be disappointed because your fields do not show up but only the category selector. This is currently normal. Even if you do only have one category you still have to select it explicitly. You can enable that a specific category shall be set as default by setting the User TSConfig option: :: TCAdefaults.tx_kbshop_tbl_yournamehere { category = 3 } Of course replace “yourtablename” with the alias you gave the table and “3” with the uid of the category which you would like to select as default. .. _Tabs-in-the-Editing-screen: Tabs in the Editing screen ^^^^^^^^^^^^^^^^^^^^^^^^^^ You will soon notice that the properties you create are in a Tab (similar like the Tabs from Flexforms) called "Basic" and may ask yourself how you can create additonal Tabs. This is easy: Just create a subpage in the page where your properties are located (only one level deep allowed) and give the page a title which shall be shown as Tab-Title. You have to enter this page into the “propertyFolder” Installation Configuration which you set when installing the extension. You have to add it to the end of list cause at the top always the main property folder has to get listed. Now just move over some properties to the new page and hit the clear- shop-cache button in the KB-Shop BE module. After those steps the properties move should show up in a new Tab. When you are using section/container fields the section will show up in the Tab where the container property is located even if the sub- properties of the container are located on a different page. .. _The-FE-Plugin: The FE Plugin ^^^^^^^^^^^^^ Now you can start to insert some testing records on a page and you will surely soon want to see some output in the FE. To begin this just go to the page where you want to show a listing of those records and create a content element of type “Plugin: Shop (cached)” there. When you created the FE plugin the first step you should take is to choose the table you want to display from the field **“Displayed Table”** after chaning it the forms updates itself. You can then go through all the available options and set it to your needs. Below is a short table of what each field is for. .. ### BEGIN~OF~TABLE ### .. _Product-Folders: Product Folders """"""""""""""" .. container:: table-row Field name Product Folders Type database relation to pages Description Here you select all pages from which you want to show records of the selected table. .. _Product-Folders-recursive: Product Folders recursive """"""""""""""""""""""""" .. container:: table-row Field name Product Folders recursive Type select box Description Here you can choose if you wish to collect also the records on the subpages of the page specified in “Product Folders” .. _Template-File: Template File """"""""""""" .. container:: table-row Field name Template File Type string Description Here you can give the path to a template file to use. .. _Displayed-Table: Displayed Table """"""""""""""" .. container:: table-row Field name Displayed Table Type database relation to (root-) categories Description Here you have the choice to select from all created tables the one which you want to display using this plugin. .. _Disable-single-view: Disable single-view """"""""""""""""""" .. container:: table-row Field name Disable single-view Type checkbox Description When checked the singleView link doesn't get generated when in listView .. _Disable-list-view: Disable list-view """"""""""""""""" .. container:: table-row Field name Disable list-view Type checkbox Description When checked the listView link doesn't get generated when in singleView .. _Items-per-page: Items per page """""""""""""" .. container:: table-row Field name Items per page Type integer Description Defines how many items get listed per page .. _Show-page-browser: Show page browser """"""""""""""""" .. container:: table-row Field name Show page browser Type boolen Description When checked and there are more items for the current query than elements per page a pagebrowser gets shown .. _Pages-in-browser: Pages in browser """""""""""""""" .. container:: table-row Field name Pages in browser Type integer Description Define how many pages get shown in the pagebrowser .. _Show-first-and-last-link: Show first and last link """""""""""""""""""""""" .. container:: table-row Field name Show first and last link Type boolean Description When set a link to the first and last page get generated in the pagebrowser. .. _Show-previous-and-next-link: Show previous and next link """"""""""""""""""""""""""" .. container:: table-row Field name Show previous and next link Type boolean Description When set a link to the previous and next page get generated in the pagebrowser .. _Show-criteria-selector: Show criteria selector """""""""""""""""""""" .. container:: table-row Field name Show criteria selector Type boolean Description When set and user-definable criterias are also set a criteria selector gets shown in the FE which a visitor can use to define criterias after which he wants to filter the displayed records .. _Criterias: Criterias """"""""" .. container:: table-row Field name Criterias Type SECTION Description See following table “Criterias” .. _Submit-Target-OK: Submit Target OK """""""""""""""" .. container:: table-row Field name Submit Target OK Type database relation to pages Description Here you can select a page to which the user shall get redirected when all fields of the current forms have been filled properly. This is used for Ordering forms. .. _Form-table: Form table """""""""" .. container:: table-row Field name Form table Type SECTION Description See the following table “Form tables” .. _Search-page: Search page """"""""""" .. container:: table-row Field name Search page Type databse relation to pages Description Here you can set a page to which full-text search request get posted. Different to the criterias full-text searches (searches after a specific word) can not get cached. For this reason you have to direct serach-request to a special page where an uncached version of the plugin is inserted. NOT IMPLEMENTED CURRENTLY .. ###### END~OF~TABLE ###### .. _Criterias: Criterias """"""""" You can easily define which records shall get shown by defining criterias in the listing plugin. More or less you build up the WHERE part of the query which selects the records from the databse. To define criterias you should already have used Flexform Sections once else it will be a little bit confusing for you I guess. To create a criteria go to the “Criteria” tab in the FE plugin and choose “NEW Criteria Item” from the select-box. When you selected it at the first moment nothing will happen – you have to save the record first using the normal “Save” button at the top and end of the record editing scren. After saving the “NEW Criteria Item” selection a new criteria item will show up in the form. Such an item looks mostly like in the follwing picture: |img-5| The topmost field in the criteria item is named “Field”. Here you can select which field of the table shall get compared to another value. All other options are explained in the table below: .. ### BEGIN~OF~TABLE ### .. _Field: Field ~~~~~ .. container:: table-row Field name Field Type select box Description Here you can select from all fields the current table has. The selected field will get compared in the WHERE query which selects the items to display in the FE .. _User-selectable: User selectable ~~~~~~~~~~~~~~~ .. container:: table-row Field name User selectable Type checkbox Description If you check this option all other options will disappear and the visitor of the website can choose which value the field selected in “Field” shall have. (See: Criteria selector) .. _Compare-string-integer-etc: Compare string/integer/etc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. container:: table-row Field name Compare string/integer/etc. Type different Description Using the “Compare” field you can select “how” the value of the field is compared to the specified value. .. _Value: Value ~~~~~ .. container:: table-row Field name Value Type different Description Here you can either input (if you mad a Text/Integer criteria) or select (if you made a db-relation criteria) the value to which to compare against. .. _Negate-compare-results: Negate compare results ~~~~~~~~~~~~~~~~~~~~~~ .. container:: table-row Field name Negate compare results Type boolean Description When set the result of the comparison will get negated – this is especially useful for database relation fields to select that specific values should not occur. .. ###### END~OF~TABLE ###### .. _Form-tables: Form tables """"""""""" The KB-Shop extension also supports Ordering Forms for letting website visitors order your products. Currently no billing mechanism is implemented for letting the visitors directly pay in your online-shop but only mails can get sent and orders can (must?) get stored in the database. This requires additonal work from you for each order – to process it manually. The concept of KB-Shop Ordering Forms is genius if you think some time about it: In TYPO3 there already exists a “huge” and very powerful forms library for generating fields out of database descriptions (TCA arrays): t3lib\_tceforms. This library is normally used for rendering the record-editing screens in the BE for all different kinds records (records of all tables). Now kb-shop simply utliilzes those form rendering libraries but instead of storing each record in the database it first is simply stored in the user-session of the clients browser which most shopping- cart systems do. This concept is called "virtual" tables. When a user has finished his ordering process this “virtual” record gets transferred to a real database table and via additonal hooks also mails can get sent to specific addresses (where people process the order then). The sending of mails and all extra data handling of orders (except storing them in the database) is not part of KB-Shop but will get implemented by add-on extensions which hook into KB-Shop. You have to create an ordering form table which contains fields like firstname,lastname,address,zip,city for letting the user input his delivery and contact data and in this root-category/table you should have a section where each element contains at least one field: "ordered product" and most probably a second field "ordering amount" which specified how many items of a product have been ordered. This way (the ordered items themselves are section elements) you get a nice display for orders in the backend. Here a listing of all fields available for a “Form table” section element: .. ### BEGIN~OF~TABLE ### .. _Form-name: Form name ~~~~~~~~~ .. container:: table-row Field name Form name Type string Description The name of this form. (Not used currently?) .. _Form-table: Form table ~~~~~~~~~~ .. container:: table-row Field name Form table Type database relation to “virtual” root-categories Description Here you can select the “virtual” table which gets used to store the data in the user session. This table defines which fields are available in the ordering process (Firstnam, Lastname, etc.) .. _Save-table: Save table ~~~~~~~~~~ .. container:: table-row Field name Save table Type database relation to “non-virtual” root-categories Description Using this field you define to which table the virtual table shall get saved when finishing the order process. .. _Transfer-TS: Transfer TS ~~~~~~~~~~~ .. container:: table-row Field name Transfer TS Type text Description Here you can define TypoScript which “translates” the virtual-table values to values acceptable for the real tables. The syntax is explained in the section “Ordering system” .. ###### END~OF~TABLE ###### See section **“Ordering system”** for more details on ordering. .. _The-FE-Plugin-HTML-templates: The FE-Plugin HTML templates ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Of course for the first test we must not miss an working HTML template. As all fields of kb\_shop tables are completely dynmically defined you can hardly give an “default” template. So in the res/ folder of the extensions directory only a template is included which shows some basic things you can do within the HTML template. First of all there are 2 main parts in a template: :: and :: You can easily create custom views by defining a template key in your TS-Setup. Then the main part will be called: :: or TMPL\_singleView\_YOURKEY respectively (see TS option: plugin.tx\_kbshop\_pi1.subpart.listView / singleView) In such a “main part” there are five different possible kind of subparts: :: PART\_criteriaSelector contains the criteria selector. PART\_listign contains the actual listing of records, PART\_pageBrowser the pagebrowser and PART\_listingEmpty gets shown instead of PART\_listing when no elements are found for the currently defined criteria. Following is a short reference for all markers allowed in the template. SingleView is completely similar to listView except that only one item is rendered. Whenever a token like “++fieldname++” or “++cobjname++” occurs you have to replace this token by a valid fieldname not including the prefix set in the install tool (so just the alias or UID of the property). In case of a cObject ++cobjname++ has to get replaced with the TS key of the cObject. So if you define for example graphicalTitle = IMAGE then the marker would be “###COBJ\_ITEM\_graphicalTitle###. .. ### BEGIN~OF~TABLE ### .. _Name-without: Name (without ###) """""""""""""""""" .. container:: table-row Name (without ###) Name (without ###) Type Type Valid in (Level)(without ###) Valid in (Level) (without ###) Description Description .. _TMPL-listView: TMPL\_listView """""""""""""" .. container:: table-row Name (without ###) TMPL\_listView Type main-subpart Valid in (Level)(without ###) file top level (1) Description When you show a listing of records the listView main-subpart of the template file will get used. .. _TMPL-singleView: TMPL\_singleView """""""""""""""" .. container:: table-row Name (without ###) TMPL\_singleView Type main-subpart Valid in (Level)(without ###) file top level (1) Description When you show a single record the singleView main-subpart of the template file will get used. .. _TMPL-listView-customkey: TMPL\_listView\_++customkey++ """"""""""""""""""""""""""""" .. container:: table-row Name (without ###) TMPL\_listView\_++customkey++ Type main-subpart Valid in (Level)(without ###) file top level (1) Description When you show a listing of records and you have defined that a special main-subpart shoould get used using the **subpart.listView** TS configuration variable then this main-subpart of the template file will get used. .. _TMPL-singleView-customkey: TMPL\_singleView\_++customkey++ """"""""""""""""""""""""""""""" .. container:: table-row Name (without ###) TMPL\_singleView\_++customkey++ Type main-subpart Valid in (Level)(without ###) file top level (1) Description When you show a single record and you have defined that a special main-subpart shoould get used using the **subpart.singleView** TS configuration variable then this main-subpart of the template file will get used. .. _ITEMS-found: ITEMS\_found """""""""""" .. container:: table-row Name (without ###) ITEMS\_found Type marker Valid in (Level)(without ###) Anywhere Description The number of found items. .. _ITEMS-index-begin: ITEMS\_index\_begin """"""""""""""""""" .. container:: table-row Name (without ###) ITEMS\_index\_begin Type marker Valid in (Level)(without ###) Anywhere Description The index of the first element shown on the current page (changes when browsing through the pages using the page browser) .. _ITEMS-index-end: ITEMS\_index\_end """"""""""""""""" .. container:: table-row Name (without ###) ITEMS\_index\_end Type marker Valid in (Level)(without ###) Anywhere Description The index of the last element shown on the current page (changes when browsing through the pages using the page browser) .. _COBJ-LISTING-cobjname: COBJ\_LISTING\_++cobjname++ """"""""""""""""""""""""""" .. container:: table-row Name (without ###) COBJ\_LISTING\_++cobjname++ Type marker Valid in (Level)(without ###) Anywhere Description This marker gets replaced by cObject specified by ++cobjname++. You have to set the TS objects in your TS setup like: :: plugin.tx_kbshop_pi1.listView.cObjects.myCObject = TEXT you must of course replace **listView** by **singleView** when you are inserting the cObject in the singleView. ++cobjname++ would be **myCObject** in this case. .. _LINK-listView-HREF-linknum: LINK\_listView\_HREF\_++linknum++ """"""""""""""""""""""""""""""""" .. container:: table-row Name (without ###) LINK\_listView\_HREF\_++linknum++ Type marker Valid in (Level)(without ###) Anywhere Description This marker contains a link to the listView which can be configured via TS. The special about this link markers is that while they get generated by the ->typoLink method the values: **linkViewUid** - item to show **linkPageNumber** - page to show are available in the registers of TSFE. which means you can access those values using a :: .data = register:linkPageNumber construct.. ++linknum++ is the number you used in the TS setup to define the link. .. _LINK-singleView-HREF-linknum: LINK\_singleView\_HREF\_++linknum++ """"""""""""""""""""""""""""""""""" .. container:: table-row Name (without ###) LINK\_singleView\_HREF\_++linknum++ Type marker Valid in (Level)(without ###) Anywhere Description The same as for the above listView link except that this link links to a detail view (specified by the value in the register **linkViewUid** ) .. _PART-criteriaSelector: PART\_criteriaSelector """""""""""""""""""""" .. container:: table-row Name (without ###) PART\_criteriaSelector Type subpart Valid in (Level)(without ###) TMPL\_\* (2) Description This subpart contains the criteria selector which allows a website visitor to select criterias for filtering the listing on his own. Normalls this selectors get rendered as checkboxes but you can easily render them as text links or in other forms. .. _PART-criteriaSelectorEmpty: PART\_criteriaSelectorEmpty """"""""""""""""""""""""""" .. container:: table-row Name (without ###) PART\_criteriaSelectorEmpty Type subpart Valid in (Level)(without ###) TMPL\_\* (2) Description When no criteria selector shall get shown then the contents of this subpart get shown instead. This subpart allows no other subparts or markers inside. .. _PART-pageBrowser: PART\_pageBrowser """"""""""""""""" .. container:: table-row Name (without ###) PART\_pageBrowser Type subpart Valid in (Level)(without ###) TMPL\_\* (2) Description This subpart contains a page browser which allows to browse between different pages of the listing when the current number of records (depending on the set criterias) don't fit onto one page (set in the FE-Plugin using: **Items per page** ) .. _PART-pageBrowserEmpty: PART\_pageBrowserEmpty """""""""""""""""""""" .. container:: table-row Name (without ###) PART\_pageBrowserEmpty Type subpart Valid in (Level)(without ###) TMPL\_\* (2) Description When no page browser has to get rendered (because it is deactivated in the FE plugin or there are less records than shall get shown on a page) this subpart will get rendered instead of PART\_pageBrowser. This subpart allows no other subparts or markers inside. .. _PART-listing: PART\_listing """"""""""""" .. container:: table-row Name (without ###) PART\_listing Type subpart Valid in (Level)(without ###) TMPL\_\* (2) Description This subpart contains the list of records. Even in single view the single record is contained in this subpart. .. _PART-listingEmpty: PART\_listingEmpty """""""""""""""""" .. container:: table-row Name (without ###) PART\_listingEmpty Type subpart Valid in (Level)(without ###) TMPL\_\* (2) Description When no records are available for the currently selected criterias (or there are none at all) then this subpart will get shown. This subpart allows no other subparts or markers inside. .. _CriteriaItem: CriteriaItem """""""""""" .. container:: table-row Name (without ###) CriteriaItem Type subpart Valid in (Level)(without ###) PART\_criteriaSelector (3) Description This subpart contains a single criteria selector item. Currently there are two options to render a criteria item. As a select box or text links (using this subpart) or as a checkbox (for 0/1 properties). Also lists of checkboxes (up to 10) are possible. This subpart will get repeated and concatenated for each criteria item a user can select from. Meaning for each select-box. .. _CriteriaItemCheckbox: CriteriaItemCheckbox """""""""""""""""""" .. container:: table-row Name (without ###) CriteriaItemCheckbox Type subpart Valid in (Level)(without ###) PART\_criteriaSelector (3) Description This subpart contains the code for a checkbox criteria selector item. .. _TITLE: TITLE """"" .. container:: table-row Name (without ###) TITLE Type marker Valid in (Level)(without ###) CriteriaItem CriteriaItemCheckbox (4) Description The title for the current select-box or checkbox. .. _ELEMENT-NAME: ELEMENT\_NAME """"""""""""" .. container:: table-row Name (without ###) ELEMENT\_NAME Type marker Valid in (Level)(without ###) CriteriaItem (4) Description This marker contains the tag name attribute value for the single checkboxes. Also in the case of just a single selectbox the name will be on this level. The same logic as with listView/singleView is used. A single checkbox is just a list of checkboxes with just one entry :) .. _CHECKED: CHECKED """"""" .. container:: table-row Name (without ###) CHECKED Type marker Valid in (Level)(without ###) CriteriaSelectorCheckbox (5) Description This marker contains normally nothing but when the current checkbox is selected for filtering it will by default contain the string: :: checked=”checked” But you can change what the content should be using the TS option: :: plugin.tx_kbshop_pi1.listView.criteriaSelector.checkedValue .. _ITEM-count: ITEM\_count """"""""""" .. container:: table-row Name (without ###) ITEM\_count Type marker Valid in (Level)(without ###) PART\_pageBrowser (3) Description Contains the number of records for the currently selected criterias (or for all available records if no criterias are set) .. _ITEM-equalWidth: ITEM\_equalWidth """""""""""""""" .. container:: table-row Name (without ###) ITEM\_equalWidth Type marker Valid in (Level)(without ###) PART\_pageBrowser (3) Description Contains 100 divided by the above value. It can get used to divide the pageBrowser into html elements of equals width depending on the number of currently shown records. .. _BROWSE-itemFirst: BROWSE\_itemFirst """"""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemFirst Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description This subpart contains markers for the “First page” link in the page browser. .. _BROWSE-itemFirstEmpty: BROWSE\_itemFirstEmpty """""""""""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemFirstEmpty Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. .. _BROWSE-itemPrevious: BROWSE\_itemPrevious """""""""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemPrevious Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description This subpart contains markers for the “Previous page” link in the page browser. .. _BROWSE-itemPreviousEmpty: BROWSE\_itemPreviousEmpty """"""""""""""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemPreviousEmpty Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. .. _BROWSE-itemList: BROWSE\_itemList """""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemList Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description This subpart contains another subpart which forms the list of pages in the page browser. This subpart gets repeated and concatenated for each single page. .. _BROWSE-itemListEmpty: BROWSE\_itemListEmpty """"""""""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemListEmpty Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. .. _BROWSE-itemNext: BROWSE\_itemNext """""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemNext Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description This subpart contains markers for the “Next page” lllink in the page browser. .. _BROWSE-itemNextEmpty: BROWSE\_itemNextEmpty """"""""""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemNextEmpty Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. .. _BROWSE-itemLast: BROWSE\_itemLast """""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemLast Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description This subpart contains markers for the “Last page” link in the page browser. .. _BROWSE-itemLastEmpty: BROWSE\_itemLastEmpty """"""""""""""""""""" .. container:: table-row Name (without ###) BROWSE\_itemLastEmpty Type subpart Valid in (Level)(without ###) PART\_pageBrowser (3) Description The contents of this subpart will get shown when the respective subpart (name without Empty) shall not get shown or is not available (i.e. first link will not be available when you are on the first page). This subpart does not contain any further subparts or markers. .. _LINK-HREF: LINK\_HREF """""""""" .. container:: table-row Name (without ###) LINK\_HREF Type marker Valid in (Level)(without ###) BROWSE\_\* (4) Description This marker contains a link (only the href attribute) to the respective page (depending on the subpart the marker is found in). .. _LINK-SELECTED: LINK\_SELECTED """""""""""""" .. container:: table-row Name (without ###) LINK\_SELECTED Type marker Valid in (Level)(without ###) BROWSE\_\* (4) Description This marker containts the contents of the LL label **text\_browser\_selected** when the currently rendered page is the active/selected/displayed one (makes only sense inside **BROWSE\_itemList** ) .. _LABEL-first: LABEL\_first """""""""""" .. container:: table-row Name (without ###) LABEL\_first Type marker Valid in (Level)(without ###) BROWSE\_\* (4) Description Contains the LL label **label\_browser\_first** .. _LABEL-previous: LABEL\_previous """"""""""""""" .. container:: table-row Name (without ###) LABEL\_previous Type marker Valid in (Level)(without ###) BROWSE\_\* (4) Description Contains the LL label **label\_browser\_previous** .. _LABEL-next: LABEL\_next """"""""""" .. container:: table-row Name (without ###) LABEL\_next Type marker Valid in (Level)(without ###) BROWSE\_\* (4) Description Contains the LL label **label\_browser\_next** .. _LABEL-last: LABEL\_last """"""""""" .. container:: table-row Name (without ###) LABEL\_last Type marker Valid in (Level)(without ###) BROWSE\_\* (4) Description Contains the LL label **label\_browser\_last** .. _LABEL-item: LABEL\_item """"""""""" .. container:: table-row Name (without ###) LABEL\_item Type marker Valid in (Level)(without ###) BROWSE\_\* (4) Description This marker contains the label for the currently rendered page. It will contain the contents of the LL label **label\_browser\_page** in which the marker ###PAGE### is substituted with the number of the current page. If the page is the current page also the marker ###MARKER\_BEGIN### and ###MARKER\_END### are substituted with a tag (on pages other than the current those markers are substituted with an empty string) .. _Subparts-of-PART-listing-or-PART-sectionnanme: Subparts of ###PART\_listing### or ##PART\_++sectionnanme++### """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" .. container:: table-row Name (without ###) Subparts of ###PART\_listing### or ##PART\_++sectionnanme++### (2,4,6,8, ...) .. _LIST-item: LIST\_item """""""""" .. container:: table-row Name (without ###) LIST\_item Type subpart Valid in (Level)(without ###) PART\_listing (3) Description This subpart gets repeated for each record found for the currently setted criterias. In the case of singleView it will get repeated only once. .. _LIST-sectionname: LIST\_++sectionname++ """"""""""""""""""""" .. container:: table-row Name (without ###) LIST\_++sectionname++ Type subpart Valid in (Level)(without ###) PART\_++sectionname++ (5, 6, 8, 10, ...) Description This subpart gets repeated for each section record found for the currently rendered record (or secton record in case of recursion). Multiple LIST\_++sectionname++ subparts also get's created when you define an overlay. .. _FIELD-SUBPART-fieldname: FIELD\_SUBPART\_++fieldname++ """"""""""""""""""""""""""""" .. container:: table-row Name (without ###) FIELD\_SUBPART\_++fieldname++ Type subpart Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10, ...) Description The contents of this marker will get kept if the field which is specified in the subpart does contain a value which evaluates to true. When the current field contains a value which evaluates to false thie contents of this subpart get removed. The markers in this section (on level 4) also can get used in this subpart so they would be on level 5 in fact. This also applies to the below subpart. .. _FIELD-SUBPART-fieldname-Empty: FIELD\_SUBPART\_++fieldname++Empty """""""""""""""""""""""""""""""""" .. container:: table-row Name (without ###) FIELD\_SUBPART\_++fieldname++Empty Type subpart Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10, ....) Description The opposite of the above subpart. .. _FIELD-RAWVALUE-fieldname: FIELD\_RAWVALUE\_++fieldname++ """""""""""""""""""""""""""""" .. container:: table-row Name (without ###) FIELD\_RAWVALUE\_++fieldname++ Type marker Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10, ...) Description This marker contains the raw database value of the specified field. .. _FIELD-VALUE-fieldname: FIELD\_VALUE\_++fieldname++ """"""""""""""""""""""""""" .. container:: table-row Name (without ###) FIELD\_VALUE\_++fieldname++ FIELD\_VALUE\_++sectionname++\_++fieldname++ Type marker Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10, ...) Description This marker contains the value of the specified field after some basic processing (RTE fields are passed through lib.parseFunc\_RTE and database relations are resolved to the titles of the records they point to.) The value of this field can also get set using stdWrap using a TS like the below. The ->data array of the cObj which is rendering the stdWrap is filled with the values for the current row. Meaning you can access them via .field = fieldname (where fieldname is an alias you set for a property). plugin.tx\_kbshop\_pi1.listView.itemList.fields.myFieldName.stripHtml = 1 of course you have to replace **listView** with **singleView** if you want to stdWrap the field in singleView. myFieldName has to get replaced with the value you also use for ++fieldname++ (the alias of the property/field). stripHtml is just an example for some stdWrap property. The fields of a container record get automatically filled into the marker with the ++sectionname++ included. This helps to distingush between fields of the main-table and containers (or overlayed tables) .. _PART-sectionname: PART\_++sectionname++ """"""""""""""""""""" .. container:: table-row Name (without ###) PART\_++sectionname++ Type subpart Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10) Description This subpart will contain the elements for a section/container field in a record. The contents of this subpart can be the same as those of a PART\_listing subpart except that they render a section-element. As they are themselves contained in PART\_listing (exactly in the LIST\_item element of a PART\_listing subpart) this nesting is recursive. Except that not a **LIST\_item** subpar is repeated inside this element but rather a **LIST\_++sectionname++** subpart. A PART\_++sectionname++ subpart also get's created when you define an overlay. .. _PART-sectionname-Empty: PART\_++sectionname++Empty """""""""""""""""""""""""" .. container:: table-row Name (without ###) PART\_++sectionname++Empty Type subpart Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10, ...) Description When a section field is empty (i.e: has no section elements) this subpart will get rendered instead and the above will get removed .. _COBJ-ITEM-cobjname: COBJ\_ITEM\_++cobjname++ """""""""""""""""""""""" .. container:: table-row Name (without ###) COBJ\_ITEM\_++cobjname++ Type marker Valid in (Level)(without ###) LIST\_item (4) Description This marker will get replaced with a cObject which get's rendered individually for reach record displayed. Thus it is possible to do a lot of nice things with values like generate GIFBUILDER images out of uploaded files (i.e: watermarks). You have to set the cObjects for the item like in the following TS: plugin.tx\_kbshop\_pi1.listView.itemList.cObjects.myCObjName = IMAGE Again you have to replace **listView** with **singleView** when you want to have the cObject available in the TMPL\_singleView main template. myCObjName has to get replaced with the same value you used for ++cobjname++. .. _COBJ-SECTIONNAME-cobjname: COBJ\_++SECTIONNAME++\_++cobjname++ """"""""""""""""""""""""""""""""""" .. container:: table-row Name (without ###) COBJ\_++SECTIONNAME++\_++cobjname++ Type marker Valid in (Level)(without ###) LIST\_++sectionname++ (6, 8, 10, ....) Description This marker will get replaced with a cObject generated for each record of a section field individually. This means you can create cObjects dependend on the values of a section-element. You set a TS object like in the following TS: plugin.tx\_kbshop\_pi1.listView.itemList.++sectionname++.cObjects.myCO bjName = RECORDS Again you will have to replace listView with singleView when you want to render the cObject for singleView. ++sectionname++ has to get replaced with the name of the section (the alias of the container field). myCObjName should be the same label which you used for ++cobjname++. Note that in the marker the sectionname must be uppercase. .. _ITEM-even: ITEM\_even """""""""" .. container:: table-row Name (without ###) ITEM\_even ++SECTIONNAME++\_even Type marker Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10, ...) Description Contains 1 when the current item is an even one. Contains 0 it it is uneven. When used for a section (wheter the section element is an even or uneven one) then the section name must be written in uppercase. .. _ITEM-uneven: ITEM\_uneven """""""""""" .. container:: table-row Name (without ###) ITEM\_uneven ++SECTIONNAME++\_uneven Type marker Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10, ...) Description Contains 1 when the current item is an uneven one. Contains 0 it it is even. When used for a section (wheter the section element is an even or uneven one) then the section name must be written in uppercase. .. _ITEM-index0: ITEM\_index0 """""""""""" .. container:: table-row Name (without ###) ITEM\_index0 ##SECTIONNAME++\_index0 Type marker Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10, ...) Description Will contain the index of the element actually rendered counted starting from 0 for the first element. .. _ITEM-index1: ITEM\_index1 """""""""""" .. container:: table-row Name (without ###) ITEM\_index1 ##SECTIONNAME++\_index1 Type marker Valid in (Level)(without ###) LIST\_item LIST\_++sectionname++ (4, 6, 8, 10, ...) Description Will contain the index of the element actually rendered counted starting from 1 for the first element. .. ###### END~OF~TABLE ###### .. _Criteria-selector: Criteria selector """"""""""""""""" When you have configured some fields in the “Criteria” Tab of the FE plugin as “User selectable” then there will be a criteria selector available. The criteria selector subpart will not get replaced by an empty string then. The PART\_criteriaSelector main subpart has to contain one subpart “” which will get repeated multiple times – once for each criteria item created in the FE plugin and set to “User selectable”. Each of those ###CriteriaItem### subparts may contain a marker “###TITLE###” which defines the title for the current criteria (the label of the field). Such a subpart also contains sub-subparts named “###CriteriaSelectorOption###”. Inside those subparts the markers “###LINK\_HREF###”, “###SELECTED###” and “###LABEL###” will get replaced by a link pointin to a page with the criteria set to a specific value. The ###SELECTED### marker will contain “selected=”selected”” when this option is currently selected. ###LABEL### will contain the values to choose from. In the default template the criteria selector is rendered as selector box – but it is easy to create a list of links instead. But this I leave to your cleverness. .. _Page-browser: Page browser """""""""""" The structure of the page-browser should be quite clear by the example template coming with the extension. It is of course possible to define other labels for each Page and for Next/Prev/First/Last via TS. See main-section “Configuration” .. _Listing: Listing """"""" ###PART\_listing### is the most importan subpart of all because it contains the real listing of elements. The structure for singleView and listView is **COMPLETELY THE SAME** . The reason for this is that “singleView” is implemented very clever as listView which only shows one uid (have a look at class.tx\_kbshop\_pi1.php method “singleView :) ) The subpart ###PART\_listing### may only contain one other subpart ###LIST\_item### which gets repeated for each displayed record. This subpart ###LIST\_items### may now contain markers for all fields used in a table and also their labels. The markers which can get used in ###LIST\_items### are the following. ++fieldname++ must get replaced by the “alias” set for each property. If you do not have set an alias you would have to enter the UID of the property instead for ++fieldname++ (you see now why it would have been a clever idea to enter aliases :) - ###LABEL\_++fieldname++### : Contains the name of the specified field as set in the property. When another language than the default is displayed of course also the alternate labels get displayed. This eases translation a lot as you don't have to have two different HTML templates if you don not have any extra text in your templates. - ###FIELD\_RAWVALUE\_++fieldname++### : This marker contain the “raw” database value of the specified field. - ###FIELD\_VALUE\_++fieldname++### : This marker contains the value after a “little bit” of processing. RTE fields are passed trough “lib.parseFunc\_RTE” for example and database relations are resolved to the title of the records they point to (so you do not only see UID's).The contents for this marker can also get passed through stdWrap so mostly all transformations should be achievable. When stdWrap properties are defined for this value the “normal” transformations which the shop is performing (lib.parseFunc\_RTE, db- rel labels) get not applied (meaing: if you define a stdWrap property for an RTE field you would have to pass it trough lib.parseFunc\_RTE yourself using the .parseFunc property of stdWrap) - ###COBJ\_ITEM\_++cobjname++### : Using this marker you can insert an arbitrary cObject “bound” to the values of each single record rendered (The fields of each record are contained in $cObj->data – you can access the fields of the rendered record with the .fields operator). This means that COBJ\_ITEM markers get rendered once for each record getting displayed (and may by thus only occur in the ###LIST\_item### subpart). This is different to COBJ\_LISTING markers which may appear everywhere in the template and contain a cObject “bound” to the values of the FE-Plugin (The fields of the FE-Plugin tt\_content record are contained in $cObj->data). .. _cObjects: cObjects """""""" As already mentioned before you have the possibility to insert arbitrary cObjects into the template. This gives you a really great flexibility as you can insert mostly any thinkable T3 content this way. For example if you have database relations to tt\_content elements in one of the tables you created you could let them get rendered in the FE-Plugin listing using a cObject. There are two different kinds of cObjects for the template. ###COBJ\_ITEM\_++cobjname++### cObjects which get rendered while the values of each record are in the data array of the cObject. This means that in a COBJ\_ITEM cObject you can access the fields you created using the “.field” operator of any stdWrap property. So an cObject which outputs the contents of an RTE field with all tags stripped would look like: :: myTextField = TEXT myTextField.field = rtefieldname myTextField.stripHtml = 1 To find out where to insert this cObject in the TS configuration read on in the following section “Configuration”. The other type of cObjects is the LISTING cObject: ###COBJ\_LISTING\_++cobjname++###. You can use this one at any place in your template. But the contents of such an cObject will be the same for the whole template – i.e: only rendered once. So if you place a COBJ\_LISTING cObject into the ###LIST\_item### subpart it will contain the same value each time. When you define a cObject for a field in a section/container or in an overlay the marker of the cObject will be: ###COBJ\_SECTION-OR-OVERLAYNAME\_++cobjname++### .. _Configuration: Configuration ------------- You can configure a lot of the kb\_shop FE plugin via TypoScript most notably to mention is the possibility to insert custom cObjects and let get fields passed through stdWrap. For many of you which are not that fit it isn't that clear which possibilities this does offer. stdWrap is some kind of magic function which calls almost any other method of the FE content rendering object (a cObject). It is some kind of branch to mostly the compete functionality of TYPO3 FE capabilities. It allows you to insert custom cObjects TEXT/IMAGE(GIFBUILDER)/RECORDS/CONTENT etc. It also has a lot of text- processing capabilities. Following is a table of all TS properties of plugin.tx\_kbshop\_pi1. Those properties will completely be the same as for plugin.tx\_kbshop\_pi2 which will be the none cached plugin used for displaying full-text-search results. .. _The-main-plugin-configuration-containers: The main plugin configuration containers ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ On the top of the plugin configuration in plugin.tx\_kbshop\_pi1 there are mostly containers for the main parts which get rendered like listing, single view, criteria selector or forms. .. ### BEGIN~OF~TABLE ### .. _forms: forms """"" .. container:: table-row Property forms Data type container Description Contains all properties for ordering forms. Default .. _listView: listView """""""" .. container:: table-row Property listView Data type container Description Contains all properties for listView. They are the same for singleView. The separation between listView and singleView in the TS is here to enable you to have different cObjects and similar for list and single view. Default .. _singleView: singleView """""""""" .. container:: table-row Property singleView Data type container Description The container for the singleView properties can contain the same subproperties than listView (see table below) Default .. _subpart-listView: subpart.listView """""""""""""""" .. container:: table-row Property subpart.listView subpart.singleView Data type string Description This TS values define which HTML template main-subpart will get used for rendering the current view. Normally TMPL\_listView gets used for list view. But when you set subpart.listView = myTemplate for example then the subpart ###TMPL\_listView\_myTemplate### will get used. Default .. _criteriaSelector: criteriaSelector """""""""""""""" .. container:: table-row Property criteriaSelector Data type container Description Container for the criteriaSelector configuration Default .. _fieldTypes: fieldTypes """""""""" .. container:: table-row Property fieldTypes Data type container Description Container for the configuration of some field types (like labels for multi checkboxes) Default .. _template-listView: template.listView """"""""""""""""" .. container:: table-row Property template.listView Data type string / stdWrap Description The template file which get's used when a listiing gets generated. Default .. _template-singleView: template.singleView """"""""""""""""""" .. container:: table-row Property template.singleView Data type string / stdWrap Description The template file which gets used when a single record gets shown Default .. ###### END~OF~TABLE ###### plugin.tx\_kbshpo\_pi1 / plugin.tx\_kbshop\_pi2 .. _The-criteriaSelector-container: The "criteriaSelector" container ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In this container you will find properties useful for configuring the criteria selector selct-boxes, text-links, or checkboxes. .. ### BEGIN~OF~TABLE ### .. _selectedValue: selectedValue """"""""""""" .. container:: table-row Property selectedValue Data type string Description This value gets inserted into the ###SELECTED### marker of a criteria item option/link when it's value has been selected for filtering. For normal criterias. Default selected="selected" .. _checkedValue: checkedValue """""""""""" .. container:: table-row Property checkedValue Data type string Description This value gets inserted into the ###CHECKED### marker of a criteria item checkbox when it has been checked for filtering. For checkbox criterias Default checked="checked" .. _dateFormat: dateFormat """""""""" .. container:: table-row Property dateFormat Data type string (strftime) Description This value specified how dates should get displayed in the critieria selector. Default %Y-%m-%d %H:%M,%S .. _checkbox-yes: checkbox.yes """""""""""" .. container:: table-row Property checkbox.yes checkbox.no Data type string / stdwrap Description Specified the label ###LABEL### for a checkbox criteria which gets rendered as selectbox (Yes/No select-box). Default LLL:criteriaSelector\_checkbox\_yes LLL:criteriaSelector:\_checkbox\_no .. ###### END~OF~TABLE ###### plugin.tx\_kbshop\_pi1.criteriaSelector / plugin.tx\_kbshop\_pi2.criteriaSelector .. _The-fieldTypes-container: The "fieldTypes" container ^^^^^^^^^^^^^^^^^^^^^^^^^^ This container allows to set some configuration which define how multi checkbox values get rendered. .. ### BEGIN~OF~TABLE ### .. _multiCheck-nothingSet: multiCheck.nothingSet """"""""""""""""""""" .. container:: table-row Property multiCheck.nothingSet Data type string Description The label which gets used when no checkbox of a multi-checkbox field has been set. Default LLL:label\_none .. _multiCheck-implodeString: multiCheck.implodeString """""""""""""""""""""""" .. container:: table-row Property multiCheck.implodeString Data type Description The string which gets used for imploding the single values which have been checked in a mult checkbox Default " / " .. ###### END~OF~TABLE ###### plugin.tx\_kbshop\_pi1.fieldTypes / plugin.tx\_kbshop\_pi2.fieldTypes .. _The-forms-container: The "forms" container ^^^^^^^^^^^^^^^^^^^^^ In this container properties can get set which set some aspects of how ordering forms get rendered. The .forms container is available on more than one possition. 3 to be exact. first on the plugin.tx\_kbshop\_pi1 top level itself. On this first level the following properties are valid: .. ### BEGIN~OF~TABLE ### .. _doublePostDelay: doublePostDelay """"""""""""""" .. container:: table-row Property doublePostDelay Data type integer Description Number in seconds which is waited until a new order with the same content get's accepted. This inhibits double posting of values on final submit. (Only available in the top-level forms container) Default 600 .. _formAddParams: formAddParams """"""""""""" .. container:: table-row Property formAddParams Data type string Description Parameters which get added to the
tag generated for ordering forms. (Only available in the top-level forms container) Default .. _respectRequired: respectRequired """"""""""""""" .. container:: table-row Property respectRequired Data type string Description A list of tables (comma separated) which defined in which table the fields set as "required" are respected. (Only available in the top- level forms container) Default .. _noCache: noCache """"""" .. container:: table-row Property noCache Data type boolean Description When set the no\_cache parameter will be added to the URL when sending a form to another page or sending the Location header which redirects the user to another page after successful completion of a form (See FE-Plugin field: Submit Target OK) Default .. ###### END~OF~TABLE ###### plugin.tx\_kbshop\_pi1.forms / plugin.tx\_kbshop\_pi2.forms On the other levels (plugin.tx\_kbshop\_pi1.listView.forms and plugin.tx\_kbshop.listView.itemList.forms - you can substitute listView with singleView any time of course if you have a form in singleView and not in listView) properties are available which configure the default value and html code for submit buttons. The .forms container is available directly on the listView/singleView TS level but also in it's sub-property itemList - similar to cObjects. This is cause a form-item (an input box for example) can get rendered bound to the listing itself (for contact/delivery address data formulars for example) and to a single element (for an "ordering amount" input field i.e.) .. ### BEGIN~OF~TABLE ### .. _submitButton: submitButton """""""""""" .. container:: table-row Property submitButton Data type string / stdWrap Description Contains the full HTML of the submit button Default .. _tablename-defVals-fieldname: ++tablename++.defVals.++fieldname++ """"""""""""""""""""""""""""""""""" .. container:: table-row Property ++tablename++.defVals.++fieldname++ Data type string / stdWrap Description Using this value you can predefine the values for fields in the virtual order table. ++tablename++ is the complete tablename of a virtual order table. ++fieldname++ is only the alias you set for a field. Default .. _recordPid: recordPid """"""""" .. container:: table-row Property recordPid Data type integer / stdWrap Description This value specified in which pid the records will get created when it hasn't been otherwise specified by the above .defVals. container/key Default .. ###### END~OF~TABLE ###### plugin.tx\_kbshop\_pi1.listView.forms / plugin.tx\_kbshop\_pi1.listView.itemList.forms / plugin.tx\_kbshop\_pi1.singleView.forms / plugin.tx\_kbshop\_pi1.singleView.itemList.forms; same for pi2 .. _The-listView-and-singleView-containers: The "listView" and "singleView" containers ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Those containers are the most important for generating the listing. They contain the definition for how each view is rendered. Also with all other occurences listView and singleView are identical. .. ### BEGIN~OF~TABLE ### .. _noCache: noCache """"""" .. container:: table-row Property noCache Data type boolean Description When set the no\_cache flag will be set during rendering of the paeg which will cause the page to not get cached. Default 0 .. _cObjects-cobjname: cObjects.++cobjname++ """"""""""""""""""""" .. container:: table-row Property cObjects.++cobjname++ Data type cObject Description ++cobjname++ must be the name of a TS cObject which will get inserted in the FE as a COBJ\_LISTING\_ cObject marker. Default .. _fieldConfig-rte-parseFunc-RTE: fieldConfig.rte.parseFunc\_RTE """""""""""""""""""""""""""""" .. container:: table-row Property fieldConfig.rte.parseFunc\_RTE Data type -> parse func Description Contains the parse func which gets used to when rendering a RTE field by default (no stdWrap used). When this is not set there is a fallback to: :: lib.parseFunc_RTE and when this is also not set to: :: tt_content.text.20.parseFunc Default .. _fieldConfig-date: fieldConfig.date """""""""""""""" .. container:: table-row Property fieldConfig.date Data type stdWrap Description This property defines how date fields get renderd by default when no special stdWrap is specified Default %Y-%m-%d, %H:%M:%S .. _listViewLink-extra-linknum: listViewLink.extra.++linknum++ """""""""""""""""""""""""""""" .. container:: table-row Property listViewLink.extra.++linknum++ Data type -> typolink Description Using this TS array and the ###LINK\_listView\_HREF\_++linknum++### marker you can define custom links to a listing of your records. This is especially nice if you want to define links setting specific values which change layout or filter for specific predefined criterias. The page number which shall get displayed is contained in the register **linkPageNumber** . Default .. _singleViewLink-extra-linknum: singleViewLink.extra.++linknum++ """""""""""""""""""""""""""""""" .. container:: table-row Property singleViewLink.extra.++linknum++ Data type -> typolink Description The same as the above option but for links to singleView displays. The itemUid of the value to link to is contained in the register **linkViewUid** - also the page is available in **linkPageNumber** like in the above option. Default .. _listViewLink-page: listViewLink.page """"""""""""""""" .. container:: table-row Property listViewLink.page Data type integer / stdWrap Description This property defines the page-uid which shall get used for links to a listing. Default current page .. _singleViewLink-page: singleViewLink.page """"""""""""""""""" .. container:: table-row Property singleViewLink.page Data type integer / stdWrap Description This property defines the page-uid which shall get used for links to a detail view. Default current page .. _forms: forms """"" .. container:: table-row Property forms Data type container Description See above section "The forms container" (lower table) Default .. _itemList: itemList """""""" .. container:: table-row Property itemList Data type container Description See section "The itemList sub-container" below. Default .. _noCache: noCache """"""" .. container:: table-row Property noCache Data type Integer Description Sets rendering to noCache Default .. ###### END~OF~TABLE ###### plugin.tx\_kbshop\_pi1.listView / plugin.tx\_kbshop\_pi1.singleView / plugin.tx\_kbshop\_pi2.listView / plugin.tx\_kbshop\_pi2.singleView .. _The-itemList-sub-container: The "itemList" sub-container ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The above properties are all "bound" to the listing itself but rather not to a single record which gets listed. This means that the ->data array of the cObject instance rendering all the stdWraps and TS cObjects contains the row from the tt\_content FE-plugin inserted into the page. When you want to render cObjects which show distinct values for each rendered record you will have to use the itemList sub- container of **listView** and/or **singleView** . These are the properties of the itemList subcontainer: .. ### BEGIN~OF~TABLE ### .. _forms: forms """"" .. container:: table-row Property forms Data type container Description See above section "The forms container" (lower table) Default .. _cObjects-cobjname: cObjects.++cobjname++ """"""""""""""""""""" .. container:: table-row Property cObjects.++cobjname++ Data type cObject Description ++cobjname++ must be the name of a TS cObject which will get inserted in the FE as a COBJ\_ITEM\_ cObject marker. Default .. _fields-fieldname: fields.++fieldname++ """""""""""""""""""" .. container:: table-row Property fields.++fieldname++ Data type string / stdWrap Description This keys contains stdWrap properties for each field (not adding the prefix set during installation). When no stdWrap properties have been given to a field some default processing will occur. When you define stdWrap properties for an RTE field you have to pass it through lib.parseFunc\_RTE yourself. Default .. _sectionname-cObjects-cobjname: ++sectionname++.cObjects.++cobjname++ """"""""""""""""""""""""""""""""""""" .. container:: table-row Property ++sectionname++.cObjects.++cobjname++ Data type cObject Description cObjects rendered for each single section-element record. (With their data row in the cObjects ->data array). ++sectionname++ has to be the name (alias) of the container property forming the section. This is the same as above property " **cObject** " in this table but for the sub-records assigned in a section to the currently rendered record. Default .. _sectionname-fields-fieldname: ++sectionname++.fields.++fieldname++ """""""""""""""""""""""""""""""""""" .. container:: table-row Property ++sectionname++.fields.++fieldname++ Data type string / stdWrap Description This key contains stdWrap properties for each field of the section- element records in the currently rendered record. ++sectionname++ has to be the name (alias) of the container property forming the section. This is the same as above property "f **ields** "(in this table) but for the sub-records assigned in a section to the currently rendered record. Default .. _overlay-table: overlay.table """"""""""""" .. container:: table-row Property overlay.table overlay.uid overlay.section overlay.marker overlay.select overlays Data type integer stdWrap boolean string selectConf Array Description overlay.table gives the uid of a category record (which must be a root-category aka. table) from which the record specified by overlay.uid will get "overlayed" over the current ->data array of the rendering cObject and the main rendering method will get called again (which will result in all markers for fields of the overlayed table getting replaced by the appropriate values). This is useful for overlaying the product table over the virtual ordering table while listing the ordering basket: You list the items in the ordering basket and over each ordered item you overlay the record for this product :) When you set overlay.table to the name of an T3 table instead of the category uid of an shop-table you can overlay any table – like fe\_users or similar By setting the suboption “section” a sub-section get's created for the overlay – meaning you have to define a ###PART\_ and ###LIST\_ subpart. Only inside those markers the fields will get replaced. Using the suboption “marker” you can define the sectioname of the PART/LIST/FIELD\_VALUE markers. I.e. if you set: overlay.marker = prodcuts overlay.section = 1 You have create a HTML template similar to: ###FIELD\_VALUE\_products\_title### Default .. _overlays: overlays """""""" .. container:: table-row Property overlays Data type container Description Inside this container you define sub-configurations referenced by numbers – the allowed directives of such a sub-configuration are the above options for an overlay. I.e: overlays { 10 = 1 10 { table = fe\_users uid.field = kbs\_owner marker = siteuser } } Default .. _hooks: hooks """"" .. container:: table-row Property hooks Data type Array Description Example: hooks.kbs\_bilder=1 hooks.kbs\_bilder < plugin.tx\_rgsmoothgallery\_pi1 hooks.kbs\_bilder { class=tx\_rgsmoothgallery\_kbshop path=uploads/tx\_kbshop big { file.maxW = 300 file.maxH = 300 } height = 300 width = 300 showThumbs= 1 thumbOpacity = 0.8 arrows = 1 hideInfoPane = 0 duration = 7500 lightbox=1 } Default none .. ###### END~OF~TABLE ###### plugin.tx\_kbshop\_pi1.listView.itemList / plugin.tx\_kbshop\_pi1.singleView.itemList / plugin.tx\_kbshop\_pi2.listView.itemList / plugin.tx\_kbshop\_pi2.singleView.itemList .. _Tutorial: Tutorial -------- By now you just got an impression of how you should set up a shop system with kb\_shop and a reference to all available properties, markers and fields. This tutorial aims at giving a short glimpse about what is possible with kb\_shop. When you implemented a shop system on your own and you think that you have a nice structure and want to improve this document then write a tutorial how to implement your kind of shop and I will add it to this document in a section called "Real-world examples". This tutorial doesn't base on a real project but is rather just a little guide on how to set up a basic table containing some fields, two tables (one of them virtual) for letting an order process happen and will show some basic practices how to create nice web-shops. **IMPORTANT:** If you haven't noticed it until now by yourself I should point you at the fact that KB-Shop not only is good for real shop systems where people order products and other stuff but for **ANY** listing of records. For example if you have a website of a customer and have to list entries for "Talks" which have been held, or a listing for "Brochures" ... or a simple "Jobs" listing you will in some cases not be able to use the standard content elements cause some special sorting (for example after a field "Publication Date") has to get used. In this case you could create a table whose name fits their contents and insert a listing plugin on the specific page. Then the Editors just will have to create Records of Type "Brochue" or similar and will get a nice list sorted after criterias you define using the criteria Tab in the FE plugin. .. _Example-1-An-assumed-example-bookshop: **Example 1: An assumed example bookshop** ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. _Step-1-Table-Configuration-Folder: Step 1: Table Configuration Folder """""""""""""""""""""""""""""""""" First you have to create a sysfolder somewhere in your page-structure (most common somewhere on the root-level, next to your extension template storage folder probably). This folder will contain the categories and properties used in the shop. .. _Step-2-Install-Extensions: Step 2: Install Extensions """""""""""""""""""""""""" Make settings: TCA Mode = 1, Property/Category Folder = Folder created in Step 1 .. _Step-3-Create-some-properties: Step 3: Create some properties """""""""""""""""""""""""""""" Example how to create a "Title" Text field property and a IMAGE property for exampe. .. _Step-4-Create-a-root-category: Step 4: Create a root category """""""""""""""""""""""""""""" .. _Step-5-Assign-properties: Step 5: Assign properties """"""""""""""""""""""""" .. _Step-6-Clear-shop-cache: Step 6: Clear shop-cache """""""""""""""""""""""" Not normal blue/red cache buttons! .. _Step-7-Create-example-records: Step 7: Create example records """""""""""""""""""""""""""""" .. _Step-8-Insert-and-configure-FE-plugin: Step 8: Insert and configure FE plugin """""""""""""""""""""""""""""""""""""" Insert record directly on page (Allow Table on Pages must be set in Step 4) .. _Step-9-Create-a-HTML-template: Step 9: Create a HTML template. """"""""""""""""""""""""""""""" .. _Step-10-Create-custom-TS: Step 10: Create custom TS """"""""""""""""""""""""" .. _Step-11-View-result: Step 11: View result """""""""""""""""""" .. _Step-12-Create-order-properties: Step 12: Create order properties """""""""""""""""""""""""""""""" firstname, lastname, addres, + section containing fields ordered product (dbrel) and order amount .. _Step-13-Create-order-root-categories-tables: Step 13: Create order root-categories / tables """""""""""""""""""""""""""""""""""""""""""""" And assign them the order properties. There must be one table which has the virtual flag set. .. _Step-14-Insert-a-FE-plugin-for-ordering: Step 14: Insert a FE plugin for ordering """""""""""""""""""""""""""""""""""""""" Fill the Forms Tab. .. _Step-15-Create-a-HTML-template-for-ordering: Step 15: Create a HTML template for ordering """""""""""""""""""""""""""""""""""""""""""" Copy over listing tempate and insert order amount fields, create delivery/billing addres template .. _Step-16-View-result: Step 16: View result """""""""""""""""""" .. _Other-documentation: Other documentation ------------------- There is a wiki available at: `http://think-open.org/kraftb/t3wiki/index.php/Main\_Page `_ Which features currently some information about how to set up a basket TS-Setup and HTML template – altough not covering everything. There is also a newsgroup available at: news://think-open.org -> not running at this moment .. _Known-problems: Known problems -------------- labelProperty and searchProperty fields of an root-category/table record show all properties and not only those available for the current table (fix bug in T3) .. _To-Do-list: To-Do list ---------- - Create a billing interface - Pass criteria items through stdWrap so “real” custom criteria selectors can get created. .. _Changelog: Changelog --------- .. ### BEGIN~OF~TABLE ### .. _0-0-1: 0.0.1 ^^^^^ .. container:: table-row Version 0.0.1 Date/Time 2006-03-?? ??:?? CET Uploaded by Bernard Kraft Changelog Initial release. Not documented. .. _0-1-0: 0.1.0 ^^^^^ .. container:: table-row Version 0.1.0 Date/Time 2006-07-27 12:00 CET Uploaded by Bernard Kraft Changelog Multiple tables, Multilanguage support, Ordering forms support, documentation added. .. _0-1-1: 0.1.1 ^^^^^ .. container:: table-row Version 0.1.1 Date/Time 2007-09-03 23:30 CET Uploaded by Bernard Kraft Changelog Overlaying other tables, IRRE support for containers/sections, mailer system (separate extension), new field type “Geographical location” (using rggooglemap extension), Wizards for text/number fields, User type defined fields, PHP 5.x support . TYPO3 >= 4.1 required .. _0-1-2: 0.1.2 ^^^^^ .. container:: table-row Version 0.1.2 Date/Time 2008-03-17 03:15 CET Uploaded by Thomas Peterson Changelog Fixing Language, Fixing Criterias, Adding Hooks for Fields, Adding Settings .. _0-2-1: 0.2.1 ^^^^^ .. container:: table-row Version 0.2.1 Date/Time 2008-03-27 02:55 CET Uploaded by Thomas Peterson Changelog Add Workspaces Backend Frontend fix little Bugs add Relation language Selection .. _0-2-3: 0.2.3 ^^^^^ .. container:: table-row Version 0.2.3 Date/Time 2009-09-02 11:45 CET Uploaded by Bernhard Kraft Changelog Extension now works with TYPO3 4.2.8Marked the extension as "deprecated" .. ###### END~OF~TABLE ###### |img-6| EXT: KB Shop - 21 .. ######CUTTER_MARK_IMAGES###### .. |img-1| image:: img-1.png .. :align: left .. :border: 0 .. :height: 360 .. :id: Graphic2 .. :name: Graphic2 .. :width: 658 .. |img-2| image:: img-2.png .. :align: left .. :border: 0 .. :height: 365 .. :id: Graphic4 .. :name: Graphic4 .. :width: 210 .. |img-3| image:: img-3.png .. :align: left .. :border: 0 .. :height: 504 .. :id: Graphic5 .. :name: Graphic5 .. :width: 480 .. |img-4| image:: img-4.png .. :align: left .. :border: 0 .. :height: 588 .. :id: Graphic6 .. :name: Graphic6 .. :width: 447 .. |img-5| image:: img-5.png .. :align: left .. :border: 0 .. :height: 251 .. :id: Graphic7 .. :name: Graphic7 .. :width: 498 .. |img-6| image:: img-6.png .. :align: left .. :border: 0 .. :height: 32 .. :id: Graphic1 .. :name: Graphic1 .. :width: 102