Võimalikud murekohad veebilehel peale cPanelile kolimist

Siinkohal üritan lahti kirjutada enamlevinud küsimused/murekohad, peale cPanelile kolimist.

1. PHP kellaaeg on vale/puudub / erineb MySQL’i kellaajast
2. Veebileht kuvab vana või vale sisu
3. Kasutades PHP7.2 versiooni, ei toimi PHP moodulid, kui on kasutusel eraldi php.ini fail
4. Varasemalt käitatud html faile php failidena, enam ei toimi
5. MySQL baasi ei ole võimalik täielikult importida/koduleht annab valge lehe või baasitabeli vea

1. PHP kellaaeg on vale/puudub / erineb MySQL’i kellaajast

Muude halduspaneelide all (kui cPanel) on reeglina vaikimisi määratud ära ka vaikimisi date.timezone määrang vastavalt selle serveri asukohale.
cPaneli all selline vaikimisi määrang puudub. cPaneli all annab PHP vaikimisi määranguks UTC.
Kui olete saanud PHP veateatena:

Warning: strtotime() [function.strtotime]: It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function.

Või teie rakendus annab vale kellaaja, tuleks see manuaalselt muuta kas:
1. cPaneli halduspaneeli kaudu SOFTWARE -> “MultiPHP INI Editor” alt vastavale domeenile, lisades sinna väärtuse:

date.timezone = Europe/Tallinn

2. Index, autoload, bootstrap või config PHP skriptis peale php tag’i:

ini_set('date.timezone', 'Europe/Tallinn');


K: “Miks te seda kohe ise serveril ära ei muuda selliselt, et oleks antud määrang vaikimisi?”
V: Kahel põhjusel. Kuna serverid kasutavad PHP mooduleid dünaamiliselt ehk siis on kliendil võimalik oma custom PHP ini failiga sätteid muuta, kaotaks antud meiepoolne muudatus koheselt mõju, kui lisatakse mõni PHP direktiiv/seade käsitsi. Kuna meil on rahvusvaheline klientuur on paljudel kasutusel eri määrangud vastava muutuja jaoks ja seega, kui viiksime vastava muudatuse sisse, kirjutaks see paljude jaoks vastava määrangu üle.

2. Veebileht kuvab vana või vale sisu

1. HTTPS korral – kas te ennem konto ületõstmist tõstsite private_html/www/… kausta alt failid public_html alla?
(cPanelil ei ole eraldi public_html ja private_html kaustu – kogu sisu serveeritakse ühtselt public_html alt)
2. “Valge leht”
– lülitage sisse MultiPHP INI editor alt error_reporting uuendage lehte ja kontollige vealogisi (kas halduspaneeli Errors alt või kodulehe juurkaustast failist error_log <- antud kohad peaksid ära näitama võimalikud murekohad, millega saab edasi tegeleda.)
– Kontrollige üle et PHP versioon on sobiv teie sisuhaldusele (vanemad Joomla jms. sisuhaldused toimivad eranditult ainult PHP 5.3’ga.)
3. 503 veateade veebilehel – kui ennem ülekolimist leht toimis kuid peale ülekolimist annab 503 veateate, tähendab see kas ressursipiirangut või probleeme PHP versiooniga. Muutke MultiPHP alt ära php versioon, lülitage sisse error_reporting ja kontrollige error_log faili domeeni juurkaustast.

3. Kasutades PHP7.2 versiooni, ei toimi PHP moodulid, kui on kasutusel eraldi php.ini fail

Antud murekoht võib tuleneda tarkvaralisest “featuurist”, kus PHP7.2 ei toimi korrektselt kasutajapoolse php.ini failis olevate sätetega.
Antud murekohast oleme teadlikud ja oleme teinud juba ka eraldi tugirequesti CloudLinux arendajatele (hetkel ootame nendepoolset lahendust).
Kui teie sisuhaldus ei kuva veateateid ja veebileht ei toimi korrektselt, kuid teil on kasutusel PHP versioon 7.2 ja domeenikaustas on näha php.ini ja .user.ini failid, tuleks testida järgnevaid lahendusi:
1. Võtta kasutusele mõni teine PHP versioon – Varasematel versioonidel toimib PHP korrektselt ka kasutajapoolse php.ini sätetefailiga (Näiteks PHP7.1)
2. Eemaldada sätetefailid ja lisada muutujad .htaccess faili – tuleks eemaldada php.ini ja .user.ini failid domeeni juurkaustast ja .htaccess failis eemaldada read:

<IfModule php7_module>
</IfModule>

Peale seda peaks hakkama toimima veebileht korrektselt ka PHP7.2 versioonis koos korrektsete moodulitega ning kasutades .htaccess failis märgitud sätteid.

NB! Peale sellist muudatust ei tohiks uusi sätteid enam PHPini Editor alt salvestada/muuta antud domeenil – vastasel juhul kirjutatakse uuesti lokaalsed sätetefailid ning veebileht jälle ei toimi.

4. Varasemalt käitatud html faile php failidena, enam ei toimi

NB! HTML ega muid failitüüpe ei ole soovitatav käitada PHP scriptidena, kuna need võivad Teie veebilehel põhjustada turvariski!
Antud koodi kasutamine on eranditult ainult Teie enda vastutusel!

Et käivitada muid kui PHP faile PHP kaudu, peaks .htaccess failis olema read (kus on siis määratud ka vastav faililaiend):

AddType application/x-httpd-ea-php56___lsphp .shtml .shtm .htm .html
AddHandler application/x-httpd-ea-php56___lsphp .php .html .htm

Kus php56 tuleks asendada siis Teie veebis kasutusel oleva php versiooniga (näitena php53 – php 5.3 korral jne.)

5. MySQL baasi ei ole võimalik täielikult importida/koduleht annab valge lehe või baasitabeli vea

(Oleme näinud seda murekohta näiteks vananenud AxiCMS korral)
Kui teil baasitabelid kasutavad enum väärtuste korral charsetti ascii ja db COLLATE väärtust ascii_bin ning default väärtus on ” või NULL, siis annab uuem andmebaasimootor ka sellekohase vea. Murekoht seisneb selles, et enum väljatüübi korral ei saa default väärtus selliselt olla ” või NULL.
Kõige lihtsam lahendus oleks asendada väärtused:
ascii => utf8
ascii_bin => utf8_general_ci

Midagi sellest asendusest katki ei lähe, küll aga tagate oma sisuhalduse tõrgeteta töö ja varundamise/taaste!

Comments are currently closed.