<p>After looking at this more, we realized the answer wasn't all that complex. We just needed a way to differentiate the context in order to write out the correct data from the single entry. In our case, we're having to build a map-based search engine for the site (think something similar to Zillow) and what we'll do there is simply check against each entry result and whether is has any Units flagged as "show separate" (the flag field will be one field in a Matrix block holding all relevant Unit data fields). If it does, we'll simply use the data from the single entry to return the appropriate number of results with the different Unit data.</p>

<p>Each of those results will then have a URL to go to a details view that includes a URL segment if the listing is a "separate unit" version. Something like: <code>sale/entry-id-or-slug/matrix-block-id</code>. (That Matrix block ID could also be another field in the corresponding Matrix block if we wanted to use the actual Unit number (ie. 203)).</p>

<p>Then the detail template will check for that last URL segment parameter and if it exists, it will use the corresponding Matrix data for that Unit and ignore the other Unit(s). And if it does not find that last URL segment, then it just returns a normal entry with all Units data not set to "show as separate listing".</p>

CC BY-SA 3.0
2017-03-18T08:55:40.640Z
2017-03-18T08:55:40.640Z
Mike
<p>One option to consider would be to use a <code>structure</code>, with the 'building' as a parent entry and the 'units' as children entries (with corresponding <code>entryType</code> of 'building' or 'unit' to set a unique field layout if needed). </p>

<p>Based on whatever logic makes most sense you could then display the building, the building with some subset of data from the units (children), or just the unit. The logic could be either an explicit checkbox or switch on the building or unit entries, or just the mere presence of unit entries (children). </p>

<p>In the structure's settings you can also set whether the 'unit' (child) URI pattern is <code>building/unit</code> (i.e. <code>{parent.uri}/{slug}</code>) or <code>building-unit</code> (i.e. <code>{slug}</code> or <code>{parent.uri}-{slug}</code>).</p>

<p>This should keep everything organized in the CMS and give you a lot of flexibility in terms of what to display where. The building can access the unit data and the unit can access the building data as needed.</p>

CC BY-SA 3.0
2017-03-18T09:00:01.680Z
Thanks Douglas. This certainly could work in certain contexts. However, I could see having to manage that structure adding a lot of admin work for the user. I forgot to set out that our site is built around a listings search engine (maybe I'm too close to the space and thought that would be a given). Anyway, our answer below takes that into account and means the admin never has to worry about anything other then adding and editing listing entries.
Mike
CC BY-SA 3.0
2017-03-20T17:16:15.527Z
No worries. That makes perfect sense.
Douglas McDonald
CC BY-SA 3.0
2017-03-17T21:52:53.103Z
2017-03-17T22:21:03.040Z
2017-03-17T22:21:03.040Z
Douglas McDonald
<p>We are building a Commercial Real Estate site for a fairly large commercial real estate company and we're coming from an older custom-built site and there is a work flow and associated data logic we're having trouble figuring out how to best replicate in Craft.</p>

<p>When they list properties for sale or lease, they have a set of common fields for a given building (ex. address, photos, city, etc) and then sometimes need to add Units within that building, each with its own set of fields (ex. size, unit number, price, etc).</p>

<p>Sometimes these Unit(s) get listed all together on the one listing (or in the Craft sense, entry) on the front end. However, sometimes they need to be listed separately on the front end (ie. individual Units can be chosen to show up as their own listing (or separate entry)). This is in varying combinations (ie. any Unit could be flagged to show as separate - but not all Units need to). In this case, those separate Units still share (and display) the common building fields (ex. address, photos, city, etc).</p>

<p>What this means from an entry point of view, is we potentially need multiple URL slugs to get to each listing when some Units are flagged to show separately (for example: sale/building1, sale/building1-unit200, sale/building1-unit303 ...or whatever).</p>

<p>So what we're trying to solve us how to handle this. We are trying to preserve an intuitive and easy workflow for the editor, where they go add a new listing on one entry page, and via a Matrix field could add multiple Units - and within each Matrix Unit block, could have a toggle field that says "Show this unit as a separate listing").</p>

<p>The question then is how to access those "show as separate" units on the front end as they technically all share the same URL slug?</p>

<p>We briefly considered using related fields (separating out units as entries and the common building data as entries) but that would become incredibly difficult to remember, maintain and organize for which units belonged to what buildings across many hundreds of listings and thousands of units. As well, many buildings do not even have units.</p>

<p>We also considered a custom plugin that would create a duplicate entry for each flagged Unit when the entry is saved (and conversely remove duplicated entries when a Unit is unflagged). That seems kludgy and possibly complicated but maybe we're wrong on that? Also, not certain if there'd be a way to hide those duplicate entries from users in the CP so they're not confused by those (as they're always thinking that they work on one single entry for each building with its units).</p>

<p>Any thoughts on how to tackle this would be greatly appreciated.</p>

CC BY-SA 3.0
2017-03-17T15:51:42.137Z
"The question then is how to access those "show as separate" units on the front end as they technically all share the same URL slug?" For that particulair issue you could just make a light switch or checkbox if you'd like and just show this type of unit only when the lightswitch or checkbox is active. What I do most of the time is play around alot with these. This way you can be really efficient with creating options for webpages or matrix blocks so you don't need alot of blocks / different types of entries
Justin Dekkers
CC BY-SA 3.0
2017-03-17T16:15:21.663Z
Thanks Justin but I don't think that addresses the core issue. If a listing has 3 Units and 1 is set to 'show separate' then on the front end there are 2 versions of this entry to show - one for the 'separate unit' version and one for the listing with the 2 other units. They both exist as separate listings to the public end user - but originate from one entry.
Mike
<entry><url>
How to show variations of a single entry? Even possible?
# How to show variations of a single entry? Even possible?

(Asked by: username_0 on 2017-03-17)

We are building a Commercial Real Estate site for a fairly large commercial real estate company and we're coming from an older custom-built site and there is a work flow and associated data logic we're having trouble figuring out how to best replicate in Craft.

When they list properties for sale or lease, they have a set of common fields for a given building (ex. address, photos, city, etc) and then sometimes need to add Units within that building, each with its own set of fields (ex. size, unit number, price, etc).

Sometimes these Unit(s) get listed all together on the one listing (or in the Craft sense, entry) on the front end. However, sometimes they need to be listed separately on the front end (ie. individual Units can be chosen to show up as their own listing (or separate entry)). This is in varying combinations (ie. any Unit could be flagged to show as separate - but not all Units need to). In this case, those separate Units still share (and display) the common building fields (ex. address, photos, city, etc).

What this means from an entry point of view, is we potentially need multiple URL slugs to get to each listing when some Units are flagged to show separately (for example: sale/building1, sale/building1-unit200, sale/building1-unit303 ...or whatever).

So what we're trying to solve us how to handle this. We are trying to preserve an intuitive and easy workflow for the editor, where they go add a new listing on one entry page, and via a Matrix field could add multiple Units - and within each Matrix Unit block, could have a toggle field that says "Show this unit as a separate listing").

The question then is how to access those "show as separate" units on the front end as they technically all share the same URL slug?

We briefly considered using related fields (separating out units as entries and the common building data as entries) but that would become incredibly difficult to remember, maintain and organize for which units belonged to what buildings across many hundreds of listings and thousands of units. As well, many buildings do not even have units.

We also considered a custom plugin that would create a duplicate entry for each flagged Unit when the entry is saved (and conversely remove duplicated entries when a Unit is unflagged). That seems kludgy and possibly complicated but maybe we're wrong on that? Also, not certain if there'd be a way to hide those duplicate entries from users in the CP so they're not confused by those (as they're always thinking that they work on one single entry for each building with its units).

Any thoughts on how to tackle this would be greatly appreciated.

**Tags:** entry, url

> **Comments:**
> **username_1**: "The question then is how to access those "show as separate" units on the front end as they technically all share the same URL slug?" For that particulair issue you could just make a light switch or checkbox if you'd like and just show this type of unit only when the lightswitch or checkbox is active. What I do most of the time is play around alot with these. This way you can be really efficient with creating options for webpages or matrix blocks so you don't need alot of blocks / different types of entries  
> **username_0**: Thanks Justin but I don't think that addresses the core issue. If a listing has 3 Units and 1 is set to 'show separate' then on the front end there are 2 versions of this entry to show - one for the 'separate unit' version and one for the listing with the 2 other units. They both exist as separate listings to the public end user - but originate from one entry.  

---

## 2 answers

### Answer by username_0 on 2017-03-18. Score: 1 | Accepted answer

After looking at this more, we realized the answer wasn't all that complex. We just needed a way to differentiate the context in order to write out the correct data from the single entry. In our case, we're having to build a map-based search engine for the site (think something similar to Zillow) and what we'll do there is simply check against each entry result and whether is has any Units flagged as "show separate" (the flag field will be one field in a Matrix block holding all relevant Unit data fields). If it does, we'll simply use the data from the single entry to return the appropriate number of results with the different Unit data.

Each of those results will then have a URL to go to a details view that includes a URL segment if the listing is a "separate unit" version. Something like: `sale/entry-id-or-slug/matrix-block-id`. (That Matrix block ID could also be another field in the corresponding Matrix block if we wanted to use the actual Unit number (ie. 203)).

Then the detail template will check for that last URL segment parameter and if it exists, it will use the corresponding Matrix data for that Unit and ignore the other Unit(s). And if it does not find that last URL segment, then it just returns a normal entry with all Units data not set to "show as separate listing".


---

### Answer by username_2 on 2017-03-17. Score: 1

One option to consider would be to use a `structure`, with the 'building' as a parent entry and the 'units' as children entries (with corresponding `entryType` of 'building' or 'unit' to set a unique field layout if needed).

Based on whatever logic makes most sense you could then display the building, the building with some subset of data from the units (children), or just the unit. The logic could be either an explicit checkbox or switch on the building or unit entries, or just the mere presence of unit entries (children).

In the structure's settings you can also set whether the 'unit' (child) URI pattern is `building/unit` (i.e. `{parent.uri}/{slug}`) or `building-unit` (i.e. `{slug}` or `{parent.uri}-{slug}`).

This should keep everything organized in the CMS and give you a lot of flexibility in terms of what to display where. The building can access the unit data and the unit can access the building data as needed.

> **Comments:**
> **username_0**: Thanks Douglas. This certainly could work in certain contexts. However, I could see having to manage that structure adding a lot of admin work for the user. I forgot to set out that our site is built around a listings search engine (maybe I'm too close to the space and thought that would be a given). Anyway, our answer below takes that into account and means the admin never has to worry about anything other then adding and editing listing entries.  
> **username_2**: No worries. That makes perfect sense.  

---

