Mosaic: Relation fields in mosaic layouts

I have a custom dexterity content type which includes a relation field. When I add that field to my mosaic layout it returns a uid instead of the actual link to the related field.
Here's the code as it shows up in the mosaic layout editor. The 'instructor' field is a relation field. I'm guessing I'll need a special relation tile or something.

 <div class="movable removable mosaic-tile mosaic-instructor-tile">
          <div class="mosaic-tile-content">
          <div data-tile="./"></div>

I think I will need to explore rapido tiles for this

1 Like

I have tried to get this working with a 'normal tile' (and I also tried with theme fragments tile )for long without luck, I am pretty sure there are some bugs.

... which means you should keep an eye on the different versions of the 'sub-packages'.

How does do it?

I'm having some serious usability issues with Mosaic, and at this point can't see how I'd ever recommend it to anybody.
I'd love to contribute to the Mosaic user story, and really appreciate David's recent comparisons to other widely used site/layout builders... There's a lot there to emulate.

Ran updates to be able to test v2.x on a test site and still problems.*
Can't add links in a text field.
Select text. Hit 'link' icon in TinyMCE bar, panel opens, insert URL in external link field. Hit Apply. Sometimes three times before the panel goes away. Nothing changes. No link.
Indeed, I can't even do it manually, since the <> tab is not in the MCE bar (is there in v2 but still...)
So I don't mean to hijack your topic David, but does anybody have an idea why this is happening? Pointers?

*I posted an issue on problems with the site update over a week ago, and have had no input on that at all.

which includes my current buildout.cfg and tracebacks

Not sure where else to go with Plone questions.
Can I buy someone a beer to take a look at this issue? Or ???

Sorta feeling lonely out here!
Thx and remember
"Resilience is the new optimism" :wink:
(I'm trying, I'm trying... Uh, politics!?)

Hmm. Well, that's weird. Immediately after describing this Mosaic problem, I went back to the site, in the same browser I'd been using all along, and was able to add a link with no problem at all.
Loki? Coyote? Mercury retrograde!?

1 Like

always check your browser's console to see what JS errors are reported

1 Like

Hey Peter,
I'm seconding @tkimnguyen on using the JS console of your browser If it crops again.

1 Like

OK. It is not working in Safari, throws this error when I hit the Edit button to edit the page.
TypeError: undefined is not an object (evaluating 'f.createRange') logged-in.js:7548

I also get a whole string of these as the page is loading initially:
patterns.Patternslib Base: This pattern without a name attribute will not be registered!

Hmm. The same errors come up in Chrome and Forefox, but indeed, I'm able to make the link work there... Some weird Safari glitch?
Who knows!?!
Too much for my aching brain!


Yes, often different browsers have different problems :slight_smile:

It's most useful to look at just the errors (red) not so much the warnings (orange/yellow).

If you click on the logged-in.js:7548 can you show us the bit of JavaScript that is there?

So back on topic.... about those relation fields and mosaic........

1 Like

The default field tile implementation should render the configured display widget of the field in question. If the result is different from the dexterity content default view and issue with example content type schema should be filed into (It's curious that it renders UUIDs, because the relation field should store "Relations" by default, not UUID.)

So, plone 5.1 over here. over a year later. Just saw this same behavior.

Any updates?

I'm getting to the point where I might be considered "professional level expert in Plone and Mosaic" @datakurre So I might be able to do something to help here.

I use both from z3c.relationfield.schema.ReationChoice and RelationList in my schema without specifying a widget. Maybe that's the issue.

Field is:

top_story = RelationChoice(
    title=_(u"Top Story"),
    description=_(u'Top Story being displayed on this Subsite.'),

widget.render() returns
<span id="form-widgets-top_story" class="text-widget relationchoice-field"> 1a6650c9066c46518c6b2f5d4cc7261a </span>

I played with this a little today, trying a hack inside standardtiles and got "results", albeit wrong results (main template was rendered), but the concept held water.

def __call__(self):
    if widget is not None:
                return self._render_reference(widget.value)
         return self._wrap_widget(widget.render())

def _render_reference(self, uid):
    """ take a uid from a reference field, de-reference it to existingcontent and render"""
    from zope.component import getMultiAdapter

    existingcontentview = getMultiAdapter((self.context, self.request),
                                          name='')['content_uid'] = uid
    return existingcontentview()

Figured I'd duplicate the existing content view behavior at least.

Wrong path? Better idea?

Not really sure what you are trying to do here.
Please dont change what the reference widget stores (it will brek a lot of stuff)

If you have your own for the tile, why not just find the content with plone api?

In your, something like:

def get_relitems(self):
linked =['relateditems'] // or whatever your field is called
linked_items = self.context.portal_catalog(UID=linked)
return linked_items (or linked_items[0] if you have relateionChoice and are sure there is only one related item)

Or maybe (in some cases… maybe this is needed if you want the image later)


Then in your you can use normal stuff like

tal:repeat="rel_item view/get_relitems"


<h1>${rel_item/Title} </h1>  etc

To answer myself, this seems to be handled by value converters in (UUIDs from widget are transformed to objects for the field and other way around).

I believe that this is the current standard behavior for related items field. The responsible package is that does register the interactive input widget for related items field, but only registers very generic display widget for it.

The generic field tile from does its best to find the currently configure display widget for the field. So, registering a proper display widget for those fields should make the trick.

Related items behavior does not seem to rely on the standard registration, but does schema annotation based registration. at master · plone/ · GitHub

If I understand you right: The uuid of the relations content is stored.

The opposite. I was wondering, why I see UUIDs when RelationObjects are stored. Yet, that was correct behavior, because there is z3c.form converter registered to do the conversion.

How can I check (for my tiles) that RealationObjects are stored.

When I (for example) do: view/data/relationField , I get the uuid. Does that mean this has passed through the converters. If so, is it possible to read it another way (as 'raw')?

Well, I only now realized that RelationValues (the correct class name for "RelationObjects") can really only be stored on PersistentTiles. And it did work in 2011 when I created data managers for that Added RelationListDictDataManager. · plone/ · GitHub

Later I realised that RelationValues make no sense on tiles, because RelationValue should be traversable to use the benefits of relation catalog (like back rerferences).

But now I am again puzzled on what makes RelationField to successfully save UUID on a tile instead of just raising some kind of adaptation error... I don't know right now.