Micheal, do you have ideas as to how this issue previously fixed itself and why failure occurred again? I have a sister-UNA site on the same server with identical settings and it works fine.

Thank you!

Got it — and I agree with your conclusion: Cloudflare + “Timeline view” permissions can be red herrings. They can explain what you saw, but they usually aren’t the root cause of “Timeline vanished / JS object missing / homepage blocks not rendering.”

Here’s what does fit everything you described (including Leonid seeing only a cert error while you thought SSL was already fixed):

1) Why @LeonidS saw a certificate error after you “fixed SSL.”

With Cloudflare in front, different visitors can hit different Cloudflare edges, and edges can behave differently for a while when:

• SSL mode is misaligned (e.g., Flexible vs Full/Strict) with the origin
• the origin cert was replaced recently and some edges or clients still fail validation
• there’s a cached redirect or cached HTML response being served from an edge
• a “custom hostname / page rule / transform rule” differs by hostname (www vs apex)

Even if you fixed origin SSL 2 days earlier, an edge/client path can still present errors depending on:

• which hostname Leonid hit (www vs non-www)
• SNI / chain / intermediate issues
• Cloudflare edge route at that moment

But: that still doesn’t explain the Safari JS error you saw (oTimelineViewOutlinePublic)—that points to UNA output not being emitted properly.

2) The “unchecked permissions boxes” mystery

Those checkboxes don’t spontaneously change. If they changed twice, something is writing to the ACL tables.

The usual culprits

1. Studio → Permissions import / “reset to defaults” (sometimes triggered implicitly during app install/upgrade)
2. App install/enable that runs install scripts which reapply default ACL for that module
3. Switching templates / language packs / rebuild routines that indirectly re-run permission set logic
4. A rare but real one: database restore of only some tables (or an “optimization” script) that rolls back -* while leaving content current

How to prove what changed (and prevent guessing)

Take a snapshot of the relevant ACL state now, so next time it happens you can diff it in 10 seconds.

Run these and save outputs:

-- What the Timeline "view" action is called in your DB
SELECT * 
FROM sys_acl_actions
WHERE Module = 'bx_timeline' AND Name LIKE '%view%';

-- Which membership levels are allowed for that action
SELECT m.*
FROM sys_acl_matrix m
JOIN sys_acl_actions a ON a.ID = m.IDAction
WHERE a.Module = 'bx_timeline' AND a.Name LIKE '%view%';

If it flips again, run the same queries and compare. That tells us exactly what was toggled and whether it was one action or multiple.

Hardening option (simple + effective)

If you’re on MySQL and comfortable with it, the most reliable “who touched this” method is an audit trigger on sys_acl_matrix to log updates/inserts/deletes to a small audit table. That will capture the exact time and change. (If you want, I’ll give you a clean trigger + log table.)

3) Why this still wasn’t the real problem

Your earlier Safari error:

Can't find variable: oTimelineViewOutlinePublic

is almost always caused by UNA failing to output the Timeline block JS into the page.

That typically happens when:

• a template wrapper (often a designbox template) is broken/missing expected markers
• the block rendering pipeline returns null (which matches your PHP deprecation: preg_replace_callback receiving null)
• a cached/minified JS bundle is stale/bad, so the object never gets defined

So: setting Timeline “view” to ANYONE can make the block “eligible,” but if the template/block pipeline is failing, it still won’t render correctly.

4) The fastest way to isolate the actual root cause (no guesswork)

Do these three checks in order:

A) Confirm whether UNA is emitting Timeline markup at all

View source on the homepage and search for:

• oTimelineViewOutlinePublic
• bx_timeline
• Timeline block container markup

If it’s absent, that’s a rendering/build issue, not permissions.

B) Confirm the Timeline block exists and is enabled on that page

In Studio → Pages (or Layouts, depending on your build), verify the homepage still has the Timeline block, and it’s not hidden for guests.

C) Eliminate Cloudflare as a confounder (properly)

“Development mode” is not enough because it doesn’t necessarily bypass everything you care about.

Temporarily create a Cloudflare rule to Bypass cache for:

• /
• /index.php*
• /page/* (whatever your homepage route is)
• /cache_public/* (if you’re serving UNA assets from there)
• any *.js / *.css that UNA aggregates

Then test from:

• a private/incognito browser
• a different network (cell hotspot)
• and with ?nocache=1 appended

This confirms whether Cloudflare is amplifying the symptom.

5) What I need from you to pin it down in one pass

Paste just these (no secrets):

1. The exact Safari console lines around oTimelineViewOutlinePublic (first 10–20 lines)
2. The UNA “view source” snippet around where Timeline JS should be (or confirm it’s missing)
3. Output of this:

SELECT * 
FROM sys_acl_actions
WHERE Module = 'bx_timeline' AND Name LIKE '%view%';

and this:

SELECT m.*
FROM sys_acl_matrix m
JOIN sys_acl_actions a ON a.ID = m.IDAction
WHERE a.Module = 'bx_timeline' AND a.Name LIKE '%view%';

With that, I can tell you whether the real problem is:

• template/designbox rendering (most likely given the null + missing JS object),
• cached aggregated JS/CSS,
• page block layout corruption,
• or an ACL/permissions reset being triggered by install scripts (explaining the checkbox flips).

If you want to skip all back-and-forth: paste the Safari console chunk + those two SQL results, and I’ll give you the exact fix + the preventative hardening steps.