Is this a WordPress bug? Did one of those darn plugins do it?! Nope, it’s a server configuration issue that silently cuts your menu items down before WordPress even knows about them, like wolves picking off sheep in the night. Or you know, the HTTP/PHP equivalent of that.

Shake your fist at the sky and take a deep breath, and I’ll lay it out for you.

High Level Overview

Let’s start at the beginning. There are three important things to understand:

1. To save a WordPress menu, you have to send data from the client (your web browser) to the server, where it is processed and stored by the WordPress Menu System. This form data is submitted to the server via an HTTP POST. PHP parses this data as a nice array that we know and love – $_POST.

2. The WordPress Menu System bases the menu items it saves on the data it receives from the client side via the $_POST array. It assumes that data that is not present should be removed – that is, WordPress deletes menu items not present in the $_POST array upon save.

3. Depending on your server configuration, not all of the POSTed variables sent by the client may be received by the WordPress, as the $_POST array can be truncated. And when that data is lost, we lose menu items. Dang.

Hold on, I’ve had enough of the techno-babble. Skip to the Solution

Here’s how it works

Every menu item on the Appearance > Menus screen has about 11-12 fields associated with it (Title, Classes, Description, ID, etc). There are also a few meta values for the menu overall (like the menu name, menu ID, and a few nonce-related fields for security). All this data gets sent to the server as POST data. Each field is a separate POST variable. So if you have 10 menu items, you’re sending around 120 POST variables (11 per menu item + various menu meta fields). If you have 100 menu items, you’re sending around 1200 POST variables.

Here’s the problem

Unfortunately, PHP’s desire to be secure and WordPress’s desire to be tidy conspire to stab you in the back. Two wrongs might not make a right, but in this case, two rights make a big ol’ headache.

PHP’s Security

For security reasons, PHP likes to limit the maximum numbers of POST vars you can submit. This is to mitigate the effects of DoS attacks. We’ll get into details below. The important bit from the PHP manual:

If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request.

This is good, but in practice, if you’re unaware of this setting (and aren’t paying attention to Warnings in the logs – and the average user isn’t), it can produce stress-induced manual hair extraction.

WordPress’s housekeeping

The WordPress Menu System save mechanism works by iterating over the $_POST array, and then discarding any menu items that weren’t present in the array.

//nav-menus.php line 341
// Remove menu items from the menu that weren't in $_POST
if ( ! empty( $menu_items ) ) {
	foreach ( array_keys( $menu_items ) as $menu_item_id ) {
		if ( is_nav_menu_item( $menu_item_id ) ) {
			wp_delete_post( $menu_item_id );
		}
	}
}

That’s good, as it prevents us from having all sorts of orphaned menu items in the posts table. But it also means that if the menu system is sent incomplete data, WordPress assumes the menu items corresponding to that data should be deleted, rather than that they should be ignored.

The Upshot: The road to confounding data loss is paved with good intentions

In the end, if the client submits more menu item variables than the PHP-configured limit, any menu items over the limit will be lost. So if you submit 1200 variables, and the limit is 1000, the last 200 are simply discarded – WordPress never even knows they were sent. These 200 variables will correspond to the last 18 items or so in your menu.

And that is why the menu items are lost. PHP prevents the menu items that you saved on the client side from reaching WordPress’s processing on the server side, so WordPress decides to delete the menu items. Who’s at fault? (I demand blood!) No one, really. It’s just a situation where you need to configure your server properly.

Menu Item Specifics

Here’s how the POST variables that are submitted on menu save break down, for those who want specifics:

Key

POST Variables (Example values using 100 menu items)

You can estimate about 12 variables per menu item to be safe. So if you want to save a menu with 150 items, you’d want a POST variable limit of no less than 150*12 + 10 = 1810.

So why does this happen suddenly and without warning?

Sometimes this issue manifests as a user reaching a simple limit: they’ve added 50 menu items. They try to add the 51st, and nothing happens if they’re adding it at the end. Or if they add it in the middle, the last menu item is dropped. The limit is 50, so every time they add X more items, the last X are deleted.

Much more distressing is the case where a user has happily had 120 menu items for the last month. Then, one fateful day, they go to manage their menu, as they have new content they wish to add. Upon adding their 121st menu item and saving, they find that suddenly, to their horror, the last 40 menu items have been deleted. How could that happen? The POST vars limit should have prevented them from adding 120 menu items in the first place, right?

