You’re right, custom_field in L&L is really just used as an attribute that you can use to filter certain loops based on the value of a custom field. I just tested this out on my and it looks like whether you use <Field author /> or <Field name=author /> it still refers to the default WordPress author field and not your custom field with the same name. Looking through the docs and testing things out, it doesn’t look like there’s currently an equivalent to custom=true from CCS.
I’ve gone ahead and created a feature request about this and I’ll be sure to update this thread if/when the feature gets released. In the short term though, I think your best bet is going to be to change the field name.
I assume the only reason you’re looking for a workaround is that you want to maintain compatibility with the CCS snippets you’ve built as you transition over to L&L, right? If so, I wonder if you could modify your CCS snippet to conditionally display either your custom author field or some new custom_author field so that when you change the name of your custom field to improve compatibility with L&L, you wouldn’t break things in CCS. Then again, I haven’t really used CCS so I’m not sure if it has that kind of conditional logic capability.
Ok, I’ll back up my instance, rename the field and see what happens.
I’m not concerned w/ compatibility with existing CCS snippets. I am working my way through, rewriting them in L&L. I’ve not renamed an existing text field, which causes me a little bit of anxiety. I don’t think renaming a text field in ACF will break the content but not anxious to find out