https is required for http2 protocol, which triggers a waterfall from all the JS bundles and slowed everything down.

• Login works fine when yarn; yarn dev;
• Login works fine on live site mana.wiki in production.
• Login doesn't work when yarn; yarn:build; yarn start:core.

If it's an env variable issue. We may need to update .env.example with all the required variables.

The way the post fetches work atm would crash the server due to graphql type errors:

https://github.com/manawiki/core/blob/main/app/routes/_site+/p+/utils/fetchPostWithSlug.server.ts

• invariant(post, "Post doesn't exist");

https://github.com/manawiki/core/blob/main/app/routes/_site+/p+/utils/fetchPostComments.server.ts

• postParentId: "JSON!", this triggers graphql type error

Because these graphql queries are dependent each other, one's invalid would trigger a server crash onto the other. We should rework these queries a bit safer so it would just render a Post not found.

Sitemaps have been broken since the subdomain switch. We'll need to fix it to get sites properly indexed.

To determine if a site has a custom domain, check for _/app/custom/config

import { config } from "./app/_custom/config";
if (config.domain) then generate custom routes.

We only want to generate a route structure for the home (index) page.

When login with edit privileges, the post updates section are missing:

Shows dom error in logs:

with <RemixDevTools showRouteBoundaries={true} />

Also see forge42dev/Remix-Dev-Tools#21

This is because root.tsx ThemeProvider would loop infinitely. The way to fix it per @AlemTuzlak is to ensure that RDT is to ensure remix dev tools are supposed to be rendered at the root as far up as possible.

I was able to trace it down to this line:

https://github.com/manawiki/core/blob/725e28635363b32fe662a9b0ca47470aaa4ed813/app/routes/%24siteId%2B/_layout.tsx#L497

                           <div
                              style={{
                                 paddingTop: safeArea?.top ?? "",
                              }}

comment it out clears the error, but I assume it's something Capacitor needs. What can we do to resolve this @pogseal ?

This is probably caused by the newly implemented cache for $siteId/_index.tsx draft/publish content mismatch for login users.

Sporadically cors error would trigger on the Payload admin panel on local,

Access to fetch at 'https://mana.wiki/api/users/me' from origin 'http://localhost:3000' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'.

iOS environment.

Disabling cors plugin in core.server.ts would clear it, so it's something with our mana.config cors.

Also seems to be cookie related?

Currently, the cache duration for logged-in users appears to be ridiculously high, which significantly impacts the editor's ability to quickly edit newly created/recently edited pages and causes potential data staleness.

While testing, I discovered that it takes roughly five minutes from the time a new entry is created within a collection to the time it displays to users. For anonymous users, five minutes should be sufficient, however, for logged-in users who always need to be shown the most up-to-date information available to prevent conflicting edits, we should reduce cache times.

Unfortunately, react-dom/server doesn't lazy load well, so we have to take a different approach with this.
See #196

@pogseal

react-dom-server is leaking into the client bundle because it's used in eactly one place in Tooltip.tsx:

Removing it cut about 70kb off the bundle:

ref: https://developer.mozilla.org/en-US/docs/Web/API/HTMLAnchorElement/hash

hash links (#) have weirdly snappy behaviors that felt jarring.

1. https://mana.wiki/starrail/collections/characters/1213
2. Click on Profile

I have seen this manifest in a couple ways,

• First click does nothing, second click works.
• the scroll works, but there's a quick snap up to top first.

Not sure if this is an upstream Remix bug or something wonky with our core, might be something we catch eventually when refactoring root/layout.

Seems like there's something that's causing hydration mismatch when SoloEditor is rendered atm. The same slate data that ran with the readonly didn't have the same problem.

This does not seem to be an error originating from any server side lru-caching.

Uncaught Error: Cannot resolve a DOM node from Slate node: 

I'm currently isolating the damage by adding in an Suspense boundary.

Since this only affects admin users, and doesn't actually affect client-side functionality of Slate, it might not be an high priority fix atm.

Works only in production. Likely related to how the checked state is set on the RadioGroup headless UI component.

          <RadioGroup.Option
                                          key={row.id}
                                          value={row}
                                       >
                                          {({ active, checked }) => (
                                             <RadioGroup.Label
                                                className={clsx(
                                                   checked
                                                      ? "bg-zinc-100 font-semibold dark:bg-zinc-700/80"
                                                      : "text-1",
                                                   "group relative flex w-full cursor-pointer items-center justify-between gap-2 rounded-md px-3 py-2"
                                                )}
                                             >
                                                <time
                                                   className="flex items-center gap-1.5 text-sm group-hover:underline"
                                                   dateTime={row?.updatedAt}
                                                >
                                                   {format(
                                                      new Date(
                                                         row?.updatedAt as string
                                                      ),
                                                      "MMMM d, hh:mm aaa"
                                                   )}
                                                </time>
                                                {index == 0 && (
                                                   <span className="rounded-full bg-zinc-200 px-2 py-0.5 text-[10px] font-bold uppercase dark:bg-zinc-600 dark:text-white">
                                                      Live
                                                   </span>
                                                )}
                                             </RadioGroup.Label>
                                          )}
                                       </RadioGroup.Option>

Replicate by opening the history modal on local vs production

https://www.webpagetest.org/vitals.php?test=230629_BiDcA5_AJ7&run=3#cls