# Composer: upravitelj paketa za PHP

> Composer objašnjen: razumijevanje composer.json, composer.lock, vendor i autoloadera, uredna isporuka u produkciju i sigurno održavanje ovisnosti.

Izvor: https://phpsos.de/hr/php/composer/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Composer je upravitelj paketa za PHP. Iz datoteke `composer.json` čita koje biblioteke projekt treba, učitava ih u mapu `vendor`, točne verzije bilježi u `composer.lock` i stvara autoloader koji automatski pronalazi klase. Composer tako upravlja kodom Vaše aplikacije, a ne samim PHP interpreterom: Composer ažuriranje ne zatvara ranjivost u PHP-u poput PHP2Shella.

## Što je Composer i čemu služi?

Jedva koja PHP aplikacija danas sadrži samo vlastiti kod. Frameworci, biblioteke za e-poštu, izrada PDF-ova ili povezivanje plaćanja dolaze kao gotovi paketi. Composer, upravitelj paketa za PHP, brine da se ti paketi okupe u odgovarajućim verzijama i da svaka ovisnost donese vlastite ovisnosti.

Za donositelje odluka to znači: velik dio koda koji radi na Vašem poslužitelju potječe od trećih strana. To je učinkovito, ali traži njegu. Za administratore i razvijatelje to znači: tko Composer uredno koristi, u svakom trenutku može pratiti koja verzija koje biblioteke radi u produkciji.

Standardni izvor paketa prema Composer dokumentaciji je Packagist.org. Dodatni izvori, na primjer interni repozitoriji agencije, mogu se upisati u `composer.json` pod `repositories`.

## composer.json, composer.lock i vendor: tri gradivna dijela

Composer radi s tri stvari koje valja poznavati prije nego što preuzmete poslužitelj ili angažirate agenciju.

| Gradivni dio | Sadržaj | Pripada li u repozitorij? |
|---|---|---|
| `composer.json` | željeni paketi s rasponima verzija (`require`, `require-dev`), pravila autoloada, postavke | da |
| `composer.lock` | točno razriješene verzije svih paketa, i neizravnih | da, prema Composer dokumentaciji izričito |
| `vendor/` | preuzeti kod paketa i stvoreni autoloader | ne, stvara se pri instalaciji |

Pod `require` stoje paketi koje aplikacija treba u radu. Pod `require-dev` stoje alati za razvoj i testiranje, na primjer okviri za testiranje ili statička analiza. Ta je podjela važna jer razvojni alati na produkcijskom poslužitelju nemaju što tražiti.

```json
{
    "require": {
        "php": ">=8.3",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}
```

Navedene verzije u primjeru odabrane su samo radi ilustracije. Koje verzije Vaš projekt treba, proizlazi iz njegovih zahtjeva.

## install ili update: razlika u radu

Obje naredbe zvuče slično, ali imaju vrlo različite posljedice.

- `composer install` čita `composer.lock` i instalira točno verzije zabilježene u njoj. To je ponovljivo i pripada u isporuku.
- `composer update` iznova razrješava sve ovisnosti, dohvaća najnovije odgovarajuće verzije i iznova piše `composer.lock`. To pripada u razvoj, uz naknadne testove.

Prema Composer dokumentaciji `update` nakon pisanja lock datoteke dodatno provodi sigurnosnu provjeru (audit), osim ako se isključi pomoću `--no-audit`. `install` prema zadanim postavkama ne provjerava; za to postoji opcija `--audit`.

## Autoloading: kako Composer pronalazi klase

