Yes—this symptom set is now a known pattern in UNA 15.0.0-A2, and (critically) it is typically not caused by the Wiki app itself.

In the UNA community thread that matches your exact errors, UNA staff reported the root cause was a modified/corrupted template file:

• specifically: templates/designbox_0.html
• fixing action: replace it with the default/original version.

That aligns with your Safari console error:

• Can't find variable: oTimelineViewOutlinePublic usually means the Timeline “outline public” JS payload never got emitted into the page, which often happens when the designbox wrapper template (the thing that renders blocks) is broken or missing expected placeholders. Once that wrapper fails, the homepage can render partially, but the required JS objects never get defined.

The PHP deprecation warning is a secondary signal:

• preg_replace_callback(): Passing null ... in BxDolTemplate.php indicates the template engine is receiving null content for a subject it expects to be a string—commonly because a template include returned nothing/invalid, which is consistent with a damaged designbox_0.html.

What I would do (in order)

1) Restore designbox_0.html to the stock/default version

Options (pick the one you can do fastest):

• If you have backups / git: restore only that file.
• If you can switch templates: temporarily switch to the default template in Studio to confirm Timeline returns. If it does, the problem is your active template’s designbox_0.html.
• Copy the default file from a clean UNA distribution of the same branch/build (or from the default template folder) over your current template’s designbox_0.html.

After restoring, proceed to cache rebuild below.

2) Hard-clear UNA caches plus aggregated JS/CSS artifacts

You already cleared caches from Studio/browser; do the server-side artifacts too (these are the ones that commonly preserve the broken JS bundle):

• Clear via Studio (again) after restoring the file.
• Then remove the aggregated/minified assets from the filesystem, so UNA regenerates them (exact folder names vary by install, but you’re targeting the cached JS/CSS and any *.gz compiled assets).

If you tell me your active template name (e.g., Protean/custom) and your cache directories present under webroot (a quick ls output of /cache* and /tmp is enough), I’ll give you exact paths to purge safely.

3) Re-test homepage with browser devtools open

Confirm that:

• the Timeline JS file(s) are loading (200, not 404/500),
• the gzip file request is returning the correct Content-Encoding: gzip header (if applicable),
• and oTimelineViewOutlinePublic is now defined.

Why “turning off Wiki” didn’t revert it

App install/enable flows can trigger template rebuilds and cache regeneration; if your designbox_0.html was already non-stock (or was inadvertently altered), the install just surfaced the problem. Disabling the app won’t revert template files or the cached bundles.

If you paste the first ~30 lines of your templates/designbox_0.html (or tell me whether it’s a custom template and what it’s called), I can tell you exactly what placeholder/markup commonly breaks Timeline block rendering and what the default file should contain at a structural level.

I'll be around...

Much thanks, Gentlemen! This is quite interesting. I am learning many things.

Your solutions will benefit others, too.

When the page began to work again with the Timeline, I thought (mistakenly) it may have been a Cloudflare cache issue - which can actually be regional.

When Leonid first examined the home-page on the other side of the world, it only displayed a certificate error with no UNA content at all. This SSL issue had been fixed 2 days prior.

Cloudflare has a Developer option to turn it off. But this does not flush the cache. Many have reported that the Cloudflare cache gets corrupted on rare occasions.

The part which amazes me is how certain boxes became unchecked regarding who had permission to view the Timeline. This has occurred twice in the last month. I have now changed this Timeline "view" setting to: ANYONE.

But these issues were not the real problem...

The same issue occurred about a week later. And I discovered that the previous issue somehow resolved itself. I have cleared all caches - cloudflare, UNA, and browser. But there is something in the gzip file which produces this error: ReferenceError: Can't find variable: oTimelineViewOutlinePublic

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!

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.