Complete Web Platform Tutorial

WordPress and GraphQL sit at opposite ends of web engineering and share one property that shapes every error in this track: both hide the database behind a layer that makes expensive things look cheap. In WordPress it is a plugin architecture where any of forty plugins can hook a query onto every page load. In GraphQL it is a resolver graph where a client asking for one extra nested field can multiply your query count by the size of a list.

So the debugging skill is the same on both sides: make the invisible work visible. A white screen is not a mystery once errors are being logged. An N+1 explosion is not a mystery once you count queries per request. Most of the fixes below are about installing that visibility first and only then changing code.

The white screen is not an error — it is a hidden error

A blank page means PHP hit a fatal error while output buffering was on and display of errors was off. The error exists; you just cannot see it. So the first move is never to start deactivating plugins by guesswork — it is to turn logging on and read the actual message, which usually names the file and line directly.

Once you can see it, the shape of the problem is almost always one of three: exhausted memory, a fatal in a plugin or theme after an update, or a PHP version incompatibility where a plugin uses syntax the installed PHP rejects.

// wp-config.php - log the fatal instead of hiding it.
// Logs to wp-content/debug.log; keep display off on a live site.
define( 'WP_DEBUG',         true );
define( 'WP_DEBUG_LOG',     true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Raise the ceiling only after confirming memory is the cause
define( 'WP_MEMORY_LIMIT',     '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Too many redirects is a disagreement about your own address

WordPress canonicalises requests: if the incoming URL does not match the stored siteurl, it redirects to the stored one. Put it behind a TLS-terminating proxy and the loop is immediate — siteurl says https, the proxy forwards plain HTTP, PHP sees a non-TLS request and redirects to HTTPS, the proxy forwards it again, forever.

The fix is to tell PHP what the proxy already knows, and to do it before WordPress boots.

// wp-config.php - trust the proxy's forwarded scheme, above the
// require of wp-settings.php so it applies before WordPress canonicalises.
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
     && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

// If you are locked out of wp-admin entirely, override both and get in,
// then set them properly in Settings and remove these lines.
define( 'WP_HOME',    'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

GraphQL's N+1 problem, and why DataLoader is the standard answer

A GraphQL resolver is called once per field per object. Ask for 50 posts and each post's author and the author resolver runs 50 times, each issuing its own query. The query is fast; there are simply 51 of them. Nothing in the schema hints at this, which is why N+1 is the defining performance problem of GraphQL APIs.

DataLoader fixes it by batching within a tick of the event loop: individual load(id) calls are collected, dispatched as one query, and the results distributed back to the callers. The critical detail is lifetime — a loader must be created per request, because its cache is a per-request cache. Sharing one across requests serves stale data across users.

import DataLoader from 'dataloader';

// One loader per request. Never module scope - that is a cross-user cache.
function createLoaders(db) {
  return {
    authorById: new DataLoader(async (ids) => {
      const rows = await db.users.whereIn('id', ids);      // ONE query
      const byId = new Map(rows.map(r => [r.id, r]));
      return ids.map(id => byId.get(id) ?? null);          // order must match
    }),
  };
}

// server setup
context: ({ req }) => ({ loaders: createLoaders(db), user: req.user }),

// resolver - looks identical to the naive version, batches underneath
Post: {
  author: (post, _args, ctx) => ctx.loaders.authorById.load(post.authorId),
}

DataLoader must return results in the same order as the requested keys, with a null or error placeholder for missing ones. Returning the database's natural order is the most common implementation bug, and it silently attaches the wrong author to the wrong post.

Non-nullable fields and query depth: two schema decisions with teeth

Cannot return null for non-nullable field is the schema enforcing a promise you made. Because GraphQL nullability propagates upward, a null in a non-null field nulls its parent, and if the parent is also non-null the error climbs until it finds something nullable — which is why one missing row can blank an entire response. The lesson is to be honest in the schema: mark a field non-null only when your resolver can always produce it.

Query depth is the mirror image. A schema where a post has an author who has posts is a cycle, and a client can nest it as deep as it likes, so a small query can demand an enormous amount of work. Depth limits, complexity scoring and a persisted-query allow-list are the three standard defences, and public APIs generally need at least two of them.