Emailed Author: There are issues with your plugin code.

Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in significant delays with your plugin being accepted.

Also please remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:

* https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

## Generic function (and/or define) names

All plugins must have unique function names, defines, and classnames. This prevents your plugin from conflicting with other plugins or themes.

For example, if your plugin is called "Easy Custom Post Types", then you might prefix your functions with ecpt_{your function name here}. Similarly a define of LICENSE would be better done as ECPT_LICENSE. You can use namespaces instead, however make sure that those also are unique. A namespace or class of 'MyPlugin' is NOT actually all that unique.

This extends to anything in a define. For example, if you were to use this, it would be a bad idea:

define( 'PLUGIN_PATH', plugins_url( __FILE__ ) );

That define is a global, so PLUGIN_PATH could conflict with a number of other things.

Don't try to use two letter slugs anymore. As of 2016, all the good ones are taken. Instead consider easy_cpts_ (from the first example).

Similarly, don't use __ (double underscores), wp_ , or _ (single underscore) as a prefix. Those are reserved for WordPress itself. You can use them inside your classes, but not as stand-alone function.

Please update your plugin to use more unique function and class names.

Some examples from your plugin:

define('yabp_URL', plugins_url( '/', __FILE__ ) );
define('yabp_PATH', plugin_dir_path(__FILE__) );
define('yabp_PREF', $wpdb->base_prefix.'n_' );
function yabp_activation()

yabp_ doesn't match this plugin name.

## Please sanitize, escape, and validate your POST calls

When you include POST/GET/REQUEST calls in your plugin, it's important to sanitize, validate, and escape them. The goal here is to prevent a user from accidentally sending trash data through the system, as well as protecting them from potential security issues.

SANITIZE: All instances where generated content is inserted into the database, or into a file, or being otherwise processed by WordPress, the data MUST be properly sanitized for security. By sanitizing your POST data when used to make action calls or URL redirects, you will lessen the possibility of XSS vulnerabilities. You should never have a raw data inserted into the database, even by a update function, and even with a prepare() call.

VALIDATE: In addition to sanitization, you should validate all your calls. If a $_POST call should only be a number, ensure it's an int() before you pass it through anything. Even if you're sanitizing or using WordPress functions to ensure things are safe, we ask you please validate for sanity's sake. Any time you are adding data to the database, it should be the right data.

ESCAPE: Similarly, when you're outputting data, make sure to escape it properly, so it can't hijack admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data.

In all cases, using stripslashes or strip_tags is not enough. You need to use the most appropriate method associated with the type of content you're processing. Check that a URL is a URL and don't just be lazy and use sanitize_text please. The ultimate goal is that you should ensure that invalid and unsafe data is NEVER processed or displayed. Clean everything, check everything, escape everything, and never trust the users to always have input sane data.

Please review this document and update your code accordingly: http://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data

## Allowing Direct File Access to plugin files

Direct file access is when someone directly queries your file. This can be done by simply entering the complete path to the file in the URL bar of the browser but can also be done by doing a POST request directly to the file. For files that only contain a PHP class the risk of something funky happening when directly accessed is pretty small. For files that contain procedural code, functions and function calls, the chance of security risks is a lot bigger.

You can avoid this by putting this code at the top of all php files:

if ( ! defined( 'ABSPATH' ) ) exit; // Exit if accessed directly

----

Please make sure you've addressed ALL issues brought up in this email. When you've corrected your code, reply to this email with the updated code attached as a zip, or provide a link to the new code for us to review. If you have questions, concerns, or need clarification, please reply to this email and just ask us.

(While we have tried to make this review as exhaustive as possible we, like you, are humans and may have missed things. As such, we will re-review the ENTIRE plugin when you send it back to us. We appreciate your patience and understanding in this.)

Emailed Author: There are issues with your plugin code.

Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in significant delays with your plugin being accepted.

Also please remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:

* https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

## Encrypted code

Using encryption methods like base64() or p,a,c,k,e,r to hide your code or otherwise make it human-unreadable is in violation of the directory guidelines, found at: https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

In specific, the fourth guideline, which reads: "4. No obfuscated code."

This also includes using phar to compress your PHP and making all your PHP mashed into one line.

It's fine to compress your code and minify, but it's not okay to hide it. All code must be human readable for inclusion in this directory.

You need to remove aws.phar

Yes, use the WHOLE library.

----

Please make sure you've addressed ALL issues brought up in this email. When you've corrected your code, reply to this email with the updated code attached as a zip, or provide a link to the new code for us to review. If you have questions, concerns, or need clarification, please reply to this email and just ask us.

(While we have tried to make this review as exhaustive as possible we, like you, are humans and may have missed things. As such, we will re-review the ENTIRE plugin when you send it back to us. We appreciate your patience and understanding in this.)

Emailed Author: There are issues with your plugin code.

Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in significant delays with your plugin being accepted.

Also please remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:

* https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

## Generic function (and/or define) names

All plugins must have unique function names, defines, and classnames. This prevents your plugin from conflicting with other plugins or themes.

For example, if your plugin is called "Easy Custom Post Types", then you might prefix your functions with ecpt_{your function name here}. Similarly a define of LICENSE would be better done as ECPT_LICENSE. You can use namespaces instead, however make sure that those also are unique. A namespace or class of 'MyPlugin' is NOT actually all that unique.

