4

we have a general module which implements some widget functionality and adds basic templates to a shop, which are defined in the widget.xml like this:

<some_module>
    <name>my name</name>
    <parameters>
        <template translate="label description">
            <visible>1</visible>
            <label>Block template</label>
            <description>Template to render the block</description>
            <type>select</type>
            <value>cms/widget/static_block/default.phtml</value>
            <values>
                <default translate="label">
                    <value>cms/widget/static_block/default.phtml</value>
                    <label>CMS Static Block Default Template</label>
                </default>
                <table_2columns translate="label">
                    <value>foobar/module/static_block/2columns.phtml</value>
                    <label>2 Columns Table</label>
                </table_2columns>
            </values>
            <sort_order>10</sort_order>
        </template>

We use that basic configuration a lot, but now want to remove one of the entires in in a child extension, which are usually just used to add more project specific templates, but should this time also remove one of the defaults. Unfortunately there's nothing like a remove tag for values entries. Also setting the value or label to an empty string does not work. :(

I'm currently looking for an event to extend the renderer and removing the values in there, but that feels quite dirty and it would be a lot nicer to do that actually in the widget.xml of the extending module. Is there a way to do that without changing the code of the parent/general module?

2 Answers 2

3

So as already discussed in the comments of Marius I created a helper block which is defined in the widget.xml:

            <helper_block>
                <type>foobar/adminhtml_widget_values_remover</type>
                <data>
                    <block_type>foobar/widget_block</block_type>
                </data>
            </helper_block>

That helper block is used to remove the values and not to display anything additional as a button (as the magento tutorials show as an example). Unfortunately it was very hard to get back to the widget node, as the helper block does not know about the node options of the main widget, so I added the block_type in the data-section. The code itself then iterates over a possible remove-node inside the tags. Other than for the layout-xml-remove you have to define the nodes to delete as childs and not as an attribute, as multiple remove nodes would be merged to one.

This is the code of the helper block:

public function prepareElementHtml(Varien_Data_Form_Element_Abstract $oElement)
{
    $aConfig = $this->getConfig();
    $aValues = $oElement->getValues();
    $oWidget = Mage::getModel('widget/widget');
    $oXmlConfig = $oWidget->getConfigAsXml($aConfig['block_type']);
    $oXmlValues = $oXmlConfig->parameters->template->values;
    $oXmlRemoves = $oXmlValues->remove;
    foreach ($oXmlRemoves->children()as $oXmlRemove) {
        $oXmlRemoveDefinition = $oXmlValues->{$oXmlRemove->getName()};
        foreach ($aValues as $iKey => $aValue) {
            $bEqualsValue = ($aValue['value'] == (string)$oXmlRemoveDefinition->value);
            if ($bEqualsValue) {
                unset($aValues[$iKey]);
            }
        }
    }
    $oElement->setValues($aValues);
}

I'm not yet really happy with the iterations and this re-reference of block-type, might improve that alter.

And the remove-definition in the widget.xml:

    <parameters>
        <template>
            <values>
                <remove>
                    <table_2columns />
                </remove>

I hope this helps, if anyone will have the same problem. :)

2

Unfortunately there is no way to remove it by using a xml tag or attribute without rewriting something.
The method that adds a field to the widget options is this: Mage_Widget_Block_Adminhtml_Widget_Options::_addField.
For fields that have the values tag this is how it works.

     if ($values  = $parameter->getValues()) {
        // dropdown options are specified in configuration
        $data['values'] = array();
        foreach ($values as $option) {
            $data['values'][] = array(
                'label' => $this->_translationHelper->__($option['label']),
                'value' => $option['value']
            );
        }
    }
    // otherwise, a source model is specified
    elseif ($sourceModel = $parameter->getSourceModel()) {
        $data['values'] = Mage::getModel($sourceModel)->toOptionArray();
    }

Also if you want to check how the values are passed to the parameter object from the xml check Mage_Widget_Model_Widget::getConfigAsObject.
There is this in that method:

                // prepare values (for drop-dawns) specified directly in configuration
                $values = array();
                if (isset($data['values']) && is_array($data['values'])) {
                    foreach ($data['values'] as $value) {
                        if (isset($value['label']) && isset($value['value'])) {
                            $values[] = $value;
                        }
                    }
                }
                $data['values'] = $values;

So everything that is in the values tag will be passed later to the field element.

I didn't see any event dispatched in either of the methods so I guess you have to rewrite one of them so you will be able to add a disabled tag or attribute on the elements inside the values tag.
If you decide to take this approach, I recommend rewriting the Mage_Widget_Model_Widget::getConfigAsObject method. Seams cleaner to me.

2
  • Thanks Marius. Some lines below your posted code in getConfigAsObject I found the usage of an helper block. With that I can also modify the values afterwards and don't need to rewrite that core block, just add the config definition for the helper block. Feels a little bit more elegant, but thanks a lot for the help, I was already looking sometime to find the part where the values are loaded :)
    – Tobias
    Commented Sep 15, 2014 at 14:00
  • @TobiasZander Nice. Why didn't I think of that? Please post an answer as soon as you have the working code. I'm really interested.
    – Marius
    Commented Sep 15, 2014 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.