Up through Middleman 3 I could determine the layout of the current page like this.
current_page.data.layout
As of Middleman 4 this no longer works. How can I determine what the current layout is in 4+?
In Middleman 4, you can access the layout of a resource with resource.options[:layout].
Related
I'm working on a store with 14,500 categories. It takes over 8 seconds to load the homepage.
I'm trying to limit the level of subcategories that are pulled in as a resource, thus dramatically decreasing the amount of data being loaded on each page bc I only need 1 level on the nav menu.
I don't see anything in the control panel, front-matter, or config file that would do this. I know this was in Blueprint, so I figured it would be in the config file but no luck.
Is this possible? Any ideas?
So I changed the store back to a Blueprint theme, and changed the category display setting to only show 1 level. Then switched back to my Stencil theme. Debugged the local JSON locally and that did the trick. Now the store is only loading 1 level deep of categories. I have no idea why this setting was overlooked in Stencil and not included in the config file.
In my plugin I need to track when a user views an issue using UI. Ideally I'd like to know if it was opened directly, or was viewed in Issue Navigator Detail View. I need to track who and when viewed an issue.
What's the best way to do this?
Cheers,
Oles
The most straightforward way would be to use a Servlet Filter plugin module and scan the requested URL for those corresponding to issue views. You can generally distinguish between viewing the issue directly and a view from within the Issue Navigator by examining the query parameters.
Alternatively, you could also build a Web Panel plugin module that renders no significant UI, but which would always be invoked when an issue is viewed. You'd probably want to position the web-panel on the right side of the issue view with atl.jira.view.issue.right.context.
In either scenario above, you can fetch the current user from an injected JiraAuthenticationContext.
I successfully installed MvcSiteMapProvider, and got the breadcrumbs working and customizing the templates to generate Twitter Bootstrap navbar menu. Everything is honky dory. Now I'd like to have a view which sole purpose would be to display the whole sitemap hierarchy (in a tree structure, nodes would be clickable).
I've found traces of old ASP.NET sitemap solution to XSLT transform the sitemap XML file. That's not only a dead-end because it's old and doesn't look like a good idea, but I also take advantage of the annotation feature of MvcSiteMapProvider.
I don't use external DI framework.
I turn to here because my search attempts came out empty. I guess I could do something like the bootstrap navbar customization, creating some templates. But I'm sure I'm not the first one and I'd be happy to see some working code if there any out there.
Per the documentation:
Html.MvcSiteMap().SiteMap() - Can be used to generate a list of all pages in your sitemap
If that doesn't meet your needs, you could always build your own custom HTML helper to display the SiteMap per your requirements. Have a look at this answer for a demo showing how to create Next and Back links according to the document outline of the SiteMap.
I tried the simple approach: editing the Contact page in the admin interface and selecting my new template within the Advanced Options section. But the form does not get displayed.
I also generated the override views:
rake refinery:override view=refinery/inquiries/inquiries/*
But looking at the app\views\refinery\inquiries\inquiries\new.html.erb file, I did not see an obvious solution to this issue.
I found this issue on github but it does not offer much detail: https://github.com/refinery/refinerycms-inquiries/issues/45
I suspect a big part of the issue is that when I change the template setting under Advanced Options, it's changing the view from the default inquiries new.html.erb to one of the standard view options. The problem is inquires extension new view is not listed as an option.
The short answer here is: you can't.
In the course of struggling with this, I came to realize that in most cases you probably don't want to be switching layouts. Not in the casual manner that I was, anyway.
What I really wanted were alternate page views. The basic web page layout and styling can be fully modified through views.
Realizing this changed my objective. I didn't need to change the layout for the inquiry pages. I needed to match the inquiry page views to my default page view. I was able to do this by overriding the inquiries extension's new and thank-you views and editing those files so that the markup and styling matched that of my default page view.
Simple enough. The only downside is it's a bit un-DRY. If I were to alter my page view, I now would likely have to repeat the changes in those two views as well.
websphere portal 8 comes with default dojo 1.7.2, and this dojo documentation for lazytreegrid if for dojo 1.7 http://dojotoolkit.org/reference-guide/1.7/dojox/grid/LazyTreeGrid.html
But when I run the example in the documentation, the treegrid is displayed like in image1. But when I use the same example, the treegrid is displayed in portal 8 differently(image2), which is quite ugly, how to get the same look and feel as in documentation
The example on the Dojo site is using "Claro" and your Portal site is using a different theme (I'm not sure which one, I think Soria).
The different themes can be loaded as modules in the Portal theme (not to be confused with the Dojo/Dijit theme).
Here's the wiki page:
http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=IBM+WebSphere+Portal+8+Product+Documentation#action=openDocument&res_title=Dojo_and_WebSphere_Portal_wp8&content=pdcontent
Look at this paragraph:
The tundra class is set on the body element in the portal Web 2.0 themes, and its corresponding CSS files are linked in as well. To use a different theme within a particular portlet, do not change the CSS classes of the body element from within the portlet because it has consequences on all other portlets and theme components that use Dijits on the page. Instead, use a separate node within the portlet to contain all the widgets used by that portlet, and assign the different theme class name on the container node inside the portlet.