Standards in a non-"commercial" world

Hello again @justintadlock :)

Let me start with a semi-negative: I understand. This isn't your cup of tea. None the less, as food for longer term thought, I wanted to share this with you / the group.

There's no need to reply (unless you wish to discuss). This is strictly #FYI / #PSA type info. Perhaps this will appeal to you as a prototyping tool? Or even a MASSIVE time saver - and bloated plugin avoider - when something simple and custom is in order. Even seasoned dev need to save time, eh? :)

In any case...

Long to short, this is all I need for a FAQ CPT

$arr_args = WPez\WPezClasses\Content_Type_Standards\FAQ::get('cpt_type'); $obj_cpt_wpezfaq = new WPez\WPezClasses\CPT\Register_Post_Type(); $obj_cpt_wpezfaq->ez_loader($arr_args);

$arr_args = WPez\WPezClasses\Content_Type_Standards\FAQ::get('fields'); $obj_cmb2 = new WPez\WPezClasses\CMB2\Preprocessor(); $obj_cmb2->ez_loader($cmb_box, $arrargs, 'prefix');

..Content_Type_Standards\FAQ - This class can return two things

1) "Common" CPT type definitions - That I mentioned in the other thread, that you're not in favor of addressing. Understood. That is CPT def that would be typical for this content type. (Or, don't panic, you can also roll you own. These are just arrays - no "code" per se.)

Currently for FAQ just one CPT type :) That said, the next time I need it, it's there. Mindlessly. Almost as if it were something I could summons from core. If I come up with a second CPT type (during some future need / project), I'll add it. And then again, it's there. Done! DRY. Nothing to re-invent.

2) An array of the standard fields w/ their properties - However, the magic, is there are some properties (within each field) that are universal (e.g., name, label) and the rest can be defined specifically for the "field generator" I'm using (e.g., currently CMB2 but ACF and others could be added.) So, in this case, the only thing my CMB2 property's array has is "type" => "some_cmb2_field_type".

The point being, there's the standard for FAQs, as well as room for the "canned" implementation. Or. roll your own. They are after all just form elements and they follow a known pattern. All bases covered

..\CMB2\Preprocessor();

This is exactly what it sez it is. The main advantages are:

1) Forms are defined via the array, not one field at a time (as are most if not all the CMB2 examples). And those arrays can be "standardized" for re-use, sharing, etc.

2) Those definitions can be "nested." That is, I might have some of my own fields but then need the "personnel content type standard" I can more or less mix and match as necessary.

Of course, say, ACF would need it's own pre-processor because it thinks differently. But the definition of the content type (in this case FAQ) is universal, applicable, and can be supplemented.

Again. I hear ya. Not what you're thinking. That's fine. I can see why not.

BUT, imho, this approach IS a step in the right direction. A step towards your more "commercial" (i.e., not custom) - less dependent (on field generators) - type approach.

In any case, in way, it's your ideal in action. I hope that makes you happy. I does me :)

Thanks again. tty

p.s. My next step is to finish the work (read: class) I've proof-of-concept'ed for universal / generic CPT field validation (e.g., required). And yes, those properties would part of the type standard "object" (read: array). The definion object is universal. What each dev does with that will be up to them. But at least they'll be starting with the same known.

justintadlock / content-type-standards

Standards in a non-"commercial" world #33