The most likely scenario leading to this massive frustration is that the server’s PHP version has been updated, either by the user or the web host (or possibly added Suhosin, but let’s focus on one thing at a time). And here’s why:

The PHP directive max_input_vars was introduced in PHP 5.3.9 (a relatively recent addition from January 10, 2012). The real issue is that this directive has a default value of 1000. That’s a limit of around 80 menu items. The problem comes from this sequence of events:

1. User adds 120 menu items while host is at PHP version < 5.3.9 (no menu item limit, because max_post_vars does not exist)
2. Host upgrades server PHP to 5.3.9+
3. User adds 121st menu item. Only the first 80 are sent to the server due to new POST variable limit. User loses 40ish menu items
4. User rips out hair and smashes computer against wall. Vows to quit WordPress once and for all

How UberMenu factors in (for those who care)

I'd like to quickly address the impact my plugin, UberMenu - WordPress Mega Menu Plugin, has on this scenario. While UberMenu does not cause this limit, it does cause the user to reach their menu item limit faster, because it adds one extra variable to each menu item.

Note that UberMenu actually adds around 10 extra settings to each menu item. However, in an effort to minimize this limitation effect, UberMenu serializes all of its settings into a single active form field (via javascript), so that it only contributes one additional POST variable per menu item, rather than 10 per item. This optimization was added in UberMenu 2.0.

So here's how it breaks down with some quick examples.

Adding UberMenu to the mix means the limit decreases by about 6 menu items per 1000 POST vars.

Unfortunately, this has the effect of customers believing UberMenu is the cause of the issue, because with UberMenu enabled they can only add 76 menu items; with UberMenu disabled, they can add 77, 78, 79... and as such it is natural to confuse symptom for cause and conclude that UberMenu is the problem. It's not; it just makes the problem apparent sooner, unfortunately.

Server Configuration Solution

As with most problems, once you understand the issue, it's easy to solve it. The server configuration is limiting the number of POST variables the can be submitted to the server; we need to increase that.

There are two ways this limit may be imposed

1. PHP's max_input_vars

The increasingly common issue is the max_input_vars PHP directive. By default, it is set to 1000. To increase this, simply set it in php.ini. I'd suggest 3000 to be safe, but 2000 should be sufficient for most sites.

max_input_vars = 3000

How do you edit php.ini? That depends on your host. If you have access to the php.ini file, simply add or edit the directive, save, and restart Apache. If you're with a web host that doesn't give you access (common with shared hosting), you may have to contact your host and have them make the change for you.

2. Suhosin

Prior to PHP's max_input_vars, the Suhosin PHP Security module introduced a similar pair of max_vars directives that are identical in purpose. Not all servers run Suhosin, but those that do will need to increase the following directives in php.ini:

suhosin.post.max_vars = 3000
suhosin.request.max_vars = 3000

Again, you may need to contact your host to get them to make these changes if you don't know how or can't do it yourself.

Restarting Apache with the new maximum POST variable values should allow you to submit all of your menu item variables and therefore save new menu items. Hoorah!

Keep in mind this won't actually recover your lost menu items - that data is gone. The only way to get it back would be to restore from a backup copy of your database.

How to edit php.ini on various hosts:

• MediaTemple
• BlueHost
• HostGator
• DreamHost

Is there a better solution?

Wouldn't it be nice if this wasn't an issue? Theoretically, there may be a few options. In practice, most are more easily said than done.

Option 1: Condense all of the WordPress Menu Item fields into a single input before submitting

This is what I did with UberMenu - just serialize all the settings and decode the string on the server side. It works well, with two caveats. First, we still have the potential to reach a menu item limit eventually. Second, it means we don't have a non-javascript fallback, and for core WordPress functionality, that's a no-go. So that solution is probably out.

Option 2: Save menu items individually

We could save menu items via AJAX, individually, so we'd only ever submit data for one menu item at a time. Again, this requires javascript, and I suspect it would also require a major reworking of how the menu system works. It would also have to be implemented carefully in order to be intuitive and convenient; I think there would still need to be a Save-All button that would sequence all of the menu items for processing.

I don't have enough expertise in the nitty gritty of the menu system to say whether this is truly a viable/practical option.

Option 3: Use a "checksum" to protect from unintended deletions

