Rename to phpbbmodders/wiki

[bonelifer]

Summary

• Renames the extension tas2580/wiki → phpbbmodders/wiki: PHP namespace, service IDs (phpbbmodders.wiki.*), route names, the @phpbbmodders_wiki/ template namespace, language loading, the notification type, CI EXTNAME and composer.json. Page URLs (/wiki/...) don't change.
• New ext.php handles existing installs:
  • it refuses to enable while tas2580/wiki is still enabled
  • on enable, before the normal migration run, it moves the old install's data to the new names:
    • migration history (with dependency lists)
    • the notification type, under either spelling (article_edit, or the older misspelled articke_edit); its ID is kept, so existing notifications still work
    • users' notification settings, merging any rows that end up identical
    • any interrupted reparser:reparse CLI run
  • it deletes the old extension record
  • the enable, disable and delete-data steps for the notification type work as before
• The wiki tables (phpbb_wiki_article) and permissions (u_wiki_*, m_wiki_*) never included the vendor name, so they are used as they are. Old migrations only change their namespace; their SQL describes what already ran and is left alone.
• Headers: standard phpBB Modders header on every PHP file. The original tas2580 and Crizz0 notices are kept. Three files added on 09/23 (add_article_description, rename_article_edit_notification, and its test) had been wrongly stamped (c) 2026 tas2580 and now carry the phpBB Modders line only.
• composer.json: phpBB Modders as Extension Developer, tas2580 and Crizz0 → Past Developer, display name phpBB Modders Wiki, PHP >=7.1.3 (phpBB 3.3's own minimum; the new code needs PHP 7), and an extra keyword.
• README: new install path and an "Upgrading from tas2580/wiki" section.

Upgrading: disable the old extension (keep its data), delete ext/tas2580/wiki, upload this version to ext/phpbbmodders/wiki, enable it, then purge the cache. If you disable from the command line, purge the cache before enabling; the CLI disable doesn't clear it.

Test plan

Claude tested on a phpBB 3.3 board (SQLite, PHP 8.4) with the old extension from main installed. The board had 7 articles, notification type 9 with 2 notifications, and 10 permissions. Claude added test data: subscriptions under both notification-type spellings (including duplicates for the same user and method), a leftover misspelled type row, and interrupted reparser resume data.

• Enabling the new version while the old one is enabled is refused.
• After disable old → delete folder → enable new:
  • all 7 articles and 10 permissions are kept
  • the 10 migration rows (and dependencies) are under \phpbbmodders\wiki\
  • type 9 is phpbbmodders.wiki.notification.type.article_edit and enabled
  • the duplicate subscriptions were merged into single rows
  • the reparser resume key moved and the unrelated key was untouched
  • only phpbbmodders/wiki remains
• /wiki, an article page and the index return 200, with no ext/tas2580 asset paths.
• The two existing notifications load and render as phpbbmodders\wiki\notification\article_edit.
• reparser:reparse phpbbmodders_wiki_article --resume resumes from the moved data.
• A fresh install (disable → delete data → enable) creates the migrations, notification type and permissions under the new name.
• The same upgrade on a phpBB 4.0 (master) board: articles and migrations kept, subscriptions merged, index renders.
• php -l on every PHP file and composer validate pass.

---

Investigated and written by Claude on behalf of William Jacoby (bonelifer).