Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
PG Lewis
@pglewis
what I test against will grow as I go along too, I'll pull more from the snippet library, or any other source for testing stuff I can get my hands on
Justin Sternberg
@jtsternberg
You're right about options page snippet in example functions
PG Lewis
@pglewis
at least not an indicator that I'm going crazy yet
Justin Sternberg
@jtsternberg
Another good test bed would be the third party addons: https://github.com/WebDevStudios/CMB2#3rd-party-resources
yah, not yet. :P
PG Lewis
@pglewis
I'm always careful to be clear with my language, there is no definitive proof that I'm not going crazy, after all
and yeah, custom field types are high on my list of testing to expand to
currently back to evaluating if I can just remove the redundant field arrays stored
that branch is instantiating field objects when they're created now, so objects always exist
and the arrays keys are accessible via ->args, so we can still return that when requested
PG Lewis
@pglewis
but keeping both an array of arrays and an array of the objects seems redundant and full of confusion for me lol
pitfalls with back compat for sure, but I'm still slowly working around them
Justin Sternberg
@jtsternberg
agree, it's pretty terrible.. updating one of the arrays in the array doesn't update the corresponding object
PG Lewis
@pglewis
I /think/ it can be done
just harder than I originally thought lol
Justin Sternberg
@jtsternberg
worst case, can re-build the array on the fly if the fields array is requested, right?
PG Lewis
@pglewis
still, tests will improve regardless of whether or not this experiment proves worthwhile
and that's nearly as important as making this branch work
unsure what to do if it's just not viable to remove the arrays
I'm still working under the stubborn assumption that it'll be doable, but not pretty in spots
and then evaluate where it lands and decide if that's better than where it started or not
but it clears up one potential issue of nesting fields in other ones
as objects will always be available and can be found by ID (you don't necessarily need an object ref if you have ID)
which could in turn mean the original syntax scott tried might be feasible
or something very close to it
since now having a field ID DOES mean you have access to the object
Justin Sternberg
@jtsternberg
that would be awesome.. a unique id per field, yah?
basically a handle
PG Lewis
@pglewis
still just using the same IDs for fields
Justin Sternberg
@jtsternberg
based on "as objects will always be available and can be found by ID"
PG Lewis
@pglewis
if it translates as a straight refactor, I think what I'll end up with is an args->fields[] array of more field objects for nested ones
Justin Sternberg
@jtsternberg
I see
PG Lewis
@pglewis
same array keys for the object list right now as the array list
as the branch stands, so it's been easy to start converting sections of code that were referencing the arrays
just point them at $field_objects instead of $fields_array
and refactor to call through to ->args on the object for the arrray stuff
current state is I'm still keeping both parallel but soon will drop the arrays hopefully and see how bad it blows up
and all of it seems to be working except for group fields, which was known it would be broken
none of that has been comitted or pushed yet though
no-fields-array is probably just a clone of no-metabox-array right now in the repo
PG Lewis
@pglewis
the no-metabox-array branch is just the refactor to remove the $meta_box property and transition to object props and I think that's viable
the no-fields-array branch will build from there, taking it the next step of trying to rid the field arrays... tougher
a unique ID per field-- a field GUID-- would be a great idea because it removes the need to have the parent ID for nested fields
but it has to work with the field ID / parent ID for back-compat first, so I'm starting the refactor that way
PG Lewis
@pglewis
thus field IDs only should need to be unique within their field group
which is how it is now, pretty sure
Justin Sternberg
@jtsternberg
yep, that's how it is currently, but seems to me we should generate a guid and store it as a field object property
and add_field could return that guid
PG Lewis
@pglewis
I like that idea as an enhancement if we get it that far
Justin Sternberg
@jtsternberg
yah for sure