@MarkKaplun this has been a long time coming... If it were me; I'd have making this priority #1 a long time ago. I cannot believe you have a team of developers, happily plodding along knowing full well there is no unified form API. I've wrote my own form API (agnostic to WP) but which I am now using to create a unified meta/form API across all areas of WP that we often use them from posts, users, taxonomy, settings, customizer and custom plugin pages as well as providing a unified way to...
...render forms in the front end (themes). That aside though, I wonder if this will spell the end for those metabox frameworks like ACF, metabox.io.
@userabuser, people (I mean me) spent years to understand the settings API, now need to learn a new trick :(
But options !== meta, and there is more to it then just handling the html forms. I can see how the settings api can be replaced without much pain but the meta is basically a way to extend the posts objects and like with rest, there is a huge step of defining what is a post and how you should extend it in favour of hacking some code
ACF provides so much more then the fields API at its current form, I will be surprised if it will be affected
*huge step being skipped
btw, when I said few days a go that I am less impressed with pippin's code was because in one of his samples he has an hybrid of settings API and html based form, and hybrids usually inherit the worse of all worlds :)
From a coding POV, the biggest problem that holds core development back is that contributors are still stuck at the DB structure, GUI elements details level, when wordpress had become complex enough it needs someone to be an architect. Assuming core wants to be OOP when it grows, you need to stop focusing on coding detaisl and start defining things in terms of object interactions. Untill you do that all the classes in the world will not make your code less procedural then it is
Maybe matt should hire someone in the caliber of @toscho as core architect to fix this problem
@MarkKaplun interesting point, will be good to see how this pans out, whether the fields API is a flop or not... though, whatever it is, it should replace all existing apis; which means breaking-changes. Having two APIs for the same thing co-exist gets messy because of the ecosystem (poor usage).
Re: pippins code... I've seen some questionable things in older architecture, but everyone does some question stuff from time to time.
> Assuming core wants to be OOP when it grows, you need to stop focusing on coding detaisl and start defining things in terms of object interactions. Untill you do that all the classes in the world will not make your code less procedural then it is...
if... if... foreach... coworker walks in "hey what you doing for lunch"... ahh where the fk was I again....
Sometimes on first pass if I am being a bit slack and want to get a working prototype up, I might do some deep nesting, but I'll always abstract it away into easy to reason about methods because if you leave it and then come back to it at some point in future (even though you wrote it) you will still be somewhat confused as to wtf is going on...
When I had much less white hair I have been thought that functions should not be longer then the number of lines you can fit in a screen and a half. I see how it is hard to do when you do html output, but it still irks me, and that function doesn't do any output. With the foreach I can actually live
but there are great comments there "$object_type - object type" :)
they could have done away with the need for global $wp_fields though... once you start going down that path, you know you've got problems with your API design
When you commit to no globals it at the very least forces you think about better design principals.
well, we will see how this will end. I know that I would not even think about attempting such a thing before having full unit test coverage of all the core admin screen.
i didn't bother looking at the customizer part, first thing I always look at is the Field API itself how low level it is and agnostic to the higher level API used to call it...
I looked into it because scot said on slac that its structure was the inspiration for the fields api, so just wondered if that bug (?) was just a copy/paste thing and if it happens also in the customizer
yeah I just read that on the github landing page "Based on the Customizer, we can enable developers to do more because they won't have to jump between different interfaces."
yet another thing I didn't want to know about php.... if you have an array which includes the value 0 a call to in_array will match every string against it. How could anyone at any time think it is an acceptable behavior? (yes, there is a "strict" parameter, but I assume every developer stumbles over this at least once)
@MarkKaplun yeah pretty backwards thinking... I've never been tripped up by it fortunately, if I'm using it, I'm usually checking the same types, but as you point out, it's a serious gotcha otherwise
Kind of reminiscent of the empty() quirk with (string) 0
Quick question: Anyone know why an ajax update_post_meta change in the page edit window would appear get "rolled back" when the user clicks the "Update" button in the interface?
I have some post meta displayed in the page template. When the user updates it via ajax in the page edit screen, the change appears on the front-end view of the page until the user hits "Update" in the page edit screen.
Not necessarily. It would be fine to just use the save_post hook, except for the fact that my interface is done in jquery. Guess I'd have to push the value into a hidden field or something?
I would maybe, turn on the debug log and throw some error_log()s into your ajax function to ensure it's catching. Maybe disable any caching plugins ( or all plugins you can ) for the time being.
Open page
Open edit screen for that page
Change hero image position
Refresh page and observe that change has taken effect
Update page
Refresh page and observe that change has been reversed
I have created a metabox :
function drama_description_metabox_markup() {
global $post;
$drama_description_metabox_markup = get_post_meta( $post->ID, 'drama_description', true );
?>
<div>
<label for="meta-box-text">Description</label>
<textare...
I have created a metabox :
function drama_description_metabox_markup() {
global $post;
$drama_description_metabox_markup = get_post_meta( $post->ID, 'drama_description', true );
?>
<div>
<label for="meta-box-text">Description</label>
<textare...
