@userabuser you online? have a question.

@kaiser shoot mate...

ah, kool. got a strange situation: I added a post meta field (to a post post inside a meta box) and realized that my sanitize callback was triggered twice. and the first time, before I actually had a value.

the sanitize callback is attached to "sanitize_{$meta_type}_meta_{$meta_key}" where $meta_type is post and $meta_key my meta field key/name.

I debugged through core and did some debug_backtrace() and saw that it was triggered by line 229 in ~/wp-admin/post.php: $post_id = edit_post();

hm

checking...

@userabuser ah, sorry. looking at backtrace this isn't the line triggering it. one sec please...

k

This is the thing: wp_update_post() on L#332 > wp_insert_post()

from there on it gets shady. 'save_post_post' is the action then triggered.

The thing is that the function that finally executes the sanitize callback is in ~/wp-includes/meta.php on L#1596: register_meta()

I haven't even ever heard of it before... but it runs. And I got no idea how and why.

function register_meta( $meta_type, $meta_key, $sanitize_callback, $auth_callback = null ) {
	if ( is_callable( $sanitize_callback ) )
		add_filter( "sanitize_{$meta_type}_meta_{$meta_key}", $sanitize_callback, 10, 3 );
	if ( empty( $auth_callback ) ) {
		if ( is_protected_meta( $meta_key, $meta_type ) )
			$auth_callback = '__return_false';
		else
			$auth_callback = '__return_true';
	}
	if ( is_callable( $auth_callback ) )
		add_filter( "auth_{$meta_type}_meta_{$meta_key}", $auth_callback, 10, 6 );

am there

It attaches a filter to sanitize_{$meta_type}_meta_{$meta_key} as well.

I got no idea what's wrong. None. Null. Nada.

problem here is its a fucking rabit hole

so edit_post takes us to wp_update_post then into wp_insert_post right

ok

As you told Sisir that you got some custom meta table handling running, I thought you might know what goes on. Or at least ...

we do... so we make use of get_metadata and update_metadata only

so wp_insert_post calls sanitize_post...

hm that cant be it...

Hm, ok. Did another debug_backtrace() now from the other side (where I attach the callback): edit_post() > update_meta() > update_metadata_by_mid() > sanitize_meta() > apply_filters()

this is where I ended up following calls to sanitize_meta, now why calling twice

No idea... It feels like watching Domino stones falling one after the other, but first the 2nd falls, then the 1st, then 2nd again...

haha... this is typical wp debugging though... one file to next

wish i had way to reproduce so i could put in my log statements too

The thing I know is that update_metadata() which is what gets called by get_post_meta() is not calling it. But this is what I am calling. And if I disable that, nothing happens at all.

There is some callback attached to some filter or hook that I keep missing.

(And I start wondering why register_meta() exists at all - AND why it has an auth callback)

@kaiser wonder exact same thing now... its because its related to add_meta_box I think? Or... something around there

so this could be possible reason for being called twice

maybe - but I'm more than unsure.

I'm trying to build a quik test case to reproduce it

its ok we are in same boat but since we are guessing, I am going to place my reluctant bet on register_meta - maybe... ha...

k

also log params of register_meta to see what callbacks are attached there if any

IDE hangs. :D

did you say you are calling update_metadata?

update_post_meta()

ok which calls update_metadata

but...

hang on

update_meta calls santize_meta and so does update_metadata

so if you are calling update_post_meta in addition to the flow of edit_post -> update_meta -> update_metadata_by_mid -> sanitize_meta then this is possibly where you are getting triggered twice...

can you confirm?

Damn it. Can't reproduce...

@userabuser my problem is that I am not calling edit_post(). That's core doing.

yeah... this is what I mean... core calls edit_post which eventually winds up in sanitize_meta and then your update_post_meta calls sanitize_meta eventually too

example mu-plugin

@userabuser ah, sorry. please download it again. forgot to add the saved meta val to the input

ok certainly see it twice

yep. and it's triggered by update_metadata_by_mid()

why the heck is this running?

because of edit_post

core calls it

i just logged it...

but it doesn't happen when you remove the update_post_meta() call.

so core doesn't call then?

interesting

let me try

It seems like core is only hooking into it per default. There's a check missing somewhere.

@kaiser core still definitely calls update_metadata_by_mid when you remove your call to update_post_meta

doesn't for me. at least it doesn't trigger the sanitize callback twice anymore

Oh, it does for me @userabuser - just forget to comment the exit in the sanitize callback back in

With update_post_meta removed, it triggers your callback once (because of default core call)

Don't get that. Why would core hook into a callback that should only run on my key? Context sensitive stuff

Why, oh why.

because santize_meta still gets called by core... in turn firing your filter anyway

It shouldn't. It should only run when there's a meta value handled attached to a meta key that specifically is wpsetest (in that case)

Ah, here we go:

function edit_post( $post_data = null ) {
	global $wpdb;

	if ( empty($post_data) )
		$post_data = &$_POST;

So my key gets referenced under meta:

'meta' =>
    array (size=1)
      187 =>
        array (size=2)
          'key' => string 'wpsetest' (length=8)
          'value' => string 'test' (length=4)

thats right

we on same page now?

y-e-s

Line # 276 in wp-admin/includes/post.php and edit_post():

	// Meta Stuff
	if ( isset($post_data['meta']) && $post_data['meta'] ) {

Seems like the problem is that it is no is_protected_meta() ...

wtf is that? either is_protected_meta() or ! current_user_can( 'edit_post_meta', $post_ID, $value['key'] )

else core will update my meta value?

hm

like if core would care about saving it in the first place ... not

is that some new crap with 4.x+? do I now have to register_meta and than core handles it?

you don't have to but... github.com/justintadlock/content-type-standards/issues/5

@userabuser I already can't wrap my head around the 1st sentence. could you rephrase that for me?

And the "always hidden" and "always accessible" look identical to me

He is just saying that unless you use register_meta on a meta_key prefixed with "_" underscore then your key will not be visible when you try to access data through the JSON api...

difference is return_true/return_false

invisible = prefix with _?

yep

you know like keys with underscore _my_key are not visible in custom fields etc

but if I register it, then - no matter if it has an _ prefix or not - it will be visible?

it will always be visible without a prefix (i think) but never visible with a prefix unless you register it... so if you want to expose hidden keys to external API you need to register.

confused much...

confused more than you could imagine

WordPress gone crazy. Officially.

when you finish working with wp tonight, go and write some real architecture in a real framework so you can feel good about yourself (like i do) and not like you are getting dumber by the minute trying to understand wp madness

And this would still not explain what exactly causes core to trigger on a highly specific custom sanitize callback.

@userabuser it's 5 am already. fighting this shit since 7pm... the only thing I'm going to do when I understand this crap is going to sleep like I wanted hours ago :P

update_metadata_by_mid <- runs on every post meta key, including yours, which in turn calls sanitize_meta which does apply_filters, and since you are hooked onto that filter, your callback runs and it runs a second time if you add your update_post_meta call.

First time by core... second time by you

doesn't matter how specific the context is... if there is a hook that matches the metakey then boom she will fire

"he will fire". do not use she in that context. makes it tougher to imagine to punch a piece of code into the face.

replace she with nacin?

don't help me getting into the wrong ideas. I already looked up the version history of the register_meta() codex page to see who added that crap:

> Registers meta key. This is for use with WordPress's various APIs as well as the custom post fields box. If you want to create custom UI, you will need to use add_meta_box.

yes very helpful explanation

yes. helpful very expedition is.

nothing more i despise than poor documentation...

who the heck thought this crap up... man.

ok, any idea on how to handle that?

this is clear case of people documenting not knowing what its even for

well problem here is that wordpress doesn't follow single responsibility principle much and that there are multiple entry points to do the same thing

don't tell me the obvious :)

the reason why update_post_meta calls santize_meta again is because it can be called out of current post context, so it has to, so you need to (if you want) manage the hook being fired so that it only fires once if you want...

Can't do that

That would force me to build a wrapper for a wrapper. And that is frankly stupid.

what is your real problem here though... is it you just dont want your hook to fire twice or is it fact that it causes some other problem?

yes. somehow it shoots the save process

but as I already can't figure out why this is happening and how I can hold core back from doing that, I can't dig deeper.

Do you even need to run your update_post_meta?

remember that update_metadata_by_mid gets called which does that for you

typically you would call update_post_meta after the fact IF you had a special case to do so or if you are out of context or allowing in-page ajax saving of individual fields

hm

need to test that

The following problem: The callback always has an empty $value (1st sanitize argument) if I don't call update_post_meta().

If you are in dashboard and a post (or custom post) edit page context then that is how I would do it, let the core default request flow handle the call for you, but as soon as you step outside of that, to maybe a custom plugin page or saving from front end or other context then you rely on update_post_meta etc.

@kaiser not for me...

update_metadata_by_mid -> santize_meta shows the value on first pass

which is correct behavior

...for your key

I removed the save meta stuff

but got that. investigating

Just retested, and yep works as expected... (core calling that filter)

value is there

ah, yeah. problem seems that it isn't saving?

just checked, value is saved for me...

in meta table, refreshed page, clear cache... she exists

doesn't ...

does

have you used register_meta()?

nop

key gets saved, value empty

wordpress impossible!

and when I save an empty value, it removes the key and removes the entry from the DB

ok?

@kaiser are you sure your computer is turned on?

hehe

@userabuser can you reproduce that on a new post and on an existing?

the above was for existing, let me try new post

does NOT work on new post

now we are getting somewhere

ha. shit.

so one calls edit_post the other write_post i think

because it depends on the switch and case

ok on new post you end up in wp_write_post:641 wp-admin/includes/post

case is "post" for new and "edit" for existing

sorry editpost

I just added get_post_custom() to the meta box in the demo plugin on the "Hello World" default post. Got _edit_lock and _edit_last as default values. No matter how often I reload - it stays like this

those two values always come through

But when I try to save something in the meta value input field (which doesn't work), I get _pingme and _encloseme. As soon as I just reload the page, the values are ... gone.

Seems like they don't even come from the $prefix_postmeta table. Guess _pingme is the global option from the options table.

Not going to look into that one.

yeah ignore that crap imo

ignored

still the other issue is killing me.

so now this seems a simple situation of what case we are in

if case is edit_post then meta insert is handled for you, if not, you need to handle it?

seems stupid to not have it consistent

no idea what the concept behind that should be

yeah no idea about the rationale

but that is what is happening

even worse: if edit then it's handled for you twice, if post then not at all

just look at write_post vs edit_post

yeah... total wtf.

Haven't dealt with that for quite some time, now coming back to something such a fundamental and basic thing and I want to shoot myself.

edge case hell at 6am - sucks to be you

thanks

I say get some sleep mate... nothing worth dealing with this rubbish now

will do now. but honestly: this is far from an edge case...

hopefully @toscho can shed some light into that (good morning)

Please read the Edit at the end. WordPress...

While thinking about how to visually check if a theme/plugin is properly prepared for i18n I thought about just filtering 'gettext' and returning gibberish or all 'XXXX' for every translation. Like that you can easily see what is left untranslated because it is hardcoded. What do you think about this? Any better approaches?

highlighting it

otherwise you know there's a string but because it's gibberish you don't know what to look for

You mean like wrapping it in a <span style="background-color:red;">?

PigLatin plugin

Oh that also seems to be a nice idea. Thanks @Rarst

You mean this?

wordpress.org/plugins/piglatin

yep

I dragged it into reasonably modern PHP while back :) it's ancient

@kraftner if you go down that route, use <mark></mark>. You can also be sure that there's no styling per default as pretty much everybody forgets about that tag.

Nice. Thanks everyone.