I'm trying to manipulate some code inside of a phpBB template file. Essentially, the forum descriptions contain some markup that needs to be converted before being displayed.
I am able to display the description using code similar to the following:
<!-- ELSEIF forumrow.FORUM_DESC -->
<li class="row"><span>{forumrow.FORUM_DESC}</span></li>
<!-- ENDIF -->
However, how can I wrap the forumrow.FORUM_DESC inside a html_entity_decode() function or something similar? I've tried moving the {forumrow.FORUM_DESC} into blocks, but the variables are different.
Probably not the best way to solve this, but I was able to modify the code to look something like this:
<!-- PHP -->echo html_entity_decode($_forumrow_val['FORUM_DESC']);<!-- ENDPHP -->
I was able to determine the values of the variables with a backtrace:
var_dump(debug_backtrace());
Again, may not be the best solution, but hopefully it helps someone else that hits this snag.
Related
My question is about nesting layouts in Laravel. I am trying to do so as seen below, which works in most cases but produces unwanted results in others.
\\MasterLayout
--code for header, navbar, etc.
#yield('content)
#yield('scripts)
\\SubLayout
#extends('layouts.MasterLayout')
#section('content')
<div>
#yield('sidebar')
#yield('main')
</div>
#endsection
#section('scripts')
<script>scripts needed in all the relevant views</script>
#yield('scripts.sub')
#endsection
\\Views
#extends('layouts.SubLayout')
--some code
#section('sidebar')
--sidebar code
#endsection
#section('main')
--main code
#endsection
#section('scripts.sub')
<script>scripts only needed in this view</script>
#endsection
In my own case, I have a further layer of nesting (a subsublayout). My controller simply redirects to the view without doing anything special. E.g.,
public function start()
{
return view('createproject/start');
}
This works pretty well in many cases, but there are some problems. For example, I can't simply include php files in the SubLayout that are needed in the views. Those includes have to go in the file in which they are being used in order to gain access to their functions. Also, placing <div></div> tags directly outside an #yield sometimes has a different effect than placing them directly inside the #section to which the #yield points. Also, while the pages work, I have gotten some strange warning messages such as that I have declared DOCTYPE multiple times or not at all, when neither is true as far as I can tell. So while the method of nesting seems to work, it's a bit unwieldy and I'm not convinced it represents best practice.
Hence, my question for the community is this: Is my suggested method of nesting layouts generally appropriate (perhaps with some caveats that address the problems I'm having) or does it exhibit some fundamental problem/confusion?
There is a related Stack Q&A that I've found here: Laravel multiple nested views but the nest() function referenced there is no longer discussed in more recent versions of the Laravel documentation (have I missed it?), so I wonder if it's still needed.
you can use components and slots for that
components-and-slots
I need to edit a page on prestashop, I've found that code
<ul id="idTab2" class="bullet">{$agencies->content}</ul>
And where should i search for that $agencies variable ?
I have found the text which is being displayed into that place in CMS.
However I'd that variable need to be define somewhere, am I right ? Anyone knows where should i search for that ? I'm new to prestashop.
Why am i asking for this ? I need to add another page for example
<ul id="idTab2" class="bullet">{$test->content}</ul>
- but I can't just simply add another page called test.
The {$agencies} variable is being set in a object derived from either the Controller or Module classes but to be honest it looks like you're working with code that has been customised (via a class override or a module) making it impossible to provide a definitive answer to your question without knowing more detail.
If you can locate the term 'agencies' in a file located under \controllers, \modules or \override in your installation, then you will be closer to finding your answer. It will be contained in a function call similar to:
$this->context->smarty->assign('agencies' , [some-variable]);
Note that the parameters to the function may also be passed as an array for multiple assignments.
I've been scouring the net in pursuit of this one. Magento Commerce comes us dry for me. grepping core code, reading Alan Storm, perusing Inchoo, and even finding related questions on SO turn up no answers for me.
With that said, my problem is with a transactional email template that works when processed from the backend but not from the frontend. Here's a snippet:
<td width="100%" colspan="2" align="left">
<!-- inject products quote table -->
{{block type="adminhtml/sales_quotation_email" template="sales/quotation/email_quote_items.phtml" inherits=$template quote=$quote salesrep=$salesrep}}
<!-- inject cross-sell products table -->
{{block type="adminhtml/sales_quotation_email" template="sales/quotation/email_quote_cross_sells.phtml" inherits=$template quote=$quote salesrep=$salesrep}}
</td>
In the backend, these blocks are rendered as expected. In the front-end, everything above and below these block directives is rendered, but it appears that the directives die in processing when it comes time to render the template. No errors are thrown.
I followed the advice here, but no luck. Originally I tried to use setDesignConfig on the email template model, but that didn't work. I even tried to set the area as an attribute in the directive, but that also did not work. A colleague suggested that I have two copies of the above templates: one set in design/adminhtml and the other design/frontend. I'd rather not have to worry about extra maintenance. Plus, I fear that I'd encounter the same problem if the block type specified in the directive comes from adminhtml. I don't want that solution.
So what am I doing wrong? What do I not understand?
How does Magento resolve the real path to the template, and is a template forced to reside in the area of its parent block?
Help is needed! Thanks.
SOLVED
I found a related post on Magento Commerce that put me back on track. I started dumping out the design configuration in two controllers: 1 in frontend and one in adminhtml. I noticed immediately that theme information was missing in the frontend request. See some sample output from my frontend controller:
Mage_Core_Model_Design_Package Object (
[_store:protected] =>
[_area:protected] => frontend
[_name:protected] => mypackage
[_theme:protected] => Array
(
[layout] =>
[template] =>
[skin] =>
[locale] => mytheme
)
[_rootDir:protected] =>
[_callbackFileDir:protected] =>
[_config:protected] =>
[_shouldFallback:protected] => 1 )
Notice that layout, template, and skin are empty in the theme property. When I dumped the design configuration from an adminhtml controller, these properties were set.
So going back to my frontend controller, I added the following line before I instantiated my email template model:
Mage::getDesign()->setArea('adminhtml');
Mage::getDesign()->setTheme('mytheme');
And poof! It worked! My blocks directives were processed and the fully rendered content was returned as expected.
So although my thinking was correct to set the area, that alone wasn't enough. I also has to configure the theme.
I'm happy with the solution. I hope it helps others. But to fully answer this question, I'm still curious if anyone knows why package information is missing from the design configuration during a frontend request. Does it have to do with the block type in the directive coming from adminhtml? That would make sense, because adminhtml has no need to worry about theme information. I just don't know where those decisions would be made in core code. See update below.
UPDATE:
Learned even more since the original post. My question gave a code sample that built a block of a type that came from adminhtml. The path to the template, I thought, was resolving to the front-end, and that was why no template could be found. That wasn't actually the case. An adminhtml block, because of its class naming convention, will look in design/adminhtml/package/default/module for your template.
However, in my particular Magento installation, I have a design override in local.xml that changes the admin theme so that it admin requests check design/adminhtml/package/mytheme/module for templates. And that is where my phtml templates are stored. So on a front-end request, the controller has no clue about this override, and is only building up the design configuration based on what is set in the store configuration for the particular package and theme.
In summary, my call to setTheme() must utilize that modified config data, like so:
Mage::getDesign()->setTheme(
(string) Mage::app()
->getConfig()
->getNode('stores/admin/design/theme/default')
);
I guess that goes to say, then, that a simple call to setArea() would be sufficient for most installations.
Finally, you will need to revert the design configuration changes after your work is done, otherwise subsequent actions might produce undesired results.
Anyway to examine the final XML structure magento comes up with after parsing & combining all the different XML files?
There is nothing of that sort which turned up on searching on the internet and I think for someone like me, magento layouts were a bit too much in the beginning & I would try to do everything on the code side.
Another thing which will help in picking up the name of different nodes that we can use, right away from the final XML structure.
Never ran into this but I believe we will have a better picture of what's overriding what.
The following will get you the merged configuration from app/etc/*.xml, app/etc/modules/*.xml, as well as each (active) module's config.xml file; when retrieving the config though there is no indication of what was overwritten, as the merges happen as each config file is being parsed:
Mage::getConfig()->getNode()->asNiceXml(); // or asXML() | asArray() | etc.
However, you seem to be asking about how the application makes use of this information. This is a function of application design.
Also, you mention "all of the different XML files." It's worth noting that these are not maintained in one massive object instance. For example, layout XML is accessed using the layout update object Mage_Core_Model_Layout_Update and can be accessed meaningfully after it's been loaded and manipulated for a given rendering scope (e.g. loadLayout() in a controller action):
Mage::app()->getLayout()->getUpdate()->asString(); // or asSimplexml() or asArray()
Yes - Commercebug. As well as a whole load of other useful features, you can also view the entire XML structure that Magento has produced.
http://store.pulsestorm.net/products/commerce-bug-2
I believe the following will output the XML: echo Mage::getConfig()->getXmlString();
You can create a script with something like this:
header("Content-Type:text/xml");
require_once '../app/Mage.php';
Mage::app();
echo Mage::getConfig()->getXmlString();
based on answer from benmarks I did
echo "<pre>".htmlspecialchars(Mage::getConfig()->getNode()->asNiceXml())."</pre>";
If you want for example to see the blocks configuration in Magento 1 you can put this in a file, place the file at the root of the site and navigate to it in a browser:
<?php
include("app/Mage.php");
Mage::app();
//just see blocks...
echo "<pre>".htmlspecialchars(Mage::getConfig()->getNode()->global->blocks->asNiceXml())."</pre>";
die();
I'm fairly new to Joomla (I've been more of a Wordpress guy) and I have a question about module positions.
Can a module know what position it's in. For instance can I do something like this:
if(modulePosition =='left'){
Do this...
}else{
Do that...
}
It seems easy enough, but I've searched for hours and can't find anything that will help me with that. I know there is a countModules function but from what I can tell, that just checks to see if the module is active or not.
Thanks for your help!
I found the answer! Mostly thanks to #Hanny. His idea of using the modules id got me googling for that and I came across the answer. For anyone else that happens to be looking to do something similar here it is.
You use a global variable $module (who'd a thought, right?)
So my code now looks like this:
$class = '';
if($module->position == 'position1'){
$class = 'class1';
}
and so on...
Pretty simple, huh?
To find out what else you can do with the global variable $module just put this in your code and see what info you can use:
echo(print_r($module));
Thanks for all your help!
The short answer is 'yes', you'll assign a module a position based on your template. When it shows up you can have conditionals like that regarding that position (different templates have different naming conventions for positions, so make sure you know what they are before coding).
For example, some use "Position12", others may use "leftcol", etc. You just have to check in the template files to see (you can check the .xml file in the template directory to see the positions listed in the template, or look in the index.php file for the jdoc includes).
In some of my experience, the only time you'll really ever need code like that is in the core layout files of the template (for example, if you have different widths of columns depending on modules being present or not), otherwise there won't really be a time where you 'may or may not' have a module showing up - because you'll explicitly be telling them where to be and when on the back end.
I tried to comment under john's solution but I don't have a enough rep points-- I wanted to add it doesn't matter what you name the module position in your template case-wise the position name you get back from $module->position is always all lowercase regardless of how you named the position in the template... ie. in your template xml somewhere you might have topBar position will be named 'topbar' not 'topBar' when you try to check it with
if($module->position == 'topBar') //always false... use instead
if($module->position == 'topbar') //what you need to use
I'm going to disagree with Hanny. I think the answer is no, not as you describe.
The template knows when it has reached a module position, and it gets a list of modules assigned to that position, then calls for them to be rendered. But it doesn't pass that information on. It's not stored in JApplication or JDocument etc either (like, nothing stores where in the template the rendering is up to or anything).
There are some hacky ways to almost get what you want though. If you know the template positions you need to search (sadly there's no easy method for getting this from the template - otherwise you could parse your template's .XML file for <position> elements...), then you could do something like:
<?php
$positions = array('left', 'right', 'top', 'bottom')
$found_in = false;
foreach ($positions as $cur_position)
{
$module_positions = JModuleHelper::getModules($cur_position);
foreach ($module_positions as $cur_module_in_pos)
{
if ($cur_module_in_pos->module == 'mod_MYMODULE')
{
$found_in = $cur_position;
}
}
}
if ($found_in)
...
Of course, this doesn't work well if your module is included multiple times on the page, but maybe that's an assumption you can make?
Otherwise it'd be up to hacking the core - you could use a JDispatcher::trigger() call before the template calls a module, set some var etc. Unfortunately there's no such event in core to start (a pre_module_render or something).
A module instance is assigned to a single position and this is stored in the database and normally you would style the position in the template. A module instance can only be assigned to one position. So while it's an interesting question, it's not really a practical one.
The exceptions to this are the following:
loadposition ... you might want to know if a module is being loaded using the plugin because this would put it potentially somewhere besides the styled area for the position. THough i would recommend always making a new instance for this precisely so you have more control.
loadmodule ... module loaded by name using the plugin. In this case again you are probably better off making a new instance of the module and styling it. Also I'd put it in a span or div anyway, depending what it is.
jdocinclude:module ... loading a module directly in a template. Again if you are doing this I would wrap it in a span or div. In this case you are also allowed to include a string of inline styles if you like that kind of thing.
Rendering the module to a string and echoing it, again that is basically a very customized solution and you would want to set the styles and options.