Ko darīt ar mājaslapu, kurai ir veca PHP vai Node.js versija?

Īsā atbilde ir šāda: vietnei ar vecu PHP vai Node.js versiju ir trīs ceļi — pielāgot kodu atbalstītam laidienam, pārbūvēt vietni no jauna vai uz laiku turēt to platformā, kas vecajai izpildvidei joprojām pārnes drošības labojumus, un tikmēr mierīgi plānot pāreju. Ceturtā ceļa — atstāt visu, kā ir, jo vietne taču strādā — patiesībā nav, jo PHP 8.1 un vecāki atzari no PHP projekta labojumus vairs nesaņem, Node.js 18. un 20. līnija arī ne, un 2026. gada oktobris abos gadījumos parādīja, ko tas nozīmē praksē.

Vietne ar vecu PHP versiju parasti nav ne izņēmums, ne kāda īpaša nolaidība. Tā tika izstrādāta pirms pieciem vai astoņiem gadiem, izstrādātājs, kas to veidoja, sen strādā citur, un vietne visus šos gadus ir kalpojusi bez lielām problēmām: pieņēmusi pieteikumus, rādījusi cenas un sūtījusi rēķinus. Pēc W3Techs datiem 2026. gada oktobrī 26,8 % vietņu, kuras izmanto PHP, strādāja uz PHP 7 un vēl 7,7 % uz PHP 5, tātad vairāk nekā trešā daļa no tām izmanto PHP, kuram atbalsts ir beidzies pirms vairākiem gadiem. Jautājums parasti rodas tikai tad, kad hostinga sniedzējs atsūta brīdinājumu vai kad kāda ievainojamība nonāk ziņās.

Kad PHP vai Node.js versija kļūst veca

«Veca» šeit nav gaumes jautājums, jo gan PHP, gan Node.js publicē grafiku, kurā ir norādīts, līdz kuram datumam katrs atzars vai līnija saņem labojumus. PHP katram atzaram dod divus gadus aktīva atbalsta un vēl divus gadus, kuros iznāk tikai kritisku drošības kļūdu labojumi, un pēc tam atzars vairs netiek atbalstīts nekādā veidā. Node.js ilgtermiņa atbalsta līnijām beigās ir uzturēšanas posms (Maintenance LTS), un, kad tas beidzas, līnija vairs nesaņem nevienu laidienu, arī tad, ja jauna ievainojamība skar tieši to.

Tabulā ir atzari un līnijas, ar kurām mūsdienās visbiežāk nākas saskarties, un to stāvoklis 2026. gada oktobrī. Datumi ņemti no PHP atbalsta beigu saraksta un Node.js laidienu grafika, un abi avoti ir jāpārbauda arī turpmāk, jo katru gadu tajos parādās jaunas rindas.

Divas rindas šajā tabulā ir vērts izlasīt vēlreiz. PHP 8.2 atbalstu zaudēs 2026. gada 31. decembrī, tātad vietne, kas 2026. gada rudenī izskatās mūsdienīga, 2027. gada janvārī būs tādā pašā situācijā kā vietne ar PHP 7.4, un pāreju ir vērts plānot jau tagad, kamēr to var izdarīt bez steigas. Node.js 20. līnija vēl 2024. gada rudenī bija aktīvā ilgtermiņa atbalsta līnija, uz kuras tika sākti daudzi jauni projekti, bet 2026. gada 30. aprīlī tā atbalstu zaudēja. Novecošana nenotiek pakāpeniski: vienā konkrētā dienā izpildvide pāriet no «saņem labojumus» uz «nesaņem neko», un vietnē tajā brīdī nemainās nekas, ko varētu pamanīt.

Kāpēc vietne, kas strādā, tik un tā ir apdraudēta

Versija bez atbalsta nekļūst bīstama tajā dienā, kad atbalsts beidzas, bet gan tajā dienā, kad tiek publiskota ievainojamība, kas skar arī to. Labojums atbalstītajiem atzariem iznāk kopā ar aprakstu, un, tiklīdz tas ir publisks, uzbrucēji var salīdzināt labotu kodu ar nelabotu un saprast, kur ir caurums. Node.js savā lapā par atbalsta beigām to saka tieši: ja ievainojamība skar arī līniju bez atbalsta, tai jauns laidiens neiznāks, un tie, kas uz tādas līnijas paliek, ir uzreiz neaizsargāti pret uzbrukumiem, kas izmanto publiskoto ievainojamību.