This extends to anything in a define. For example, if you were to use this, it would be a bad idea:

define( 'PLUGIN_PATH', plugins_url( __FILE__ ) );

That define is a global, so PLUGIN_PATH could conflict with a number of other things.

Don't try to use two letter slugs anymore. As of 2016, all the good ones are taken. Instead consider easy_cpts_ (from the first example).

Similarly, don't use __ (double underscores), wp_ , or _ (single underscore) as a prefix. Those are reserved for WordPress itself. You can use them inside your classes, but not as stand-alone function.

Please update your plugin to use more unique function and class names.

Some examples from your plugin:

function dropdown_options
function linked_draft_row_action

## Please sanitize, escape, and validate your POST calls

When you include POST/GET/REQUEST calls in your plugin, it's important to sanitize, validate, and escape them. The goal here is to prevent a user from accidentally sending trash data through the system, as well as protecting them from potential security issues.

SANITIZE: All instances where generated content is inserted into the database, or into a file, or being otherwise processed by WordPress, the data MUST be properly sanitized for security. By sanitizing your POST data when used to make action calls or URL redirects, you will lessen the possibility of XSS vulnerabilities. You should never have a raw data inserted into the database, even by a update function, and even with a prepare() call.

VALIDATE: In addition to sanitization, you should validate all your calls. If a $_POST call should only be a number, ensure it's an int() before you pass it through anything. Even if you're sanitizing or using WordPress functions to ensure things are safe, we ask you please validate for sanity's sake. Any time you are adding data to the database, it should be the right data.

ESCAPE: Similarly, when you're outputting data, make sure to escape it properly, so it can't hijack admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data.

In all cases, using stripslashes or strip_tags is not enough. You need to use the most appropriate method associated with the type of content you're processing. Check that a URL is a URL and don't just be lazy and use sanitize_text please. The ultimate goal is that you should ensure that invalid and unsafe data is NEVER processed or displayed. Clean everything, check everything, escape everything, and never trust the users to always have input sane data.

Please review this document and update your code accordingly: http://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data

Example:

$original_post_id = $_GET['post'];

----

Please make sure you've addressed ALL issues brought up in this email. When you've corrected your code, reply to this email with the updated code attached as a zip, or provide a link to the new code for us to review. If you have questions, concerns, or need clarification, please reply to this email and just ask us.

(While we have tried to make this review as exhaustive as possible we, like you, are humans and may have missed things. As such, we will re-review the ENTIRE plugin when you send it back to us. We appreciate your patience and understanding in this.)

Emailed Author: There are issues with your plugin code.

Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in significant delays with your plugin being accepted.

Also please remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:

* https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

## Don’t use ‘if exists’ like a silver bullet

