The way I create relationships between fake post types via Flutter is really hacky, but for the projects I was working on, it was acceptable. The idea is that you eliminate the need for the general "Posts" write panel (which Flutter enables you to hide). So for example, say the website you are creating needs three fake post types: Blog posts, Book posts, and Press Releases. In Flutter, we'd create three write panels and assign each panel to a specific category (preventing the end-user from being able to select a category, so that when they create new posts from these write panels, they are already in the given category). Now the end user will simply choose from one of our write panels: "Press Releases," "Books," or "Blog" to create new posts, and Flutter enables us to give each "type" of post a set of GUI'd custom fields.

In the back end, we rewind the query in single.php, and point each category (blog, press releases, and books) to its own single template: single-blog.php, single-press-releases.php, and single-books.php. We can then retrieve the custom field data in each template and handle each category of post (or fake post type) independently.

Finally, creating relationships between the fake types is a matter of careful naming. Another example: Say you have a book catalog, and you need to be able to associate "Blog" posts with "Book" posts. In the "Blog" post's write panel in the Dashboard (created through Flutter), you'd need to create a GUI'd custom field that contains a predefined list of every "Book" post available in the system. Because the end-user is selecting a "Book" post from the dropdown, you don't have to worry about her entering the name incorrectly. Then, in the single-blog.php template, you can retrieve which book is "associated" with the blog post by getting that value from the custom field. Then, once you have that value, you can look up the Book "type" post in a separate wp_query (still within the single-blog.php template), and in turn obtain its custom meta.

The difficulty with all this in Flutter as it stands is that you have to maintain the master list of books in the Flutter field within Flutter's write panel creation area. Every time the end-user creates a new Book "type" post, you have to add that book to the dropdown, so that she can select that book in the Blog "type" post. (This is okay in a book catalog, because we only added books once a year.) But to overcome this difficulty, you would ideally want to pour the list of books into the dropdown directly from the database, so that you never have to manually update it.

I've been swimming deeply in Flutter for a little over a year now, amidst 80% joy and 20% frustration (almost always from clunky query mishaps). I've been trying so hard lately to get comfortable enough with Pods to excuse its bigger faults (as you point out), and it's... yeah. Stripping away all that it makes me strip (UI, tags, global search, yadda...) for the sake of relationships just doesn't feel worth it. So I think I'm back to Flutter. Or some cocktail of the two.

Hence my question, and I know / apologize that this is one of those "probably beyond the scope of a comment" questions. Can you -- either in a comment, or post, or neither if it's too big -- expand just a *bit* on: "I’ve also created stable relationships between post 'types' through Flutter fields that wouldn’t be manageable for the end user without the grouping capabilities that Flutter’s GUI allows for"? Just on a high-level view, how did you do this, or what baked-into-WP method did you exploit to pull it off (taxonomies, etc)? Your cited sites look great, and the relationships seem pretty parallel to what I'm after.

Until someone take the plugin and start to working on it flutter is officialy dead

David.

We won't see the GUI for the custom post types introduced by 2.9 until 3.0 (presumably). And even then, the custom write panels that are possible in Flutter still won't be available in core.

A patched up Flutter is still a viable option until we see real Flutter-like capabilities in WP.

However, in the meantime, Flutter can do the job well enough for small- to medium-scale sites. I've patched Flutter well enough to use it in production on several sites, so there's no need to wait for real post types. I've tried just about all the plugins out there for handling this stuff, and hands down, only Flutter is advanced enough to do the kind of stuff, right now, that we want to do CMS-wise (Pods offers real post types, but it's so unfriendly from an end-user POV, that it's useless in production).

Custom write panels like Magic Fields and Flutter are good front ends, but combining that with the post type and serialized meta information that should be used in the backend is what I'm waiting for. I'll probably try to make Magic Fields work with WPMU for now as I think the Flutter team is understandably focused on revenue-generating work. This is just another reason why something so central to WP as a CMS needs to move into core (much moreseo than image-editing I might gratuitously add).