| Author | Message |
|---|---|
|
Written on: 14. 01. 2012 [15:55]
|
|
|
artus
Artus
Topic creator
registered since: 25.08.2011
Posts: 14
|
Hello, please forgive me if this is the wrong place for my posting. But I have multiple issues comming together with a solution I want to share with you. First of all here is my setup: * TYPO3 4.5.7 * TemplaVoila! 1.6.dev * RealURL 1.11.2 * Static Info Tables 2.3.0 * TypoGento 1.1.0-beta * Magento 1.6.1 My first problem was the missing support for the Magento Compiler. The second one was the header integration doesn't provide including Magento resources using TYPO3 header fields like jsFiles or cssFiles. And at least a comfortable support for the integration of Magento Blocks like cart_sidebar on all TYPO3 pages. So I have started developing two extensions to make this all possible. To support the Magento Compiler I have simplified the TypoGento autoloader using the PHP reflection api instead rewriting the class hierarchy on file system level. The downside of this approach is currently TypoGento only works in TYPO3. This means if you browse to Magento directly TypoGento is not loaded. I will post a solution for this later. For a improved integration of the Magento header I've written a class which uses the members jsFiles, cssFiles, jsInline and if there is no other possibility additionalHeaderData of the TYPO3 page renderer. With that you have for example a better support of compressing and merging your resources. A handy possibility to use Magento Blocks like cart_sidebar or top.search on every page of TYPO3 is very important for a project of our customer. But the problem was essentially, that TypoGento doesn't know which Magento action path (e.g. /catalog/product/view) to take if no plugin in the page content is set. On the other hand we have already a little tool to do an similiar job with target pages (plugin.tx_fbmagento_pi1.target_pids). I thought what is missing here is just a router which does the job in both directions, thus we can tell TypoGento what pages get used for specific actions paths like /checkout/cart/index and what actions paths get used for specific page ids. Now my TypoScript Setup looks like this: TYPOSCRIPT # plugin includeLibs.tx_fbmagento_pi1 = EXT:fb_magento/pi1/class.tx_fbmagento_pi1.php # default routes plugin.tx_fbmagento_pi1 { routes { # fallback if no action set is given for the current page 10 { source { pid = TEXT pid { data = field:uid wrap = | } } target { route = typogento controller = index action = index } section = actions } # every route set matching /catalog/product/view route to special page 20 { source { route = catalog controller = product action = view } target { pid = 79 } section = pages } # every route set matching /checkout/cart/* route to special page 30 { source { route = checkout controller = cart action = * } target { pid = 76 } section = pages } # ... } } # magento search block temp.search = USER temp.search { userFunc = tx_fbmagento_pi1->main block = top.search nowrap = 1 } # magento basket block temp.basket = USER_INT temp.basket { userFunc = tx_fbmagento_pi1->main block = cart_sidebar nowrap = 1 } Also I've changed the behaviour using GET variables from the HTTP request and the FlexForm setup of a TypoGento plugin in the page content so I can make nicer URLs with TypoGento removing unnecessary variables if they already configured otherwise. Now my RealURL setup looks like this: PHP $TYPO3_CONF_VARS['EXTCONF']['realurl'] = array(
'_DEFAULT' => array(
// ...
'fixedPostVars' => array(
'product' => array (
array (
'GETvar' => 'tx_fbmagento[shop][id]',
'userFunc' => 'EXT:weetypogento/lib/class.tx_weetypogento_realurl.php:&tx_weetypogento_realurl->productRewrite'
),
array ('GETvar' => 'tx_fbmagento[shop][route]', 'noMatch' => 'bypass'),
array ('GETvar' => 'tx_fbmagento[shop][controller]', 'noMatch' => 'bypass'),
array ('GETvar' => 'tx_fbmagento[shop][action]', 'noMatch' => 'bypass'),
array ('GETvar' => 'tx_fbmagento[shop][s]', 'noMatch' => 'bypass'),
array ('GETvar' => 'tx_fbmagento[shop][category]', 'noMatch' => 'bypass')
),
'cart' => array (
array (
'GETvar' => 'tx_fbmagento[shop][action]'
),
array (
'cond' => array('prevValueInList' => 'add'),
'GETvar' => 'tx_fbmagento[shop][product]',
'userFunc' => 'EXT:weetypogento/lib/class.tx_weetypogento_realurl.php:&tx_weetypogento_realurl->productRewrite'
),
array (
'cond' => array('prevValueInList' => 'delete,configure'),
'GETvar' => 'tx_fbmagento[shop][id]'
),
array ('GETvar' => 'tx_fbmagento[shop][route]', 'noMatch' => 'bypass'),
array ('GETvar' => 'tx_fbmagento[shop][controller]', 'noMatch' => 'bypass'),
array ('GETvar' => 'tx_fbmagento[shop][s]', 'noMatch' => 'bypass')
),
// ...
'79' => 'product',
'76' => 'cart',
// ...
),
'postVarSets' => array (
'_DEFAULT' => array (
'uenc' => array (array ('GETvar' => 'tx_fbmagento[shop][uenc]'),),
)
)
)
);I also have fixed some minor issues on Windows machines in the old autoloader before I've written a new one. Beside these hopefully useful changes I ran into some issues using the checkout process when I'm logged in as backend user. Maybe TYPO3 and its locking system gets confused and resulting in silent exceptions with redirections and/or "page generation" messages. I hope you will find this solution usefull and give me some feedback. If you want I will post newer versions here. Greetz [This article was edited 1 times, at last 14.01.2012 at 15:55.] |
|
Written on: 14. 01. 2012 [15:56]
|
|
|
artus
Artus
Topic creator
registered since: 25.08.2011
Posts: 14
|
Here is the Module for Magento. I hope I've forgot nothing else otherwise post your issue here and I will answer it as soon as possible. [This article was edited 4 times, at last 14.01.2012 at 16:09.] |
|
Written on: 18. 01. 2012 [14:12]
|
|
|
artus
Artus
Topic creator
registered since: 25.08.2011
Posts: 14
|
Hi, here is the last update of the TYPO3 extension. I will give you some more detailed explanation about what you can do with it and how it works: Requirements Running installation of: * TYPO3 >= 4.5.7 < 4.6 * TypoGento 1.1.0-beta * Magento 1.6.1 The both extensions posted here for TYPO3 (tx_weetypogento.zip) and Magento (Wee_Typogento.zip). Magento Compiler Just activate it in Magento backend and it should work. Advanced Header Should work if extension property 'auto_header' is enabled in fb_magento and you use the default 'head' block in Magento. Advanced Routing The main benefit of this feature is, it allows putting Magento blocks like 'cart_sidebar' on every TYPO3 page just with TypoScript. The underlying concept is still that every frontend page request TYPO3 receives can result at the maximum in one Magento request for a specific action resp. controller (e.g. /checkout/cart/add). Lets say we want everywhere in a page tree the Magento block 'top.search' whether or not any other Magento content would be on a page. TYPOSCRIPT # setup magento search block temp.search = USER temp.search { userFunc = tx_fbmagento_pi1->main block = top.search nowrap = 1 } Therefore we need a basic action which renders a layout with this block. Because currently I don't know better I've written a simple one which renders just the default layout handles: PHP // this is part of the posted module for Magento
class Wee_Typogento_IndexController extends Mage_Core_Controller_Front_Action {
public function indexAction() {
$this->loadLayout();
$this->renderLayout();
}
}Now we got a Controller which does the job we can use it in TypoScript: TYPOSCRIPT plugin.tx_fbmagento_pi1 { # setup basic action route routes { # the current page id (field:uid) to /typogento/index/index 10 { source { pid = TEXT pid { data = field:uid wrap = | } } target { route = typogento controller = index action = index } # default section for all routes with pid->action section = actions # default priority #priority = 0 } } } With this we have a basic route (default priority) which is used if nothing else is setup for a page. Now let's say we got a page 'Products' in this tree which have a additional Magento Frontend Plugin which targets the action '/catalog/category/view' and the category 'xyz'. What happens now depends on the priority: * Default priority for TypoScript routes is 0 (changeable) * Priority for route sets of Frontend Plugins in page content is 9 (not changeable) * Priority for route sets of non empty variables (tx_fbmagento['shop'][...]) in HTTP request is 10 (not changeable) * Empty variables in HTTP request will be removed (not changeable) According to that requesting our 'Products' page would result in '/catalog/category/view/xyz' on Magento with the blocks 'content' and 'top.search'. As you may have noticed, we have antoher little tweak in our TypoScript routes. Wildcards and route set values have the following precedence: * Exact match have the highest precedence * Wildcard match with non empty value lowers the precedence once * Mismatch with empty value lowers the precedence once * Mismatch with non empty value have the lowest precedence For example we have a sub tree with various category views and one product view: TYPOSCRIPT plugin.tx_fbmagento_pi1 { routes { # every route set matching /catalog/product/* to special page 100 { source { route = catalog controller = product action = * } target { pid = {$site.navigation.entries.product} } section = pages } # every route set matching /catalog/category/* to current page 110 { source { route = catalog controller = category action = * } target { pid = TEXT pid { data = field:uid wrap = | } } section = pages } } } Now every link in a Magento block for '/catalog/category/*' would you use the current page and any link for '/catalog/product/*' would use the special page in '{$site.navigation.entries.product}'. Please notice that routes with incomplete target route sets will be merged if theirs source route set are equal; the merge respects the priority and precedence and the resulting route will gets the highest priority value of its parts. Page Meta Data I've also changed the access to meta properties (e.g. Title or Keywords) of the current Magent page through TypoScript. Let's say you want on the page under '{$site.navigation.entries.product}' the meta keywords and description of the displayed product. With the base layout of Magento this should work if you have setup the TYPO3 page with a Magento frontend plugin right: TYPOSCRIPT [globalVar = TSFE:id = {$site.navigation.entries.product}] page.meta { keywords { field > data = register:magePageKeywords wrap = | } description { field > data = register:magePageDescription wrap = | } } [global] In other words this here depends on what Magento action was called with the TYPO3 page in '{$site.navigation.entries.product}'. If you have used a basic route like above it should at least be '/typogento/index/index'. Limitations * TypoGento doesn't work out of TYPO3 like before * TYPO3 < 4.5.7 shouldn't work Hope thereby might be something useful. Greetz [This article was edited 4 times, at last 18.01.2012 at 14:32.] |
|
Written on: 11. 02. 2012 [18:04]
|
|
|
artus
Artus
Topic creator
registered since: 25.08.2011
Posts: 14
|
Hi, forget about my last uploads here. Finally I've forked Flagbit's TypoGento on GitHub and pushed the initial release today (github.com/witrin/TypoGento/tree/develop). The features I descriped here are still topical and onwards improved and partially extended. I will provide some documentation as soon as possible! Greetz |
