ReferenceError: define is not defined on admin page

I can’t get into admin page. On the browser console I get the error:

Uncaught ReferenceError: define is not defined

To Reproduce

Get with the browser on .

It could be caused during a version upgrade. I was using ghost v1 and I upgraded ghost-cli and ghost to last versions (in that moment, 3.0.0). After that, I could access sometimes to the admin page. I guess it can be caused because something in the cache expired or a synchronization issue between javascript functions.

Today I upgraded to last version (3.2.0) but it still happens.

Technical details:

  • Ghost Version: 3.2.0
  • Node Version: v8.16.0
  • Browser/OS: Ubuntu 16.04 / last versions of chrome and firefox
  • Database: mysql 5.7

ghost doctor

Ghost doctor returns green checks for everything:

✔ Checking system Node.js version
✔ Checking logged in user
✔ Ensuring user is not logged in as ghost user
✔ Checking if logged in user is directory owner
✔ Checking current folder permissions
✔ Checking operating system compatibility
✔ Checking for a MySQL installation
+ sudo systemctl is-active ghost_blog-csimadroom-com
Instance is currently running
ℹ Validating config [skipped]
✔ Checking folder permissions
✔ Checking file permissions
✔ Checking content folder ownership
✔ Checking memory availability

Any idea what can be causing the issue?

@koldLight I’m able to access your admin page OK, no JS errors. It sounds like somewhere you’ve got a cached version of the admin app’s JS files that is corrupted.

Are you running any caches or a CDN in front of your site?

Hmm, accessing with Chrome rather than Safari did throw an error on first load. For some reason the file was not served correctly…

Uncaught ReferenceError: define is not defined

The file is being served completely blank even though it’s a 200 response, that explains the define is not defined error because the define function definition is not present in a blank file.

What hosting setup are you using?

Thanks for the quick response!

I’m hosting ghost on my own virtual machine, a ubuntu 16.04, shared with other resources. I’m using nginx with ssl (via letsencrypt).

My nginx configuration looks like this:

# HTTP - redirect all requests to HTTPS:
server {
  listen 80;

  error_log /var/log/nginx/blog_error.log;
  access_log /var/log/nginx/blog_access.log;

  return 301 https://$host$request_uri;

# HTTPS - proxy requests on to local Node.js app:
server {
  listen 443;
  root /apps/blog/blog/system/nginx-root;

  ssl on;
  ssl_certificate /etc/letsencrypt/live/;
  ssl_certificate_key /etc/letsencrypt/live/;
  ssl_trusted_certificate /etc/letsencrypt/live/;

  error_log /var/log/nginx/blog_error.log;
  access_log /var/log/nginx/blog_access.log;

  location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $http_host;

  location ~ /.well-known {
    allow all;

  client_max_body_size 50m;


My ghost config.json is:

  "url": "",
  "server": {
    "port": 2369,
    "host": ""
  "database": {
    "client": "mysql",
    "connection": {
      "host": "localhost",
      "user": "XXXXXXX",
      "password": "XXXXXXXXXX",
      "database": "XXXXX"
  "mail": {
    "transport": "Direct",
    "options": {
      "service": "Mailgun",
      "auth": {
        "user": "XXXXXXXX",
        "pass": "XXXXXXXX"
    "from": "MY_EMAIL"
  "logging": {
    "transports": [
  "process": "systemd",
  "paths": {
    "contentPath": "/apps/blog/blog/content"
  "bootstrap-socket": {
    "port": 8000,
    "host": "localhost"

I don’t know why my ghost config json was on port 2369 and nginx was reverse proxying 2368, and I put both on 2368. But the issue is still there.

Yes, it looks like the vendor.min.js is not being served OK. The rest of the css / js resources are OK:

I’m not using any external CDN, just my server.

@koldLight doing a google search for “nginx net::ERR_INCOMPLETE_CHUNKED_ENCODING” it sounds like it could be a permissions problem on your server.

When nginx proxies a file over a particular size it can write it to disk as a temporary file, if the permissions on it’s directory are incorrect then it can result in the error you’re seeing. There’s a related stack overflow answer here

If it doesn’t seem to be that, maybe look into the resource usage on your server to make sure you’re not hitting any memory or disk space limits.

1 Like

Thanks! You hit the nail on the head, I just had to fix the ownership of /var/lib/nginx.

I thought it was a migration related issue because it started happening after migrating from v1 to v3. But what happened was that, after the migration, the vendor.min.js grew and nginx started using /var/lib/nginx as a working directory for temporary large files.

Thanks for the help :slight_smile: