• Resolved Matt Scheidler

    (@matt6303)


    I upgraded to 1.10.1 today, and the “Menu Options” section was completely wiped out – all the checkboxes, save for one random row, were set to unchecked.

    I thankfully had backed up my database prior to the upgrade, so I downgraded back to 1.9.2 and then restored the database in order to return to my prior settings.

    I will be glad to provide further details … not sure exactly what you might need. And not sure if it was some sort of conflict on my end as opposed to a true problem with the plugin itself. For now I will just continue with 1.9.2 which was working as expected.

    https://www.ads-software.com/plugins/adminimize/

Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author Frank Bueltge

    (@bueltge)

    1.9 and 1.10 have a difference between the Menu items, the Group items of the menu, not the sub-menu.
    Maybe this is a problem. I have added a fallback for the old keys, but maybe you have a specific topic. On default after update, you should update the settings and all should work.

    Hallo, Frank. Hello, @matt6303

    I am not opening a new issue because I think I am having the same issue, in a slightly different form, and guess this might help to find the problem.

    I have 6 Custom Post Types in a Multisite install, and the settings after the 4th custom post just don’t hold. I choose “Select All” for some roles, check the checkbox for specific settings for other roles ( like (#pageslugdiv) hidden), update/save, but when the page is reloaed, checkboxes are not check and settings not kept.

    Hope this help.

    Plugin Author Frank Bueltge

    (@bueltge)

    Hi.
    I think it is a problem with the webspace and the settings of the php instance.
    The value max_input_vars is maybe to small, not big enough for so much input fields. Maybe you can change this, normally in the php.ini file or about support of the Webspace. Alternative is the manual entry in the .htaccess of the install.
    php_value max_input_vars 3000

    Also should it possible to add this on the top of the wp-config.php, like @ini_set( 'max_input_vars', 3000 ); to set a higher value.

    Also a helpful post about this value – https://www.a2hosting.com/kb/developer-corner/php/using-php-directives-in-custom-htaccess-files/setting-the-max-input-vars-directive-in-an-htaccess-file

    Hope this help.

    Thanks again for the info Franky,

    It seems GoDaddy Hosting does not let me access the php.ini file.
    Perhaps there’s another way?

    Whenever I edit the .htaccess file, the whole website gives an error.
    Could you please tell me, on the .htaccess file, where exactly should I place this?:
    php_value max_input_vars 3000
    Also, Do I need like an opening and closing tags or so?

    Really, I’m not a programmer…

    I did seem to successfully add:
    @ini_set( 'max_input_vars', 3000 );
    to the wp-config.php file.
    It gave no errors but Adminimize still wouldn’t save the rest of the settings.

    Here’s what the wp-config.php looks like:

    <?php
    /**
     * The base configuration for WordPress
     *
     * The wp-config.php creation script uses this file during the
     * installation. You don't have to use the web site, you can
     * copy this file to "wp-config.php" and fill in the values.
     *
     * This file contains the following configurations:
     *
     * * MySQL settings
     * * Secret keys
     * * Database table prefix
     * * ABSPATH
     *
     * @link https://codex.www.ads-software.com/Editing_wp-config.php
     *
     * @package WordPress
     */
    
    @ini_set( 'max_input_vars', 3000 );
    
    // ** MySQL settings - You can get this info from your web host ** //
    /** The name of the database for WordPress */
    
    define('WP_MEMORY_LIMIT', '256M');
    ...

    Just sharing a performance concern + how i worked around. Maybe it helps you guys.

    I thought that, maybe, having a var space too big could have a negative impact on performance. And, as my website is on WPEngine, i can’t change php.ini. So, I worked around like this on https://www.superlumina.com.br , which is a multisite install:

    • created a custom capability ( e.g. foo_dashboardaccess ) using User Role Editor plugin;
    • added this new capability only for specific foles (e.g. admin or editors);
    • installed Remove Dashboard Access plugin and allowed access only to those specific role. Could have done this by code as well;
    • in order to enforce this policy, I removed all capabilities, except read, for author, contributor and subscriber roles.;
    • as these roles don’t have access to WP dashboard anymore, one needs to use Adminimize only for the allowed roles. Thus, needs less var space and <i>minimize</i> (pun intended) the problem of loosing settings
    Plugin Author Frank Bueltge

    (@bueltge)

    @the Wachamacallit a valid howto is my link, the answer above.
    This answer should also help – https://stackoverflow.com/questions/14309258/max-input-vars-limited-in-php-5-2-17
    And here in a WP environment, same problematic: https://jonathannicol.com/blog/2014/03/02/wordpress-custom-fields-not-saving-phps-max_input_vars-may-be-to-blame/

    @ceslo thanks for sharing your workaround.

    Thank you so much for your reply guys.
    I’ll test those out and let you know.

    Plugin Author Frank Bueltge

    (@bueltge)

    Welcome.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘"Menu Options" values lost upon upgrade’ is closed to new replies.