2026. gada oktobrī tieši tas notika abām platformām gandrīz vienlaikus. 21. oktobrī PHP izlaida ārkārtas labojumus divām kritiskām ievainojamībām, kas pazīstamas ar nosaukumu PHP2Shell, un oficiālus laidienus saņēma tikai atzari no 8.2 līdz 8.5, bet atzariem 7.4, 8.0 un 8.1 drošības komanda izņēmuma kārtā sagatavoja vien minimālus pirmkoda labojumus tiem, kas PHP būvē paši. Tajā pašā dienā Node.js izlaida labojumus desmit ievainojamībām, un 18. un 20. līnija no paša projekta tos nesaņēma vispār. Abus gadījumus sīkāk esam aprakstījuši atsevišķi: rakstā par PHP2Shell un rakstā par Node.js drošības atjauninājumu.

Otrs risks ir mazāk redzams, bet ilgtermiņā lielāks. Veca izpildvide neļauj atjaunināt neko no tā, kas atrodas virs tās: WordPress spraudņi, Composer un npm pakotnes un pats ietvars savos jaunajos laidienos vecu PHP un Node.js pamazām pārstāj atbalstīt, tāpēc vietne nevar saņemt arī to labojumus. WordPress pats iesaka PHP 8.3 vai jaunāku un par vecākiem atzariem raksta, ka to oficiālais atbalsts ir beidzies un tie var padarīt vietni neaizsargātu. Tā vecā izpildvide vairs nav viena atsevišķa problēma, bet slānis, kas neļauj atrisināt visas pārējās.

Kad kaut kas notiek, cena ir krietni augstāka par plānotu atjaunināšanu. Uzlauzta vietne nozīmē tīrīšanu, atjaunošanu no dublējumkopijas, paroļu un atslēgu nomaiņu un, ja tika skarti klientu personas dati, arī izvērtējumu, vai par personas datu aizsardzības pārkāpumu ir jāziņo uzraudzības iestādei, turklāt viss tas notiek steigā, kamēr vietne nestrādā vai rāda apmeklētājiem svešu saturu. Pāreja šajā situācijā tik un tā ir jāveic, tikai tagad to nākas darīt pēc uzlaušanas, nevis pirms tās, un bez iespējas mierīgi visu pārbaudīt testa vidē.

Kāpēc vecu PHP versiju nevar vienkārši nomainīt hostinga panelī

Hostinga panelī pāreja uz jaunāku PHP versiju aizņem vienu klikšķi, un tieši tāpēc tā ir viltīga: ja kods tai nav gatavs, vietne pārstāj strādāt nākamajā sekundē, bieži ar tukšu lapu vai kļūdas paziņojumu. Pārejot uz nākamo lielo laidienu, PHP apzināti izņem funkcijas, kas ilgus gadus bija novecojušas. PHP 7.0 izņēma veco mysql paplašinājumu, uz kura balstījās daudzas vecākas vietnes, bet PHP 8.0 savā nesaderīgo izmaiņu sarakstā cita starpā izņēma funkcijas each() un create_function(), kuras vecākā kodā ir sastopamas joprojām.

Node.js pasaulē klasisks piemērs ir 17. līnija, kurā izpildvide pārgāja uz OpenSSL 3.0. Laidiena paziņojumā Node.js brīdināja, ka lietotne, kura pati vai kuras moduļi lieto algoritmu vai atslēgas garumu, ko OpenSSL 3.0 pēc noklusējuma vairs neatļauj, saņems kļūdu ERR_OSSL_EVP_UNSUPPORTED, un kā pagaidu risinājumu piedāvāja palaišanas parametru --openssl-legacy-provider. Kļūdu nereti izraisīja nevis projekta paša kods, bet kāda no tā atkarībām, tāpēc to nācās labot kodā, ko projekta komanda pati nemaz nebija rakstījusi.

