Download the PHP package lucamauri/activitywiki without Composer

On this page you can find all versions of the php package lucamauri/activitywiki. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of lucamauri/activitywiki

Informations about the package activitywiki

ActivityWiki

Integrate your MediaWiki instance with the Fediverse via ActivityPub.

Overview

ActivityWiki is a MediaWiki extension that enables wiki instances to participate in the Fediverse by implementing the ActivityPub W3C protocol. It allows Mastodon users and other Fediverse participants to follow your wiki and receive notifications when pages are created, edited, or deleted — directly in their Fediverse timeline.

ℹ️ Current status: v1.1.0 — first fully working release. Identity (actor + WebFinger), Security (HTTP Signatures, including a documented key rotation path), Publishing (outbound delivery to followers, with a real database-backed outbox), and Receiving (inbox, Follow/Undo handling, a real database-backed followers collection) are all complete and verified live against real Fediverse traffic (Mastodon). All five ActivityPub-spec-required endpoints — actor, WebFinger, outbox, followers, inbox — are implemented and working end-to-end. See the Roadmap section below for what's deferred as a post-release fast-follow.

Requirements

Installation

Choose whichever of the two methods below fits how you manage your MediaWiki installation. Both end up in the same place — an ActivityWiki directory inside your extensions/ folder — so the remaining steps (2–4) are identical either way.

Option A — Clone from GitHub

Option B — Install from Packagist via Composer

ActivityWiki is published on Packagist as lucamauri/activitywiki. This method only works if your MediaWiki installation is itself Composer-managed (i.e. you ran composer install at some point to set up core, rather than installing purely from a tarball/git clone with no composer.json at the wiki root — most modern installations qualify).

From your MediaWiki installation root (the directory containing the main composer.json, not the extensions/ directory):

