Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Runtime adapters

Open
  • Is something wrong?
#1 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
docker, php, vscode, wordpress
Domain
backend, cli, devops, tooling

Research direction

Start by separating the listed runtimes and concerns: caching, network calls, child processes, progress, filesystems, and mounts. Read the linked issues 46 and WordPress Playground issue 1026; the payload names no implementation files or tests, so the first milestone is agreeing on scope and runtime boundaries before defining what done means.

Written by the indexing model from the issue text.

Description

Architecture

Blueprints should support at least the following runtimes:

  • wp-cli
  • Docker
  • wp-now
  • Playground
  • Native PHP CLI
  • VS Code extension

Runtime-specific features

Caching the downloads

Blueprints shouldn't download the same 10MB WordPress.zip twice. Let's make sure we cache the downloads and invalidate the entries as new versions of Core and Plugins are released.

  • In native PHP CLI, we can cache in the filesystem, e.g. ~/.wp/. Ideally, this would take HTTP headers into consideration.
  • In Playground, we can rely on HTTP cache built into fetch(). In addition, we could cache at the service worker level.
  • In VS Code, there's a caching API AFAIR.
  • In Docker, we could use the docker build layers for caching.
Network calls
  • In native PHP CLI, we can use libcurl or fopen("https://")
  • In Playground, we can only rely on fetch(). We can't open raw TCP sockets so fopen("https://") and libcurl cannot be easily used.
  • In VS Code, we can open raw TCP sockets so fopen("https://"), but libcurl isn't since Playground doesn't support it yet.
Spawning child processes

Blueprint steps, wp-cli, phpunit, and other tools will often spawn child processes.

Reporting progress
  • In any CLI, we should display an ASCII progress bar.
  • With Docker as a backend, we should report the build progress somehow.
  • In Playground, progress bar is a <div> that needs to change its widths and innerText
Filesystem interactions

I'd love to avoid abstract the filesystem and just use the regular PHP functions like copy() and fread()

Local mounts

It may useful to support mounting directories

  • In the browser, we would either bale out (with a warning?) or mount an OPFS directory, whether that's page-specific or a local directory handle
  • In wp-now and Docker, we can mount directories in the runtime without changing anything on the disk
  • In Native PHP we could use symlinks

Technical implementation

Dependency injection

Let's explore the dependency injection pattern. Pimple is a tiny service container we can use to plug-in runtime-specific implementations:

$container = new Container();
switch ( $runtime ) {
	case self::RUNTIME_NATIVE:
		$container['downloads_cache']   = function ( $c ) {
			return new FileCache();
		};
		$container['http_client']       = function ( $c ) {
			return HttpClient::create();
		};
		$container['progress_reporter'] = function ( $c ) {
			return function ( ProgressEvent $event ) {
				echo $event->url . ' ' . $event->downloadedBytes . '/' . $event->totalBytes . "                         \r";
			};
		};
		break;
	case self::RUNTIME_PLAYGROUND:
		$container['downloads_cache']   = function ( $c ) {
			// @TODO
		};
		$container['http_client']       = function ( $c ) {
			// @TODO
		};
		$container['progress_reporter'] = function ( $c ) {
			// @TODO
			// post_message_to_js();
		};
		break;
Other ideas

What are other viable solutions to this problem?

Dominant language
PHP
Stars
61
Forks
22
Avg merge
19h 34m
Merged PRs (30d)
7

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WordPress/php-toolkit

All issues in WordPress/php-toolkit

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.