Probably going to end up having to restructure into a Pages app, cron worker, and shared utilities
Probably going to end up having to restructure into a Pages app, cron worker, and shared utilities
HThis. Pages itself does not support any handlers other than fetch, so Crons have to be in a separate Worker
VSigh aw well
VThanks!
VFor some reason R2 just flat out doesn't work anymore. My production code (same code) works just fine, but when I attempt to pass in Headers objects to portions of r2.get or object.writeHttpMetadata, as is supported or at least was, it errors out with cannot stringify arbitrary non-POJO's. Then, if I remove all usage of that, the instant r2.get returns an object the body is read already so it's impossible for me to actually read what's inside the object and do anything with it.
VIs this a known issue or something new or?
VLike R2 just flat out doesn't work locally anymore which isn't the greatest
SgenerateStaticParams doesn't work on cloudflare, no?
Jit tells you in the next sentence how you can use it
SNow I get it. Dang. And btw does
This is my
/api route work on Cloudflare? Or will it break?This is my
api/revalidate/route.ts
Nadd export const runtime = 'edge'
GIs it possible to turn off minification somehow? Attempting to port an existing next app over to cloudflare pages but we're running into some issues and it's not clear where this is originating from
Nyes for every page/api that should run on the edge
Napi should always run on the edge
IActually, just adding it to the root layout worked fine for us, but we don't use API endpoints but a binding to an actual worker.
IThis error means that somewhere within your SSR code you're probably passing a relative path to an URL constructor
J--disable-worker-minificationGWhere do you pass this to? Google shows 0 results searching for this option
GAh sourcegraph is a lifesaver, found it: https://sourcegraph.com/github.com/cloudflare/next-on-pages/-/blob/packages/next-on-pages/src/cli.ts?L47
GAre there any tricks to catch uncaught errors, ideally globally somewhere? Some errors don't come with stack traces at all, which makes it a nightmare to track down where they might come from
Jinternal errors means something went wrong inside cloudflare pages/workers
GYeah, but most likely because of some bad input? With the non-descript error + no stack trace it's a needle in a haystack problem. We dumped a ton of try/catch into our app and eventually found something. In a worker it's a bit easier to debug as you can just wrap at the entrypoint and catch any uncaught errors
Jits something going legitimately wrong on cloudflare's end if you get just 'Error: internal error', you will normally need an employee to check if they can see something for the deployment id
GHmm okay, is there anything we can check if this happens locally running with wrangler/workerd?
GWe're just running this locally while trying to get it working, haven't setup any deployments yet
Jmaybe something throwing an exception in workerd locally
GNothing visible in the output. I'll hit up our cloudflare support contacts to see if we can get someone from CF to take a look. Thanks for your help!
RHas anyone done work to optimize the bundle size of their Next.js build?
RWith the App Router, it seems that pretty much everything gets bundled together, regardless of whether it's client or server side.
SHello everyone, Do you guys build nextjs pages project using nx project.json?
FHey does someone have a good idea for how to set up your API_URL environment variables?
I am currently setting them in my wrangler.toml file and then using getRequestContext().env.API_URL to access them. This works both locally and in deployment for my functions in api/route/..
However when i try to access my apis at ”api/route” (using fetch in my page.tsx component) it works locally but seems to break in production:/
Thanks for any respons!
I am currently setting them in my wrangler.toml file and then using getRequestContext().env.API_URL to access them. This works both locally and in deployment for my functions in api/route/..
However when i try to access my apis at ”api/route” (using fetch in my page.tsx component) it works locally but seems to break in production:/
Thanks for any respons!
AIs there any way to make some built-in environment variables public?
I'm trying to access
I've looked into
UPDATE: The solution is using the env config option to map them to
I'm trying to access
CF_PAGES_BRANCH & CF_PAGES_URL within a client component for functionality, but I can't seem to access them as NEXT_PUBLIC_* is not appended.I've looked into
getRequestContext, but that doesn't seem to work for my usecase, as it's only for server-side code.UPDATE: The solution is using the env config option to map them to
NEXT_PUBLIC_* variables.
ZHello everyone, everything ok?
I'm working on a project with nextjs 14 and when I upload the project to cloudflare pages. Only one page works in SSR. The others do not load the fetch. Has anyone had this problem and know how to solve it?
I'm working on a project with nextjs 14 and when I upload the project to cloudflare pages. Only one page works in SSR. The others do not load the fetch. Has anyone had this problem and know how to solve it?
Jdo you get any errors in your deployment logs?
Jif you tail your deployment with wrangler or use log stream, you should be able to see logs for the internal server errors
Jwouldnt know what's going on without seeing the full source code
AHi, is it possible to modify this page and put a new one?
HIf you are on the Pro, Business, or Enterprise plan you can customize and brand these pages for your whole account or for specific domains. You can design custom error pages to appear during a security challenge or when an error occurs.- Configuring Custom Pages (Error and Challenge)
Cloudflare Docs
Cloudflare uses a wide range of error codes to identify issues in handling request traffic. By default, these error pages mention Cloudflare; however, …
Nlately ive been getting some weird builds that refer variables that dont exist
Nthey're always called
Nasync__chunk_xxxxx (5 digits)