Products
GG网络技术分享 2025-03-18 16:14 0
Composer 是 PHP 的一个依赖管理工具。我们可以在项目中声明所依赖的外部工具库,Composer 会帮你安装这些依赖的库文件,有了它,我们就可以很轻松地使用一个命令将其他人的优秀代码引用到我们的项目中来。
Composer 默认情况下不是全局安装,而是基于指定的项目的某个目录中(例如 vendor)进行安装。
Composer 需要 PHP 5.3.2+ 以上版本,且需要开启 openssl。
Composer 可运行在 Windows 、 Linux 以及 OSX 平台上。
Windows 平台上,我们只需要下载 Composer-Setup.exe 后,一步步安装即可。
需要注意的是你需要开启 openssl 配置,我们打开 php 目录下的 php.ini,将 extension=php_openssl.dll 前面的分号去掉就可以了。
安装成功后,我们可以通过命令窗口(cmd) 输入 composer --version 命令来查看是否安装成功:
接下来我们可以更改阿里云 Composer 全量镜像:
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
取消配置:
composer config -g --unset repos.packagist
项目配置
仅修改当前工程配置,仅当前工程可使用该镜像地址:
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
取消配置:
composer config --unset repos.packagist
调试
composer 命令增加 -vvv 可输出详细的信息,命令如下:
composer -vvv require alibabacloud/sdk
遇到问题?
1. 建议先将Composer版本升级到最新:
composer self-update
2. 执行诊断命令:
composer diagnose
3. 清除缓存:
composer clear
4. 若项目之前已通过其他源安装,则需要更新 composer.lock 文件,执行命令:
composer update --lock
5. 重试一次
Linux 平台可以使用以下命令来安装:
# php -r "copy('https://install.phpcomposer.com/installer', 'composer-setup.php');"
# php composer-setup.php
All settings correct for using Composer
Downloading...
Composer (version 1.6.5) successfully installed to: /root/composer.phar
Use it: php composer.phar
移动 composer.phar,这样 composer 就可以进行全局调用:
# mv composer.phar /usr/local/bin/composer
切换为国内镜像:
# composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
更新 composer:
# composer selfupdate
Mac OS 系统可以使用以下命令来安装:
$ curl -sS https://getcomposer.org/installer | php
$ sudo mv composer.phar /usr/local/bin/composer
$ composer --version
Composer version 1.7.2 2018-08-16 16:57:12
切换为国内镜像:
$ composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
更新 composer:
$ composer selfupdate
要使用 Composer,我们需要先在项目的目录下创建一个 composer.json 文件,文件描述了项目的依赖关系。
文件格式如下:
{
"require": {
"monolog/monolog": "1.2.*"
}
}
以上文件说明我们需要下载从 1.2 开始的任何版本的 monolog。
接下来只要运行以下命令即可安装依赖包:
composer install
除了使用 install 命令外,我们也可以使用 require 命令快速的安装一个依赖而不需要手动在 composer.json 里添加依赖信息:
$ composer require monolog/monolog
Composer 会先找到合适的版本,然后更新composer.json文件,在 require 那添加 monolog/monolog 包的相关信息,再把相关的依赖下载下来进行安装,最后更新 composer.lock 文件并生成 php 的自动加载文件。
update 命令用于更新项目里所有的包,或者指定的某些包:
# 更新所有依赖
$ composer update
# 更新指定的包
$ composer update monolog/monolog
# 更新指定的多个包
$ composer update monolog/monolog symfony/dependency-injection
# 还可以通过通配符匹配包
$ composer update monolog/monolog symfony/*
需要注意的时,包能升级的版本会受到版本约束的约束,包不会升级到超出约束的版本的范围。例如如果 composer.json 里包的版本约束为 ^1.10,而最新版本为 2.0。那么 update 命令是不能把包升级到 2.0 版本的,只能最高升级到 1.x 版本。关于版本约束请看后面的介绍。
remove 命令用于移除一个包及其依赖(在依赖没有被其他包使用的情况下),如果依赖被其他包使用,则无法移除:
$ composer remove monolog/monolog
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 0 updates, 2 removals
- Removing psr/log (1.0.2)
- Removing monolog/monolog (1.23.0)
Generating autoload files
search 命令可以搜索包:
$ composer search monolog
该命令会输出包及其描述信息,如果只想输出包名可以使用 --only-name 参数:
$ composer search --only-name monolog
show 命令可以列出当前项目使用到包的信息:
# 列出所有已经安装的包
$ composer show
# 可以通过通配符进行筛选
$ composer show monolog/*
# 显示具体某个包的信息
$ composer show monolog/monolog
我们可以告诉 Composer 安装的具体版本,例如:1.0.2,指定 1.0.2 版本。
通过使用比较操作符来指定包的范围。这些操作符包括:>,>=,<,<=,!=。
你可以定义多个范围,使用空格或者逗号 , 表示逻辑上的与,使用双竖线 || 表示逻辑上的或。其中与的优先级会大于或。 实例:
我们也可以通过使用连字符 - 来指定版本范围。
连字符的左边表明了 >= 的版本,如果右边的版本不是完整的版本号,则会被使用通配符进行补全。例如1.0 - 2.0等同于>=1.0.0 <2.1(2.0相当于2.0.*),而1.0.0 - 2.1.0则等同于>=1.0.0 <=2.1.0。
可以使用通配符来设置版本。1.0.*相当于>=1.0 <1.1。
例子:1.0.*
我们先通过后面这个例子去解释~操作符的用法:~1.2相当于>=1.2 <2.0.0,而~1.2.3相当于>=1.2.3 <1.3.0。对于使用Semantic Versioning作为版本号标准的项目来说,这种版本约束方式很实用。例如~1.2定义了最小的小版本号,然后你可以升级2.0以下的任何版本而不会出问题,因为按照Semantic Versioning的版本定义,小版本的升级不应该有兼容性的问题。简单来说,~定义了最小的版本,并且允许版本的最后一位版本号进行升级(没懂得话,请再看一边前面的例子)。
例子:~1.2
^操作符的行为跟Semantic Versioning有比较大的关联,它允许升级版本到安全的版本。例如,^1.2.3相当于>=1.2.3 <2.0.0,因为在2.0版本前的版本应该都没有兼容性的问题。而对于1.0之前的版本,这种约束方式也考虑到了安全问题,例如^0.3会被当作>=0.3.0 <0.4.0对待。
例子:^1.2.3
如果你没有显式的指定版本的稳定性,Composer会根据使用的操作符,默认在内部指定为-dev或者-stable。例如:
约束 | 内部约束 |
1.2.3 | =1.2.3.0-stable |
>1.2 | >1.2.0.0-stable |
>=1.2 | >=1.2.0.0-dev |
>=1.2-stable | >=1.2.0.0-stable |
<1.3 | <1.3.0.0-dev |
<=1.3 | <=1.3.0.0-stable |
1 - 2 | >=1.0.0.0-dev <3.0.0.0-dev |
~1.3 | >=1.3.0.0-dev <2.0.0.0-dev |
1.4.* | >=1.4.0.0-dev <1.5.0.0-dev |
例子:1.0 - 2.0如果你想指定版本只要稳定版本,你可以在版本后面添加后缀-stable。
minimum-stability 配置项定义了包在选择版本时对稳定性的选择的默认行为。默认是stable。它的值如下(按照稳定性排序):dev,alpha,beta,RC和stable。除了修改这个配置去修改这个默认行为,我们还可以通过稳定性标识(例如@stable和@dev)来安装一个相比于默认配置不同稳定性的版本。例如:
{
"require": {
"monolog/monolog": "1.0.*@beta",
"acme/foo": "@dev"
}
}最近,一些客户的网站碰到了一个奇怪的问题:网站后台能正常进去,但是前台显示不了,提示:安装文件不存在,请上传安装文件。如已安装过,请新建config/install.lock文件。我在网上查了一下,是有一些网站出现类似情况,但是都不是wordpress程序网站,是MetInfo 网站管理程序的问题。
开始,我也是一头雾水。wordpress为什么会出现这样的一个问题呢?wordpress程序里根本就没有config/install.lock这样的文件名。幸好,一个客户把他的ftp帐号给我,让我帮他彻底清查一下,这样,我就可以查看他网站空间里所有的文件了。于是,我开始一个一个地排查。
因为,在网站后台里主题的设置都正常,而且原来出现的“编辑里找不到主题functions.php 文件”的情况也没有出现了(原问题前台提示:Fatal error: Call to undefined function is_mobile() in D:\\wwwroot\\maiyou360\\wwwroot\\wp-content\\themes\\ebuy\\index.php on line 2 ),所以主题基本没有问题。因为,换成默认的主题也是仍然提示:安装文件不存在,请上传安装文件。如已安装过,请新建config/install.lock文件。
主题没有问题,那也有可能是主题上一层 themes文件夹下的 index.php文件出问题,于是我把wordpress程序里的相关文件重新上传一下,问题依旧,那说明,themes 文件夹下的index.php文件是没有问题的。
接着往上找,查看一个 wp-content 文件夹下的index.php文件有没有问题,同样,没有问题。
于是,我直接找到wordpress 程序的 index.php文件,这下,终于让我明白了原因,问题就出现在这个文件上。这个文件被人修改过了,代码如下图:
而wordpress程序的原 index.php文件的源代码是非常简单的,如下图:
问题症结找到了,把wordpress程序里的原文件 index.php 文件重新上传覆盖,问题得到解决,网页前台恢复正常。问题虽然解决了,但是我还是非常慎重地提醒了这个客户,告诉他,他的网站被人攻击了,他的网站空间存在安全问题,应该提醒空间商做好相关的安全防护,并且,要立刻修改ftp密码、网站空间的后台密码、以有网站密码,越复杂越好。同时,如果这种问题以后又出现,就最好换一个安全的空间,最好是换一个稍大点的空间商,他们的安全一般都会比小空间商做得要好很多。
Demand feedback