| Autor | Zpráva | ||
|---|---|---|---|
| lokutus7323 Profil * |
#1 · Zasláno: 13. 3. 2015, 11:55:03
Dobrý den,
nejsem si jist, zdali jsem zařadil svůj dotaz správně. Vzhledem k tomu, že můj projekt je psaný v PHP, nicméně vůbec netuším, čím by mohl být způsoben, zkouším to zde. Mám evidenční systém v PHP, kam přištupuji já, kolegové a zákazníci. Poslední dobou se ovšem stává, že uživatelé přicházející přes Safari nebo Chrome vytvoří objednávku, dají uložit a naskočí jim stránka "Stránku se nepodařilo zobreazit". Nemyslím klasickou 404, ale spíše jako kdyby neměli připojení k internetu. Myslel jsem si, že zákazníci mohou mít nestabilní internet, nicméně stává se to i kolegovi, kterému se toto děje pouze v našem evidenčním systému, který logicky používá stejné internetové připojení jako já. Ve firefoxu se za poslední půlrok nic takového nestalo. Osobně mám podezření na jQuery nebo něco co prohlížeč přetíží. Eventuelně chyba ve vykreslování HTML5 (?). Podle mých zkušeností by se ani jedno z toho nemělo projevovat takto, ale třeba jste se někdo s něčím takovým setkal a vyřešil. Eventuelně je nějaký způsob jak řádně debugovat toto chování? Standardní konzole v Chrome nic zásadního nevypíše. PS: Určitě by asi do jisté míry pomohlo, kdyby si všichni lidé vymazali profil v prohlížeči, nicméně to svým zákazníkům asi nevysvětlím. Navíc jiné webové stránky problém nezpůsobují. Děkuji za rady |
||
| jefitto44 Profil |
#2 · Zasláno: 13. 3. 2015, 12:36:37
jQuery s tým určite nemá nič spoločné. Chrome vykresľuje HTML5 elementy už nejakú dobu... chyba môže byť na serveri (.htaccess?, alebo v PHP. Každopádne serveru je v podstate jedno, či na neho pristupuješ cez chrome, cez firefox, cez apple hodinky, alebo nebodaj cez IE. Skús pozrieť logy z PHP, možno tam bude niečo ako Out of memory... mne sa to teraz stáva, ale na localhoste. Keď prevediem sql query, vyhodí mi prázdnu stránku. Žiadna chyba, proste bielo. A problém je práve tam, že je to out of memory (Keďže ide o 50 000 riadkov).
|
||
| Fisir Profil |
#3 · Zasláno: 13. 3. 2015, 13:20:45
Reaguji na jeffita44:
Neblábol. Chyba je v Chromu, pokud by se pokazil PHP skript (a pak je nesmysl, aby fungoval v ostatních prohlížečích), viděl by jen prázdno, rozhodně ne hlášku prohlížeče, která se používá pouze v případě chyb ve vykreslování, spojení se serverem a takových věcí, které nemůže kodér ovlivnit. Reaguji na lokutuse7323: Používáš .htaccess? Jestli ano, pošli jeho obsah. Měníš nějak HTTP hlavičky (funkce header())? Jestli ano, pošli inkriminované kusy PHP kódu.
Dále by se hodila ukázka výsledného HTML, které v Chromu způsobí chybu, ale jinde funguje. |
||
| lokutus7323 Profil * |
#4 · Zasláno: 13. 3. 2015, 19:10:56
Ahoj,
děkuji za reakce. Chybu nezpůsobuje jedna určitá stránka, respektive né vždy, jednou to spadne, jindy se stejná akce ve chromu povede bez problému. Nejčastěji vše padá po uložení objednávky nebo úkolu. (jen pro informaci, jádro, které jsem napsal je hodně podobné vnitřní logikou a strukturováním jádru Prestashopu, pokud Vám to pomůže) Takže mám například PHP soubor pro práci s objednávkami: Existuje stránka s výpisem objednávek Kliknete na tlačítko upravit, proběhne přes <a> redirect na detail objednávky(totožný soubor, jiné GET parametry) Upravíte, kliknete na uložit, stránka se díky <form action="" refreshne a provede POST, PHP vše zpracuje a uloží. Poté se provede přes header() redirect na adresu výpisu objednávek s poděkováním... .htaccess soubor pro tuto subdoménu nevedu, používám pouze standardní .htaccess od WEDOSu pro hlavní doménu: (bez toho by mi na wedosu nefungovala subdoména jako taková)
<IfModule mod_rewrite.c>
# URL rewriting module activation
RewriteEngine on
# cele domeny (aliasy)
RewriteCond %{REQUEST_URI} !^domains/
RewriteCond %{REQUEST_URI} !^/domains/
RewriteCond %{HTTP_HOST} ^(www\.)?(.*)$
RewriteCond %{DOCUMENT_ROOT}/domains/%2 -d
RewriteRule (.*) domains/%2/$1 [DPI]
# subdomeny (s nebo bez www na zacatku)
RewriteCond %{REQUEST_URI} !^subdom/
RewriteCond %{REQUEST_URI} !^/subdom/
RewriteCond %{HTTP_HOST} ^(www\.)?(.*)\.([^\.]*)\.([^\.]*)$
RewriteCond %{DOCUMENT_ROOT}/subdom/%2 -d
RewriteRule (.*) subdom/%2/$1 [DPI]
# aliasy - spravne presmerovani pri chybejicim /
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^domains/[^/]+/(.+[^/])$ /$1/ [R]
# subdomeny - spravne presmerovani pri chybejicim /
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^subdom/[^/]+/(.+[^/])$ /$1/ [R]
RewriteBase /
RewriteRule ^kategorie/([0-9]+)\-([a-zA-Z0-9-]*) index.php?controller=category&id_category=$1 [QSA,L]
RewriteRule ^clanek/([0-9]+)\-([a-zA-Z0-9-]*) index.php?controller=clanek&id_clanek=$1 [QSA,L]
RewriteRule ^reference/([0-9]+) index.php?controller=reference&id_reference=$1 [QSA,L]
RewriteRule ^reference index.php?controller=reference [QSA,L]
RewriteRule ^([A-Za-z0-9-\_]+)/?$ index.php?controller=static&static_url=$1 [QSA,L]zde by tedy snad problém být neměl. Co se úprav HTTP hlavičem týče, zde je ukázka kódu jak je používám : }elseif(Tools::isSubmit("edit")){
if(!$o->update())
$this->_error=$o->getError();
if(!$this->_error){
$this->afterUpdate($o->id);
Tools::redirectController($this->helperForm->controller,((isset($this->helperForm->controller_attr)) ? $this->helperForm->controller_attr : "conf=2"));
}
};A zde třída Tools, metoda redirectController: public static function redirectController($controller_name=false,$args=false)
{
$url = Context::getContext()->link->getControllerLink($controller_name,$args);
header('Location: '.$url);
exit;
}a část kódu Context::getContext()->link->getControllerLink generuje absolutní URL.
|
||
| Davex Profil |
lokutus7323:
„Eventuelně je nějaký způsob jak řádně debugovat toto chování? Standardní konzole v Chrome nic zásadního nevypíše.“ Nejlepší bude začít analýzou síťové komunikace Chrome se serverem po odeslání formuláře ve vývojářských nástrojích. Případně bude dobrý odkaz na živou ukázku systému, klidně kopii nad testovací databází s dočasnými přístupovými údaji. |
||
|
Časová prodleva: 10 let
|
|||
0