ハクソク

世界を動かす技術を、日本語で。

2014年の私の一時的なPHP修正が約2000万インストールを達成しました。今日はそれを非推奨にします。

2026年9月16日原文(jakeasmith.com)

概要

PHP製の一時的なパッチ が、想定外に 2,000万回以上インストール された経緯 WPMLやSPIPなど有名CMSでも利用 されていた事実 バグや保守の問題 に直面し、 非推奨化を決断 より良い代替手段 の登場と セキュリティリスク への配慮 一時的な修正が長期間使われた教訓

174行のPHPが2,000万回使われた経緯

  • 2012年、AOLのCMSのPHPアップグレード 対応のため、一時的なパッチとして174行のPHPコード作成
  • pecl_http拡張のhttp_build_url()関数の代替 として自作実装
  • ComposerとPackagistで公開 し、他の開発者も利用可能に
  • 1～2年の短期利用を想定した一時的なshim として設計
  • 結果として 2,000万回以上インストール され、月間40万回以上の利用実績

予想外の広がりと主要プロジェクトでの利用

  • WPML（WordPressの多言語プラグイン） がコードベースに直接バンドル
    • 150万以上のサイトで稼働
  • idna-convertライブラリが依存し、SPIPやDebian/Ubuntuにも組み込み
  • 多くのウェブサイトで今も動作中 という事実
  • Composer経由以外にも幅広く利用 されていた実態

久しぶりの再訪とバグ発覚

  • 数年ぶりにパッケージを確認 し、利用の多さに驚愕
  • GitHub上で複数のIssueが報告
    • 例： パス末尾のスラッシュにより「a」文字が全て消えるバグ
    • // Workaround for trailing slashes というコメント下の回避策が原因
  • 長期間バグが気付かれなかった ことに驚き

維持・引き継ぎ・非推奨の選択肢

  • PHPから離れて久しく、保守継続は困難
  • 新しいメンテナーに渡すリスク （信頼性・セキュリティ）
  • PHP LeagueのURIライブラリやPHP 8.5の標準URI API 登場
  • 古いshimに頼るより、公式かつ安全なものに移行推奨
  • 攻撃者による乗っ取りのリスク も考慮
  • READMEで移行方法を案内し、非推奨化を決断

一時的な修正が残した教訓

  • 「一時的なコード」が長期間使われる現実
  • 保守されないコードのリスク と コミュニティの進化 の重要性
  • 多くの開発者やユーザーへの感謝
  • AOLのCMSも結局「一時的な」polyfillのまま2020年まで稼働

セキュリティと信頼性の観点からの非推奨化

  • 広く使われるパッケージの引き継ぎは大きな責任
  • 未検証の新メンテナーによるリスク
  • Veritasiumのxz Utilsバックドア動画を例に警鐘
  • 今後は新規修正なし、バグも未修正のまま
  • 「一時的な修正」の終焉と、より良い選択肢への移行推奨

Hackerたちの意見

https://packagist.org/packages/jakeasmith/http_build_url

└

JavaScriptの世界は、君のパッチと比べると複雑なプロジェクトで溢れてるよ。これらの例を見てみて： https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-even https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/is-whitespace-character https://www.npmjs.com/package/isarray

└

決め手はバグがあるかどうかだと思う。バグを直すのも直さないのも、どっちも悪影響があるからね。もし既知のバグがなくて、使うのに問題がなければ、そのまま放置しておいて、ドキュメントに目的が古くなったって書いておくだけでいいかな。

└

記事から: > だから、決断をしなきゃいけなかった。約10年ぶりにPHPに戻るか、パッケージを提供してくれた人の一人に渡すか、それともそのまま放置するか。今はAIの時代だ。何年も触っていないオープンソースプロジェクトのメンテナーとして、まずはAIに問題の修正を提案させて、その内容をチェックすることから始めるつもり。これで精神的な負担が減るし、多くのユーザーが依存している古いコードベースを壊すリスクも減るよ。プロジェクトを非推奨にするのは、オープンソースのゲームを別の次元でプレイすることだね。このプロジェクトに依存するのは最初から悪いアイデアだったって言って、みんなに次に進むように促す。でも、非推奨のプロジェクトで修正をリリースするのも全然アリだよ。だから、両方の行動は別の次元にあって、2つの選択肢の間の選択ではないんだ。

AOLで一緒に働いてたよね。ここで会えて嬉しい！元気にしてるといいな！

└

これを読んで2014年に戻った気分だ。あの頃のAOLでの仕事はどうだった？

うまくいく一時的な修正ほど、永続的なものはないよね。

あの規模のインストールベースを持つパッケージには、移行オプションを印刷する最終リリースがあるの？人々は何年後かに古いStack Overflowの回答を通じて見つけると思うよ。

└

このパッケージはPackagistで廃止されてるよ。

このパッケージは廃止されており、もはやメンテナンスされていません。代替パッケージは提案されていません。 composerを使って依存関係として追加したり、ロックファイルからインストールすると、次のようになります： $ composer require jakeasmith/http_build_url […] パッケージjakeasmith/http_build_urlは廃止されているので、使用を避けるべきです。代替パッケージは提案されていません。 […] $ rm -r vendor/ $ composer install […]

  • jakeasmith/http_build_url (1.0.2)をインストール中：アーカイブを展開中 パッケージjakeasmith/http_build_urlは廃止されているので、使用を避けるべきです。代替パッケージは提案されていません。 […]

これを読んで本当に懐かしくなった。Laravel 5.xの頃にウェブ/ソフトウェア開発を始めたんだけど、今と比べると日常が全然違ってて驚くよ！

リポジトリをアーカイブすべきかな？あんまりこの機能使ってる人見ないけど、Githubには実質死んでるリポジトリがたくさんあるよね。

└

これに+1だね - ジェイクはパッケージを非推奨にするっていう最善の選択をしたと思う（これがローカルのツールで表示され、静的解析ツール（つまりセキュリティベンダー）によっても取り上げられるし）、リポジトリをアーカイブすることで、リポジトリにアクセスする人にもそれを示している。

Hacker Newsで議論の続きを見る