Sivusto palvelimelta toiselle siirron jälkeen blankko

Sivusto on Neobitin webhotellissa. Se siirrettiin palvelimelta toiselle koska vanhalle palvelimelle ei vieläkään ollut PHP:n päivityspäivää tiedossa (5.2 -> 5.3). DNS-tietojen päivittyminen kesti vuorokauden eivätkä sivut senkään jälkeen toimi. Sekä julkinen että ylläpitoliittymä antavat vain tyhjän valkoisen sivun ilman merkkiäkään edes sivun lähdekoodissa. Minkäänlaisia virheilmoituksiakaan en saa sivuista irti millään. Olen cPanelin kautta pyrkinyt tonkimaan ongelmaa ja etsimään ratkaisua. Mielenkiintoista on, että alla oleva FPA-tieto on ajettu palvelimelta onnistuneesti. Olen myös

• palauttanut Joomlan oletus htaccess-tiedoston käyttöön ja poistanut sen kokonaan
• poistanut SEFin käytöstä
• poistanut Admin Toolsin käytöstä
• muuttanut tietokantayhteyden käyttämään mysql:ää mysqli:n sijaan
• muuttanut tietokantataulujen moottorin MyISAMista InnoDB:ksi
• varmistanut että tietokanta on paikoillaan ja kunnossa
• varmistanut että tietokantayhteys on oikein määritelty configuration.php:ssä
• varmistanut että cookie-asetuksissa ei ole mitään eikä live_site-asetusta ole configuration.php:ssä
• varmistanut että palvelin täyttää Joomla 2.5:n minimivaatimukset
• varmistanut että palvelin täyttää JEventsin, Admin Toolsin, Akeeba Backupin ja Kunenan vaatimukset, joista viimeiden GD, DOM ja JSON eivät täyty
• etsinyt vastausta Joomla.orgin foorumilta
• etsinyt spesifistä tietoa Joomla 2.5:n yhteensopivuudesta MySQL 5.5 version kanssa (FPA väittää ettei palvelin tue Joomla 2.5:tä)
• tarkastanut error_login ja access_login; ensimmäisessä ei ole mitään, jälkimmäinen väittää http-pyyntöihin vastatun onnistuneesti (200)
• varmistanut että virheiden raportointi on päällä ja php-asetus riittävän verbaalinen ja asettanut debugin configuration.php:ssä päälle

Neobitti tonkii asiaa samalla ja on nyt näköjään palauttanut tiedostot hakemistoon uudelleen. Nyt alkaa keinot loppua. APUA!

Joomlassa on bugi, joka aiheuttaa juuri tuollaisen valkoisen sivun, mikäli log-hakemistoon ei pysty kirjoittamaan. Bugiin löytyy jo korjauskin...

Nimimerkillä käyttänyt myös tunnin tai pari ihmetellessä, miksei se jo toimi!

Kiitos, Matias, en nopealla Googlauksella löytänyt korjausta tai bugiraporttia, olisko linkkiä?

P.S. Minusta itseasiassa näyttää siltä, että logs-hakemisto on kirjoitettavissa (755), joten päteekö tämä minun tapaukseeni?

Entäpä omistaja? Logit kirjoitetaan aina apachen käyttäjällä, eli sillä pitäisi olla kirjoitusoikeudet hakemistoon ja sen tiedostoihin.

Pienen etsinnän jälkeen löysin bugin, joka koski ainakin minua:
github.com/joomla/joomla-cms/pull/1174

Jos ongelma ei ratkea tuolla, kannattaa alihakemistoon luoda uusi joomla-asennus ja katsoa miten se toimii. Sen jälkeen on melko helppo vertailla mikä on samaa ja mikä ei.

Matias kirjoitti: Entäpä omistaja? Logit kirjoitetaan aina apachen käyttäjällä, eli sillä pitäisi olla kirjoitusoikeudet hakemistoon ja sen tiedostoihin.

Tässä tapauksessa PHP:tä ajetaan CGI:nä, joten lokien kirjoitus tapahtuu tilin käyttäjätunnuksella.

Toimiiko sivusto vaikkapa WAMPISSA? Miten laitoit virheenilmoituksen päälle? Eli jos laitoit sen päälle vaikkapa configuration.phpssä voi olla että tiedostoa ei lueta koska (esimerkiksi) jollain edeltävällä rivillä on tarpeeksi paha syntax error.

