I am studying Views, and I’ve already figured out all the settings, but I don’t understand why these three settings are needed. I marked with arrows the settings that I don’t understand.
And in FORMAT -> Show -> Fields -> Settings:
Header is used to add content before the view, this might be a title, computed element, another view, etc.
Use Aggregation can be used to group various fields together with different methods, implementing SQL aggregate functions. This can be used to, for example, count results of various fields together.
Provide default wrapper elements tells Drupal to add some basic html elements around the fields to make it layout a bit better, but it does mean that it is harder to style, for instance:
With default wrapper elements
<div class="field-test">
<span class="field-test-wrapper">
<li class="field-test-value">Some value</li>
</span>
</div>
Without default wrapper elements
<li class="field-test">Some value</li>
Some other good places to look for help and information are:
https://www.drupal.org/docs/8/core/modules/views
https://www.youtube.com/watch?v=dJD7GZanDuY
https://www.sqlservertutorial.net/sql-server-aggregate-functions/
Related
I'm looking to find a way to show an image in some various 2sxc drop-down controls. The image would help visualize some style guides. The most obvious example would be where we have a drop-down that gives the user the ability to select a few different heading styles. Variances in heading styles are often much more complex than h1,h2,h3,h4 (also some projects could have upwards of 15 heading styles) and if we could give the end-user a visual representation of how each drop-down might alter the view, I think this would go a long ways to help end users managing content.
This gets a little complex because while something like content types and views already have an image thumbnail, in a more dynamic content type with more flexible data entities, the end result could vary significantly.
I think drop-downs are the most common use case for a image representation because drop-downs or bools often have the largest change in final view code.
I don't think there is currently a way to do something like that unless you want to build your own custom input controls (which I do think is possible). A useful alternative is the Notes field for your Content-Type field. This is WYSIWYG and as of v10+, is also visible in the content editor's UI. So you can include a separate reference page link right there. We do this all the time lately. For example, we often use Bootstrap Buttons and Alerts and most sites have these in customized colors, so we include a link to a page (opens in new window/tab) that shows them what the various choices will look like.
Note that in 2sxc 9 and 10 you can create custom input types. It's fairly difficult in V9 and V10 will have a different API (because it's using WebComponents now). It's still not final and not documented, but that would be an option. If it's really urgent you can contact us through 2sxc.org
Let's say I have two pages, MyWebsite/website/index.html and MyWebsite/website/item.html. Is it possible in AEM for index.html to use menu1 and item.html to use menu2, while each menu is completely different?
This is easily doable. There are so many possible ways of accomplishing your goal; how you do it is going to be based on how you've decided to architect your pages, components, and authoring UX.
If you hard include the navigation component into the page, you could have the index and item pages use different templates and page types. One page type could inherit from the other with only the partial which includes the navigation overlayed. Each page type would hard include a different navigation component.
You could use a single page type with a hard included parsys where the author can use either of your two navigation components.
You could use one page type and have the option to change the navigation component resource type in the page properties.
You could have a single navigation component with the option to change designs in the component dialog.
If by "totally different" you mean that the component style and functionality remain the same, just the link text and destinations change, then you can use a single page component and a single navigation component. The component might read the sibling and/or child pages and dynamically create the links. This is a common scenario.
If you want the navigation component to inherit down to subpages, you can use an iparsys or a regular parsys and InheritanceValueMaps. Both are common practices with different effects depending on your goal.
This was a very broad question. If you choose a direction that you want to go and post code with more specific questions, we can be of more help.
I'm developing an online magazine, and am using Views to generate blocks for the homepage.
I am using a slightly customized Article as the content type for most of my data, with Views providing blocks with the necessary fields from those Articles. For example: the Latest Blogs View shows the Short Headline and Teaser fields, but the Top Headline View provides a block with the Image and Full Headline fields.
Right now I'm using Views to filter Article by tag, so Articles need to be tagged to show up on the homepage. Most of my blocks are lists and don't need the tightest sorting flexibility. However, some blocks are not lists, or it's important for the end user to have control over the display order of Articles in certain blocks. Is there a way to enforce site-wide 1:1 tagging for term:article relationships. For example, I want to ensure that only one Article is tagged top.news.1 (the first Top News slot), and likewise only one article is tagged top.news.2. When someone wants to add top.news.2 to an Article, the one Article that already has that tag will lose it. Or something like that.
I have played around with Views enough to gather that it is really powerful, so this level of microcontrol might not be necessary with the right configuration, but I think restricting taxonomy versus configuring Views filtration would address the problem more directly.
I've looked around the web and haven't been able to find anything really relevant. Sorry if I missed something obvious.
Thank you!
Is it correct that you (or your site editor) want the ability to:
spotlight a certain nodes
arbitrarily change the order of the spotlighted nodes, or add/remove a node from the spotlight while keeping the position of the other nodes?
If so, your best bet is likely Nodequeue, which does exactly that, and allows you to restrict the number of nodes spotlighted. It's very easy to use and our non-technical clients have no problems with it.
If your use case is different from that or requires more flexibility, Nodequeue may not be the right fit, but it works great for the specific example you're describing.
I'm currently working on a Drupal site (I'm fairly new to Drupal) and need to be able to create some blocks of content that appear on multiple pages and remain consistent between those pages. I'll need it so that if I change the content in one place, the change will be reflected in all places it appears.
I've looked around in CCK a bit but can't seem to find a way to accomplish this there. Is there a way to accomplish this?
Thank you!
You can define your own blocks at /admin/build/block/add, just put your content inside a block and then go to "page specific visibility settings" and put the pages, on which the block should appear there.
There are other ways to achieve something like you describe, if the blocks don't do what you need you should provide some more details on what exactly you want to do. Depending on the structure of your site, you could also use a node (set to appear at the top of lists) that is set to appear on those pages.
It would depend of what kind of data you need to display in this block if its static use
/admin/build/block/add
if you intend to fetch some content from your content types use views to create such block and then use "page specific visibility settings".
We are contracting an external consultant out to generate XHTML (Transitional) and CSS for most of the major pages of a new project we are currently working on.
I've been asked to put together a list of guidelines for them so that we can be sure that a certain level of quality can be expected. As a bit of technical background, we will be incorperating the raw HTML they provide into an ASP.NET web forms application (utilising the usual master pages / external stylesheets / jquery). Javascript should not be a consideration, but formatting and organisation of CSS should be.
I've made a start but quickly realised that this is probably not a unique situation and that a tried and tested list might be out there somewhere that I can at least use as a template! Has anyone got any experience of this?
From a technical standpoint, pages must pass validation is probably the first test I'd have.
I would expect the site to be able to be used by someone with JavaScript disabled, and someone using a screen reader (this is quite a good one as it should also highlight issues with inappropriately used tables and other things such as missing image alt tags, inconsistent use of header tags etc.).
One good test I always make for myself is opening the page and ctrl+scroll.
The zooming gives you an immediate idea about how flexible and liquid your design is.
In IE this tends to fail no matter what, but there you could also try to make the font bigger and see what happens (pay attention to buttons stretching vertically for example)
Give them a list of browsers (browser version and OS) you expect them to support.
Should the accessibilty guidelines be adhered? You could agree on supporing some of the points in the Checklist for Web Content Accessibility Guidelines. The list is actually quite usefull, since it will not only insure that your site works for people with disabilities but also for browsers without JavaScript, CSS, Images. The list also contains some general good practices for building sensible web sites.
Since you're using ASP.NET make sure that they only include one <form> per web page. Or at least, be prepared to make some workarounds, if you allow them to use more.
If you're planning on using AJAX show them ASP.NET AJAX Control Toolkit so that they don't spent time on things that have already been built.
I would insist on that they use some proven frameworks like YUI css reset and jQuery.
One thing that makes passing an HTML / CSS template between multiple front-end developers is proper structuring and indenting of the markup. The same way books are broken down into volumes, chapters, paragraphs, sentences, words, spaces, and periods, there is a hierarchical structure that makes HTML and CSS easy to read (and on the other hand a way of coding that makes things a total mess)
As a rule of thumb:
<body>
<div id="first">
<p>
Some text goes in here...
<p>
<ul>
<li>A list item</li>
<li>A list item</li>
<li>A list item</li>
<li>
<ul>
<li>
A link
</li>
</ul>
</li>
</ul>
</div> <!-- #first ends -->
</body>
This kind of adherence to structure can really cut down on time by making scanning code super easy for whoever is working on it– regardless of whether they wrote it or not.
Apart from validation the following points should be keep in mind
- Accessibility (Who are the audience)
- CSS based design (Where semantics are well designed)
- Be consistent with your naming convention (css and id naming. This will be beneficial in the long run when any change needs to be made, when a new css has to be applied etc).
Check out the following best practices from yahoo developer library...
http://developer.yahoo.com/performance/rules.html
Also since you are using ASP.net be careful when naming usercontrols as the client side ID that is generated could be quite long and unexpected(asp.net generates the id at runtime);
Some good info could be found at
http://woork.blogspot.com/2008/11/useful-guidelines-to-improve-css-coding.html
Indeed, make sure that the page passes validation.
Also pay attention to semantics, the page should be in a logical order when CSS is disabled (which is the case for some browsers and screen readers). Make sure that headings are actually <h#> tags and that all images have appropriate alt tags. Also make sure tables are only used to display information and are not used for formatting. The menu should be constructed as a list not as divs (semantics).