Number One Fan

It should be dynamic – “?param1=11&param2=22” could be “?param1=111&param2=222” on the same page

Loco is the only free alternative to WPML for translation. I honestly don’t know why you marked that topic as resolved

From the documentation I got the idea that the problem may be is the directory of the .po files – they were placed in the custom directory …/wp-content/languages/loco/plugins. If the .po files are placed in …/wp-content/languages/plugins the localized string are shown correctly. However it more of workaroud for me, because using the custom “loco” directory is easier to track my own translations.

The code works, thanks.
It is true that in WordPress there are many ways to find the username, but each of them can be tracked and blocked. If UsersWP is used you have no way to hide the username. As for me it would be better if the username/displayname shown to the public is something different from the real username for login.
So if I force an email only login I can’t see how one can still use a username to login.

I want to completely disable username login, because of two reasons:
1. You know that using email vs username for login, is a debated question and my personal preference is using email-only login.
2. UsersWP plugin exposes one’s username on their public profile page. As for me, that is a bad design decision, which allows a random attacker with brute force to guess only the password of an another user, because his/her username is clearly seen. Most users have simple passwords and if I force strong passwords, many will give up registration. Email-only login is a workaround for that.

I put a password field on the account page. That’s where my problems comes from. I will remove it and will use the change password form, which solves both problems. Anyway it will be good to be able to change the password and other account settings from one screen.

It works that way and I figured out that is also works by using:

remove_all_filters( 'add_post_metadata');

but it is a workaround at best

The $post_ID is correct.
The problem is that even is I use directly:

add_post_meta($post_ID, 'my_field', 'value1', false);
add_post_meta($post_ID, 'my_field', 'value2', false);

the Pods hooks are trigerred and I am not able to add more then one entry to ‘my_field’. I traced the hooks execution to PodsAPI.php:3033 “unset( $params->data )” (‘my_type’ is not taxonomy), where the meta value is lost. I don’t know is it a bug, but I don’t currently know more options of adding multiple entries to a custom field.

Thanks, that’s what I needed.