I just wandering on how I can get the configuration data for my custom module. The configuration can be set from the admin system->configuration and how to pull it in frontend?
$configValue = Mage::getStoreConfig('sectionName/groupName/fieldName');
sectionName, groupName and fieldName are present in etc/system.xml file of your module.
The above code will automatically fetch config value of currently viewed store.
If you want to fetch config value of any other store than the currently viewed store then you can specify store ID as the second parameter to the getStoreConfig function as below:
$store = Mage::app()->getStore(); // store info
$configValue = Mage::getStoreConfig('sectionName/groupName/fieldName', $store);
you should you use following code
$configValue = Mage::getStoreConfig(
'sectionName/groupName/fieldName',
Mage::app()->getStore()
);
Mage::app()->getStore() this will add store code in fetch values so that you can get correct configuration values for current store this will avoid incorrect store's values because magento is also use for multiple store/views so must add store code to fetch anything in magento.
if we have more then one store or multiple views configured then this will insure that we are getting values for current store
Magento 1.x
(magento 2 example provided below)
sectionName, groupName and fieldName are present in etc/system.xml file of the module.
PHP Syntax:
Mage::getStoreConfig('sectionName/groupName/fieldName');
From within an editor in the admin, such as the content of a CMS Page or Static Block; the description/short description of a Catalog Category, Catalog Product, etc.
{{config path="sectionName/groupName/fieldName"}}
For the "Within an editor" approach to work, the field value must be passed through a filter for the {{ ... }} contents to be parsed out. Out of the box, Magento will do this for Category and Product descriptions, as well as CMS Pages and Static Blocks. However, if you are outputting the content within your own custom view script and want these variables to be parsed out, you can do so like this:
<?php
$example = Mage::getModel('identifier/name')->load(1);
$filter = Mage::getModel('cms/template_filter');
echo $filter->filter($example->getData('field'));
?>
Replacing identifier/name with the a appropriate values for the model you are loading, and field with the name of the attribute you want to output, which may contain {{ ... }} occurrences that need to be parsed out.
Magento 2.x
From any Block class that extends \Magento\Framework\View\Element\AbstractBlock
$this->_scopeConfig->getValue('sectionName/groupName/fieldName');
Any other PHP class:
If the class (and none of it's parent's) does not inject \Magento\Framework\App\Config\ScopeConfigInterface via the constructor, you'll have to add it to your class.
// ... Remaining class definition above...
/**
* #var \Magento\Framework\App\Config\ScopeConfigInterface
*/
protected $_scopeConfig;
/**
* Constructor
*/
public function __construct(
\Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig
// ...any other injected classes the class depends on...
) {
$this->_scopeConfig = $scopeConfig;
// Remaining constructor logic...
}
// ...remaining class definition below...
Once you have injected it into your class, you can now fetch store configuration values with the same syntax example given above for block classes.
Note that after modifying any class's __construct() parameter list, you may have to clear your generated classes as well as dependency injection directory: var/generation & var/di
for example if you want to get EMAIL ADDRESS from config->store email addresses.
You can specify from wich store you will want the address:
$store=Mage::app()->getStore()->getStoreId();
/* Sender Name */
Mage::getStoreConfig('trans_email/ident_general/name',$store);
/* Sender Email */
Mage::getStoreConfig('trans_email/ident_general/email',$store);
Related
Before i state my problem, please be aware that this is my first time working with Typo3 and/or creating an Extbase extension.
SO basically i want to create an extbase extension for Typo3, but i seem not to be able to wrap my head around the concept of transfering an object (assigned to the view of a specific template) via arguments to an action, with the purpose of attaching the object to another (with a 1:n relation).
My example:
I have an Objekt of the type "Appliance" assigned to the view of a template ("Show.html"). I can list all the properties of it in the Template, so it definitely exists in the view.
Now i want to create an Object of the type "Host" using a form and then attaching it to this specific "Appliance" object.
The problem is: I can't transfer the object of the type "Appliance" to the specific Action of the Controller of the type "Host" which itself should then assign it to the view of another template.
Look at the following code example:
<f:link.action action="new" controller="Host" arguments="{appliance:appliance}" >Add Host X</f:link.action>
This is the specific code line in the "Show.html" template that transfers the "Appliance" object to the Action "new" of the "Host" controller using arguments... The "Host" controller:
public function newAction(\Cjk\Icingaconfgen\Domain\Model\Appliance $appliance, \Cjk\Icingaconfgen\Domain\Model\Host $host = NULL)
{
$this->view->assign('appliance', $appliance);
$this->view->assign('host', $host);
}
At this point i get the following error message:
"Argument 1 passed to
Cjk\Icingaconfgen\Controller\HostController::newAction() must be an
instance of Cjk\Icingaconfgen\Domain\Model\Appliance, none given"
What am i doing wrong?
You need a Docblock that describes these parameters.
What may look like just comments, actually follows the PHPDoc standard. These declarations are interpreted by the TYPO3 ReflectionClass to map your Domain Model and validate parameters and object properties.
Make sure you completely flush the cache whenever you add or update one of these.
/*
* #param \Cjk\Icingaconfgen\Domain\Model\Appliance $appliance
* #param \Cjk\Icingaconfgen\Domain\Model\Host $host
* #return void
*
*/
public function newAction(\Cjk\Icingaconfgen\Domain\Model\Appliance $appliance, \Cjk\Icingaconfgen\Domain\Model\Host $host = NULL)
{
$this->view->assign('appliance', $appliance);
$this->view->assign('host', $host);
}
You need to be sure that there is an Appliance model given in your Fluid template, easily by debugging it before the link with e.g. <f:debug>{appliance}</f:debug>
If this is okay, you should add some doc comments above your newAction because Extbase is referring to that.
An example would be: (just as I am writing this, a good example was posted). :)
I've got a prestashop setup that has a small 'customization form' that currently saves the information to the products default customization text input. I did this to save time on having to write a complete custom module to add additional customization form fields and such.
Currently all the inputs are serialized (json) and entered as a long string into the text input like this:
Client Customization: %5B%5B%7B%22name%22%3A%22trophy%5B1%5D%5Bline1%5D%22%2C%22engraving%22%3A%22Test%20Trophy%22%7D%2C%7B%22name%22%3A%22trophy%5B1%5D%5Bline2%5D%22%2C%22engraving%22%3A%22test%20trophy%22%7D%2C%7B%22name%22%3A%22trophy%5B1%5D%5Bline3%5D%22%2C%22engraving%22%3A%221111111%22%7D%5D%5D
On the front end - when the customized data is displayed I can use PHP to decode & display it appropriately.
Is there a way where I can change that globally somewhere so I don't have to try and find every place where it might display and add that PHP code?
I'm running into the issue that I can't seem to find where to add the PHP code to 'decode' that string for the emails that are being sent out - so the long ugly string is being seen instead of the nice few lines of customization the user entered.
Any thoughts on how to handle this? Is there a spot where I can globally assign the decoded string to the products customization?
You could either try the PaymentModule class to decode the string just before the emails are sent, or Product's method called "getAllCustomizedDatas" for a more "global" approach.
And then test a lot, of course :)
Here's a quick draft of the second approach:
<?php
class Product extends ProductCore
{
public static function getAllCustomizedDatas($id_cart, $id_lang = null, $only_in_cart = true, $id_shop = null)
{
$datas = parent::getAllCustomizedDatas($id_cart, $id_lang, $only_in_cart, $id_shop);
/*
* Iterate over $datas, you're looking for
* [id_product][id_product_attribute][id_address_delivery][id_customization][datas]
* Datas will contain an array of fields broken by their type. You can then decode
* the ones that need to be decoded and return the result:
*/
return $datas;
}
}
I have a viewer helper function that loads the main content alongside the footer/header. The bug/unexpected behavior occurred when I loaded the array's key for the header that shares the same name for a variable in the main content view - the same array is loaded for both the header and main content.
I thought it's normal, since the same $data array was sent to the header and main content as-well(as mentioned before). So the variable will naturally be present in both views. But, well, it wasn't exactly like that. I unset the $data variable after sending the data to the header then re-created it when I wanted to send some data to the main view - but still the problem is not fixed.
I made a simple example for this bug/unexpected behavior:
Consider this view, named test:
<?php
echo $some_data;
And this controller:
class Test extends CI_Controller {
function index() {
$data['some_data'] = 'Some data.';
$this->load->view('test', $data);
/*
* Output:
* Some data.
*/
unset($data);
unset($data['some_data']);//Just to make sure it's not PHP's fault.
$this->load->view('test');
/*
* Output:
* Some data.
*
* Even though the $data variable is unsetted AND not passed!
*/
$different_data = array();
$this->load->view('test', $different_data);
/*
* Output:
* Some Data.
*
* Still outputs the same thing, even though
* I'm sending different array(and the $data array is unstted).
*
*/
}
}
Note: The whole code will output Some data. three times.
The only way to solve this issue is sending a different array and setting the array key(which is some_data) to something else which will override the old one.
So, is this a bug or something made by CodeIgniter's dudes?
we had the same problem like you and our Alien coworker found THE solution:
if file: codeigniter\system\core\Loader.php
find the code: (i think the line number is 806):
$this->_ci_cached_vars = array_merge($this->_ci_cached_vars, $_ci_vars);
and correct it to:
$this->_ci_cached_vars = $_ci_vars;
best regards
This is expected behavior.
Once variables are set they become available within the controller class and its view files. Sending an array in $this->load->view() is the same as sending an array directly to $this->load->vars() before calling the view file. This simplifies things for most people using multiple views in a controller. If you are using multiple view files in a single controller and want them to each have their own set of variables exclusively, you'll need to manually clear out the $this->load->_ci_cached_vars array between view calls.
A code comment in the Loader class describes another situation showing why this is the desired default behavior:
//You can either set variables using the dedicated $this->load_vars()
//function or via the second parameter of this function. We'll merge
//the two types and cache them so that views that are embedded within
//other views can have access to these variables.
This is a CodeIgniter issue. The variables you are sending in seems to be cached until you override them. I have encountered this myself and can verify it.
$this->load->view('test', array('some_data' => NULL));
where I want tu put an initial value.
I have seen that quicksearch has 'q' element but I can't access it, for example this does not find the q element:
$quickSearch->getElement('q');
How can I access the quicksearch in order to set an initial value?
Looking at the source of it can help you find things out. Agile Toolkit is designed in a way where developer should take advantage of the knowledge of the source code.
QuickSearch is derived from Filter which is derived from Form, so there should be addField somewhere. Looking at the QuickSearch, you'll find it inside recallAll() function. There are no calls to this functions so we should look into the parent class - Filter.
Filter sets up a hook in api to call recallAll after initialization have been finished. That means to be able to access the field you can either redefine a method or add a hook yourself.
Hook:
$this->api->addHook('post-init',function() use($quickSearch){
$quickSearch->getElement('q')->set('hello');
});
Extending
class MyQuicksearch extends QuickSearch {
function recallAll(){
parent::recallAll();
$this->getElement('q')->set('hello');
}
}
Finally you can take advantage of knowing where recallAll is loading their default values from and simply do this:
$quicksearch->memorize('q','hello');
to address this, we must first understand how the Search Field of the QuickSearch Class is added to the Grid Basic Class. so upon investigation of the source code, we can see that:
QuickSearch Class does not track (or save a PUBLIC reference of) the Form_Field q
Form_Field q is ONLY added DURING the Rendering phase of the grid
knowing these, we can now proceed adding the modifications to address item #1.
first, we need to add a variable to track the Form_Field q in the QuickSearch Class:
var $search_field=null; // add this line (1)
function recallAll(){
$ff=$this->addField('line','q','');
$this->search_field=$ff; // and this line (2)
parent::recallAll();
:
:
}
second, to address item #2, on our page where the grid is defined, we need add a follow-up hook, example:
class page_gridsearchtest extends Page {
var $search=null;
function init() {
parent::init();
$g = $this->add('MVCGrid');
$g->setModel('Employees');
if($g){
$this->search=$g->addQuickSearch(array('fullname'));
if($this->search)
$this->api->addHook('post-init',array($this,'MyHook')); // add hook
}
}
function MyHook(){ // hooked method
if($this->search->search_field) {
if($this->search->search_field->get()=='')
$this->search->search_field->set('Juan'); // set initial search if blank
$this->search->search_field->setCaption('Employee Name Search');
}
}
}
this will set a CAPTION beside the QuickSearch field and add a DEFAULT search text if the search field is empty.
if this is just a one-time thing, then this may be useful as a quick fix because directly making changes to the library source is very unorthodoxed and does not follow the OOP concept of extending and sub-classing as promoted by ATK.
I have a custom multi select attribute which I'd like to take part in filtering of products. The attribute is set as used in Layered Navigation however doesn't appear in the list of available filters. Could be due to custom model implementation?
Anyone have some tips where to check why it doesn't appear? Attribute is set for several products
Magento version used is EE 1.11
Thanks
For those who will struggle with this in the future: the problem is in Mage_Catalog_Model_Resource_Product_Indexer_Eav_Source file on line 191. By default multi select attribute values are being pulled from eav_attribute_option and if your custom attribute uses custom source model the attribute will not be indexed.
I don't know as of yet if it's intended but I couldn't find a better solution than overriding that model in local pull and adding required values in $options array.
Hope this helps someone, someday
What is the backend_type. i.e. are the values stored in the catalog_product_entity_varchar or catalog_product_entity_text table?
The backend_type has to match the checks in Mage_Catalog_Model_Resource_Eav_Attribute::isIndexable(), so text wouldn't work without rewriting the attribute model.
Is the is_filterable and/or is_filterable_in_search attribute property set?
The Mage_Catalog_Model_Product_Indexer_Eav::_registerCatalogAttributeSaveEvent() checks for those when updating the index for the layered navigation.
Are the methods getFlatColums(), getFlatIndexes() and getFlatUpdateSelect() implemented in the custom source model?
This actually is only required for building and updating the flat catalog product tables (so the used_in_product_listing or is_filterable property needs to be set in order for Magento to pick up the attribute).
Check the class Mage_Eav_Model_Entity_Attribute_Source_Table as a reference on what these there methods are supposed to return.
NOTE: I'm adding this in a new answer to use the code format.
How it was said, the problem is with multiselect attributes using a custom source model.
Solution:
Rewrite the class
Mage_Catalog_Model_Resource_Product_Indexer_Eav_Source
Override the method:
_prepareMultiselectIndex
add this code after the $options array is filled with the default code (check line 200 in original file)
foreach($attrIds as $attId){
if( ! isset($options[$attId])){
$options[$attId] = $this->_getOptionsFromSourceModel($attId);
}
}
add this method too:
protected function _getOptionsFromSourceModel($attId)
{
$options = array();
/** #var Mage_Eav_Model_Entity_Attribute_Abstract $attribute */
$attribute = Mage::getResourceSingleton('catalog/product')->getAttribute($attId);
/** #var Mage_Eav_Model_Entity_Attribute_Source_Abstract $source */
$source = $attribute->getSource();
$sourceOptions = $source->getAllOptions();
if($sourceOptions){
foreach($sourceOptions as $sourceOption){
if(isset($sourceOption['value'])){
$options[$sourceOption['value']] = true;
}
}
}
return $options;
}
I couldn't find a less intrusive way to fix this.