Widget problems

[paales]

When we use widgets we encounter some problems:

I have the following fallback setup:

twiszt:default
bootstrap:nl
bootstrap:default
base:default

1. When creating a widget in twiszt/default it only fetches the block references from twiszt/default and base/default and therefor it can't find the block references added in bootstrap/nl or bootstrap/default.

This poses a bit of a problem, because the system doesn't know about the design fallback scheme at this point. Any suggestions how to fix it?

2. When I add the widget to bootstrap/nl (or bootstrap/default) it does show the block references as expected, but when trying to save the widget there is not XML saved because it does a template check and can't find it.

The following change fixes it so it loads the frontend instead of the admin

Index: app/code/local/Aoe/DesignFallback/Model/Design/Package.php:30
-       $configuration = Mage::getStoreConfig('design/fallback/fallback', $this->getStore());
+       $configuration = Mage::getStoreConfig('design/fallback/fallback', $defaults['_store']);

2a) The system doesn't load the correct rows from the core_layout_update.

I have three widgets:

According to the design fallback scheme it should load all three widgets.

in Mage_Core_Model_Resource_Layout::fetchUpdatesByHandle it only fetches the current theme instead of the fallback themes. In fact it only loads twiszt/default and never even loads the updates for base/default, which could be considered a bug. According to my point of view it should fetch all the updates from the fallback scheme instead of only the current.

The following change fixes it (of course model should be overwritten to really apply):

Index: app/code/core/Mage/Core/Model/Layout/Update.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- app/code/core/Mage/Core/Model/Layout/Update.php (date 1363194606000)
+++ app/code/core/Mage/Core/Model/Layout/Update.php (revision )
@@ -360,7 +360,18 @@
     {
         $_profilerKey = 'layout/db_update: '.$handle;
         Varien_Profiler::start($_profilerKey);
-        $updateStr = $this->_getUpdateString($handle);
+        /* @var $design Aoe_DesignFallback_Model_Design_Package */
+        $design = Mage::getSingleton('core/design_package');
+
+        $params = array();
+        $design->updateParamDefaults($params);
+        $scheme = $design->getFallbackScheme($params);
+        $updateStr = '';
+        foreach ($scheme as $layout) {
+            $updateStr = $this->_getUpdateString($handle,
+                array('package' => $layout['_package'], 'theme' => $layout['_theme'])) . $updateStr;
+        }
+
         if (!$updateStr) {
             return false;
         }
@@ -380,9 +391,9 @@
      * @param string $handle
      * @return mixed
      */
-    protected function _getUpdateString($handle)
+    protected function _getUpdateString($handle, $params = array())
     {
-        return Mage::getResourceModel('core/layout')->fetchUpdatesByHandle($handle);
+        return Mage::getResourceModel('core/layout')->fetchUpdatesByHandle($handle, $params);
     }

     public function fetchRecursiveUpdates($updateXml)

[fbrnc]

Hi Paul,
I'm currently on vacation (Roadtrip in California :) so I won't be able to look at this in detail in the next two weeks.
Anyways, thanks for your feedback and your patch. I'm happy to review it and to merge it as soons as I'm back (though, you might have to ping me and remind me...)

Bye, and have a great day,

Fabrizio

[paales]

Nice! Have fun! Don't do too much work stuff.

I'll create a pull request, have to have it fixed in the next few days or else the frontend devs can't continue their work.

[paales]

@fbrnc Bumping the issue. If you got an idea for the first issue, let me know, can create a PR if you haven't got the time to fix it.

[fbrnc]

Hi Paul,

I probably won't have any time to recreate a scenario for that and dig into this in the near future. Your're saying this problem is related to rendering widgets, right? And your solution adds the fallback mechanism to this because the other code is not used when it comes to rendering widgets?

Is your latest pull request (#6) still up-to-date? If so and you can confirm it is working, I'm happy to merge your code!

Thank you,

Fabrizio

[paales]

Hi @fbrnc ,

Yeah the latest pull request is still up-to-date, fixes points 2 and 2a.

As for point one:

1. When creating a widget in twiszt/default it only fetches the block references from twiszt/default and base/default and therefor it can't find the block references added in bootstrap/nl or bootstrap/default.

This poses a bit of a problem, because the system doesn't know about the design fallback scheme at this point. Any suggestions how to fix it?

When developing new sites our frontend developers have the following problem:
For the new site they create a new widget area ( in the XML) which is added to the current theme (twiszt/default in this example). Now in the backend they select twiszt/default. The new area shows up, great, the template shows up so this works as expected. The problem arises when they save the widgets, the system checks if the template exists in the current package, but it doesn't (only exists in bootstrap/default) so it doesn't save any XML.

The check can be found here: /app/code/core/Mage/Widget/Model/Widget/Instance.php:492, once removed, this isn't an issue anymore, but that is a workaround, not a fix.

To fix this issue as well as the first issue the 'other theme' should be available as well in the layout update. Since the designfallback is defined per store and not per theme this poses a problem. At the point of saving, the store view isn't defined, thus the proper fallback is unknown.

Solution a.) Use the fallback of the default configuration. This solution is a tad hacky.
Solution b.) Use all the themes as a single fallback in the admin panel
Solution c.) Define the fallback per theme instead per storeview. I'm not sure how to implement such a thing (where would the configuration go? twiszt/default/etc/fallback.xml or something?) I think this would be the best solution.

Any suggestion?

[paales]

@fbrnc I've created an update that uses solution c. Please take a look at: ho-nl-fork@489252a

What do you think about this idea?

Edit: The thing that I thought about to change is making the fallback.xml more general, making it a config.xml and extend the normal config (don't know about performance etc.)

[fbrnc]

Hi Paul,

I created this module back then as a proof-of-concept and never ended up using it. Setting up a scenario to test these changes will take me some time and to be honest I've got other things on my list that I'd like doing a lot more if I had some more time left :)

I appreciate your offer to contribute fixes and improvements back. If you send me a new pull-request I'm ok with merging it (without being able to test it). Or you continue working with your fork.
I hope you understand.

Bye, and have a great weekend,

Fabrizio

[paales]

Hi @fbrnc, thanks for even responding :)

We currently use the module because we developed our own frontend framework which rewrite a great deal of base templates, works great so far.

If this module isn't maintained anymore, we'll just use our fork of the module. If I'm satisfied about the quality of the code (has run in production for some time and no weird bugs pop up), i'll create a pull request.

Thanks for creating all these cool modules, really appreciate your work.

Ps. What was the reason you didn't end up using the module?

[fbrnc]

Hi Paul,

I'm happy to hear that your using this module and it works fine for you. Even more happy to see that you picked up development to extend it even more.

We did not end up using it because we haven't had the need of having more than the "usual" fallbacks so far. This might change, but until now every project was fine with the default fallback hierarchy.

Have a great day,

Fabrizio