Upfront on Multisite: Changes not saving, uninformative JS errors

I've done a fair bit of research on this, and tried: the .htaccess trick, switching Upfront child themes, clearing the cache, using different browsers, and disabling every plugin before making changes/saving. Nothing is working.

The only clue I have is that jQuery seems to hang on the Upfront editor (and only for the editor). Everything else loads like normal on every other page, except that Upfront seems to be a sluggish theme in general.

Aside from "There was an error saving your changes", these are the jQuery messages:

I'm not clever enough to understand what's going on there, so I'm turning to you for help! Support access is granted, I am looking forward to getting this sorted. ????

  • Adam Czajczyk

    Hello Anne,

    I have accessed your site and I was able to load Upfront editor with no issues under recent Chrome on Windows. I wasn't however able to save changes that I made to the site.

    Could we try some basics first? Please make sure that inside your "wp-config.php" file there's this line:

    define('WP_MEMORY_LIMIT' , '256M');

    If it's not there, please add it. It should be placed above the "/*That's all! Stop editing... " line. Once this is done, please clear all cache in your browser and give it another try.

    Let me know what was the result, please!
    Best regards,
    Adam

    • Anne

      Hey Adam, I've done that and it doesn't seem to help.

      The error I've been able to find now is that http://launchjet.io/site/wp-admin/admin-ajax.php returns as 404 not found when Upfront tries to ping it for saving the changes.

      However, that file loads in the browser and otherwise seems to function just fine. Even changing this to 777 permissions didn't fix the issue. If anything, it seemed to break some of the Upfront loaded styles. Ideas?

      This is the only useful thread I've found so far on debugging this issue in the code, but it all seems like stuff that would be deep in the heart of Upfront to fix. I'm assuming the mod_security was to override this? I've even tried adding:

      <IfModule mod_security.c>
      SecFilterEngine Off
      SecFilterScanPOST Off
      </IfModule>

      And (separately):

      <IfModule mod_security.c>
      SecFilterInheritance Off
      </IfModule>

      In an .htaccess within the /site/wp-admin folder as recommended in another thread I found. Nothing makes the 404 error stop triggering.

      In other news, I also just found out where the ModSecurity stuff is in my VPS WHM. However, I don't know how to configure it from that side of things to allow this to stop happening. But thankfully I now have this data:

      Request:	POST /site/wp-admin/admin-ajax.php
      Action Description:	Access denied with code 406 (phase 2).
      Justification:	Pattern match &quot;\\b(?:(?:s(?:ys(?:(?:(?:process|tabl)e|filegroup|object)s|c(?:o(?:nstraint|lumn)s|at)|dba|ibm)|ubstr(?:ing)?)|user_(?:(?:(?:constrain|objec)t|tab(?:_column|le)|ind_column|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id) ...&quot; at ARGS:data.

  • Anne

    Okay. After a lot of digging and testing, I was able to get Upfront working by disabling several rules from my VPS WHM... though, this does seem less than optimal as a permanent fix.

    The rules triggered were: 959007, 950904, and 950906

    In review, for anyone else running their own VPS with Upfront:

    1. Login to your WHM as root. My version of WHM is WHM 54.0 (build 21) and my server is CENTOS 6.7 x86_64 kvm – I have no idea what other versions/servers this is available for.
    2. Find "Security Center" and then, "ModSecurity™ Tools". This is where you want to be. Click it.
    3. On the "Hits List" page (default) you can see the errors and IDs being triggered by your site – such as "959007: Blind SQL Injection Attack". Your rules may be different depending on your configuration, so if the IDs I provided aren't working, that's how you figure out what your site is tripping over.
    4. Go to "Rules List" and search for that ID.
    5. Disable the ID, and then hit the "Deploy and Restart Apache" button that pops up.

    I had to repeat this process several times before I found all of the rules this triggered for me. I attempted to use these IDs in my .htaccess only and re-enabled them from the server so that it only effected this one domain, but that didn't work and that's what I'm looking into figuring out next.

    At least for now, this gets Upfront working while I worry about my own security issues on my own. :sweat_smile:

    Thanks for the help guys! I couldn't have figured it out without your clues. :slight_smile: