All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Commerce/old version

From TYPO3Wiki
Jump to: navigation, search

<< Back to Projects page


Main editor: Ingo Schmitt, Volker Graubaum

notice - Note

See the new version of the documentation - and please help to merge.


In TER: commerce

Current Status

Commerce is availiable in the sourceforge SVN t3xdev, project commerce. [ - tx_commerce]

Please do only register for the "new" bugtracker at and use the mailinglist:

The current class documentation is availiabe at [].

Feature list

Original thread is at [1]...

Implemented Shops

Here you can enter the URLs of the shops you have implemented with Ext-commerce .






























The features have been put in an project sheet to let other developers participate and to get funding for this project. Generall discussion about this project is done via the newsgroup or via regular irc-chats.

Developing has started after we finished the DB model which can be found here:

See also the project description here:

Wish List

  • Have some fun
  • Multilanguage shop system
  • Catalogimport via XML
  • Catalogexport via XML
  • The possibility to change an order's status (i.e. from Pending to Sent) by clicking a link in an e-mail (makes it easy to manage orders if order processing is done only by e-mail and not with the T3 backend/frontend)
  • "Downloadable" products. It would be great if you could not only sell physically unique articles via the shop but also digital resources like images, PDFs, software ... Would be great to have the ability to build bundles of downloadable products (for example: the shop has single mp3 tracks (products) and albums containing 4 tracks (4 products) acting as a bundle.
  • For Downloadable products: Secure Delivery Service for Download Links via Email (Without login to FE/BE) using for example PayPal Instant Payment Notification (IPN). If the customer finish a pending payment he´ll get the dl-links to his paypal emailadress. Customer can download each product n times within m hours
  • For pictures: They should be displayed as a gallery which mirrors the folder structure where the pictures are stored. The pictures should be automatically included into the shop when creating a new subfolder with pictures, because it is often exhausting to add each picture to the shop separately when having large picture folders. Each picture folder should have an own description and price per picture. The pictures should contain a watermark which is removed after payment.
  • Ability to combine physical and downloadable Products in one order
  • Selling website content. It would be cool if it would be possible, to sell access to TYPO3 pages with commerce. So you could for example sell access to the "Community Corner" of your website. Technically, this would be selling access to usergroups. So the customer (having a fe_user account) then buys the membership of the fe_group "Customer Corner Access" for example. Read this for more info.
  • add possiblity to get products information from robert lemkes document
  • real time price calculator - By selecting multiple feautures, the total amount will change accordingly in real time. See for an existing example. (=> This is a *must*, for shops in germany, by law.)
  • suit extension
  • templating with templa voila
  • api/hooks for payment gateways (paypal) ? Hooks for payment gateways are available, there is an implementation of the paypal-express-checkout feature
  • api/hooks for shipping gateways (UPS,GLS,GP,DHL ... )
  • add functionality from zk_produkts (stock/deals/...)
  • different prices for different customer groups
  • different prices for different localized pages (countries)
  • different products in teaser sections based on criteria, such as locations and dates.
  • Add related 'extras' to a product, when one product is shown allow related extras to be added at the same time
  • Customers who bought this also bought these.....
  • You recently viewed these products.....
  • offer single items which disappear when sold (for selling used stuff) and which can't be bought twice or more often by editing the basket.
  • Product attributes which might change the price of a product (eg colour1 = price + $20; colour2 = price + $30), maybe attributes are separate products which then are linked
  • alternating list displays
  • different tax rates for one product
  • should mostly adapt the main neat functions of osCommerce
  • The possibility to use many images for each product
  • The possibility to use tables created in RTE (doesn’t work in current version of tt_products)
  • The possibility to download user manuals (PDF) for each product
  • The possibility for multivendor shops, to enable different suppliers (providers) to sell products and services or downloadable goods in one check-out session to customers directly
  • Feedback and comments from users
  • Rating of products
  • support for each category its own admin who can see only the orders for its own category --> bigger shops with different catergoy administrators
  • Advanced stock management: prognoses based on history (no. sold previous year), cost, turnover and profit calculation, low stock warning based on delivery time, extend product with features (i.e. colour, size, etc.) and statisics based on product features (most sold size, colour, etc.). This feature could create high efficiency with low effort.
  • Affiliate system
  • The ability to sell time interval -based subscriptions (of an electornic product, etc.) with automatic expiration of user group membership (for an excellent example, see AgileBill, )
  • Import of cvs, excel, openoffice, SAP, navision and other formats should be supported for import product data
  • Payment gateways from osCommerce (paypal, secpay, ipayment, credidcards, etc. etc)
  • Possibility to enter slide-scaling prices according to quantities (Staffelpreise, i.e. 100 units=€10,00/unit 500 units=€8,99/unit etc.)
  • Possibility to use 4 decimals (0,0231) for wholesale items.
  • User/buyer-tracking with remote adress
  • Cookie-ing last visit
  • Catalogpagelike presentation of different artikels in one picture and selection by active areas.
  • Colormanagemant of navigation/titlebar/etc. depending on category or artikel or usergroup etc. to support "emotional selling"
  • Drag and drop of articles to shoppingcart
  • An Interfacte to different commodity management systems/softare (in german: Warenwirtschaftssysteme).
  • Links from textpages to products and articles and links from products/articles to other products/articles.
  • Supplements for products or articles through the radio buttons (PC = 300$ / +1GB RAM = +20$ / +2GB RAM = +40$ /...).

Real Time Price Calculator (i.e. you see the total value of the product in real time, when you select or deselect multiple features - see for an existing example)

Should have payment gateways like paypal, firstpay Click&buy (germany),creditcards Did I miss any gateway? fell free to add some... (osCommerce has the following payment gateways:,, ipayment, paypal, psiGate, SECpay, trustcommerce)

Needs flexible pricing methods, e.g. XML-Catalogs that define a certain pricing mechanisms for a customer-article-relationship or for customer groups, article categories.

And flexible product catalogs, depending on the status of the customer. Could be a XML-solution.

RealURL integration to get nice URLs, e. g.: /products/shoes/boots.html, /products/shoes/boots/12345.html

Product categories


  • nested
  • related
  • multiple parent categories
  • multiple languages
  • access via normal t3 features (hidden, group, time)


  • defining article attribute kinds per category which are inherited to all child articles

Database fields:

  • title
  • subtitle
  • description
  • pictures
  • related categories

Booksellers need more database fields. A good range is: author, title, subtitle, bibliographical data (such as binding, no. of pages etc. - no use having those as attributes of a product), description, picture (the rest pretty much as mentioned). Products are usually sorted by author's name in a product list, and it's helpful for customers if author and title show up in the shopping cart. Good alternative: allow users to create their own database fields.



  • can have more than one parent category
  • multiple languages
  • access via normal t3 features (hidden, group, time)


  • defining article attribute kinds per product which are inherited to all child articles

Database fields:

  • title
  • subtitle
  • description (using RTE)
  • search key words
  • picture



  • variable Attributes
  • variable tax rates
  • minimum order unit
  • multimedia content
  • access via normal t3 features (hidden, group, time)
  • related articles
  • stock handling
  • action attributes (new, price off ..)
  • flexible pricing
  • multiple currencies

Can Features:

  • Plugin-Concept for stock


  • Tax-Handling in general - Static Tables vs TypoScript, Handling of US States
  • special offer handling
  • multimedia content handling via DAM
  • selling DAM Content

Database fields:

  • prices quantity stored (with control and report of stock size)
  • article numbers

Nice Features:

  • manufacturer
  • additional information (pagelink & filelink)


attributes are storing article specific informations, such as size, wheight, color (attribute-kinds)....

Must Features: attribute kinds can be defined as must/can per categorie/ product for all articles below attribute kinds can be added to articles Values are stored via attribute-kind, calue relations

Can Features Separate handling for values


Offers can store information for separate placments for articles. E.g. Jubilee, trade off, new.


  • Flexible Duration
  • Variable Price
  • Price check for new price, shows everytime the cheapest price.



Price offs can be handed via different systems. It could be e.g. connected with a FE_user_group, or with offers or within the amount of the shopping basket

Default handing for following Types:

  • people and group (for product and in general)
  • discount for a special shopping value (e.g. 200 €)
  • discount for a special shopping quantity (e.g. 5 of a product will give one more)

Can features:
Felxible Configuration features via TS Plugin-Concept for more discount types


related to Article

Database Fields

  • name
  • address
  • logo
  • description
  • rating
  • link

Shopping cart

A Shopping Cart is handeling the information about what items are currently put into the cart during the Session

Issue: How to store Cart data (DB/Session Data) and how to identify user.

Must Features: API for adding, storing, changing articles in cart Currencies handeling

Can Features:

shopping list

Can Feature A shopping list stores old carts for the next visit. Normally carts are stored

Issue: how to store the List (Cookie, Login..)


The Checkout is handels the complete User interaction process, as Adress, payment, userdata, delivery. A Checkout uses the prior filled Cart

Must Features:

  • handeling user registration via FE_user (with API) incl. automated user generation with first order
  • ability to add separate deilivery adress
  • plugin system for different Payment Methodes
  • different country options
  • different payment and shipment options (with different prices) (handles also credit card number encryption)
  • Support for payment by debit entry (Lastschrift)
  • special payment options for special groups
  • overview shopping cart
  • confirmation of terms and conditions (AGB)
  • Transport costs handeling (incl. API)

Can Features:

  • General Shipping API to include different Weight/Place tables


Provides an API for handling billing points like

Calculation of shipment costs by weight or item-no.


Order Systems holding the information belonging to the order.

  • change and see status of order (ordered, shipped, rejected, finished)
  • add notes for orders

Nice features:

  • Proof customer satisfaction
  • Add shipping API so Status of shipping could be seen (future)

Additional Features

  • wish list
  • Coupons (eg. gift certificate that gives some arbitrary discount)
  • bonus (when he has returned the last order he can get a bonus for the next time)


More discussion???

  • complete breakup/separation between logic(php,classes) and HTML, means *no* HTML in any class! =), tableless CSS-Templates
  • support of multiple database systems (DBAL)
  • automatic creation of billing and delivery papers
  • order tracking and sending of order emails
  • search for articles
  • monitoring system for lack of products in the stock
  • MVC design: separation of classes for data model and view/controller
  • interfaces to other software (e.g. popular business-software like LexWare in Germany)
  • Using DAM for mediafiles
  • Following a personal wishlist based on experience OSC, CRELOADED =OSC+all extensions etc.:
  • Avoid OSCOMMERCE set-back: Avoid >3 directory levels.
  • Avoid OSC problems: Define entry ports for extension modules (code modifs prohibited!)
  • Avoid OSC problems: Config data mostly into files, secured dir's, no softw panic if DB down
  • Avoid OSC problems: put multi-language data into arrays, allow for operation on them.
  • Avoid OSC problems: Avoid many single DB tables; insert dummy free char fields =Reserve


  • (first Step csv Export of orders, with filters) file (XML) import / export for products / categories basic setup during installation
  • wide ranging settings and customization with TScript flexforms for general settings on the pages


Other relating projects to Party Information Framework (edit this, in alphabetical order)

  • Commerce Shop Extension This extension use an 1:N relation for addresses and included an own addressmanagement, which should be part of the Party Information Framework.
  • Enhanced Rights Management - a pear class for a RBAC / Role Based Access Control.
  • Inline Relational Record Editing - 1:n relations for BackEnd-Forms -- Oliver Hader
  • Newloginbox development coordination - Ingmar Schlecht and Stefan Strasser
    The User list plugin (pi3) of Newloginbox is related to the Party Framework. If the Party Framework will ship with a user listing plugin, the pi3 of Newloginbox wouldn't be needed any more.
  • Users Addresses - relations between fe_user and tt_address, best practice discussion - Elmar Hinz
  • dkd_feuser_belogin - relation between fe_user and be_user