joe_bopper

Hi Mike,

Thanks for getting in touch and sorry for taking a while in getting back to you.

In terms of the placeholder, the attribute title field in the menu item being edited is the place you can change it in the admin area. It isn’t the most intuitive thing, but it is the closest when working with the WP default attributes. Take note though, in order for you to have a placeholder in the html, your theme needs to explicitly support html5. This is the standard behaviour of WordPress search boxes and so I have kept it in (line 272).

The plugin is intentionally simple and lightweight and so doesn’t have any kind of settings page.

For your submit button, once again it’s almost definitely down to your theme and 100% definitely not this plugin. As you’ve noticed, a submit button is provided as seen on line 274 and line 281. I reckon your theme’s css is likely not displaying input tags of type submit.

It’s worth noting that the plugin has been made so that you (potentially) have full control over how the search box is displayed by providing the output filter hook get_nav_search_box_form on line 291. Because of this, there should be no need to edit the plugin files (and it is highly not recommended).

Then again, if you ever feel it is necessary to edit the files in future, get in contact about the problem and I’ll try to help sort it out – maybe through an update, maybe through other means. Also, if you do edit files, don’t forget to change the plugin name; that way you’ll avoid updates deleting your changes. (It’s also useful to download the plugin again but keep deactivated so that you can see when updates are available).

I’m marking this as resolved as I believe the issues are with your theme and not with this plugin. Feel free to revert this if you think otherwise.

Cheers,
Joe

Hi.

As far as I can tell, the changes aren’t coming through to the frontend site. Are you using a caching plugin or anything like that? If so, you may have to flush it in order for changes to come through.

Also, if you can make changes, you may well find it better to use padding on the ul element rather than using line-height on the anchors. You may want to filter out screen reader only content too.

ul#menu-main-menu{
  padding-top: 50px;
}

ul#menu-main-menu li a{
  margin-top: 5px;
  padding-left: 0px;
  padding-right: 0px;
}

.navbar-nav>li>a{
  line-height: 20px !important;
}

ul#menu-main-menu  li{
  padding-left: 15px;
  padding-right: 15px;
}

.screen-reader-text{
  height: 0;
  width: 0;
  overflow: hidden;
}

You may want to tweak the values to fit best.

Hope this helps.

Cheers,
Joe

Hi Tracy,

Thanks for getting in touch. The issue you’re having is to do with your theme’s css. Do you have any way of adding styling rules? If not, I’m afraid I can’t help you as it is down to your theme having overly specific styles. On the other hand, if you can add css, simply put in:

.bop-nav-search label {
  line-height: 120px !important;
}

to match what you currently have for the anchor links you have in the rest of the menu.

Cheers,
Joe

PS There are probably plugins that’ll give you some css styling access; I haven’t used any so can’t give a recommendation.

Thanks very much! I’m pleased this plugin has worked well for you.

Cheers,
Joe

P.S. I’ve just updated the plugin to v1.3.1 to stop the object caching conflict.

Ah, that old problem. I’ll put out an update to circumvent this issue and stop it happening again. Caching engines should NOT be using WordPress’s object cache across requests, yet, sadly, it seems many do.

Thanks for getting back to me and for the kind review.

Cheers,
Joe

Hi Kevin,

Sorry for taking a while to get back to you.

I’m afraid I can’t replicate your issue with a clean install of WP4.2.2 with both W3TC and BSBITFNM. Do you have any specific settings to W3TC that are different to the ones applied by default?

I think this is more likely to be an issue with how W3TC caches and it may be that old pages are being loaded or something like that. Caching engines can be quite naughty.

Cheers,
Joe

There’s also some info in the FAQs section regarding writing your own html form.

I’m marking this as resolved, but feel free to change it back to unresolved if you still need support.

Cheers,
Joe

Hi Rebecca,

Thanks for getting in touch.

By default the submit button should have the text ‘Search’, so I can’t say I know where your problem is. It may be something to do with your theme?

Cheers,
Joe

Hi Alex,

I’m afraid I don’t know enough about the context of your html to help. How css changes the display of one element is highly dependent on the elements around it and their css, so I cannot say with any certainty what is stopping your right float.

You could have a go playing around with the display and position css properties (these are often the properties that cause unexpected behaviour) and maybe the width property of parent elements.

As this isn’t a problem to do with the plugin itself, I am marking this as not a support question. This does not mean that I am unwilling to provide any further help, but just so it doesn’t appear like an issue with the plugin.

Cheers,
Joe

Turned out to be a conflict caused by another plugin.

This’ll be circumvented in the next release, but is not seen as high enough priority to warrant a release of its own.

Cheers. I’ll see what I can do.

Hi Jamie,

Can’t say I have much experience with OptimizePress, but unless the theme is incredibly restrictive, they are wrong about the necessity to hack core files.

A few things that may help to diagnose your problem.

* Are you the admin/do you have admin permissions on your WP installation?
* Do you have access to the php code?
* A list of all the plugins on your wp install.
* Do you have a child theme to your OptimizePress install?
* Screenshots of wp-admin/nav-menus.php

Cheers,
Joe

PS If you’re comfortable with it, I’m happy to have a look at your wp install.

Hi jshiller,

I’m not sure what’s causing your problem. Are you using any other plugins that could be impacting the admin area for nav menus?

Cheers,
Joe

Hi Fred,

Thanks for getting in touch. Sorry to hear you’re having issues; I’m aware how frustrating it can be when a plugin isn’t working as expected.

I’m afraid this isn’t an issue with the plugin but with WordPress itself. I have no idea why, but WP has thought it best to hide many features of nav-menus.php by default.

Every time nav-menus.php (trac link – line 487) is accessed, the function wp_nav_menu_setup is run. This function registers some of the meta boxes in the sidebar (the one for adding new menu items) and decides which are the default fields available for each menu item. So far, so nice. It then goes on to do something I cannot fathom the reason for and decides to hide a number of the default fields for new users. This is shown in the code below:

// If first time editing, disable advanced items by default.
    if( false === get_user_option( 'managenav-menuscolumnshidden' ) ) {
        $user = wp_get_current_user();
        update_user_option($user->ID, 'managenav-menuscolumnshidden',
            array( 0 => 'link-target', 1 => 'css-classes', 2 => 'xfn', 3 => 'description', ),
            true);
    }

This seems like complete folly to me as it is doing this in a rather permanent fashion and it is not clear how to fix this.

However, it can be fixed!

tl;dr; There is a drop down at the top of the screen called “Screen Options” which has the “advanced” fields unchecked. Check the ones you want to be visible.

I’m marking this as resolved, but let me know if you’re still having issues.

Cheers,
Joe

Hi,

I’ve updated the plugin now to work around the core function.

Cheers.