This package declares "type": "mediawiki-extension" in its own composer.json, which the composer/installers plugin (bundled with MediaWiki core's own composer.json by default) recognises and uses to place the extension's files directly into extensions/ActivityWiki/ automatically — no manual cloning or moving required.

If composer require fails with something like "could not find a matching version" or complains about missing composer/installers, your MediaWiki installation likely isn't Composer-managed at the root level. In that case, use Option A instead — there is no functional difference between the two once the files are in place.

To upgrade later, either method works the same way going forward: git pull for Option A, or composer update lucamauri/activitywiki for Option B.

2. Add to LocalSettings.php

3. Run database setup

4. Set up WebFinger routing

This step is required. Without it, the wiki is completely invisible to Fediverse search, even though every other endpoint works correctly. See WebFinger routing below for full instructions.

Configuration

All configuration variables are optional. The defaults are shown below.

To see ActivityWiki's debug log output, add a dedicated log channel in LocalSettings.php:

WebFinger routing

The WebFinger protocol (RFC 7033) requires that requests be served from a fixed, well-known path at the root of your domain:

This path is outside MediaWiki's normal URL space, and MediaWiki cannot serve it on its own. Setting this up correctly requires two things: a small entry-point script, and a web-server rewrite rule pointing to it. Both are described below.

Throughout this section, replace /path/to/your/wiki/ with wherever your MediaWiki installation actually lives (the directory containing rest.php), and replace /your-script-path/ with your own $wgScriptPath (e.g. /w, /wiki, or empty if MediaWiki is installed at your domain root). These vary per installation — there is no universal default.

Why a separate entry-point file is needed

MediaWiki's REST router validates that every incoming REQUEST_URI starts with the REST base path (e.g. /your-script-path/rest.php). A plain web-server-level rewrite from /.well-known/webfinger straight to the REST path is not enough on its own — the rewrite happens after PHP has already read $_SERVER['REQUEST_URI'], so MediaWiki's router still sees the original, unrewritten URI and rejects the request with a rest-prefix-mismatch error, even though the route and handler (WebFingerHandler) are correctly registered.

The fix is entry-points/webfinger.php, included with this extension. It corrects $_SERVER['REQUEST_URI'] itself before MediaWiki boots, then hands off entirely to rest.php. It contains no business logic of its own — all actual WebFinger handling still happens in WebFingerHandler.php.

Future improvement: A MediaWiki core patch to accept configurable REST base path validation would make this entry-point file unnecessary. Worth contributing upstream separately.

Step 1 — Copy the entry-point file and set your script path

Copy entry-points/webfinger.php from the extension to the same directory as rest.php:

Open the copied file and confirm the rewritten path matches your $wgScriptPath:

Replace /your-script-path/ with your actual $wgScriptPath (for example, if $wgScriptPath = '/w', this line should read '/w/rest.php/activitywiki/webfinger').

Step 2 — Add the web-server rewrite rule

Apache

Add the following rule inside the <VirtualHost> block that serves your wiki, before any existing MediaWiki rewrite rules:

⚠️ Do not anchor the pattern with a leading /. Inside a <VirtualHost> block (as opposed to an .htaccess file), Apache's RewriteRule matches the URL path without a leading slash. A pattern written as ^/\.well-known/webfinger$ will never match — Apache will silently fall through to its normal file-serving logic and return a generic Apache 404 page, with nothing logged anywhere that points to the actual cause. If %{DOCUMENT_ROOT}/webfinger.php is not where you copied the file in Step 1 (for example, if your DocumentRoot is a parent directory of your wiki installation rather than the installation directory itself), adjust the target path accordingly.

The QSA flag (Query String Append) passes the ?resource=... parameter through. The L flag stops further rule processing for this request.

Nginx

Add the following to your server block:

Replace /your-script-path/ with your $wgScriptPath, matching Step 1. This approach rewrites REQUEST_URI directly via FastCGI parameters, so the entry-points/webfinger.php file is not needed for the Nginx path.

Behind a reverse proxy (Anubis, Varnish, Cloudflare, etc.)

If your setup uses a reverse proxy in front of your web server, make sure /.well-known/ paths are passed through without being blocked or challenged. Most proxy configurations already allow this for Let's Encrypt compatibility, but bot-detection layers (e.g. Anubis) can sometimes intercept paths that look unusual. If WebFinger works when tested directly against your web server but not from the public internet, check your proxy's passthrough or allow-list rules for /.well-known/.

Step 3 — Reload your web server

Step 4 — Verify

Request the well-known URL directly:

A correct response is 200 OK, with Content-Type: application/jrd+json, and a JSON body shaped like:

An unrecognized resource correctly returns a 404 with a small JSON error body (e.g. {"error":"Resource not found on this server."}) — that's expected and fine.

Troubleshooting

Symptom Likely cause Fix
404 Not Found, Content-Type: text/html, Apache/Nginx server signature in the body Rewrite rule isn't matching — most commonly the leading-slash mistake described above Check the RewriteRule/location pattern; confirm it's in the <VirtualHost> block that actually serves your public HTTPS traffic
500, JSON body mentioning rest-prefix-mismatch entry-points/webfinger.php missing, in the wrong location, or its hardcoded script path doesn't match $wgScriptPath Re-check Step 1
500, JSON body mentioning ArgumentCountError or similar routes.json's webfinger route is missing a required service, or extension files are out of date Confirm you're running the current version of the extension; check routes.json lists all services WebFingerHandler's constructor requires
Works when curled directly against the server but not from the public internet A reverse proxy is intercepting or challenging the request Check your proxy's passthrough rules for /.well-known/
404 with a small JSON body (not HTML) This is MediaWiki's own "resource not found" response Check that the resource parameter's username and domain match your actual $wgActivityWikiActorUsername and $wgServer

Key rotation

ActivityWiki's HTTP Signature key pair (used to sign every outbound activity, and served publicly as part of the actor object) is generated automatically on first install — you don't need to do anything for normal operation. A dedicated maintenance script, maintenance/GenerateKeys.php, exists for two situations:

⚠️ Rotation is immediate and has real consequences. The moment the new key is stored, every outbound HTTP Signature is signed with it. Any Fediverse server that has cached your old public key (some do cache aggressively) may continue rejecting your signed requests until that cache expires on their end — there is no way to force this from your side. This is expected and self-resolves; it is not a bug in the rotation itself.

Restart PHP-FPM after running the script, as a precaution (the script will remind you).

Repository Structure

Roadmap

Phase 0 — Audit fixes ✅ Complete

Phase 1 — Identity ✅ Complete

Phase 2 — Security ✅ Complete

Phase 3 — Publishing ✅ Complete

Phase 4 — Receiving ✅ Complete

Phase 5 — Administration & consolidation ✅ Mostly complete

Post-release fast-follows (not blockers)

Post-MVP (deferred, not scoped)

Troubleshooting

Check the actor endpoint is reachable

Should return actor JSON, not a 404.

Check WebFinger is reachable at the public well-known path

See the WebFinger routing troubleshooting table above if this doesn't return a correct JSON response.

Check debug logs

Set $wgActivityWikiDebugLevel = 1; and configure a log channel (see Configuration above), then:

License

GPL-2.0-or-later. See LICENSE file for details.

References

In the spirit of IDIC 🖖🏻 forged at WikiTrek, shared freely with the Galaxy

All versions of activitywiki with dependencies

PHP Build Version
Package Version
Requires php Version >=8.0.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package lucamauri/activitywiki contains the following files

Loading the files please wait ...