En vaan kerta kaikkiaan meinaa keksiä mitään syytä, että
miksi include tai require_once kaataa sovelluksen siten,
että tilalle tulee joku iframe systeemi(Mistähän lie repästy sekin, koko sovelluksessani en käytä IFrameja) ja IFramen sisällä on joku sovellukseni tekemä error-viesti.
Kaikki toimii ok localhostissa, mutta palvelimella hommat ei enää toimi. Ongelmat kuitenkin näyttäisi poistuvan, jos poistan kaikki itse käyttämäni require_once rivit. Toisaalta (Yii) Framework varmasti käyttää kyseisiä funktioita, että tällä kertaa olen taas ihan pihalla, että mistä ongelma voisi johtua?
Tässä osoite:
http://www.ustedvende.com/plazagrande/site/
Jotta ongelman saisi toistettua, pitää kirjautua ensin sisään: kille/kille.
Nämä ovat rivit, jotka kaataa ohjelman:
Tiedosto yksi random tiedosto /protected/components/MainStorage.php
public function texts($subject, $variation)
{
require_once("test.php");
/*
die();
$texts = new PTexts(); //creating new texts object.
$texts->init($subject, $variation); //inserting the texts.
return $texts; //return texts object
*/
}/protected/components/test.php
<?php //echo "Hilliputti"; ?>
Onko oikeat chmodit asetettu include tiedostoille, poluissakin vois olla jotain häikkää, mut jos localhostissa toimii niin sitten varmaan ei.
Olet nyt testaillu suuntaan ja toiseen ja näyttäisi, että tuossa polku jutussa tulee niitä ongelmia ja polusta aiheutuva lopputulos on aina vähän randomi.
Onks noissa polkujutuissa jotain vuoren varmaa taktiikka, että miten ne tulisi oikeaoppisesti asettaa:
Nyt esimerkiksi seuraavakoodi pätkä toimii locallissta, mutta ei palvelimella:
var_dump(dirname(__FILE__)."/PTexts.php"); require_once(dirname(__FILE__)."/PTexts.php");
Ja näytöllä tulee:
string(71) "/home2/verkkbpv/public_html/plazagrande/
Joka on tiedoston oikea polku.
Ja näyttäisi, että kaikki ennen kyseistä require_once koodiriviä tuotettu html tulostuu näytölle ja sen jälkeinen ei tulostu.
Ja suuret kiitokset ideoista!
Laita palvelimella varoitukset ja virheilmoitukset käyttöön (vähintäänkin lokitiedostoon) ja lue ne, niin varmaan ongelman syy selviää.
Joo, oot oikeassa Metabolix, niin kuin yleensä!
Mulla oli nämä käytössä(Metabolixin aiemmasta kehoituksesta):
error_reporting(E_ALL);
ini_set('error_reporting', E_ALL);Mutta itse virheilmoitus löytyi cpanelin lokitiedoistoista:
[Tue Mar 06 15:33:34 2012] [error] [client 193.167.107.251] client denied by server configuration: /home2/verkkbpv/public_html/protected/components/ [Tue Mar 06 15:33:29 2012] [error] [client 193.167.107.251] client denied by server configuration: /home2/verkkbpv/public_html/protected/components/ [Tue Mar 06 15:33:25 2012] [error] [client 193.167.107.251] client denied by server configuration: /home2/verkkbpv/public_html/protected/components/MainStorage.php [Tue Mar 06 15:32:10 2012] [error] [client 193.167.107.251] client denied by server configuration: /home2/verkkbpv/public_html/protected/components/MainStorage.php
Eli ilmeisesti serveriä ei kiinnostanut antaa lupia tuolle require_once komennolle, vaikka tosin palvelin chmod asetuksia olen kokeillut suuntaan ja toiseen.
Täytyy varmaan heittää viestiä serverin ylläpitäjälle, että mistäköhän tämmöiset configuraatiot on peräisin.
Nuo PHP-rivisi ovat väärin (teet saman asian kaksi kertaa), etsipä jokin niistä vanhoista viesteistäni muistin virkistämiseksi. Pitäisi laittaa display_errors päälle.
Noilla ilmoituksilla ei näytä olevan mitään tekemistä ongelmasi kanssa. Tuskin edes ovat omien sivunlataustesi aiheuttamia.
Oli niillä jotain tekemistä, mutta eivät ilmeisesti kuitenkaan pääsyy.
No nyt sain vihdoin selvitettyä, kerrottakoon muillekin itseni kaltaisille hönöille opetukseksi, jos jostain syystä muita sellaisia sattuis olemaan :D
Eli ensinnäkin tuolla protected kansiossa oli .htaccess joka
sanoo: deny from all, eli niihin oli pääsy kielletty niihin tiedostoihin, eikä niitä sen takia myöskään voitu ladata. Tiesin tiedoston olemassa olon mutta jostain syystä tässä vaiheessa se ei tullut mieleenkään.
Seuraavaksi tosiaan kaikkissa tarpeellisissa tiedostoissa ei ollut kuitenkaan asetukset 0755, mikä oli Synomin veikkaus, olin laittanut vain osaan.
Kolmanneksi, joissakin noissa tiedostoista piilomerkkeinä toimivat rivinvälimerkit (Notepad++ näyttää LF ja CF) oli sellaisessa muodossa(MAC), että palvelimen PHP(UNIX) ei osannut tulkita niitä oikein, esim;
<php
echo "testi";
?>
<!--
olikin palvelimella näin:
<?phpecho "testi";?>
-->Sitten tuolta serveriltä löytyi varmaankin tuon Apachen tai jonkin muun ansiosta, niin jokin error_log tiedosto jonka avulta lopulta sain selville noin rivien loppumerkki syyn, kiitos Metabolixin error lokeihin kannustamisesta. Ilmeisesti jos olisin tajunnut laittaa tuon display errorsin päälle, niin olis varmaan tullut ne logi merkinnät suoraan näytölle tai jotain ja ongelma olisi ratkennut myös monta kertaa nopeammin.
Aikaa näiden kolmen ongelman ratkaisuun meni multa n. 6 tuntia :D että näinkin sen työpäivän voi käyttää.
Paulus M kirjoitti:
.htaccess ... deny from all, eli niihin oli pääsy kielletty niihin tiedostoihin, eikä niitä sen takia myöskään voitu ladata.
Tällä ei ole vaikutusta PHP:n toimintaan. Include ei lataa tiedostoja HTTP-palvelimelta vaan avaa ne suoraan levyltä (ellet käytä includessa http://-alkuista osoitetta, mitä toki on lähes aina väärin ja vaarallista).
Okei, kiitti tiedosta! Se oli varmaan sitten toi 0755 ja sitten noi rivienloppumerkit mitkä oli pielessä.
Mac OS X:ssä rivinvaihto on ihan "standardi Unix-rivinvaihto" eli \n. PHP osaa kyllä ihan varmasti käsitellä myös \r\n:n ja pelkän \r:nkin. Minusta kuulostaa nyt vähän siltä, että vielä kuuden tunninkaan jälkeen sinulla ei ole käsitystä siitä, mikä ongelma oli tai miten se ratkesi...
CRLF eli \r\n on muuten Windows-rivinvaihto.
Ei kyllä mä varmaan vihdoin tällä kertaa olen osunut oikeaan, koska vielä löytyy noita pelkän CR omavia filejä sovelluksestani ja Notepad++ näyttää, että se olisi MAC merkintä. Ne vaihdan Windows tai UNIX merkintään, niin toimii ja parse error messaget katoaa kyseisistä fileistä, koska silloin tulee joko LF tai CRLF.
Se voi olla Notepad++ bugi, mutta tässä se kuitenkin johtui, täällä todistus sanoilleni:
lainaus:
One area that notepad++ does not handle well is mixed-format files. For example, a file has mostly Windows CRLF at the end of each line. One line is terminated with a CR. That orphan CR will not be obvious. notepad++ will report it as a Windows CRLF file. Oddly, the default keyboard shortcuts include Ctrl-M to terminate a line with a single CR (Mac format) but not Ctrl-J to terminate a line with a single LF (Unix format).
Ja linkki SourceForgeen:
http://sourceforge.net/projects/notepad-plus/forums/forum/331754/topic/4892072
The Alchemist kirjoitti:
Mac OS X:ssä rivinvaihto on ihan "standardi Unix-rivinvaihto" eli \n.
Mutta Paulus puhuikin Mac-rivinvaihdosta eli \r:stä. (ennen OSX)
Aihe on jo aika vanha, joten et voi enää vastata siihen.