wizzud

I don’t think it’s feasible to add script to the plugin because there are simply too many ways of applying expand/collapse, and everybody wants something slightly different! Some want click activation, some want hover; different icons or font glyphs, at the front or at the end; some want all open, some all closed, some partially open; some want a clicked sub to close all sub within it, others just want the clicked sub to close; etc, etc, etc. No matter how generic you try to make something like that there’s always someone who “needs” it to be different.
So, I think the answer is No. However, if you want a starting point for some script to apply yourself, you could try this? :

jQuery(function($){
  $('.widget_custom_menu_wizard').each(function(){
    $(this).find('ul ul').each(function(){
      var an = $('<a/>', {href:'#'})
        .addClass('cmw-expander')
        .html('<span>▲</span><span>▼</span>');
      an.css({marginRight:'0.5em',textDecoration:'none'})
        .find('span').eq(1).hide();
      an.on('click', function(){
        var d = $(this).data(),
            act = d.open===false?'slideUp':(d.open?'slideDown':'hide');
        $(this).siblings('ul')[act]();
        $(this).find('span').each(function(i){
          $(this)[!i === !d.open ? 'hide' : 'show']();
        });
        d.open = !d.open;
        return false;
      });
      $(this).parent().prepend(an);
    });
  }).find('.cmw-expander').trigger('click');
});

I’m sorry, it’s taken me a while, but there is now a new version – 1.1.0 – which should hopefully provide the additional functionality mentioned in this thread.

actually it is possible; this works for me (down to IE8)…

.mapsmarker:after {
	clear: left;
	content: "";
	display: block;
	height: 0;
	overflow: hidden;
	visibility: hidden;
	width: 100%;
}
.leaflet-container {
	-webkit-box-sizing: border-box;
	-moz-box-sizing:    border-box;
	box-sizing:         border-box;
	float: left;
	width: 50%;
}
.lmm-listmarkers {
	border-top: 1px solid #cccccc;
	float: left;
	width: 50% !important;
}
.lmm-listmarkers table {
	width: 100% !important;
}

Seems to cope with width set (in the layer) as either ‘px’ or ‘%’, bearing in mind as you do so that the map will be half the width. Obviously percentages can be changed, and all the rules could be qualified with an additional class, either on the map’s container (within the post/page content) or (Robert?) on the div.mapsmarker element.
To be responsive, and move it back under the map at a specific breakpoint, simply…
.leaflet-container, .lmm-listmarkers{width:100% !important;}

@caeles
So if I could refer you back to the questions that I asked of Francesco, the answers would be …
(a) FG
(b) FG
(c) FG
… is that right?
Ie. show only the immediate child items of the current item’s root item?

In other words, if you’re currently anywhere within branch B – including B itself – show B’s immediate children, F & G. And likewise for any other root branch (A & C)

Thanks Francesco.

It looks like the request would be for Children of B, including parent (ie. B); the output would be conditional upon current item being within that selection, and would be limited to a depth of 2 (ie. the level at which current item is found, plus current item’s immediate children).

The current widget doesn’t have that ‘conditional’ aspect (when a specific menu item is selected for the ‘Children of’ filter), and only includes parent (of a ‘Children of’ filter) as afterthought.

I’ll see what I can do.
Regards…

Thank you!

If I may ask for clarification of “…start the menu from the top parent of the current page…“?

In the following menu hierarchy, which of the menu items would you want to be able to configure the widget to show if :
(a) K was the current page? BGK? BGKLM? BFGK? BFGKLM? Maybe ABFGKLMC? Or something else?
(b) M was the current page? BGMPQ? Or …?
(c) B was the current page? …

A
– D
– E
B
– F
– G
– – K
– – L
– – M
– – – P
– – – Q
C
– H
– J

ACF adds a filter – acf/format_value_for_api/type=wysiwyg – to the retrieval of a wysiwyg field. The filter is acf_field_wysiwyg::format_value_for_api(), which runs wpautop() and do_shortcode(). So when you call get_field() on a wysiwyg field, that filter has already been applied. If you then apply the ‘the_content’ filters yourself, those filters include (re-)running wpautop() and do_shortcode(), and a host of other functions.

Applying the filter on the result of the get_field() call would run wpautop() and do_sortcode() twice. What I really wanted to do was get back to the documented Template usage of the Wysiwyg field :

The API will return your content formatted for HTML (the same way that the_content() does)

I eventually got around it by adding the following code to my child theme’s functions.php …

function my_acf_format_value_for_api($value, $post_id, $field){
	return str_replace( ']]>', ']]>', apply_filters( 'the_content', $value) );
}
function my_on_init(){
	if(!is_admin()){
		remove_all_filters('acf/format_value_for_api/type=wysiwyg');
		add_filter('acf/format_value_for_api/type=wysiwyg', 'my_acf_format_value_for_api', 10, 3);
	}
}
add_action('init', 'my_on_init');

I think I can shed some light on this, since I’ve just come across the same issue…

In my particular case it was due to the inclusion of the Cyclone Slider 2 extension, which uses Malsup’s jQuery Cycle2 plugin. Both the Cycle plugin (also by Malsup) and the Cycle2 plugin declare jQuery.fn.cycle(), so whichever one of NextGen or Cyclone Slider 2 gets initialised latest is going to govern which $.fn.cycle() ends up being used, Cycle or Cycle2. In my case, Cyclone Slider 2 comes in second, so Cycle2 gets into $.fn.cycle(), and the APIs for Cycle2 and Cycle are quite different. So, when NextGen slideshow tries use Cycle2 as if it where Cycle, it doesn’t work! It initialises and does the basics as expected, but there is no ‘before’ option or ‘addSlide’ method (among other things) available in Cycle2 … which is how NextGen’s slideshow expects to be able to load any slides beyond the first 3.

One work around is to enable the Flash slideshow in NextGen, and use that instead of the default jQuery Cycle mechanism.
Another option (in my case) is to use Cyclone Slider 2 to show the NextGen gallery, instead of using NextGen itself?

As for a more permanent solution?
Hmmm … I guess that one way might be for NextGen to update its slideshow to use Cycle2 instead of Cycle. However, that won’t remove the possibility of further conflicts between extensions that use Cycle and extensions that use Cycle2!