Tāpēc pāreja ir izstrādes darbs, nevis iestatījums. Kods ir jāpārbauda pret jauno izpildvidi, novecojušās funkcijas jāaizstāj, atkarības jāatjaunina līdz laidieniem, kas to atbalsta, un viss jāizmēģina testa vidē, pirms to ierauga klienti. Nelielai vietnei uz uzturētas platformas tas var būt dažu stundu darbs, bet sistēmai, kuras ietvaram atbalsts ir beidzies pirms vairākiem gadiem, pāreja nereti nozīmē arī ietvara nomaiņu, un tad tas jau ir projekts ar savu budžetu un grafiku, nevis uzdevums, ko var paveikt starp citiem darbiem.

Trīs ceļi: atjaunināt, pārbūvēt vai turēt aizsargātu

Ceļu nosaka divas lietas: cik tālu kods ir atpalicis no atbalstītas versijas un cik ilgi vietnei vēl ir jākalpo. Ja vietni pēc gada tik un tā plānots aizstāt ar jaunu, lielu pāreju vecajā kodā veikt nav vērts, bet, ja tā ir uzņēmuma ikdienas darba rīks, ko izmantos vēl vismaz piecus gadus, pagaidu risinājums tikai atliek neizbēgamo un padara to dārgāku. Tabulā ir trīs ceļi, kas reāli ir pieejami, un tas, ko katrs no tiem atrisina un ko ne.

Atjaunināšana ir pareizā izvēle, ja vietne balstās uz uzturētu platformu, piemēram, WordPress vai Laravel, un no atbalstīta atzara to šķir viens vai divi lieli soļi. Tad darbs ir paredzams: jāatjaunina ietvars un spraudņi, jāizlabo tas, ko pārbaudes rīki atrod, un jāpārslēdz PHP. Pārbūve ir godīgākais ceļš, ja pats ietvars ir bez atbalsta, ja vietne ir rakstīta uz PHP 5.x bez jebkāda ietvara vai ja kodu neviens vairs nesaprot, jo tad atjaunināšanas izmaksas ātri pietuvojas jaunas vietnes izmaksām, bet rezultāts joprojām ir vecs kods.

Trešais ceļš tiek apspriests retāk. Vecu vietni var turēt platformā, kas tās izpildvidei joprojām pārnes drošības labojumus, izolē to no citām vietnēm un bloķē zināmus uzbrukuma paraugus vēl pirms labojuma. Tas nav aizstājējs pārejai, un pats Node.js šādu atbalstu sauc par pagaidu risinājumu, taču tas ir godīgs veids, kā iegūt laiku: pāreju var veikt plānotā tempā, nevis nedēļā pēc kārtējā drošības paziņojuma. Svarīgākais vārds šeit ir «termiņš», jo bez tā pagaidu risinājums kļūst par pastāvīgu.

Kas ir pārnests drošības labojums un kāpēc versijas numurs par to neko nepasaka

Pārnests labojums nozīmē, ka drošības labojumu, kas izstrādāts jaunākam laidienam, kāds pielāgo un iebūvē vecākā laidienā, ko lietotājs jau izmanto. Red Hat, kas šādi uztur savas Linux distribūcijas pakotnes, raksta, ka tikai pēc versijas numura klients nevar spriest, vai viņa sistēma ir ievainojama, jo labojums maina pakotni, bet ne versijas numuru. Tieši tāpēc ievainojamību skeneri, kas skatās tikai uz numuru, šādās sistēmās mēdz kļūdaini ziņot par problēmām, kuras jau ir novērstas.

PHP un Node.js gadījumā to dara vairāki piegādātāji. Linux distribūcijas pārnes labojumus savām PHP un Node.js pakotnēm visu distribūcijas atbalsta laiku. CloudLinux savām alt-php pakotnēm, kuras hostinga serveri ar CloudLinux izmanto, labojumus pārnes arī atzariem, kuriem PHP atbalsts sen beidzies: PHP2Shell gadījumā tā statusa lapa 21. oktobrī paziņoja, ka gatavo labotas pakotnes visiem alt-php atzariem no 5.2 līdz 8.5, un nākamās nakts laikā tās bija pieejamas. Šīs pakotnes tagad ir daļa no uzņēmuma TuxCare paplašinātā atbalsta, kura noteikumos kā mērķis augstas un kritiskas bīstamības ievainojamībām ir minēts labojums 14 dienu laikā pēc publiskošanas.

