20
Try passing your relatedTo parameters as an array:
{% set members = craft.users.group('members').relatedTo([ 'and', { targetElement: services }, { targetElement: locations } ]) %}
or a little easier to read:
{% set entries = craft.users({
group: 'members',
relatedTo: [
'and',
{ targetElement: services },
{ targetElement: ...
13
The data in Craft is handled mostly by Models (and arrays of Models). Before pulling actual information, you define your criteria in an ElementCriteriaModel using generic parameters and parameters specific to what you are trying to get (entries, assets, etc.). You then use one of the ElementCriteriaModel's functions to pull the actual data. You will get ...
10
To be honest, those two parameters may seem to be slightly similar but provide a totally different functionality.
From their documentation on search:
search
Only fetch entries that match a given search query. (See Searching for the syntax and > available search attributes.)
Which means whatever you pass in .search(query), and there is a rather complex ...
10
When you call this:
craft.entries({section: 'games'}).relatedTo(category).relatedTo(craft.entries.section('reviews'))
that second relatedTo param is just overriding the first one. Lucky for you, that parameter does accept multiple criteria (see the “Passing Multiple Relation Criteria” section on http://buildwithcraft.com/docs/relations#the-relatedTo-param)....
8
One method is to build your params before performing the search.
{# set base params #}
{% set params = {
section: 'portfolio',
limit: null
} %}
{% set relatedParams = ['and'] %}
{# status #}
{% if craft.request.getParam('status') %}
{% set status = craft.request.getParam('status') %}
{% set params = params|merge({'companyStatus':status}) %}
...
7
There's still a few kinks to work out, but I developed a plugin that solves this problem using Craft's native Many to Many relationship that already exists.
Basically, I've created a field type that links the relationship from the other side of things and allows you to add entries to it.
You can find it here:
https://github.com/page-8/craft-manytomany
...
7
When you relate an element from a Matrix block, it's important to know that the relation is between the Matrix block and the related element; nor the entry (or whatever has the Matrix field) and the related element.
So, the correct way to select related elements through a Matrix field is:
{% set employer = craft.entries.section('companies').slug(segment) %}...
7
One approach would be to create a comments channel with an entries fieldtype (with sources checked for any channels that you want to allow commenting; limit set to 1) called 'relatedEntry' (or whatever you like). On your article template, include a for loop to display existing comments relateTo the entry. Check to see if there is a current user, and if yes, ...
7
This feature has now made it into Craft core as of version 2.6.
See this link for documentation on the subject:
https://craftcms.com/docs/templating/eager-loading-elements
7
I think this is what you mean:
{% set sectionBEntries = craft.entries.section('B').authorId(currentUser.id) %}
{# 'relatedTo' works both ways, so we can use sectionBEntries
as input for relatedTo to get all section A entries that have
a relation to one of the section B entries by currentUser #}
{% set sectionAEntries = craft.entries.section('A')....
7
Figured it out, trying to use the Entry as the source was wrong as the 'stores' relationship field actually belongs to the matrix field.
So by setting the matrix field as the source this is now working just fine!
craft()->relations->saveRelations($field , $matrixBlock, $relations);
7
If you want to do it in a single query, Marion's answer is probably the best.
Otherwise, you could do something like this:
{% set idsHavingCategory = craft.entries.section('news').relatedTo(category).limit(null).ids() %}
{% set omitIds = 'and, not ' ~ idsHavingCategory|join(', not ') %}
{% set entries = craft.entries.section('news').id(omitIds) %}
...
7
Since Apples and Bananas are children of Fruit, all entires that are related to Apples or Bananas are also related to Fruit, which is why you are getting the the results you are getting. If you need to exclude entries related to the subcategories, you can do something like this:
{% set dontInclude = [] %}
{% for child in craft.categories.descendantOf(...
7
The issue with your current code is that you're looping over each type/size category, creating a parameter in your relatedTo query for each one. This means that you're currently creating a query that looks like this:
relatedTo([
'and',
{ targetElement: 1 },
{ targetElement: 2 },
{ targetElement: 3 },
{ targetElement: 4 }
])
...which, ...
answered Jul 22 '18 at 13:03
Mats Mikkel Rummelhoff
18.8k3 gold badges26 silver badges59 bronze badges
6
You're very close! Try this:
$criteria = craft()->elements->getCriteria(ElementType::Entry);
$criteria->section = 'concepts';
$criteria->limit = null;
$criteria->relatedTo = array(
'targetElement' => $e,
'field' => $field
);
$elements = craft()->elements->findElements($criteria);
Keep in mind, in this instance, $...
6
Relations fields can store multiple related values (even if you only have one item). Perhaps try to pass an array to the 'quiz' value:
'quiz' => array($data['itemId'])
Alternatively, if you are submitting all of your content, in the correct format, you can get rid of your $entry->getContent()->setAttributes line and use the setContentFromPost ...
6
You can assign ingredients to recipes using the built-in Entries field type.
Then, to view which recipes an ingredient is used on, check out the Introvert plugin. It gives you a new field type that can be used to simply show reverse relationships, also providing links to edit those other entries.
6
I've been thinking about ways to achieve this recently, and I've put together a basic proof-of-concept plugin for fetching one level of relations for a collection of elements, with no more than two extra queries for each element type.
One query to get the IDs of the related elements, and then another to actually fetch and return the elements with the ...
6
Give this a whirl, Mark:
{% for image in craft.assets.relatedTo(tags).order('elements.dateCreated desc') %}
6
Check out the documentation for craft.categories which should do what you need. In this example, I assume that 'landing pages' are the same as your level 1 categories, in which case you don't need to deal with the entries at all:
{% set categories = craft.categories.group('navCategories') %}
<ul id="nav">
{# using 'nav' and 'children' will create ...
6
Crisis averted, thanks largely in part to the versitile nature of the relatedTo targetElement processing. The relevation came that I could feed an array of category ids (inclusive) into that element, and use a single relatedTo "and" parameter overall to get my intended filtering:
{% set params = {
section: 'technologies',
limit: null
} %}
{% set ...
6
Have a look at the 'Going Through Matrix' section at http://buildwithcraft.com/docs/relations#the-relatedTo-param.
{% set articles = craft.entries.section('articles').relatedTo({
targetElement: entry,
field: 'myMatrixField.fieldHandle'
}) %}
6
This is how relationships work in Craft at the moment. Each relation equals +1 query. If you don't access your relation on an entry the query isn't executed. So by only fetching title and/or id you don't run any extra relationship queries.
Caching is your best option at the moment to make the query count go down. Make use of caching to cache large chunks of ...
6
This should be as simple as setting the relation field (category, asset, etc.) value on the entry as an array of related element IDs before saving.
$entry->setFieldValue('categoryFieldHandle', [$categoryId1, $categoryId2]);
Craft::$app->elements->saveElement($entry);
This will work for all relation fields:
$entry->setFieldValue('...
5
You probably have to query a new ElementCriteriaModel for each asset in your loop and use the relatedTo parameter to filter the relevant "content" entries.
You could use the targetElement property with the relatedTo parameter to be more spezific on that relation. But you should be fine using the element property or the short syntax relatedTo(element), if ...
5
Completely untested, but try something like:
{% set ids = [] %}
{% if craft.request.getQuery('sector') %}
{% set ids = ids|merge([craft.request.getQuery('sector')]) %}
{% endif %}
{% if craft.request.getQuery('impact') %}
{% set ids = ids|merge([craft.request.getQuery('impact')]) %}
{% endif %}
{% if craft.request.getQuery('topic') %}
{% set ...
5
I've used this method before, works quite nice!
The way to do this:
Create the fields you need for commenting (name, message, etc.). Be sure to add a relational field to which you can later assign the 'parent entry'
Create a section (channel) called comments (or whatever else you want to call it)
Assign the fields to the section you just created
Use a ...
5
It appears the preferred way is by using getDescendants() — In fact, the children property is actually an alias for getDescendants(1). (The parameter specifies a maximum distance (i.e. number of levels) of the child from the parent.)
5
To answer my own question see below:
As carlcs pointed out correctly the problem actually isn't located in getting the category - which works just well and is the right way to do it - but in how the relation to the entries is done.
I should check if the tag (coming from the url) actually resolves to a "real" category, otherwise just all entries will be ...
5
I got this to work with search:
{% set uncategorizedEntries
= craft.entries.section('news').search('-category:*') %}
Here category is the category field. You are searching everything in news which does not have a category field that matches *.
Only top voted, non community-wiki answers of a minimum length are eligible