ilyad

I wonder if the inline registration is really happening before being enqueued. You may have called these in your code in the wrong order, but do your callbacks execute in that order?

Yes, inline registration is called from wp_enqueue_scripts action, that enqueue check prevents it from registering, so that means datepicker is not enqueued. I enqueue datepicker in shortcode which is far more later than wp_enqueue_scripts. If I remove ‘return’ inside wp_localize_jquery_ui_datepicker, wp_add_inline_script is getting called, still far earlier than datepicker in my shortcode, and registered localization script is getting into html after datepicker script in the middle of html.

More data!
I found that wp_add_inline_script(script_handle, code) will register inline code even if the script handle is not enqueued yet! If script is enqueued later then inline code is added to it. Thats the behaviour I have expected!
But wp_localize_jquery_ui_datepicker checks manualy if datepicker has been enqueued!
if ( ! wp_script_is( ‘jquery-ui-datepicker’, ‘enqueued’ ) ) {
return;
}

I don’t know why it checks. This check is indirectly included in wordpress’s scripts system. And removing that check here will fix everything.

All you said is right. I like this wordpress scripts system and never insert scripts in any other way.
The only thing is that I speak about not my personal inline script, it is WordPress’s. This localization function wp_localize_jquery_ui_datepicker is wordpress’s internal, and is added by wordpress in default-filters.php like this:

add_action( ‘wp_enqueue_scripts’, ‘wp_localize_jquery_ui_datepicker’, 1000 );
add_action( ‘admin_enqueue_scripts’, ‘wp_localize_jquery_ui_datepicker’, 1000 );

So wordpress will translate datepicker automatically if it will be enqueued in one of these two actions.
Or if I add wp_localize_jquery_ui_datepicker as action to other later actions like wp_head or wp_footer.
Or if I manually call wp_localize_jquery_ui_datepicker in the right place.
But I don’t feel comfortable messing with stuff intended to be working silently by itself, that’s why I decided to ask here.

Thanks for your thoughts.
Well, in my opinion wp_add_inline_script should work like actions and filters do: you register your extension and whether the script is inserted into html, extensions are also inserted, no matter where it will happen, in head or in footer. Correct me if I’m wrong, but most user-interaction scripts (like datepicker) could be loaded after the page body and are not required in head.

For now I manually call wp_localize_jquery_ui_datepicker in shortcode after I enqueue plugin script, which depends on jquery datepicker script.

The wordpress navigation menu is not actually connected to TML.

I think the reason why you had links in your nav-menu, is that default menu has “add all top-level pages” checkbox set.

Check your menu in admin console under “Customize” -> “Menu”.
You can manualy add required pages to your navigation menu.

Well… Commented out this code as said in nearby topic
//require_once( THEME_MY_LOGIN_PATH . ‘/includes/class-theme-my-login-ms-signup.php’ );

I read all the code concerning user registration, and was very confused of two parallel logics: normal site and multisite. Logic is dublicated and different in your plugin as well as in wordpress core.

The registration of MU user is much more strict and complicated but to my surprise normal register user function working fine on multisite even from one of the subsites.

But one problem left is that when custom password enabled, there is no email confirmation required. User receives email with link but account is working right after you press “register”.