Node.js līnijām bez atbalsta tādu pašu pakalpojumu piedāvā komerciāli partneri, kurus Node.js pats nosauc savā atbalsta beigu lapā: HeroDevs, NodeSource un TuxCare. Node.js gan uzreiz piebilst, ka šāds atbalsts ir uzskatāms par pagaidu risinājumu un mērķim vienmēr jābūt pārejai uz atbalstītu versiju. CloudLinux 2026. gada oktobra Node.js laidiena laikā pārnesa labojumus arī savām 16., 18. un 20. līnijas pakotnēm, kuras hostinga klienti izvēlas cPanel sadaļā Setup Node.js App.

Pārbaudīt to pēc versijas numura nevar. Komanda php -v vai node -v pēc pārnesta labojuma rāda tieši to pašu, ko pirms tā, un CloudLinux savā Node.js paziņojumā to raksta atklāti: līnijām bez atbalsta numurs pēc atjaunināšanas nemainās. Mainās pakotnes laidiena numurs, kuru redz tikai servera administrators, tāpēc koplietošanas hostingā atbildi var dot vienīgi hostinga sniedzējs.

Robeža ir jāpasaka tikpat skaidri. Pārnests labojums aizsargā pašu PHP vai Node.js, bet neaizsargā WordPress spraudni, kura autors to pārstāja atjaunināt, pašu rakstītu kodu ar SQL injekciju vai npm pakotni, kuras jaunākie laidieni vecu Node.js vairs neatbalsta. Turklāt piegādātāji labojumus pārnes katrai līnijai atsevišķi, tāpēc katrai konkrētajai ir jāpārbauda, vai tā vispār ir sarakstā, un TuxCare savos noteikumos patur tiesības labojuma vietā piedāvāt risku mazinošu pasākumu.

Kad veca ir nevis izpildvide, bet pati platforma

Dažkārt problēma nav izpildvidē, bet pašā platformā, uz kuras vietne uzbūvēta, un tad pārnesti PHP labojumi palīdz tikai daļēji. Labākais piemērs ir Drupal 7: tā drošības atbalsts beidzās 2025. gada 5. janvārī, un kopš tā laika pats Drupal projekts tam vairs neizlaiž ne drošības, ne saderības atjauninājumus. Vietne uz Drupal 7 var strādāt uz pilnībā salabota PHP, bet tās kodols, moduļi un tēma tik un tā paliek ar visām ievainojamībām, kuras tajos vēl tiks atrastas, jo bez maksas tās vairs neviens nelabo.

Arī šeit ir pieejams maksas pagaidu risinājums: Drupal asociācija ir izveidojusi paplašinātā drošības atbalsta programmu, kurā maksas atbalstu piedāvā pārbaudīti piegādātāji, piemēram, HeroDevs un Tag1 Consulting. Tas ir tas pats princips, kas pārnestiem PHP labojumiem, tikai vienu slāni augstāk, un tam ir tie paši ierobežojumi: tas atliek pāreju, bet to neatrisina, un katrs gads uz vecas platformas padara pāreju dārgāku, jo pieaug attālums līdz pašreizējam laidienam un sarūk to izstrādātāju skaits, kuri veco platformu vēl pārzina.

Tāpēc pirms jebkāda lēmuma ir vērts pārbaudīt visus slāņus, nevis tikai PHP: izpildvidi, platformu vai ietvaru, spraudņus vai moduļus un pašu rakstīto kodu. Ja novecojis ir tikai PHP, bet WordPress, Laravel vai cita platforma ir uzturēta, pāreja parasti ir paredzams darbs. Ja veca ir pati platforma, jautājums vairs nav par PHP atzaru, bet par to, vai vietni pārcelt uz platformas jauno laidienu vai uzbūvēt no jauna, un tieši šajā vietā pārnestu labojumu uzdevums ir dot laiku pieņemt šo lēmumu bez steigas.

Kā vecu PHP un Node.js turam mūsu serverī

