The default Phoenix project has app.html.eex and root.html.leex. In the routing file, I see plug :put_root_layout, {RoveWeb.LayoutView, :root} which specifies the root layout. However, I don't see anything similar for the app.html.eex layout. Is that explicitly defined anywhere, or is there a Phoenix default which automatically renders app.html.eex as a layout?
Yes, app.html.eex is the default application layout when you're not using LiveView.
More info here
Related
I created a custom config file for CKEditor using a yaml-file as suggested and registered it in my extension for my custom elements.
$GLOBALS['TYPO3_CONF_VARS']['RTE']['Presets']['custom_rte'] = 'fileadmin/templates/css/custom_rte.yaml';
This works fine as long as I'm in the default workspace.
When I switch to the draft workspace and save an element, the config is lost and I get the default Toolbar, without my custom css and buttons.
Any idea what this could cause?
Typo3 8.7.15
The solution was actually pretty easy.
I had to set the default preset for the CKEditor in the extension, instead of using the custom one and then set that in the Page TSConfig.
So this works (in ext_localconf.php)
$GLOBALS['TYPO3_CONF_VARS']['RTE']['Presets']['default'] = 'fileadmin/templates/css/custom_rte.yaml';
That way the CKEditor always uses my custom yaml-file. No Page TSConfig needed.
I am trying to build a tabbed application using Sticky States from UI-Router extras.
The contents of my tabs contain some directives that "register" themselves to a service. I would like to have, on initialization, a full registration so that the service knows all those directives. That means rendering the states in the background, without displaying them, as if the user manually clicked on all the tabs before starting to use the application.
Is there any way I can do this ? Thank you.
I'm currently developing a component that includes an "editor" field in his parameters (the form mandated by the com_config).
The value of the "filter" attribute of the field in the "config.xml" file is : "raw".
Despite all the HTML here is fired, remains only the textual content.
On this website I'm doing the same thing for the parameters of a plugin and It work very well here, so I think that it's not a story of Joomla! configuration or editor configuration (I use the same editor with the same user account) ...
Is it a constraint imposed by the configuration component ??
Thank you for your lights!
It is difficult to say without some code to look at, but the raw filter should not remove HTML.
You could try building the same functionality using http://www.component-creator.com and view the code it generates or simply just use the built component instead of your own code.
I have developed a Joomla module that does provides a form, processes its post data, does some calculations and displays the results.
The module includes a button to print the results. I'm currently using JavaScript to open a new window, paste the relevant HTML and open the print dialog.
Instead of JavaScript I would prefer to provide a separate URL for the print view and simply open that in a _blank target. This would make the application work better for people using screen readers or not having JavaScript available.
Is there any way that I can tell Joomla to not render the template along with my module? I was thinking that creating a component fixes that issue, but had to find that components are rendered into the template, too...
BTW: I have Joomla 1.5.22
To achieve what you want you have to add additional tmpl=component query string parameter to the request URL. This will disable template and module rendering.
Your URL will look something like this: index.php?option=com_xxx&view=xxx&tmpl=component
Since you are using Joomla 1.5 you can request index2.php?option=com_xxx&view=xxx and it will only render the component. Joomla 2.5 does not have index2.php so if you plan to migrate in future, don't use this option.
If you are using SEF then adding ?tmpl=component at the end on URL does the trick.
To go a step deeper... in your template directory you have component.php file, that is the file that's being loaded by tmpl param. You can copy component.php to my_component.php, do necessary changes and load your custom component template with index.php?option=com_xxx&view=xxx&tmpl=my_component
The joomla way of doing it would be to set your output to "raw", see this tut:
http://www.katcode.com/displaying-raw-output-in-joomla-by-setting-format-in-the-component/
I'm under the impression that the user agent stylesheet in browsers such as Safari, Chrome and Firefox is something that is internal to the browser and can't be directly modified (rather a style property needs to be overridden).
I'm also under the impression due to various websites including Mozilla's that the default value of the box-sizing property for Webkit and Mozilla is "content-box."
I tested this on a rather simple dummy page viewed in various browsers.
My problem is that on two pages in our production application the default property is different, and we can't figure out why this is.
One one page we see a box-sizing property of "border-box" in the Web Inspector or console. It's assigned to the CSS selector input:not([type="image"]), textarea.
On the other page there is no mention of the box-sizing property in the Web Inspector or console.
Does anyone know if there's some way to directly affect the box-sizing definition in the user agent stylesheet for a particular page? Maybe there's a library that does this? We're using prototype.js and swfobject.js in the application...
UPDATE: In case I wasn't clear on almost every page in my web application and in every "dummy" page I've tested on the box-sizing property has the default "content-box" value. For some reason one particular page in my web application shows in the web inspector that the user agent stylesheet (the one used by the browser for its defaults) has set that property to "border-box." I can't for the life of me figure out why this is. I'm looking for anything that might cause Firefox to change what its default value for that property is.
Just had this same issue. What was happening in my case was that someone had put a snippet of Javascript code above the <!doctype html>. As a result, when I inspected DOM through firebug, it appeared that the document didn't have a doctype.
When I removed the snippet of JS code such that the doctype declaration was at the very top of the file, the doctype reappeared and fixed the box-sizing problems I was seeing (the same one you had).
See:
Hope this helps.
I had the same issue on chrome which by default added the following user agent style rule:
input:not([type="image"]), textarea {
box-sizing: border-box;
}
After adding the doctype property <!DOCTYPE html> the rule no longer appeared.
No, you can't touch the browser default stylesheet, and yes, browsers do have different rules for box-sizing specifically in respect to form fields. This is for compatibility with old browsers that used to implement form fields entirely with native OS widgets that CSS couldn't style (and so which didn't have ‘border’ or ‘padding’ as such).
Why not just put your box-sizing/-moz-box-sizing/-webkit-box-sizing rule in the site stylesheet? Works for me, I often use this to make inputs with set widths line up across modern browsers. (IE 6–7 don't support it, though, so need some extra help.)