I'm using the term loosely here, but we could submit an extra form field that acts as a "checksum", indicating how many menu items are being sent to the server for processing. WordPress's menu save process could then check this value to make sure the number of menu items that it has received in the $_POST array is equivalent to the number of items it expects to receive. If it finds a discrepancy, it could avoid deleting missing menu items; however, it may be too late to save newly submitted menu items that were previously unknown.

Option 4: Native Nested Menus

Another thought would be to provide a native nesting/import functionality in WordPress. Essentially, each menu item would have an option to nest a separate menu as its submenu. This would allow users to divide up their menu items among multiple menu trees, to be dynamically assembled when the menu is printed. There are some existing plugin solutions out there that already do this, I believe. This would also enhance the reusability of the menu system, as users could potentially use the same menu subtree fragments in multiple menus.

Option 5: Provide a Warning

I think this is really the best option, at least in the short term. Simply detect the potential issue and alert the user to it. Providing explanations and solutions (or links to solutions) within the interface is generally the most efficient way to inform a user of what they need to be aware of and resolve.

And that brings us to...

The Menu Item Limit Detector Plugin

As a first step toward this, I've written a rudimentary plugin that attempts to detect impending menu item limits by roughly (and conservatively) estimating the remaining POST variables based on the prior save and the current variable limits. It adds an alert in the Appearance > Menus screen when the user approaches the limit, and explains the issue.

The obvious downside to the plugin is that users need to be aware of the issue in order to install it in the first place... and the whole point of the plugin is to provide that awareness. Chicken and egg much? This'd be far more useful in WordPress Core.

Download the Plugin Contribute on Github

Please try out the plugin and let me know if it helps! If it's useful, I'll add it to the WordPress plugin repository.

And let me know if you have any creative suggestions for solving this problem! I highly doubt the options I've presented are comprehensive, but I hope they start the conversation going in the right direction.

UberMenu 2.3 was released today, and includes a variety of updates and feature enhancements:

• Updated Search Box Styling
• Ability to name custom widget areas
• Improved localization
• Added ability to include custom javascript
• Ability to disable updates
• Separated basic.css into LESS stylesheets for easier customization
• Improved compatibility with nested plugin styles
• Improved Windows 8 Mobile touch compatibility
• Fixed minor skin bugs

Important upgrade notes

For those upgrading from a previous version of UberMenu, there are a few changes to the plugin to be aware of.

General upgrade

UberMenu 2.3 has a lot of refactoring and refining to the core code. It’s best to delete the previous plugin files and replace them with the new version. Don’t forget to back up any changes!

Style Generator Skins

In the latest version of UberMenu, LIs are now qualified with the .menu-item class in stylesheets in an effort to improve widget and shortcode style compatibility. As a result, you may need to re-save your style generator styles in order to update the skin to be compatible with the latest version.

custom.css Skins

If you are using a custom.css file, you will need to move it into the new /custom folder for it to be picked up by the new version of UberMenu. That is, save your custom.css before upgrading, then move it to the /custom folder.

Also, in the latest version of UberMenu, LIs are now qualified with the .menu-item class in stylesheets in an effort to improve widget and shortcode style compatibility. You will likely need to qualify all of the appropriate LIs in your custom stylesheet with the .menu-item class as well in order to make sure your styles have a high enough specificity to be applied. Generally, a simple find-and-replace from ” li” to ” li.menu-item” will resolve the issue – just be careful not to duplicate the class, and not to replace any LIs that aren’t actually menu items in your style selectors.

You may also need to add the class .megaMenu to any top level ULs in your skins to make sure your styles are specific enough.

Sorry for the inconvenience! But these changes will help improve future compatibility with other content you might like to place in your menu

Search Bar

UberMenu 2.3 introduces a new search bar style and functionality, and will replace your old UberMenu search short code automatically. If you wish to revert to the old style, please use the short code [ubermenu-search-v1]

Enjoy UberMenu 2.3!

Update April 13, 2013

UberMenu 2.3 bugs that have now been resolved in 2.3.0.1

Unfortunately, a few bugs were introduced in UberMenu 2.3, and have now been resolved. They are noted below for your reference:

Easy Integration Shortcode

Please note, if you are using the Easy Integration shortcode – [uberMenu_easyIntegrate] (normal PHP Easy Integration should not be affected), do not update yet.