Mūsu pārvaldītais hostings ir vieta mūsu pašu serverī, kas strādā uz CloudLinux, un katrai vietnei PHP versiju izvēlas atsevišķi hostinga panelī. Šobrīd tajā ir pieejams PHP no 5.4 līdz 8.4, bet Node.js lietotnēm gan atbalstītās 22. un 24. līnijas, gan vecās 16., 18. un 20. līnijas. Tas nozīmē, ka vecu vietni pie mums var pārcelt ar to pašu PHP vai Node.js, ar kuru tā strādā tagad, un vispirms to nostabilizēt, nevis pārcelšanas dienā vienlaikus mainīt arī kodu, kas ir drošākais veids, kā pārcelšanas laikā neko nesalauzt.

Kā tas darbojas praksē, 2026. gada oktobrī varējām izmērīt paši. PHP2Shell labojumi iznāca 21. oktobra pēcpusdienā, un mūsu serverī visi vecie PHP atzari no 5.4 līdz 8.1 tagad strādā ar pakotnēm, ko CloudLinux pārbūvēja tās pašas dienas naktī, mazāk nekā diennakti pēc PHP laidiena, un kurās labojums ir pārnests. Atzari no 8.2 līdz 8.4 pārgāja uz oficiālajiem labotajiem laidieniem 8.2.35, 8.3.36 un 8.4.27, bet Node.js 16., 18. un 20. līnija 22. oktobrī saņēma CloudLinux pakotnes ar pārnestiem labojumiem, lai gan pats Node.js projekts tām labojumus neizlaida. Vecajiem atzariem numurs nemainījās, tāpēc to pārbaudījām nevis pēc numura, bet pēc tā, kad izpildāmie faili tika pārbūvēti.

Tas nav viss, ko platforma dara. CloudLinux ievieto katru hostinga kontu atsevišķā izolētā vidē, ko sauc par CageFS, un tajā lietotāji neredz citus servera lietotājus un pat viņu lietotājvārdus, kas apgrūtina uzlaušanas izplatīšanos no viena konta uz citiem. Imunify360 tīmekļa lietojumprogrammu ugunsmūris PHP2Shell gadījumā sāka bloķēt zināmos uzbrukuma paraugus 21. oktobrī, vairākas stundas pirms labotā PHP publicēšanas. Neviens no šiem slāņiem nepadara vecu vietni neievainojamu, taču kopā tie sašaurina laiku, kurā zināma ievainojamība ir izmantojama, un ierobežo, cik tālu uzlaušanas sekas var sniegties.

Tāpēc vecas vietnes pārcelšanu pie mums iesakām uztvert kā pagaidu risinājumu ar termiņu, nevis galamērķi. Vietni pārceļam ar to pašu izpildvidi, pārbaudām, ka viss strādā tāpat kā iepriekš, un pēc tam kopā ar Jums vienojamies, līdz kuram datumam un kādā secībā tā pāriet uz atbalstītu versiju, lai pagaidu risinājums nekļūtu par pastāvīgu. Mūsu pārvaldītais hostings sākas no €45 mēnesī, un uzturētas izpildvides, kontu izolācija un ugunsmūris ir daļa no tā, par ko šajā summā maksā. Ja Jums ir vietne ar vecu PHP vai Node.js versiju, atsūtiet mums tās adresi, un mēs pateiksim, kurš no trim ceļiem tai der un ar ko sākt.

Kā uzzināt, kura PHP vai Node.js versija ir Jūsu vietnei

Ātrākais ceļš ir hostinga panelis. cPanel hostingā ar CloudLinux sadaļa Select PHP Version rāda versiju, kas izvēlēta visam kontam, bet MultiPHP Manager rāda versiju katram domēnam atsevišķi, un, ja domēnam tur ir norādīta sava versija, noteicošā ir tā. Node.js lietotnēm to pašu rāda sadaļa Setup Node.js App, kur katrai lietotnei ir sava rinda. Skatīties ir vērts uz katru vietni, nevis tikai uz galveno, jo vienā kontā mēdz būt vairākas vietnes ar dažādiem PHP atzariem, un aizmirsta testa kopija vai sena kampaņas lapa nereti joprojām ir sasniedzama no interneta.

