この問題は何度も投稿されていることは承知していますが、私にとっては別の問題のように思えます。
確かにこのエラー
警告: require(vendor/autoload.php): ストリームを開けませんでした: C:\xampp\htdocs\site_web\send_mail.php の 3 行目にそのようなファイルまたはディレクトリはありません
致命的なエラー: require(): C:\xampp\htdocs\site_web\send_mail.php の 3 行目で、必要な 'vendor/autoload.php' (include_path='C:\xampp\php\PEAR') を開けませんでした
私のコードの先頭の次の行に表示されます:
require 'vendor/autoload.php';
したがって、私のコンピューターのどこかに /vendor/autoload.php ファイルがあるはずです (composer をインストールして実行しましたcomposer require phpmailer/phpmailer)。
そこで、dir /s autoload.phpWindowsのコマンドラインで次のファイルを検索し、次の場所でファイルを見つけましたC:\Windows\SysWOW64\vendor\autoload.php。
しかし、私にとって、syswow64フォルダーにはautoload.phpで確認できるものは何もありません。ここで何が欠けているのかわかりません。
ベストアンサー1
欠けているのは の実行ですcomposer install。これにより、パッケージがインポートされ、自動ロード スクリプトとともにベンダー フォルダーが作成されます。
相対パスが正しいことを確認してください。たとえば、PHPMailer のサンプル スクリプトはexamples/プロジェクト ルートの下の にあるので、そこから composer オートローダーをロードするための正しい相対パスは になります../vendor/autoload.php。
見つかった autoload.php は、C:\Windows\SysWOW64\vendor\autoload.phpおそらくグローバル Composer インストールです。通常、ここには phpcs、phpunit、phpmd などが配置されます。
composer update同じものではなく、おそらく使用したいものでもありませんupdate。コードが現在のパッケージ バージョンでテストされている場合、実行すると破損が発生し、さらに作業とテストが必要になる可能性があります。そのため、update特別な理由があり、それが何を意味するのかを正確に理解していない限り、実行しないでください。さらに明確にするために、実稼働中のアプリが破損する可能性が高いため、ローカルでのみ実行しcomposer update、サーバー上では実行しないでください。
自分のサーバーで実行できないため (たとえば、共有されていてシェルにアクセスできないため)、composer を使用できないという苦情をよく目にします。その場合でも、composer は使用できます。ローカル (そのような制限のない環境) で実行し、生成されたローカルの vendor フォルダーを他のすべての PHP スクリプトとともにアップロードします。
を実行するcomposer update と も実行されcomposer install、現在フォルダーがない場合vendor(プロジェクトの新しいチェックアウトがある場合は通常) はフォルダーが作成され、composer.lock既存のファイルも上書きされ、その中にタグ付けされたパッケージのバージョンが更新されます。これが潜在的に危険な点です。
同様に、現在ファイルがない場合composer.lock（たとえば、プロジェクトにコミットされていない場合）、composer installも事実上 を実行します。 したがって、これら 2 つは互換性がないcomposer updateため、その違いを理解することが重要です。
名前を付けて単一のパッケージを更新することもできます。例:
composer update ramsey/uuid
これにより、指定されたバージョンが再度解決されcomposer.json、ベンダー フォルダーにインストールされ、composer.lock一致するようにファイルが更新されます。 1 つのパッケージに特定の更新だけが必要な場合、一般的な方法よりも問題が発生する可能性がはるかに低くなりますcomposer update。
ライブラリが独自のファイルを含まないのは普通のことですcomposer.lock。バージョンを修正するのはアプリ側であり、使用するライブラリ側ではありません。そのため、ライブラリ開発者は、アプリ開発者が必要とするよりも広範囲のホスト環境との互換性を維持することが求められます。たとえば、ライブラリは Laravel 5、6、7、8 と互換性があるかもしれませんが、それを使用するアプリでは他の理由で Laravel 8 が必要になる場合があります。
Composer 2.0では、インストールとアップデートの結果の間に残っていた矛盾が解消されました。Composer 1.xを使用している場合は、必ずアップグレード。