[dannelito]

Blir även strul med phpLD hos City Network märkte jag precis.

_SERVER["SCRIPT_NAME"] (och _SERVER["PHP_SELF"]) är satt till /~100xxx/domän.se/public_html/filnamn.php istället för /filnamn.php som är brukligt. Detta resulterar i knepiga URLer då phpLD använder sig av _SERVER["SCRIPT_NAME"].

[Crystal]

UnikGrafik lyckades du få till det eller fortfarande strul ?


Mvh

[johan1234]

Jag pushar lite extra. Vet att de inte vill hitta en enkel fix som försvinner vid nästa uppdatering som vi sa. Återkommer denna vecka med besked... :-)

[johan1234]

En liten update. Problemet är följande och lösningen finns på länken nedan. Vi kommer titta vidare på hur vi kan hålla hög säkerhetsnivå och ändå tillåta lite kodning som inte följer standarder hela vägen. Onekligen så att vi alla vill ha hög säkerhet - men samtidigt inte krångla - så det är en balansgång. :-)

UnikGrafik - hoppas du med relativ enkelhet löser det med nedan som vi gjorde. Jag hoppas på ett blogginlägg om detta för att så tydligt som möjligt beskriva...

Lösning:

Efter lite googlande löste vi problemet genom att uppdatera en rad vardera i filerna admin/login.php och admin/init.php (ni ser hela artikeln om detta här: http://www.prestashop.com/forums/vie...n_redirect_bug).

Anledningen till denna problematik är att PrestaShop (och dessvärre andra tredjepartsprodukter också) har en felaktig förväntning på värdet i variabeln $_SERVER['PHP_SELF']. Att detta värde skiljer sig från andra miljöer beror på säkerhetsnivån i vår installation för att bland annat låta varje kund köra som en egen användare, etc.

[UnikGrafik]

FYI

Jepp, denna hårtkodad fullösning funkade och nu kan jag logga in på admin på både Prestashop version 1.3.5 och 1.4.6.

För de som har samma problem som jag, gör följande:

1. öppna init.php och login.php filer som ligger i din admin mappen (namnet varierar beroende på hur har du döpt om mappen till efter installationen)
2. gå till raden som sätter variabeln "$cookie"
$cookie = new Cookie('psAdmin', substr($_SERVER['SCRIPT_NAME'], strlen(__PS_BASE_U....
3. hårdkoda pathen till admin mappen. tex
$cookie = new Cookie('psAdmin', "namn-på-din-admin-mapp-som-du-har-döpt-om-efter-installationen");
Detta skall du göra i BÅDA filerna
4. ladda upp filerna igen och testa logga in

Felmeddelande om att path är inte samma kommer visas upp fortfarande MEN denna gången kan du nu logga in på admin panelen i Prestashop.

Johan på City Network lovade att de kollar upp detta och försöker fixa felet centralt så att man slipper skriva om core filerna i Prestashop för att få de funka på deras webbhotell.

Jag vill passa på nämna att Johan på CN har verkligen visar hur kundservice skall skötas på ett webhotell. Trevligt, kundvänligt och effektivt. Tummen upp för CN!

[tartareandesire]

Det bör ju dock påpekas att City Network inte gjort något fel utan att det är PrestaShop som är dåligt kodat.

[Björklund]

Ursprungligen postat av tartareandesire

Det bör ju dock påpekas att City Network inte gjort något fel utan att det är PrestaShop som är dåligt kodat.

Men om inte _SERVER["PHP_SELF"] fungerar, då är det väl knappast kodarens (PrestaShop) fel?

[Dennis Holm]

Ursprungligen postat av Björklund

Men om inte _SERVER["PHP_SELF"] fungerar, då är det väl knappast kodarens (PrestaShop) fel?

problemet var inte att funktionen inte funkade.
Problemet var att prestashop jämförde 2 olika funktioner för att vara säker på att filen låg på rätt ställe...
Så förstod jag det iallafall.

[johan1234]

Unikgrafik - Tusen tack för de snälla orden. Förstår frustrationen när något inte funkar - speciellt i detta fallet. Tack för ditt tålamod.

Björklund - jag är långt ifrån expert - men enligt vår leverantör, våra egna experter samt ett par intagna konsulter så ger vårt system rätt svar. Dock är den lösningen som Prestashop använder inte helt ovanlig (rätt eller fel) - trots att den inte följer standard. Detta gör att vi ser om vi kan hålla standarden som den ska vara - men ändå fixa så förväntat svar ges i de fallen Prestas lösning används. Det har hög prio så vi får se om vi kan lösa inom den närmsta tiden.

[AndersN]

Detta är inte menat som någon kritik utan snarare en frågeställning.

Om ert system ger rätt svar så ger alla andra webbhotell jag använt (One, Binero 1.0 o 2.0, Surftown, Orderland, FS-Data, Webkonsulterna) inkl. ert gamla system fel svar på variabeln?

Jag säger inte att ni har fel, jag tycker bara det är underligt.

Någon som har en fix för att få tinyMCE och AjaxFilemanager att fungera under dessa inställningar?

/Anders