Composer stvara datoteku `vendor/autoload.php`. Kada se jednom uključi, PHP svaku klasu učitava tek kada je zatreba. Za vlastiti kod u odjeljku `autoload` određuje se koji namespace leži u kojoj mapi. Za to se preporučuje PSR-4, standard PHP-FIG-a. Kako to točno radi, objašnjava stranica [Namespaces i autoloading](https://phpsos.de/hr/php/namespaces-autoloading/); pregled svih standarda daje stranica [PSR standardi](https://phpsos.de/hr/php/psr-standards/).

```php
<?php
require __DIR__ . '/../vendor/autoload.php';

$log = new Monolog\Logger('app');   // učitava se automatski po potrebi
```

## Composer u produkciji: uredna isporuka

Za isporuku se pokazao dobrim čvrst redoslijed. Najbolje ga je izvoditi u build pipelineu, a ne ručno na poslužitelju.

1. **Provjeriti lock datoteku:** `composer validate` osigurava da je `composer.json` valjan i da je `composer.lock` aktualan.
2. **Instalirati bez razvojnih paketa:** `composer install --no-dev` izostavlja `require-dev`.
3. **Optimizirati autoloader:** `--optimize-autoloader` (skraćeno `-o`) pretvara pravila u popis klasa. S `--classmap-authoritative` PHP klase učitava isključivo s tog popisa.
4. **Sigurnosna provjera:** `composer audit --locked` provjerava verzije iz lock datoteke prema poznatim sigurnosnim objavama i prijavljuje napuštene pakete.
5. **vendor izvan webroota:** Putem URL-a smije biti dostupna samo javna mapa s ulaznom skriptom.

```bash
composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev
```

`composer outdated` dodatno pokazuje koji instalirani paketi imaju novije verzije. To je osnova za planirana ažuriranja umjesto užurbanih pojedinačnih akcija.

## Composer, sigurnost i PHP2Shell

Composer i PHP2Shell tiču se dviju različitih razina. Ranjivosti CVE-2026-109618 i CVE-2026-109619 leže u samom PHP interpreteru. Otklonjene su u PHP-u 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a nakon toga se svi PHP procesi moraju ponovno pokrenuti. Nikakav `composer update` ni paket u `vendor` tu ništa ne mijenja.

Ipak, Composer pripada u svaku provjeru nakon incidenta. Tko na poslužitelj unese zlonamjerni kod, može mijenjati i datoteke u `vendor`, a `vendor/autoload.php` učitava se pri svakom zahtjevu. Svježi `composer install` iz provjerene lock datoteke u prazan direktorij stoga je dobra metoda za ponovnu uspostavu stanja paketa. Kako ovisnosti redovito provjeravati zbog poznatih ranjivosti, opisuje vodič [composer audit](https://phpsos.de/hr/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Važno:**
> Zeleni `composer audit` ne govori ništa o razini zakrpa PHP-a. PHP izvršno okruženje provjeravajte zasebno, na primjer našom [PHP Patch uslugom](https://phpsos.de/hr/leistungen/php-patch-service/).

## Kako PHP SOS konkretno pomaže?

- Za svaku aplikaciju evidentiramo PHP verziju, Composer pakete i stanje lock datoteke te pritom uredno razdvajamo interpreter i biblioteke.
- Provjeravamo odgovaraju li `vendor` i lock datoteka jedno drugome te leže li u produkciji razvojni paketi ili izmijenjene datoteke.
- Uspostavljamo ponovljivu isporuku s `install --no-dev`, optimiziranim autoloaderom i auditom.
- Nakon incidenta iznova uspostavljamo stanje paketa iz provjerene lock datoteke i dokumentiramo rezultat.


## Česta pitanja

**Mora li composer.lock u Git repozitorij?**  
Da. Composer dokumentacija izričito preporučuje commitanje datoteke composer.lock. Samo tako razvoj, CI i produkcija instaliraju potpuno iste verzije paketa.

**Koja je razlika između composer install i composer update?**  
install instalira verzije zabilježene u composer.lock. update iznova razrješava ovisnosti, dohvaća odgovarajuće novije verzije i iznova piše composer.lock. Na produkcijski poslužitelj pripada samo install.

**Zatvara li Composer ažuriranje PHP2Shell ranjivost?**  
Ne. Composer upravlja bibliotekama Vaše aplikacije, a ne PHP interpreterom. PHP2Shell zatvara samo ažuriranje PHP izvršnog okruženja na ispravljenu verziju i ponovno pokretanje svih PHP procesa.

**Gdje bi trebala biti mapa vendor?**  
Idealno izvan javno dostupnog web-direktorija. Mnogi frameworci u webroot stavljaju samo mapu public, dok vendor leži jednu razinu iznad.

## Izvori

- [Composer: Basic usage](https://getcomposer.org/doc/01-basic-usage.md)
- [Composer: Command-line interface](https://getcomposer.org/doc/03-cli.md)
- [Composer: The composer.json schema](https://getcomposer.org/doc/04-schema.md)