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...