New answers tagged

0

<div class="menu-wrapper"> <div class="menu1"> <?php wp_nav_menu( array( 'theme_location' => 'menu-1', 'menu_id' => 'top-menu', ) ); ?> </div> <div class="menu2"> <?php wp_nav_menu( array( '...


0

I just found some kind of workaround. I set the right "edit options" for this user. To be honest I do not know what this right means, but the user is now able to edit all the posts - so the links now have a valid target (href) Strange behaviour. Somebdoy can explain this?


0

I updated only those parts which leads to explain the things which I was trying to tell you in my first answer. plugin-name.php define("PLUGIN_DIR_PATH",plugin_dir_path(__FILE__)); add_action( 'admin_menu', 'wim_register_my_custom_menu_page' ); function wim_register_my_custom_menu_page() { add_menu_page( __( 'Plugin name', 'textdomain' ), ...


0

Add a new URL using add_submenu_page (without any parent assigned) and post your form data on that URL. Refer to this page for adding sub-menu page. Also, you should not send form data on any PHP file like this. This, will opens up your plugin for external attacks. Let, know if you unable to figure out the way of doint this. Have a Good Day!


0

The problem was in the names of the meta keys of the wpAA_users table: instead of using wp_capabilities and wp_user_level I should have used the actual prefix, that is wpAA_capabilities and wpAA_user_level. With these modifications I can now access the site as administrator.


1

Use this code to require the file from your theme's functions.php file: require get_template_directory() . 'includes/dashboard.php'; For the sake of completeness (and sanity) my dashboard.php file lives here: my-theme/includes/dashboard.php I took a closer look at the original issue, and I think what's happening is that the require statement is silently ...


Top 50 recent answers are included