EEConf 2024 is around the corner! EEConf 2024
I just had a VERY smooth upgrade from v3 to v4 – congrats, EllisLab! – and now I am eager to make use of the new features, not the least fluid fields. I am just not quite certain how.
For example, I have an existing news blog that currently has a body field, an image field and an extended text field. My issue with this setup has been how inflexible it is in terms of where I can place images. So, can the fluid field type help me out even though there’s years of existing content within these fields? Can they be used within the fluid field from now on? Or will I need brand-new fields for this channel and a switch in the template to go from old to new?
Edited to add: I also can’t wrap my head around how I could use fluid fields if I normally display the body field and an image on the channel’s index and then you can click through to the entry to get body, image and extended text.
Updating a bit, as I have started experimenting with adding a fluid field to an existing channel. It appears that even if I tell it to include the pre-existing body field, image field and extended text field, I still end up with a new entry page that shows the pre-existing fields as separate entities outside of the fluid field, which makes for a bit of a confusing new entry situation.
It also looks like there’s no way of setting an order for how I want the fields to appear any longer, but they just default to alphabetic? That also seems very confusing.
Hi Linda,
Glad to hear the upgrade went smoothly!
Fluid is a new field type that allows site builders to give content editors more flexibility when entering content into Channel entries. There is no direct path from a traditional static field to a Fluid field. So you cannot assign an existing field to a Fluid field and have the content transfer.
For instance in your example, you have an existing blog with three static fields. If you add a Fluid field to that channel, even if you use the same three static fields in your Fluid field, the content will not transfer, as you are making a new instances of those fields that now live inside the Fluid field.
You would need to manually transfer the content from the static fields into the Fluid fields. Then after the content is moved over, you can remove the static fields from the Blog channel, and use jut the fluid field moving forward.
The fields inside a Fluid Field default to alpha sort, because they are reorder-able inline which is what gives them the new flexibility. All other field types should be re-arrangeable using Publish Layouts.
Sorry for any confusion this new field type has caused! We’re hoping that it will become a new tool, to work alongside the existing tools!
A follow-up question, now that I have had time to consider your description of the fluid field. If I understand correctly, the same fluid field could be used across multiple channels and the fields placed inside of it could also be used across multiple channels. So, if for organisational purposes I create a field group called Blog and place within it the fields Blog Content (fluid), Blog Text (textarea) and Blog Images (grid), I can then setup Blog Text and Blog Images as useable by the fluid field Blog Content and then assign Blog Content on its own to Blogs A, B and C? And further, in Blog A, B and C, each entry can use any combination of Blog Text and Blog Images, multiple times each if needed?
The thing I can’t grasp at all if all of this is true is how a particular instance of Blog Text within a particular Blog is identified? Lets say I want to show just the first instance of Blog Text on the index of Blog A, even if a particular entry maybe uses Blog Text 3-4 times. Is this possible?
Hi Linda,
A fluid field is exclusive to the channel to which it is assigned. Meaning that if you assign the same fluid field to multiple channels, each one will only interact with the channel it is assigned to. You cannot share content across channels using the same field, fluid or otherwise.
But you can share the individual and grouped fields across multiple channels, and each channel will mange it’s own content for each field it uses. Those channels just won’t be able to see the content of the other channels that use the same fields.
Migrating content from one field-type to another isn’t an easy task considering the near infinite possibilities. We are still discussing internally a potential solution, but it is not a high priority feature.
Right, I understand that even if you assign the same fluid field to multiple channels, it will essentially act as a different field for each channel. But in a specific channel, is there any way to identify a specific instance of a field assigned TO a fluid field? For example, a post uses three instances of a textarea field. Is there a tag that will retrieve just the first one, so that you can have an index that shows only part of a post?
Its understandable but disappointing that migrating isn’t a high priority feature. The flexibility of fluid fields is sorely needed for a couple of my channels, but mixing in a fluid field among the legacy fields would make the publish layout daunting to use for other editors.
I’ve not used the new Fluid field, but have used some 3rd party solutions that simulated or were potentially precursors to the idea, like Content Elements. My understanding in using those was that anything you needed to call separately, such as title or a summary was best as a pre-defined field and the ‘fluid’ field provided more control for writers/editors of fields that didn’t need to be specifically defined.
For example, we used ‘Content Elements’ with a client who did publications. There are a number of fields, while not absolutely required, we wanted pre-defined for the writers and editors— title, subtitles, languages, summary, cover_image, publish_date (which could be a month or so after the write date), etc. That said, fields like the body, additional_info, and research could be turned because it would be great to have the writer/editor control adding images, lists, text blocks, etc.
In this example, if we were to convert the client, I’d probably do the following: • add three new fields: body_fluid, addinfo_fluid, research_fluid; • add the following if/else statement: {if body !=""} display former layout {if:else} display new layout {/if} (since all legacy data would have a body) • hide/close the former fields on the publishing form.
Now, as I said, I haven’t used the new Fluid fields yet, and my first project is a brand new site. But this was my expectation after reading the description.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.