TimThumb

I introduced a bug with timthumb in 2.3. If you are using Timthumb, please do not upgrade yet.

I have a fix and have already submitted version 2.3.0.1 (April 12 4PM EDT), and I will update this post when it is approved by CodeCanyon and ready for download. Thanks for your understanding and sorry for the inconvenience!

Update April 13: Version 2.3.0.1 is now available and safe to upgrade – thanks!

The basic idea is this: Each template is wrapped in HTML comments so that the output on the front end looks something like this (simplified):

<body>
    <header>
      ...
    </header>

    <div class="main">

        <!-- begin archive.php [theme_name] -->
        <div class="primary">

              <!-- begin content.php [theme_name] -->
              <article class="post">

              </article>
              <!-- end content.php -->
        </div>
        <!-- end archive.php -->

        <!-- begin sidebar.php [theme_name] -->
        <div class="sidebar">

        </div>
        <!-- end sidebar.php -->

    </div>
  

    <footer class="site-footer">
      ...
    </footer>

</body>

This gives the developer/customer an immediate reference for where to start looking in the theme files in order to locate the appropriate spot to make changes/override in a child theme. Of course, you could do this with static HTML comments in each template – I’ve done this in my previous theme, and it has definitely helped customers. The downside is that every time you make a new template, if you base it off of an existing template (which I expect is a common scenario), you have to remember to update the comments. That can be a bit tedious, and failure to do so can result in inaccurate comments, and the last thing we want is to send the customer on a wild goose chase. This technique avoids that.

Of course, sometimes the classes applied to the body tag can be enough to identify the template for advanced users, but the source of a template file can still be ambiguous if a child theme is in use, or when we are using nested content templates. This technique makes it immediately clear which template is producing which code.

We’ll define two functions that dynamically output the template location within the theme. Then we just add these functions to the start and end of each template file to act as bookends for the code. We can copy these functions as many times as we want, and they will always remain accurate within the template they appear (just remember that wherever the __FILE__ magic constant is invoked is the location that will be printed – that’s why __FILE__ must be passed as a parameter). Moreover, if we want to change the structure of the comment, or remove them altogether based on a setting, that becomes trivial to accomplish. Here are the functions, which you should namespace:

function begin_template( $file ){
	?>	<!-- begin <?php echo basename( $file ) . " [".basename( dirname( $file ) ) ."]" ; ?> -->
	<?php
}
function end_template( $file ){
	?><!-- end <?php echo basename( $file ); ?> -->
	<?php
}

Then within the template files, they are called like this:

<?php tinderbox_begin_template( __FILE__ ); ?>
<?php tinderbox_end_template( __FILE__ ); ?>

Each function determines the file name and prints it within an HTML comment. For the beginning comment, we also print out the directory in which the template appears – this makes it easy to determine if the template is from the parent or child theme.

Here’s a basic example of how index.php might look (this is Underscores-based):

get_header(); ?>
		
		<?php begin_template( __FILE__ ); ?>
		<div id="primary" class="content-area span8">
			<div id="content" class="site-content" role="main">

			<?php if ( have_posts() ) : ?>

				<?php tinderbox_content_nav( 'nav-above' ); ?>

				<?php /* Start the Loop */ ?>
				<?php while ( have_posts() ) : the_post(); ?>

					<?php
						/* Include the Post-Format-specific template for the content.
						 * If you want to overload this in a child theme then include a file
						 * called content-___.php (where ___ is the Post Format name) and that will be used instead.
						 */
						get_template_part( 'content', get_post_format() );
					?>

				<?php endwhile; ?>

				<?php tinderbox_content_nav( 'nav-below' ); ?>

			<?php else : ?>

				<?php get_template_part( 'no-results', 'index' ); ?>

			<?php endif; ?>

			</div><!-- #content .site-content -->
		</div><!-- #primary .content-area -->
		<?php begin_template( __FILE__ ); ?>

<?php get_sidebar(); ?>
<?php get_footer(); ?>

The functions bookend the meat of the template, excluding headers, sidebars, and footers. In the content-{type}.php templates, the comment functions would wrap the entire contents of the file.

Now we can make as many copies of this template as we want, and never worry about updating the comments. Nifty.

I think if more developers adopt this type of commenting (in addition to standard code commenting), it’ll go a long way toward customers becoming self-sufficient in sourcing template files and making their own customizations. Plus, I find it makes things much easier for myself during the development process.

You can see that I’ve placed anchor tags in the photo caption to link to the photo credit:

Photo credit: <a href="http://www.flickr.com/photos/nattu/2735064420">nattu</a></code>

When you click the “Insert into Post” button, you end up with this markup in your editor:

[ caption id="attachment_1133" align="alignleft" width="300" 
caption="Photo credit: <a href=&quot;http://www.flickr.com/photos/nattu/2735064420&quot;&gt;nattu&lt;/a&gt;"]
<a data-rel="prettyPhoto" title="The Entrance" href="http://localhost/agility/wp-content/uploads/2012/03/TheEntrance.jpg">
<img src="http://localhost/agility/wp-content/uploads/2012/03/TheEntrance-300x199.jpg" alt="" title="The Entrance" width="300" height="199" class="scale-with-grid size-medium wp-image-1133" /></a>[/caption]

Skip to the code solution

The Problem

The issue is that all the HTML entities in the caption attribute (specifically, the anchor tags) are encoded. That is, instead of

Photo credit: <a href="http://www.flickr.com/photos/nattu/2735064420">nattu</a>

we have

Photo credit: <a href="http://www.flickr.com/photos/nattu/2735064420">nattu</a>

As a result, instead of getting the desired output in our caption:

Photo credit: <a href="http://www.flickr.com/photos/nattu/2735064420">nattu</a>

We get the encoded HTML markup instead:

Photo credit: <a href="http://www.flickr.com/photos/nattu/2735064420">nattu</a>

The Solution

Now, the HTML entities have to be escaped in order to safely place them in the caption=”" attribute of the caption shortcode (or at least the double quotes do), and in any event it’s very inconvenient to decode the entities manually. What we’ll need to do is decode them programmatically when the shortcode is processed at run time.

Helpfully, WordPress’s img_caption_shortcode function (wp-includes/media.php) includes a filter that allows us to hook in and override the caption. Here’s the original function:

/**
 * The Caption shortcode.
 *
 * Allows a plugin to replace the content that would otherwise be returned. The
 * filter is 'img_caption_shortcode' and passes an empty string, the attr
 * parameter and the content parameter values.
 *
 * The supported attributes for the shortcode are 'id', 'align', 'width', and
 * 'caption'.
 *
 * @since 2.6.0
 *
 * @param array $attr Attributes attributed to the shortcode.
 * @param string $content Optional. Shortcode content.
 * @return string
 */
function img_caption_shortcode($attr, $content = null) {

	// Allow plugins/themes to override the default caption template.
	$output = apply_filters('img_caption_shortcode', '', $attr, $content);
	if ( $output != '' )
		return $output;

	extract(shortcode_atts(array(
		'id'	=> '',
		'align'	=> 'alignnone',
		'width'	=> '',
		'caption' => ''
	), $attr));

	if ( 1 > (int) $width || empty($caption) )
		return $content;

	if ( $id ) $id = 'id="' . esc_attr($id) . '" ';

	return '<div ' . $id . 'class="wp-caption ' . esc_attr($align) . '" style="width: ' . (10 + (int) $width) . 'px">'
	. do_shortcode( $content ) . '<p class="wp-caption-text">' . $caption . '</p></div>';
}

add_shortcode('gallery', 'gallery_shortcode');

We’re just going to hook in and use the same code, but add a line of our own to decode the HTML tags.

$caption = html_entity_decode( $caption );

The Code

So, our final function, which I’ve placed in functions.php, looks like this:

//Our custom caption shortcode function is based on the WordPress Core version with a small change
function custom_img_caption_shortcode( $a , $attr, $content = null) {

	extract(shortcode_atts(array(
		'id'	=> '',
		'align'	=> 'alignnone',
		'width'	=> '',
		'caption' => ''
	), $attr));

	if ( 1 > (int) $width || empty($caption) )
		return $content;

	$caption = html_entity_decode( $caption );  //Here's our new line to decode the html tags

	if ( $id ) $id = 'id="' . esc_attr($id) . '" ';

	return '<div ' . $id . 'class="wp-caption ' . esc_attr($align) . '" style="width: ' . (10 + (int) $width) . 'px">'
	. do_shortcode( $content ) . '<p class="wp-caption-text">' . $caption . '</p></div>';
}
//Add the filter to override the standard shortcode
add_filter( 'img_caption_shortcode', 'custom_img_caption_shortcode', 10, 3 );

