Concepts
Last updated
Was this helpful?
Last updated
Was this helpful?
Plugin constants GRAVITY_PLATFORM_PREFIX (string prefix for variable/option names) and GRAVITY_PLATFORM_PUBLIC_SETTINGS (array of option names and configurations).
Script file includes/settings.php. looping over the setting configurations defined in GRAVITY_PLATFORM_PUBLIC_SETTINGS, register plugin settings and save options in the database using prefixed keys. Using similar logic, define fields for the platform settings object type in WP GraphQL.
Add utility component GravityFormSelect to backend components; a reusable component that renders a select element with Gravity Forms forms as options. Also adds a re-usable effect hook useGravityFormsList to easily grab the list of forms from anywhere within the application.
Update Site Header backend and frontend blocks. On the backend, values for the main contact form ID are get and set using the core site settings store. On the frontend, the main contact form ID is added to the WordPress globals query and passed as a prop to the Site Header when rendering the modal contact form.
One of our core features in Kairos is visual preview of blocks. We currently achieve this by executing each frontend block's getBlockProps functions within the Block Editor to retrieve props data so we can successfully render the frontend block for visual preview of any block attribute changes applied before publishing the page.
If we maintain this idea of calling each frontend block's getBlockProps function in order to fetch preview data within our Edit.tsx files, we need to simplify how we retrieve site globals like menu data when they are needed by the block being previewed.
On the frontend, we take care of injecting site globals such as menus when executing the block's getBlockProps function (we do this to avoid refetching the same data for each block that needs that data), but aren't currently injecting it in the block editor. As is, we have to maintain conditional logic within each block's getBlockProps method to fetch site globals.
A particular use case for this is the Site Header. The frontend block currently needs a menus prop in order to render in the FSE and currently relies on conditional logic to retrieve site globals within it's getBlockProps method when the block is rendered for preview.
UX Decisions : Simple & Fast. Big & Easy to Convert.
Server Side Rendering
In Kairos, we are using SSR for the cart & checkout.
Incremental Static Regeneration
The rest of Kairos is using Incremental Static Regeneration.
Enables long/indefinite static cache that’s hosted on CDN nodes for ~100ms server response across the globe.
This, coupled with Cloudflare Image Resizing is making our pages fully load in about 1.5 seconds on average currently (once cached), with more room for improvement.
We can now rebuild page cache on demand. But, not just invalidate - revalidate: There is no blocking wait time for the frontend user while page cache is rebuilt. And, it only takes 300ms to re-render and re-deploy the page to all CDN edge nodes across the world.
Longer cache persistence means less load on the WP server since any one page will not be requested more than once per 24 hours (as currently configured).
Enables maintaining data cache between builds/releases. This, combined with Next.js atomic deployment capabilities on Vercel means we will be able to do releases at any time during the day for frontend fixes with no downtime or slowdown.
Enables scanning links and pre-rendering pages in the background.
Enables statically generating important pages at build time if necessary, so no traffic will be necessary in order to build cache.
These items help us mask some of the WordPress performance issues we’ve encountered.
