Home Forums Weaver Xtreme Theme Abort in customizer

Viewing 7 posts - 17 through 23 (of 23 total)
  • Author
  • #72818

    From serverfault.com: memory_limit = -1

    “This simply means to “have no memory limit” meaning: let the script use whatever is left over from the operating system and other important processes running.

    So if the machine has 4GIG and the OS + other processes use 2GIG, then your script will get the remaining 2GIG.”

    To Weaver’s point, it looks like your server is using too much memory to allow WP & Xtreme to work correctly on this site.




    This sets the maximum amount of memory in bytes that a script is allowed to allocate.
    This helps prevent poorly written scripts for eating up all available memory on a server.
    Note that to have no memory limit, set this directive to <code class="literal">-1.

    Without seeing the user forum description you provided, I think the authoritative source at php.net is a better description.

    If I’m reading the abort trail correctly, the script halts when sprintf is fed the wrong number of parameters. I have a hunch that the value in $memlim is not what Weaver expects (a positive integer) and is unchecked, and when fed as a parm to sprintf shows up as a null or some such.


    I sm travelling and cannot look at the theme’s source code. That bug was fixed, so I don’t understand why it is showing up.

    The -1 value is either something new in the PHP standard, or was never actually used much because providers were not in the habit of providing unlimited PHP memory. That particular issue will be addressed in the next version.

    Sorry for all the problems this has caused, but if it is a theme issue, it will be addressed in a day or two..


    I created a page on the suspect site using your code to fetch the memory limit:


    It displays -1 as expected. Thus, the script that follows tries to remove a non-existent “M”, evaluate -1 against WEAVERX_PHP_MEMORY_LIMIT, which then causes the string “-1” to be passed into sprintf, which is where the script aborts.

    I won’t be the last user who has a hosting company set php.ini memory_limit = -1, so you should address this. If you develop a patch you would like me to test, I’ll be happy to help.

    In the meantime, this is delaying other work I need to do. Not urgent, but things are backing up on our side.

    Here is the code in the page I created:

    [php]$memlim = get_cfg_var('memory_limit'); echo "|$memlim|";[/php]

    First, safe travels.

    Second, I can’t quickly tell when -1 became part of the PHP package. But it looks like it is here to stay.

    Third, happy to help. If you develop a patch you want field tested, I’m available.



    I’m just back to my development environment, and found a fix. First, the warning message will not display if the value is -1.

    And second, turns out that the warning message is display in two places: in the Customizer, where the sprintf remained broken, and in the Legacy Dashboard interface. The problem was fixed in the Legacy interface, but apparently the user actually had a low PHP memory limit and increased it to something other than -1, so it seemed the issue was fixed – but not in the Customizer version. (The sprintf’s were both broken, but the wording of the two messages is not the same.)

    I apologize for saying the bug had been fixed. It had, but just in one place. And it turns out that even if there hadn’t been the sprintf bug, the warning message does pop up every time you load the Customizer from scratch. But it now checks for -1, and won’t show at all.

    I will upload the new version tomorrow.


    Great. I’ll make a note to update when I see it.

Viewing 7 posts - 17 through 23 (of 23 total)
  • You must be logged in to reply to this topic.