And that’s it! Just pop that code into your functions.php and you should be able to add links to your photo captions. If anyone knows a better way of doing this, let me know in the comments. Enjoy!

1. In Appearance > Menus, click the Screen Options tab

2. Under Show advanced menu properties, check CSS Classes

3. Now expand any menu item to reveal the CSS Classes (optional) text input.

4. Enter your class name and save your menu to apply the class to the menu item

The class will be added to the LI (list item) element, the same element that has the menu item ID attached. You can then style your item like this, where .menu is replaced by the class used for your menu:

/* Target the menu item LI */
.menu li.myClass{
  /* Margin might go here */
}
/* Target the menu item Anchor (link) */
.menu li.myClass > a{
  /* Colors, font sizes, would normally go here */
}

/* Target the menu item LI in UberMenu */
#megaMenu ul.megaMenu li.myClass{

}
/* Target the menu item Anchor (link) in UberMenu */
#megaMenu ul.megaMenu li.myClass > a{
  /* Colors, font sizes, would go here */
}

Remember that you may need to increase your selector specificity or use the !important flag in order to ensure that your new styles are applied.

5. Enjoy even more customization control over your menu!

Note that this is a standard WordPress feature and works with or without UberMenu.

In the last year I’ve gathered a lot of insight into the menu process through my interactions with the many users I’ve supported. I’ve learned a lot about what features users make the most use of, what tends to cause confusion, common customization needs, and a whole lot more.

I’ve spent the last month and a half distilling this accumulated knowledge into what is now UberMenu 2.0, refining functionality and enhancing the feature set. My goals with UberMenu 2.0 have been:

1. Increase the intuitiveness of the plugin
2. Improve areas that tend to cause customer confusion
3. Increase javascript efficiency
4. Increase plugin extensibility
5. Improve menu design, robustness, and flexibility

I’m very proud of the new UberMenu 2.0, which represents a huge time investment to deliver major enhancements. Here are some of the new features in UberMenu 2.0.

Enhanced CSS

The basic CSS structure of UberMenu has been torn down and rebuilt to provide an even stronger foundation for the menu. This means menus act more intuitively out of the box, and customizations are simpler to implement. It also means that UberMenu works excellently as a pure CSS menu with full-width submenus.

More Efficient Javascript

A stronger CSS foundation means less calculations in the javascript, which leaves us with a much lighter weight and more efficient jQuery plugin enhancing UberMenu. The javascript has also been rewritten as a jQuery plugin, implementing jQuery best practices. The upshot is that UberMenu now loads and runs faster than ever.

Full Width Submenus and Defined Columns

One part of UberMenu 1.x which was less intuitive than it could be was column formatting. Columns were sized entirely based on their content size, which led to some interesting corner cases. While these issues were easily resolvable via custom CSS, for users without a working knowledge of the box model, such strange behavior was frustrating and confusing.

In UberMenu 2.0, columns can be sized in two ways, on a per-submenu basis: naturally, or in grid based columns. In a natural layout, each column is sized to its contents, and each column may be a different width. This is great for single-row submenus. For multiple-row submenus, UberMenu 2.0 adds the ability to set a submenu to be full-width, and apply a specific number of columns to the submenu. These columns will be uniformly sized, and extend the entire width of the submenu automatically.

I believe this new system is much more intuitive and will provide users a much better experience when wrangling their submenus into the formats they desire.

Fully Responsive Menus

When designing Agility HTML5 Template, I spent a long while studying responsive design best practices. UberMenu makes use of that knowledge to deliver a responsive mega menu. As the viewport changes, UberMenu’s contents size intelligently to optimize display at each size. (Note this can be disabled for non-responsive themes).

iPhone and iPad Compatibility

Going hand in hand with the responsive mega menu enhancements, UberMenu is now even more compatible with iOS devices, delivering an intuitive user experience for responsive themes.

More Flexibility

Another goal of UberMenu 2.0 is to build in some of the most common customizations into the Control Panel, to avoid core UberMenu edits. Now you can:

1. Customize dropdown animation speeds
2. Trigger via hover in addition to hoverIntent and click
3. Customize hover intent timing
4. Disable image resizing
5. Enable or disable loading UberMenu on registration and login pages