Using if (!function_exists(‘NAME ‘)) { around all your functions and classes sounds like a great idea until you realize the fatal flaw. What happens IF someone else has a function with the same name and their plugin or theme loads first?

Your plugin breaks. And that would suck. Please only use if-exists checks for SHARED libraries.

Example:

if( !function_exists('get_paypal_donate_link') )
{
/**
* Get PayPal Donate Link by Country
*/
function get_paypal_donate_link()

That's just a bad habit to get into.

## Please sanitize, escape, and validate your POST calls

When you include POST/GET/REQUEST calls in your plugin, it's important to sanitize, validate, and escape them. The goal here is to prevent a user from accidentally sending trash data through the system, as well as protecting them from potential security issues.

SANITIZE: All instances where generated content is inserted into the database, or into a file, or being otherwise processed by WordPress, the data MUST be properly sanitized for security. By sanitizing your POST data when used to make action calls or URL redirects, you will lessen the possibility of XSS vulnerabilities. You should never have a raw data inserted into the database, even by a update function, and even with a prepare() call.

VALIDATE: In addition to sanitization, you should validate all your calls. If a $_POST call should only be a number, ensure it's an int() before you pass it through anything. Even if you're sanitizing or using WordPress functions to ensure things are safe, we ask you please validate for sanity's sake. Any time you are adding data to the database, it should be the right data.

ESCAPE: Similarly, when you're outputting data, make sure to escape it properly, so it can't hijack admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data.

In all cases, using stripslashes or strip_tags is not enough. You need to use the most appropriate method associated with the type of content you're processing. Check that a URL is a URL and don't just be lazy and use sanitize_text please. The ultimate goal is that you should ensure that invalid and unsafe data is NEVER processed or displayed. Clean everything, check everything, escape everything, and never trust the users to always have input sane data.

Please review this document and update your code accordingly: http://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data

Your class WPASUI_Runcode is VERY dangerous as it's running code without checking it's sane.

Which really is why no one makes plugins like these. While it should only be used by people who know better, it won't be, and as such it's a gateway to being hacked.

----

Please make sure you've addressed ALL issues brought up in this email. When you've corrected your code, reply to this email with the updated code attached as a zip, or provide a link to the new code for us to review. If you have questions, concerns, or need clarification, please reply to this email and just ask us.

(While we have tried to make this review as exhaustive as possible we, like you, are humans and may have missed things. As such, we will re-review the ENTIRE plugin when you send it back to us. We appreciate your patience and understanding in this.)

Emailed Author: There are issues with your plugin code.

Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in significant delays with your plugin being accepted.

Also please remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:

* https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

## Generic function (and/or define) names

All plugins must have unique function names, defines, and classnames. This prevents your plugin from conflicting with other plugins or themes.

For example, if your plugin is called "Easy Custom Post Types", then you might prefix your functions with ecpt_{your function name here}. Similarly a define of LICENSE would be better done as ECPT_LICENSE. You can use namespaces instead, however make sure that those also are unique. A namespace or class of 'MyPlugin' is NOT actually all that unique.

This extends to anything in a define. For example, if you were to use this, it would be a bad idea:

define( 'PLUGIN_PATH', plugins_url( __FILE__ ) );

That define is a global, so PLUGIN_PATH could conflict with a number of other things.

Don't try to use two letter slugs anymore. As of 2016, all the good ones are taken. Instead consider easy_cpts_ (from the first example).

Similarly, don't use __ (double underscores), wp_ , or _ (single underscore) as a prefix. Those are reserved for WordPress itself. You can use them inside your classes, but not as stand-alone function.

Please update your plugin to use more unique function and class names.

Some examples from your plugin:

function dr_add_plugin_action_links
function dr_display_options()

## Hooking into Init for everything

add_action("init", "dr_check");

That's not a good idea. You can hook into the functions that comment, and only run when comments are made. That will make your plugin faster

----

Please make sure you've addressed ALL issues brought up in this email. When you've corrected your code, reply to this email with the updated code attached as a zip, or provide a link to the new code for us to review. If you have questions, concerns, or need clarification, please reply to this email and just ask us.

(While we have tried to make this review as exhaustive as possible we, like you, are humans and may have missed things. As such, we will re-review the ENTIRE plugin when you send it back to us. We appreciate your patience and understanding in this.)

Admin Menu Editor lets you manually edit the Dashboard menu. You can reorder the menus, show/hide specific items, change premissions, and more.

Features

• Change menu titles, URLs, icons, CSS classes and so on.
• Organize menu items via drag & drop.
• Change menu permissions by setting the required capability or role.
• Move a menu item to a different submenu.
• Create custom menus that point to any part of the Dashboard or an external URL.
• Hide/show any menu or menu item. A hidden menu is invisible to all users, including administrators.

The Pro version lets you set per-role menu permissions, hide a menu from everyone except a specific user, export your admin menu, drag items between menu levels, make menus open in a new window and more. Try online demo.

Notes

• If you delete any of the default menus they will reappear after saving. This is by design. To get rid of a menu for good, either hide it or change it’s access permissions.
• In the free version, it’s not possible to give a role access to a menu item that it couldn’t see before. You can only restrict menu access further.
• In case of emergency, you can reset the menu configuration back to the default by going to http://example.com/wp-admin/?reset_admin_menu=1 (replace example.com with your site URL). You must be logged in as an Administrator to do this.

Normal installation

1. Download the admin-menu-editor.zip file to your computer.
2. Unzip the file.
3. Upload the admin-menu-editor directory to your /wp-content/plugins/ directory.
4. Activate the plugin through the ‘Plugins’ menu in WordPress.

That’s it. You can access the the menu editor by going to Settings -> Menu Editor. The plugin will automatically load your current menu configuration the first time you run it.

WP MultiSite installation

If you have WordPress set up in Multisite (“Network”) mode, you can also install Admin Menu Editor as a global plugin. This will enable you to edit the Dashboard menu for all sites and users at once.

1. Download the admin-menu-editor.zip file to your computer.
2. Unzip the file.
3. Create a new directory named mu-plugins in your site’s wp-content directory (unless it already exists).
4. Upload the admin-menu-editor directory to /wp-content/mu-plugins/.
5. Move admin-menu-editor-mu.php from admin-menu-editor/includes to /wp-content/mu-plugins/.

Plugins installed in the mu-plugins directory are treated as “always on”, so you don’t need to explicitly activate the menu editor. Just go to Settings -> Menu Editor and start customizing your admin menu

Notes
* Instead of installing Admin Menu Editor in mu-plugins, you can also install it normally and then activate it globally via “Network Activate”. However, this will make the plugin visible to normal users when it is inactive (e.g. during upgrades).
* When Admin Menu Editor is installed in mu-plugins or activated via “Network Activate”, only the “super admin” user can access the menu editor page. Other users will see the customized Dashboard menu, but be unable to edit it.

1.7.3

• Fixed a bug where closing the menu properties of a custom menu item could set “extra capability” to “read”.
• Added a workaround for WooCommerce 2.6.8 to display the number of new orders in the “Orders” menu title.
• Minor cosmetic changes.
• Tested with WP 4.7 and 4.8-alpha.

1.7.2

• Added capability suggestions and access preview to the “Extra capability” dropdown.
• The plugin now remembers the last selected menu item and re-selects it after you save changes.
• Fixed a layout issue where menus with very long titles would appear incorrectly in the menu editor.
• When you change the menu title, the window title will also be changed to match it. You can still edit the window title separately if necessary.
• Moved the “Icon URL” field up and moved “Window title” down.

1.7.1

• Split the “required capability” field into two parts – a read-only field that shows the actual required capability, and an editable “extra capability” that you can use to restrict access to the menu.
• Added more detailed permission error messages. You can turn them off in the “Settings” tab by changing “Error verbosity level” to “Low”.
• Tested up to WP 4.6.

1.7

• Added a “Plugins” tab. It lets you hide specific plugins from other users. Note that this only affects the list on the “Plugins” page and tasks like editing plugin files, but it doesn’t affect the admin menu.
• Tested up to WordPress 4.6-beta3.

1.6.2

• Fixed a bug that made menu items “jump” slightly to the left when you start to drag them.
• Fixed a Multisite-specific bug where temporarily switching to another site using the switch_to_blog() function could result in the user having the wrong permissions.
• When saving settings, the plugin will now compress the menu data before sending it to the server. This reduces the chances of exceeding request size limits that are imposed by some hosting companies.
• You can dismiss the “Settings saved” notification by clicking the “x” button.
• Tested up to WordPress 4.5.2.

1.6.1

• Fixed a bug introduced in version 1.6 that prevented the “collapse menu” link from working. In some cases, this bug also made it impossible to switch between “Help” tabs.

1.6

• Improved PHP 7 support.
• Added a few more menu icons.
• Added tabs to the settings page: “Admin Menu” and “Settings”. These tabs replace the heading buttons that were previously used to switch between the menu editor and general plugin settings.
• Added basic support for the special “customize” and “delete_site” meta capabilities.
• Fixed a bug that prevented menu items with an empty slug (i.e. no URL) from showing up.
• Fixed a bug where collapsing menu properties would flag the “Icon URL” field as having a custom value even if you hadn’t actually changed it.
• Fixed a rare WPML conflict that sometimes caused the admin menu to use a mix of different languages.
• Improved compatibility with buggy plugins and themes that throw JavaScript errors in their DOM-ready handlers.
• Renamed jquery.cookie.js to jquery.biscuit.js as a workaround for servers with overly aggressive ModSecurity configuration. Apparently, some servers block access to any URL that contains the text “.cookie”.
• Added a compatibility workaround for the DW Question & Answer plugin. The hidden “Welcome”, “Changelog” and “Credits” menu items should no longer show up when you activate AME.
• Added locking to reduce the risk of triggering a race condition when saving menu settings.
• Removed the non-functional “Embed WP page” option.
• Tested up to WordPress 4.5-RC1.

1.5

• Added “Keep this menu open” checkbox. This setting keeps a top level menu expanded even if it is not the current menu.
• Added sort buttons to the top level menu toolbar.
• Added an arrow that points from the current submenu to the currently selected parent menu. This might help new users understand that the left column shows top level menus and the right column shows the corresponding submenu(s).
• Added a new editor colour scheme that makes the menu editor look more like other WordPress admin pages (e.g. Appearance -> Menus). You can enable it through the plugin settings page.
• New and unused menu items will now show up in the same relative position as they would be in the default admin menu. Alternatively, they can be displayed at the bottom of the menu. You can configure this in plugin settings.
• Fixed a rare bug where the menu editor would crash if one of the menu items had a null menu title. Technically, it’s not valid to set the title to null, but it turns out that some plugins do that anyway.
• Top level menus that have an empty title (“”, an empty string) are no longer treated as separators.
• Made all text fields and dropdowns the same height and gave them consistent margins.
• Fixed a number of layout bugs that could cause field labels to show up in the wrong place or get wrapped/broken in half when another plugin changed the default font or input size.
• Fixed a minor layout bug that caused the “expand menu properties” arrow to move down slightly when holding down the mouse button.
• Fixed a minor bug that could cause toolbar buttons to change size or position if another plugin happens to override the default link and image CSS.
• Added a workaround for plugins that create “Welcome”, “What’s New” or “Getting Started” menu items and then hide those items in a non-standard way. Now (some of) these items will no longer show up unnecessarily. If you find menus like that which still show up when not needed, please report them.
• Fixed a few other layout inconsistencies.
• Improved compatibility with buggy plugins that unintentionally corrupt the list of users’ roles by misusing array_shift.
• Fixed a URL parsing bug that caused AME to mix up the “Customize”, “Header” and “Background” menu items in some configurations.
• Fixed a layout issue where starting to drag one menu item would cause some other items to move around or change size very slightly.
• Fixed JavaScript error “_.empty is not a function”.
• Increased minimum required WordPress version to 4.1.
• Renamed the “Show/Hide” button to “Hide without preventing access”. Changed the icon from a grey puzzle piece to a rectangle with a dashed border.
• Made the plugin more resilient to JavaScript crashes caused by other plugins.
• Use <h1> headings for admin pages in WordPress 4.2 and above.
• Made the “delete” button appear disabled when the selected menu item can’t be deleted.
• Moved the “new separator” button so that it’s next to the “new menu” button.
• Changed the close icon of plugin dialogs to a plain white “X”.
• Increased tooltip text size.
• Improved compatibility with IP Geo Block.

1.4.5

• Fixed a TypeError: invalid 'in' operand a error that caused compatibility issues with WordPress 4.3.
• Fixed a bug where the current menu item wouldn’t get highlighted if its URL included %-encoded query parameters.
• Fixed a bug in menu URL generation that could cause problems when moving a plugin menu from “Posts”, “Pages” or a CPT to another menu. The URL of the menu item got changed in a way that could break some plugins.
• Fixed a .htaccess compatiblility issue with with Apache 2.3+.
• Fixed an incorrect directory name in an error message.
• The “Links” menu will no longer show up in the editor unless explicitly enabled. As of WP 3.5, the “Links” menu still exists in WordPress core but is inaccessible because the Links Manager is disabled by default.
• Tested with WordPress 4.3.

1.4.4

• Tested with WordPress 4.2.

1.4.3

• Trying to delete a non-custom menu item will now trigger a warning dialog that offers to hide the item instead. In general, it’s impossible to permanently delete menus created by WordPress itself or other plugins (without editing their source code, that is).
• Added a workaround for a bug in W3 Total Cache 0.9.4.1 that could cause menu permissions to stop working properly when the CDN or New Relic modules were activated.
• Fixed a plugin conflict where certain menu items didn’t show up in the editor because the plugin that created them used a very low priority.
• Signigicantly improved sanitization of menu properties.
• Renamed the “Choose Icon” button to “Media Library”.
• Minor compatibility improvements.

1.4.2

• Tested on WP 4.1 and 4.2-alpha.
• Fixed a bug that allowed Administrators to bypass custom permissions for the “Appearance -> Customize” menu item.
• Fixed a regression in the menu highlighting algorithm.
• Fixed an “array to string conversion” notice caused by passing array data in the query string.
• Fixed menu scrolling occasionally not working when the user moved an item from one menu to another, much larger menu (e.g. having 20+ submenu items).
• Fixed a bug where moving a submenu item from a plugin menu that doesn’t have a hook callback (i.e. an unusable menu serving as a placeholder) to a different menu would corrupt the menu item URL.
• Other minor bug fixes.

1.4.1

• Fixed “Appearance -> Customize” always showing up as “new” and ignoring custom settings.
• Fixed a WooCommerce 2.2.1+ compatibility issue that caused a superfluous “WooCommerce -> WooCommerce” submenu item to show up. Normally this item is invisible.
• Fixed a bug where the plugin would fail to determine the current menu if the user tries to add a new item of a custom post type that doesn’t have an “Add New” menu. Now it highlights the CPT parent menu instead.
• Fixed a very obscure bug where certain old versions of PHP would crash if another plugin created a menu item using an absolute file name as the slug while AME was active. The crash was due to a known bug in PHP and only affected Windows systems with open_basedir enabled.
• Added more debugging information for situations where the plugin can’t save menu settings due to server configuration problems.
• Other minor fixes.

1.4

• Added a special target page option: “< None >”. It makes the selected menu item unclickable. This could be useful for creating menu headers and so on.
• Added a new menu editor colour scheme that’s similar to the default WordPress admin colour scheme. Click the “Settings” button next to the menu editor page title to switch colour schemes.
• Fixed strange boxes showing up in the icon selector in Internet Explorer.
• Fixed duplicate top level menus mysteriously disappearing. Now the plugin will properly warn the user that all top level menus must have unique URLs.
• Fixed an obscure bug where changing the “Target page” from the default setting to “Custom” and back would occasionally make some menu properties suddenly show up as modified for no apparent reason.
• Fixed incorrect submenu item height and margins in WP 4.0-beta.
• Fixed a minor layout bug where items with no title would be smaller than other items.
• Fixed combo-box dropdown button height for WP 3.9.x.
• Added a workaround for a bug in WordPress Mu Domain Mapping 0.5.4.3.
• Added a workaround for the very unusual situation where the “user_has_cap” filter is called without a capability.
• Fixed duplicates of bbPress menu items showing up.
• Changed the default custom menu icon to the generic “cogwheel” icon from Dashicons.
• Other small UI changes.
• Raised minimum requirements to WordPress 3.8 or later. This is mainly due to the increased reliance on Dashicons as menu icons.

1.3.2

• Added a large number of menu icons based on the Dashicons icon font.
• Fixed default menu icons not showing up in WP 3.9.
• Fixed a rare “$link.attr(…) is undefined” JavaScript error.
• Fixed a bug where a hidden submenu page with a URL like “options-general.php?page=something” would still be accessible via “admin.php?page=something”.
• Fixed several other minor bugs.
• Tested up to WordPress 3.9-RC1. Minimum requirements increased to WP 3.5.

1.3.1

• Tested with WordPress 3.8.
• Fixed several minor UI/layout issues related to the new 3.8 admin style.
• Fixed a bug where moving an item to a plugin menu and then deactivating that plugin would cause the moved item to disappear.
• Fixed deleted submenus not being restored if their original parent menu is no longer available.
• Fixed a rare glitch where submenu separators added by certain other plugins would sometimes disappear.
• Fixed a conflict with Shopp 1.2.9.
• Made the plugin treat “users.php” and “profile.php” as the same parent menu. This fixes situations where it would be impossible to hide a “Users” submenu item from roles that don’t have access to the “Users” menu and instead get a “Profile” menu.
• Added extra logging for situations where a menu item is hidden because a higher-priority item with the same URL is also hidden.
• Minor performance improvements.

1.3

• Added a new settings page that lets you choose whether admin menu settings are per-site or network-wide, as well as specify who can access the plugin. To access this page, go to “Settings -> Menu Editor Pro” and click the small “Settings” link next to the page title.
• Added a way to show/hide advanced menu options through the settings page in addition to the “Screen Options” panel.
• Added a “Show menu access checks” option to make debugging menu permissions easier.
• Added partial WPML support. Now you can translate custom menu titles with WPML.
• The plugin will now display an error if you try to activate it when another version of it is already active.
• Added a “Target page” dropdown as an alternative to the “URL” field. To enter a custom URL, choose “Custom” from the dropdown.
• Fixed the “window title” setting only working for some menu items and not others.
• Fixed a number of bugs related to moving plugin menus around.
• Changed how the plugin stores menu settings. Note: The new format is not backwards-compatible with version 1.2.2.

1.2.2

• Replaced a number of icons from the “Silk” set with GPL-compatible alternatives.
• Tested with WP 3.6.

1.2.1

• Fixed a rare bug where the icon selector would appear at the bottom of the page instead of right below the icon button.
• Fixed incorrect icon alignment when running the MP6 admin UI.
• Tested on WP 3.6-beta1-24044.

1.2

• Added an icon drop-down that lets you pick one of the default WordPress menu icons or upload your own through the media library (only in WP 3.5+).
• Fixed misaligned button text in IE/Firefox.
• Fixed menus that have both a custom icon URL and a “menu-icon-*” class displaying two overlapping icons. You can still get this effect if you set the class and URL manually.
• Fixed a compatibility problem with Participants Database 1.4.5.2.
• Tested on WP 3.5.1 and WP 3.6-alpha.

1.1.13

• Fixed a layout glitch that would cause the editor sidebar to display incorrectly in WP 3.5.
• When trying to determine the current menu, the plugin will now ignore all links that contain nothing but an “#anchor”. Various plugins use such links as separators and it wouldn’t make sense to highlight them.
• Tested on WP 3.5 (RC6).

1.1.12

• Fixed several more small CPT-related bugs that would cause the wrong menu to be marked as current.
• Tested on WP 3.5-beta2.

1.1.11

• Tested on WP 3.4.2 and WP 3.5-alpha-21879.
• Fixed a visual glitch related to the arrow that’s used to expand menu settings. In certain situations clicking it would cause the arrow icon to be briefly replaced with multiple copies of the same icon.
• Fixed the position of the URL and capability dropdown lists. Now they should show up directly under the corresponding input box instead of appearing some distance down and to the right.
• Fixed the size of the toolbar buttons – now they’re perfectly square.
• Fixed a rare bug that would sometimes cause the wrong menu to be marked as active/expanded.
• Only display the survey notice on the menu editor page, not on all admin pages.

1.1.10

• Added a new user survey. The notice will only appear for users who didn’t complete or hide the previous one.
• Fixed a number of bugs in the code that determines which menu should be expanded.
• Fixed compatibility issues on sites running in SSL mode.

1.1.8

• Fix author URL (was 404).
• Tested on WP 3.4.1
• Update plugin description. Some notes were no longer accurate for the current version.

1.1.7

• Tested on WP 3.4
• Fixed a rare “failed to decode input” error.
• Fixed menus not being expanded/collapsed properly when the current menu item has been moved to a different sub-menu.
• Added a shortlist of Pro version benefits to the editor page (can be hidden).

1.1.6.1

• Tested on WP 3.3.2
• Added a user survey.

1.1.6

• Tested on WP 3.3.1.
• Fixed a couple 404’s in the readme and the plugin itself.

1.1.5

• Fixed an error where there would be no custom menu to show.
• Removed the “Feedback” button due to lack of use. You can still provide feedback via blog comments or email, of course.

1.1.4

• Fixed the updater’s cron hook not being removed when the plugin is deactivated.
• Fixed updates not showing up in some situations.
• Fixed the “Feedback” button not responding to mouse clicks in some browsers.
• Fixed “Feedback” button style to be consistent with other WP screen meta buttons.
• Enforce the custom menu order by using the ‘menu_order’ filter. Fixes Jetpack menu not staying put.
• You can now copy/paste as many menu separators as you like without worrying about some of them mysteriously disappearing on save.
• Fixed a long-standing copying related bug where copied menus would all still refer to the same JS object instance.
• Added ALT attributes to the toolbar icon images.
• Removed the “Custom” checkbox. In retrospect, all it did was confuse people.
• Made it impossible to edit separator properties.
• Removed the deprecated “level_X” capabilities from the “Required capability” dropdown. You can still type them in manually if you want.

1.1.3

• Tests for WordPress 3.2 compatibility.

1.1.2

• Fixed a “failed to decode input” error that could show up when saving the menu.

1.1.1

• WordPress 3.1.3 compatibility. Should also be compatible with the upcoming 3.2.
• Fixed spurious slashes sometimes showing up in menus.
• Fixed a fatal error concerning “Services_JSON”.

1.1

• WordPress 3.1 compatibility.
• Added the ability to drag & drop a menu item to a different menu.
• Added a drop-down list of Dashboard pages to the “File” box.
• When the menu editor is opened, the first top-level menu is now automatically selected and it’s submenu displayed. Hopefully, this will make the UI slightly easier to understand for first-time users.
• All corners rounded on the “expand” link when not expanded.
• By popular request, the “Menu Editor” menu entry can be hidden again.

1.0.1

• Added “Super Admin” to the “Required capability” dropdown.
• Prevent users from accidentally making the menu editor inaccessible.
• WordPress 3.0.1 compatibility made official.

1.0

• Added a “Feedback” link.
• Added a dropdown list of all roles and capabilities to the menu editor.
• Added toolbar buttons for sorting menu items alphabetically.
• New “Add separator” button.
• New separator graphics.
• Minimum requirements upped to WP 3.0.
• Compatibility with WP 3.0 MultiSite mode.
• Plugin pages moved to different menus no longer stop working.
• Fixed moved pages not having a window title.
• Hide advanced menu fields by default (can be turned off in Screen Options).
• Changed a lot of UI text to be a bit more intuitive.
• In emergencies, administrators can now reset the custom menu by going to http://example.com/wp-admin/?reset_admin_menu=1
• Fixed the “Donate” link in readme.txt
• Unbundle the JSON.php JSON parser/encoder and use the built-in class-json.php instead.
• Use the native JSON decoding routine if it’s available.
• Replaced the cryptic “Cannot redeclare whatever” activation error message with a more useful one.

0.2

• Provisional WPMU support.
• Missing and unused menu items now get different icons in the menu editor.
• Fixed some visual glitches.
• Items that are not present in the default menu will only be included in the generated menu if their “Custom” flag is set. Makes perfect sense, eh? The takeaway is that you should tick the “Custom” checkbox for the menus you have created manually if you want them to show up.
• You no longer need to manually reload the page to see the changes you made to the menu. Just clicking “Save Changes” is enough.
• Added tooltips to the small flag icons that indicate that a particular menu item is hidden, user-created or otherwise special.
• Updated the readme.txt

0.1.6

• Fixed a conflict with All In One SEO Pack 1.6.10. It was caused by that plugin adding invisible sub-menus to a non-existent top-level menu.

0.1.5

• First release on wordpress.org
• Moved all images into a separate directory.
• Added a readme.txt

This plugin allows you to replace a file in your media library by uploading a new file in its place. No more deleting, renaming and re-uploading files!

A real timesaver

Don’t you find it tedious and complicated to have to first delete a file and then upload one with the exact same name every time you want to update an image or any uploaded file inside the WordPress media library?

Well, no longer!

Now you’ll be able to replace any uploaded file from the media “edit” view, where it should be. Media replacement can be done in one of two ways:

It’s simple to replace a file

1. Just replace the file. This option requires you to upload a file of the same type as the one you are replacing. The name of the attachment will stay the same no matter what the file you upload is called.
2. Replace the file, use new file name and update all links. If you check this option, the name and type of the file you are about to upload will replace the old file. All links pointing to the current file will be updated to point to the new file name.

This plugin is very powerful and a must-have for any larger sites built with WordPress.

Display file modification time

There is a shortcode available which picks up the file modification date and displays it in a post or a page. The code is:
[file_modified id=XX format=XXXX] where the “id” is required and the “format” is optional and defaults to your current WordPress settings for date and time format.

So [file_modified id=870] would display the last time the file with ID 870 was updated on your site. To get the ID for a file, check the URL when editing a file in the media library (see screenshot #4)

If you want more control over the format used to display the time, you can use the format option, so [file_modified id=870 format=Y-m-d] would display the file modification date but not the time. The format string uses standard PHP date() formatting tags.

Wishlist / Coming attractons

Do you have suggestions? Feel free to contact me at mans@mansjonasson.se

Quick and easy installation:

1. Upload the folder enable-media-replace to your plugin directory
2. Activate the plugin through the ‘Plugins’ menu in WordPress
3. Done!

What does this plugin actually do?

This plugin makes it easy to update/replace files that have been uploaded to the WordPress Media Library.

How does it work?

A new option will be available in the Edit Media view, called “Replace Media”. This is where you can upload a new file to replace the old one.

I replaced a file, but it didn’t change!

There are two main reasons this would happen.

First, make sure you are not viewing a cached version of the file, especially if you replaced an image. Press “Refresh” in your browser to make sure.

Second, if the file really looks unchanged, make sure WordPress has write permissions to the files in your uploads folder. If you have ever moved your WP installation (maybe when you moved it to a new server), the permissions on your uploaded files are commonly reset so that WordPress no longer has permissions to change the files. If you don’t know how to do this, contact your web server operator.

3.0.6

• Tested with WP 4.7.2
• New PT translations (thanks Pedro Mendonca! https://github.com/mansj/enable-media-replace/commit/b6e63b9a8a3ae46b3a6664bd5bbf19b2beaf9d3f)

3.0.5

• Tested with WP 4.6.1

3.0.4

• Fixed typo in .pt translations (https://github.com/mansj/enable-media-replace/pull/18)
• Fixed better error handling in modification date functions (https://github.com/mansj/enable-media-replace/pull/16)
• Tested with WP 4.4.1

3.0.3

• Scrapped old method of detecting media screen, button to replace media will now show up in more places, yay!
• Made sure the call to get_attached_file() no longer skips filters, in response to several users wishes.
• Suppressed error messages on chmod()
• Added Japanese translation (Thank you, chacomv!)

3.0.2

• Cleaned up language files
• Added Portuguese translation (Thanks pedro-mendonca!)
• Tested with WP 4.1
• Added missing Swedish translation strings

3.0.1

• Tiny fix to re-insert the EMR link in the media list view.

3.0

• Updated for WordPress 4.0
• Now inheriting permissions of the replaced files, Thank you Fiwad

2.9.7RC1

• Moved localization files into own directory. Thank you Michael
• Moved screensots into own directory. Thank you Michael

2.9.6

• Added fix by Grant K Norwood to address a possible security problem in SQL statements. Thanks Grant!
• Created GitHub repo for this plugin, please feel free to contribute at github.com/mansj/enable-media-replace

2.9.5

• Bug fix for the short code displaying the modification date of a file
• Updated all database queries in preparation for WP 3.9

2.9.4

• Bug fix for timezone changes in WordPress
• Minor UI change to inform the user about what actually happens when replacing an image and using a new file name

2.9.3

• Added call to update_attached_file() which should purge changed files for various CDN and cache plugs. Thanks Dylan Barlett for the suggestion! (https://wordpress.org/support/topic/compatibility-with-w3-total-cache)
• Suppressed possible error in new hook added in 2.9.2

2.9.2

• Small bug fix
• Added hook for developers to enable purging possible CDN when updating files – thanks rubious for the suggestion!

2.9.1

• Added Brazilian Portuguese translation, thanks Roger Nobrega!
• Added filter hook for file name creation, thanks to Jonas Lundman for the code!
• Added modification date to the edit attachment screen, thanks to Jonas Lundman for the code!
• Enhanced the deletion method for old file/image thumbnails to never give unnecessary error messages and more accurately delete orphaned thumbs

2.9

• Added Portuguese translation, thanks Bruno Miguel Bras Silva!
• New edit link from media library
• After uploading, the plugin now takes you back to edit screen instead of library

2.8.2

• Made another change to the discovery of media context which will hopefully fix a bug in certain cases. Thanks to “Joolee” at the WordPress.org forums!
• Added a new, supposedly better Russian translation from “Vlad”.

2.8.1

• Fixed a small bug which could create error messages on some systems when deleting old image files.

2.8

• New and safer method for deleting thumbnails when a new image file is uploaded.
• New translations for simplified Chinese (thanks Tunghsiao Liu) and Italian (grazie Marco Chiesi)
• Added method for detecting upload screen to ensure backwards compatibility with versions pre 3.5

2.7

• A couple of changes made to ensure compatibility with WordPress 3.5. Thanks to Elizabeth Powell for the fixes!

2.6

• New and improved validation of uploaded files, now using WP’s own functions for checking file type and extension. Thanks again to my old friend Ulf “Årsta” Härnhammar for keeping us all on our toes! This should also hopefully fix the problems people have been having with their installations claiming that perfectly good PDF files are not allowed file types.

2.5.2

• The “more reliable way” of determining MIME types turned out to be less reliable. Go figure. There seems to be no perfect way of performing a reliable check for MIME-types on an uploaded file that is also truly portable. I have now made checks for the availability of mime_content_type() before using it, using the old method as a fall-back. It is far from beautiful, so if anybody has a better way of doing it, please contact me!

2.5.1

• Bug fix – there is now a more reliable way of determining file type on your upload so you can upload PDF files without seeing that pesky “File type does not meet security guidelines” message.
• New translation to Danish – thanks to Michael Bering Petersen!

2.5

• Tested with WordPress 3.2.1
• New translation to German – thanks to Martin Lettner!
• New translation to French – thanks to François Collette!

2.4.1

• Bug fix for WordPress 3.1 RC. Now properly tested and should be working with 3.1 whenever it finally comes out.

2.4

• Bug fixes, security fixes. Thanks to my old pal Ulf “Årsta” Härnhammar for pointing them out!
• New method for uploading avoids going around WP, for greater security.

2.3

• Lots of code trimmed and enhanced, thanks to Ben ter Stal! Now working properly with Windows systems, better security, optimized loading, and much more.
• Added Dutch translation by Ben ter Stal.

2.2

• Bug fix, fixed typo in popup.php, thanks to Bill Dennen and others for pointing this out!

2.1

• New shortcode – display file modification date on your site (see description for more info)
• A couple of bug fixes for final release of 3.0 – Thanks to Jim Isaacs for pointing them out!

2.0.1

• Added support for SSL admin

2.0

• Replaced popup with inline navigation when replacing media
• Added instructions in admin link under Media

1.4.1

• Tested with WordPress 3.0 beta 2

1.4

• Removed short tags for better compatibility.

1.3

• Added support for wp_config setting “FORCE_SSL_ADMIN”

1.2

• Added Russian translation, thanks to Fat Cower.

1.1

• Minor bugfix, now working with IE8 too!

1.0

• First stable version of plugin.