Wolfie

Just to add a bit more info, back when there were cookie issues with 4.7.11 and .1, the fix to that (.2) is when the problem started.

Could you test this on an install of yours just to confirm that it's not just happening to me?

You certainly may. (Shall I wait for you to actually ask? 😉) When I change the data storage settings in the ACP (Advanced -> Data Storage tab), it gives me a new constants.php file to use and then I have to confirm the file (which it checks to make sure it has been done properly). So that's how I know that it's reading the constants.php file just fine. Earlier when I made a reply to the other topic, I noted the time and then went off to do something. I returned to the computer a little over an hour later (1h 10m? 1h 20m?) and the session had been timed out. It's on the live site, not a test/dev site.

Okay, would appear that I spoke too soon. The value is NOT being honored on either install. Tested this earlier by looking at the time and then a little over an hour later I went to do something in the ACP and the session had timed out. This is the setting in the constants.php file (which I can confirm is being read just fine by the suite). \define( 'ACP_SESSION_TIMEOUT', 86400 );

That did it.

To confirm, the one with the active license? URL is n*.com and not d*.com? Just tried in Opera, clearing cache and opening a private window, signed in (front and acp), used Page Builder link, and not seeing the ">" except in the middle of the screen where it shows the instructions.

On your own install, or have you tried it on mine? The other site that I updated has it working just fine, so I don't believe it's a bug in the suite. If it is, it's one that requires certain circumstances to be met in order to be triggered. Same account on both ends, and only on the one site. Also, just tested the ACP timeout and I think there may be a bug with that, as I have it set to expire after 86,400 seconds (1 day) but it's expiring after only an hour, as it was doing on the other site. Could you test that as well?

Close my Incognito window, emptied browser cache, opened it back up, signed in, and then AFTER that, used the link in the ACP to open up the page builder into the Incognito window. Still not working. Emptying the browser's cache shouldn't matter when opening a fresh Incognito window (when none are already open), but I did just to be safe. Also, I may have been wrong about the timeout session being honored. I'll have to wait to confirm, but this is in the "constants.php" file and the software is definitely able to read it as I had made a change where it provided me with an updated "constants.php" file to use and it verified I had updated it. \define( 'ACP_SESSION_TIMEOUT', 86400 );

I disabled, enabled. Uninstalled, deleted all custom databases, uploaded all files, installed. Still not working.

Site 1 that I upgraded, Page Builder works just fine. (But ACP timeout isn't being honored.) Site 2, Page Builder isn't working. (But the ACP timeout works just fine.) I've tried clearing caches, changing the cookie prefix, and using a browser that I usually don't use except to watch Twitch streams and isn't working on there either. Even checked via another computer and still not working. (I have removed the custom cookie prefix setting.) Is there another setting available for rebuilding the content (html/js/etc) that I can try?

So I've upgraded another site and it appears to be working fine with that, just not the first one that I upgraded. However, the first one is now inactive (can't afford to renew it as I renewed another one instead). So short of clearing the cache, which I have done multiple times, any suggestions would be nice.

Unlikely, unless the server you're on is really slow. If you're on a shared server, then including your password in the command line can be a huge security risk. Just an FYI.

If you're using the default skin that comes with the software, then I recommend seeing if any of the skin templates have been altered. Also, check the various 3rd party apps you have installed (if any) to make sure that they are legit. It's quite possible that something is happening internally (not guaranteed, but better to check and be sure). If the skin is a 3rd party skin, ask the author if they'd be willing to examine the skin to see if it's been altered in any malicious way. Assuming that everything is clean internally, it's time to look outside of the IPS suite. Have you installed anything else on your domain that isn't party of the suite? Subdomain, another URL for a different type of page, etc.? If so, check the contents there to see if anything has been maliciously added. If not, then you may need to contact your hosting company for assistance in figuring out how someone was able to install malicious code on your site. There could be a security update they need to install or a setting that needs to be changed. Before doing ANYTHING though, download a full backup of EVERYTHING! (Full database and all the files for your website.) This will serve two purposes. One is in case something more goes wrong, you can restore and retry. Second is that you could provide the files (and/or data) to someone you can trust to look through and see if they can find anything malicious. Better safe than sorry!

Would have to be since it was working prior to the .1 release that I updated to (from 4.7.11 to 4.7.11.1). So yes, that's the constant that is being set in constants.php.

Okay, but what PHP version is your community running on? In the ACP, click on the "Support" link at the top right and it'll tell you the PHP version in use on the next page.