Great start!

Hey there @mgibbs189 ! Thanks so much for the kind words and feedback. I’d like to give you a timeline on where we are on the items you mentioned and why we made some of the decisions we made.

1. The “Model icon” can’t currently be changed after creation

Great feedback, we have a fix in the works now.

On the Single and Multi select fields, we are already hard at work to bring that one to life. If you browse the code you’ll see that we have not yet activated that feature but the code is there and ready. We’re just iterating on the final field solution based on some edge case issues we found so folks don’t get breaking changes in a future update. It’s coming very very soon!

4. From what I can tell, the post types (“Models”) aren’t /?s=searchable and there appear to be relatively few hooks to latch onto currently.

Thank you, both of these are things we intend to explore. On searchability: we have an open issue around making models public and searchable. On hooks: we’ve exposed few hooks on purpose at the moment because our pre-1.0 code is in flux. But we recognize the importance of hooks and want to add them later when we’re sure they will be ready for public use.

5. Considering having boolean fields store a value, even when unselected.

That’s interesting. I think in this case you could use the new single-select field when we activate it soon! On the boolean saving false, are there any particular cases where this is used that you could share? ??

6. Repeater fields! This is the biggest deal-breaker for me, but obviously one of the hardest features to pull off. Is this something that’s planned?

Absolutely understand the need for repeat data. We put our initial efforts in this problem with repeater-like functionality through data relationships. For instance, if you wanted an employee directory where employees can be part of many different model types (maybe departments), you might not want to enter their information each time you added them to some other data model. Maybe you want them associated with some type of “buildings” content model to define what building they work in. In that case, it would leave room for error in data entry and repeat work.

In place of repeaters we made the relationship field so that you can select from another data model (in the example case, “employee” model) to attach their data to that entry in the associated model. Repeater fields are something we’re looking to get feedback on how folks are using them. I would very much appreciate your feedback on how you use them! Being that ACM is completely focused on building content models, we’ve strayed from repeaters because a majority of use cases we’ve found are focused on rendering down to some defined markup that the repeater represents. For headless solutions this makes less sense because it’s up to the application developer to define how those data entries are used. This is not to say that we are against repeaters, we’ve just heard little feedback on how people are using them in non-render based ways.

Would you be open to having a call or chat to talk more about how you would use ACM?

Hey Anthony,

2, 3. Thanks for the reply. Glad to hear about single/multiple selects. I haven’t dug much into the code, but did want to emphasize how helpful it’d be if multi-select values were stored as separate rows in postmeta (versus serialized). It would make meta_query lookups so much cleaner and more efficient.

5. When doing meta_query lookups, WP ignores posts that lack a value. Plus I feel like it’s more intuitive to have:

[ 'key' => 'the_boolean', 'value' => 'off' ]

or

[ 'key' => 'the_boolean', 'value' => 0 ]

instead of

[ 'key' => 'the_boolean', 'compare' => 'NOT EXISTS' ]

6. Repeaters are incredibly useful, especially for things where having a full on post item / model for it would be overkill.

A simple example involves putting a Media field within a repeater to allow for multi-files (or a gallery).

Another example: I have a documentation page with small (often 1-2 line) code snippets scattered throughout. For this, I have a repeater with a couple sub-fields (name, content). Then I just stick the tag name wherever each snippet should appear. Having a post type just to store a bunch of tiny code snippets would be super tedius.

Last example: think of a yarn collection. Each item would contain (a) the yarn name (which could be a separate model), and (b) the quantity in hand (manually entered)… if that makes sense.