WordPress vietnē to var redzēt arī administrācijas panelī: sadaļā Tools → Site Health, cilnē Info, blokā Server ir norādīta PHP versija, uz kuras vietne strādā. Ja paneļa nav, var izveidot failu ar funkciju phpinfo() un atvērt to pārlūkā, taču pēc tam fails noteikti jāizdzēš, jo tas ikvienam apmeklētājam parāda servera konfigurāciju. Komanda php -v šeit palīdz mazāk, nekā šķiet, jo tā rāda komandrindas PHP, bet tīmekļa pieprasījumus bieži apkalpo cits atzars, kas izvēlēts hostinga panelī. Node.js projektā vēlamo līniju bieži norāda package.json lauks engines vai fails .nvmrc, bet tā ir tikai vēlme, un kurš Node.js lietotni patiešām darbina, jāskatās tur, kur process tiek palaists.

Ja piekļuves nav vispār, jautājums jāuzdod hostinga sniedzējam vai izstrādātājam, kurš vietni uztur. Formulējums, kas ietaupa saraksti: «Kura PHP vai Node.js versija apkalpo mūsu vietni? Ja tai atbalsts ir beidzies, vai tā saņem pārnestus drošības labojumus, no kā tie nāk un kad pakotne pēdējo reizi tika atjaunināta? Līdz kuram datumam Jūs iesakāt pāreju?» Atbilde uz pēdējo jautājumu daudz pastāsta arī par pašu sniedzēju, jo, ja datuma nav, parasti nav arī plāna.

Pāreja uz atbalstītu versiju: kā to izdarīt bez pārsteigumiem

Pāreja sākas ar inventarizāciju, nevis ar pārslēgšanu. Jāpieraksta, kurš PHP atzars un kuri paplašinājumi vietnei ir vajadzīgi, kādi plānotie uzdevumi to darbina fonā, ar kādām ārējām sistēmām tā sazinās un kuras tās daļas ir kritiskas biznesam, piemēram, pasūtījumu forma, maksājumi vai rēķinu sūtīšana. Mērķa versiju ir vērts izvēlēties ar rezervi: PHP 8.4 drošības labojumus saņems līdz 2028. gada 31. decembrim, PHP 8.3 līdz 2027. gada beigām, bet pāreja uz PHP 8.2, kuras atbalsts beidzas jau 2026. gada beigās, nozīmētu vēl vienu pāreju pavisam drīz. Node.js gadījumā mērķis vairumā gadījumu ir 24. līnija.

Otrais solis ir koda pārbaude, un PHP kodam to var lielā mērā automatizēt. PHPCompatibility ir PHP_CodeSniffer noteikumu kopa, kas pārbauda, vai kods ir saderīgs ar konkrētu PHP versiju, bet Rector daļu nepieciešamo izmaiņu var veikt automātiski. Neviens no tiem neaizstāj cilvēka pārbaudi, taču tie ātri parāda, vai darba apjoms ir mērāms stundās vai nedēļās, un tieši tas ir vajadzīgs, lai izlemtu starp atjaunināšanu un pārbūvi. WordPress vietnei vispirms jāatjaunina spraudņi un tēma, un tikai pēc tam jāpārslēdz PHP.

Trešais solis ir testa vide, proti, vietnes kopija ar jauno PHP vai Node.js, kurā tiek izmēģinātas visas kritiskās darbības: formas, maksājumi, e-pasta sūtīšana, imports un eksports. Kļūdu žurnāls šajā posmā ir svarīgāks par vizuālo pārbaudi, jo brīdinājumi par novecojušām funkcijām tur parādās ilgi pirms tam, kad kaut kas apstājas. Ceturtais solis ir pārslēgšana mazas noslodzes laikā ar iespēju atgriezties: hostingā ar versiju izvēli atpakaļceļš ir tas pats viens klikšķis, ar kuru tā tika pārslēgta, tāpēc risks ir mazs, ja vien dublējumkopija ir svaiga un kāds pirmo nedēļu seko kļūdu žurnālam.

Node.js lietotnei loģika ir tā pati, tikai rīki ir citi. Pāreju starp lielajām līnijām ir vērts veikt pa vienai, pēc katras palaižot lietotnes testus, un īpaša uzmanība jāpievērš pakotnēm ar kompilētu kodu, jo tās tiek būvētas konkrētai Node.js līnijai un pēc pārejas ir jāpārbūvē. Vispirms jāatjaunina atkarības, kas jauno līniju vēl neatbalsta, un tikai pēc tam jāmaina pati izpildvide, citādi kļūdas no abām pusēm sajaucas un ir grūti saprast, kura no tām ko izraisīja.