Tyhmiä kysymyksiä, mutta tiedän kokemuksesta kuinka "tyhmien kysely" aiheuttaa joskus sellaisen nolottavan "Ai niin" efektin joka ei välttämättä liity kysymyksiin mitenkään.

En pysty nyt kehitysympäristöä pystyttämään, pöytäkoneeni kiintolevy on hajoamassa ja se on poissa pelistä.

Kaikki toimenpiteet on pakko tehdä cPanelin tiedostohallinnan tai SSH-yhteyden kautta, sillä tilanne on muuttumaton: Joomlan kumpikin käyttöliittymä on puhtaan valkoinen. Niinpä virheiden raportointi on laitettu configuration.php:n arvoa muuttamalla päälle. Silmämääräisesti tiedosto näyttää virheettömältä. PHP:n virheiden raportointiasetukset ovat olleet alunperinkin E_ALL ja päällä.

Matiaksen ehdottamaan alihakemistoon uudelleen asennusta kokeilin. Tiedostojen purkaminen menee Kickstartilla ihan putkeen mutta kun tullaan DB restore -vaiheeseen:
"Your session write path and the installation directory are not writable. One of them must be writable for the installation to continue."
Jos yritän tästä huolimatta tietokannan palautusta luomaani uuteen tietokantaan se epäonnistuu herjalla:
"No database definitions were found or no database was selected."
Näyttää siis siltä että vika olisi todella käyttöoikeuksissa/omistajuuksissa.

Toisaalta: kävi ilmi että GD, DOM ja JSON tuet on palvelimella. Ne näkyvät phpinfossa mutta eivät FPA:ssa. Jotain kummallista tässä ympäristössä on.

Akeeban dokumentaatiosta kirjoitti: Akeeba Backup Installer reports that the session write path and the installation directory is unreadable

This problem means that ABI can not start a session to store the information you provide to it between each step of the restoration process. There are many possibilities to solve it. Please note that ABI (Akeeba Backup Installer) runs after Kickstart, albeit some people confuse the two of them.

First, try clicking on Next. If this works, you don't have to worry about it. Sometimes the hosts report false information about the PHP session save path which causes ABI to mistakenly report an error. If, however, you get a message "No database definitions were found or no database was selected", you have to follow the next steps to solve this issue.

Your first approach should be asking your host to fix the PHP session save path to something which is writable by your hosting account. This is a very common misconfiguration issue on Plesk-based hosts. If your host can't fix it, they might be able to give you instructions for creating a .htaccess to override the PHP session save path. No matter which solution they provide, you don't have to run Kickstart again or upload the extracted files again; you can access ABI again by visiting www.yoursite.com/installation/index.php where www.yoursite.com is the domain name you are restoring to.

Another solution is to change the permissions of the installation directory after Kickstart has extracted your archive (just right before you click the Run the Installer button) or after you have uploaded the extracted files if you're not using Kickstart. In both cases, try using your FTP client to change the permissions of the installation directory (but NOT its contents!) in your site's root to 0777. Then, click on the Run the Installer button in Kickstart or access ABI again. If, after doing that, you get a blank page when trying to access ABI, try changing the permissions of the installation directory to 0775. If that still results in a blank page, you have to follow the previous paragraph's suggestion.

If both of these solutions don't work out for you, you will unfortunately have to go through the scenic route, i.e. perform a manual restoration. The complete instructions are described in the "Unorthodox: the emergency restoration procedure" section of our User's Guide. Our suggestion: it's best to switch to a different host. There is a strong possibility that Joomla! might not work properly unless you have a working PHP session storage.

Kaveri yleensä tietää mistä puhuu...

Tämä näyttää omituiselta:
kun käsittääkseni tuo uid: 1/gid: 1 on root.

Joo, olen myöskin vakuuttunut Nicholasin osaamisesta. Myös Arton osaamisen luotan. Jos se yhdistys Joomla.fi:n taustalle joskus syntyy, yksi tuote voisi olla rohkean hintaiset koulutuspäivät verkkoisännille Joomlasta...

Tuo Kickstarttaus alihakemistoon meni läpi kun asetti session.save_pathin htaccess-tiedostossa, mutta se asennus ei toimi yhtään paremmin kuin siirretty sivusto.

Tänään ei valitettavasti ole Neobitistä kuulunut mitään.

Piti hakea lohtunamisäkki, sen verran kyrsii.