Some drive-by comments...

• The name Fieldmanager_Content potentially implies some sort of relationship to post_content that might prove confusing. I don't have a great alternative to offer, though. Fieldmanager_Display? Fieldmanager_InBetween?

• I think it would be great if the field could accept the path to a file as an alternative to accepting the content string, as it would allow a developer to maintain a separate .md file rather than have to manage the content within PHP variables.

• Along the lines of Matt's suggestion: There's currently one class responsible for handling three content types, but I wonder whether the developer experience would be improved by instead having three classes, one for each content type. For maintainers, these classes would likely be smaller and thus have less to maintain. For developers, only one thing needs to be specified to use the field (the class) instead of two (the class and the type property). Lastly, FM already has abstract classes for similar situations (e.g. Fieldmanager_Options).

@dlh01, thanks David, I've split out Fieldmanager_Content into Fieldmanager_Plaintext, Fieldmanager_Markup, and Fieldmanager_Markdown. I had originally gone down this path, but found it was possibly too verbose, but your suggestion encouraged me to revisit. I do think it's a better developer experience at the end of the day, even at the expense of some additional code to maintain.

I like your point about loading files, but I think file_get_contents is a simple way to achieve that. I wouldn't add support for anything more complex as part of this initial implementation.

new Fieldmanager_Markdown(
	[
		'content' => file_get_contents( __DIR__ . '/readme.md' ),
	]
);

@jameswburke I like this new direction. I think it would be beneficial for the three classes to share an abstract class. An abstract class would DRY up the code a bit and make it easier for a third party to add their own variant, e.g. if someone wanted to add their own Textile field or whatever.

file_get_contents() certainly works, and it isn't mutually exclusive with adding a file property later. The downside to consider is performance: The file has to be read from disk immediately rather than only in the moment that Fieldmanager needs it.

Updated autoload approach to support a Fieldmanager\Library\Package\Class format, and implemented abstract class Fieldmanager_Content and refactored for other content fields.

@mboynes & @dlh01, could you take another look at my latest pass on this? Thanks!