Fresh menu skins

Both design trends and my own design skills have advanced a lot in the last year. UberMenu 2.0 features refreshed menu skins, with progressive CSS3 enhancements. The designs are now cleaner and more modern (the old designs are still included for legacy use, if desired).

Watch for more menu skin options coming soon!

Rewritten Style Generator

The UberMenu Style Generator has been completely rewritten to make use of LESS via lessphp. This means more consistency and easier upgrades. The new Style Generator also has the ability to write your custom style to an external stylesheet rather than including the CSS in the site header (though that is still an option).

A note on backwards compatibility

In developing UberMenu 2.0, I’ve made every effort to maximize compatibility with previous UberMenu installations. All menu items and their options, as well as UberMenu Control Panel options, will remain intact. Unfortunately, some sacrifices had to be made in the name of progress. Because the underlying CSS structure has been enhanced, some types of customizations may no longer appear as desired and may need to be reworked – though in some cases they will no longer be necessary at all! Specifically, submenu positioning and column resizing may need to be readdressed. However, all previous class names and IDs have remained consistent to minimize the impact and make the transition for users from 1.x to 2.0 as smooth as possible.

Well, that’s about it. I hope UberMenu customers enjoy the upgrade! It’s been a long process getting to this point, and I’m very pleased with the results. Feedback is always welcome and will be considered for future releases whenever possible.

Thanks again to all UberMenu customers for your business!

ReplyPantry is a Google Chrome Extension that allows Envato Marketplace users to insert customized text snippets into forum posts or item comments.

Once you install ReplyPantry you’ll see the can icon below your reply boxes in the forums – and above in the item comments. Click the can icon to show the canned text snippets (“cans”), and click a can title to insert that canned text. You’re able to add, save, edit, and remove cans. Hopefully it’s fairly intuitive.

If you’re using Google Chrome, clicking the download link should allow you to download and prompt you to install the extension.

Add the functional code

First, here’s the code to add (anywhere, but functions.php works well. It’ll be added to CF7 DTX some time down the road hopefully).

//Define the key to store in the database
define( 'CF7_COUNTER', 'cf7-counter' );

//Create the shortcode which will set the value for the DTX field
function cf7dtx_counter(){
    $val = get_option( CF7_COUNTER, 0) + 1;  //Increment the current count
    return $val;
}
add_shortcode('CF7_counter', 'cf7dtx_counter');

//Action performed when the mail is actually sent by CF7
function cf7dtx_increment_mail_counter(){
    $val = get_option( CF7_COUNTER, 0) + 1; //Increment the current count
    update_option(CF7_COUNTER, $val); //Update the settings with the new count
}
add_action('wpcf7_mail_sent', 'cf7dtx_increment_mail_counter');

Configure the Contact Form

Next, we set up our contact form. We’re going to add a new hidden dynamic field to it using CF7 DTX and the new shortcode we just wrote. Here’s what that code would look like in the Contact Form 7 Form Settings:

[dynamichidden cf7-counter "CF7_counter"]

Finally, we want to include the count in the message we receive, so we’ll add it to the CF7 Message Body field:

Count: [cf7-counter]

Some Notes

• The counter only increments when the mail is actually sent. Form loads and failed sends won’t trigger the count to increase.
• If two contact forms are submitted without reloading the page, the count will be incremented properly, but it won’t be reflected in the email. This is because the count that is sent in the email is only updated when the page loads. To update it without a page load, you’d need to write some JS that hooks into CF7′s send callbacks.

That’s about it – enjoy! Let me know in the comments if you find this useful (or run into any trouble).

Here’s a free CSS3 Apple-style menu skin for use with UberMenu – WordPress Mega Menu Plugin.

How to install

1. Copy the contents of the download to your plugins/wp-uber-menu/styles/skins/custom.css file.
2. In Appearance > UberMenu > Style Settings, set Style Application to Preset
3. Set Style Preset to Custom

Enjoy!

Here’s a set of pure CSS3 Progress Bars. They are currently static (their progress percentage is set via CSS), but they could be adapted to any progress bar script I expect.

Inspiration and Resources:

• Orman Clark’s Miniature Progress Bar
• Lea Verou’s Checkerboard, striped & other background patterns with CSS3 gradients